Created attachment 119677 [details] dmesg output from boot onwards The desktop freezes consistently after a few minutes using the nouveau driver. Only the mouse can still be used. The system is still fully operational and reachable via ssh.
Created attachment 119678 [details] X log as part of the sstem log redirected by GDM
I would start by blacklisting the NVIDIA driver, to prevent it from loading while Nouveau is being used as it may results in conflicts. (Just write a file named `whichever_name_you_want.conf` in `/etc/modprobe.d/`, and containing `blacklist nvidia`.) Regarding the second attachment, could you rather please attach Xorg0.log as found in `~/.local/share/xorg/`, or `~/.local/xorg/` or `/var/log/`? (From a run that froze, and please attach the corresponding dmesg, so that both the dmesg and the Xorg.log are from the same run.) (In reply to ruben from comment #0) > The desktop freezes consistently after a few minutes using the nouveau > driver. Have you noticed anything that may cause the freeze, like starting a browser, running some OpenGL application, or even some fancy compositor animation?
(In reply to ruben from comment #0) > Created attachment 119677 [details] > dmesg output from boot onwards > > The desktop freezes consistently after a few minutes using the nouveau > driver. > > Only the mouse can still be used. The system is still fully operational and > reachable via ssh. I have the same behaviour on a Latitude e6420 with NVIDIA Corporation GF119M [NVS 4200M] GPU. > Have you noticed anything that may cause the freeze, like starting a browser, > running some OpenGL application, or even some fancy compositor animation? No. The crashes happen at random intervals. Most of the time there isn't any intensive application opened when it happens. Regarding the compositor, in my case, the freeze happens even if there isn't any actively used. The software versions I'm using are: xf86-video-nouveau 1.0.11+31+g1ff13a9 mesa 11.0.6 xorg-server 1.18.0 plasma-workspace 5.4.95 (happened with a stable version as well 5.4.3) If you connect via ssh, you can see on the dmesg can be seen the following error: > nouveau E[ PFIFO][0000:01:00.0] INTR 0x00800000 most of the time preceaded by: > nouveau W[ PFIFO][0000:01:00.0] INTR 0x01000000: 0x00000005 Also the full trace of this failure can be observed on the Xorg log. I've attached all logs on the raported 'Bug 71659'.
I experience the same issue. I have noticed that it only occurs if plasma is built with gles2 support (on gentoo, requiring the while QT+KDE stack to be built with gles2). A very similar freeze occurs with enlightenment/wayland, so I assume it's a bug in nouveau.
(In reply to Yoram from comment #4) > I experience the same issue. > I have noticed that it only occurs if plasma is built with gles2 support (on > gentoo, requiring the while QT+KDE stack to be built with gles2). > > A very similar freeze occurs with enlightenment/wayland, so I assume it's a > bug in nouveau. Thanks for the info! To maintain my DE, for the time being, I've switched on KDE/Openbox. Things seem to work great for now.
(In reply to Pierre Moreau from comment #2) > I would start by blacklisting the NVIDIA driver, to prevent it from loading > while Nouveau is being used as it may results in conflicts. (Just write a > file named `whichever_name_you_want.conf` in `/etc/modprobe.d/`, and > containing `blacklist nvidia`.) The system was already like this, but it still crashes. > Regarding the second attachment, could you rather please attach Xorg0.log as > found in `~/.local/share/xorg/`, or `~/.local/xorg/` or `/var/log/`? (From a > run that froze, and please attach the corresponding dmesg, so that both the > dmesg and the Xorg.log are from the same run.) I am seldom at this computer at the moment, but if it crashes again I will do that. Still the attachements before should provide the same information. Should they not? > (In reply to ruben from comment #0) > > The desktop freezes consistently after a few minutes using the nouveau > > driver. > > Have you noticed anything that may cause the freeze, like starting a > browser, running some OpenGL application, or even some fancy compositor > animation? No, nothing special. May even happend when I am practically leaving the computer untouched. In case it helps, I am using GNOME 3.
Recently I had to switch to nouveau due to a problem with the official nvidia drivers, and I have been experiencing ramdom gui freezes. The mouse still moves on the screen, but I cannot interact with the gui. The nvidia modules are NOT installed in the system. I usually can connect via ssh and reboot the machine. The freeze happens at random times, there is no particular sequence to produce it. I use KDE on opensuse 42.1. lspci is: 01:00.0 VGA compatible controller: NVIDIA Corporation GF108 [GeForce GT 730] (rev a1) I will attach the pertinent kernel logs.
Created attachment 127379 [details] Kernel log 1
Created attachment 127380 [details] Kernel log 2
Created attachment 127381 [details] Kernel log 3
Previously reported here: https://bugzilla.suse.com/show_bug.cgi?id=1004311
(In reply to Marcelo Jimenez from comment #7) > The freeze happens at random times, there is no particular sequence to > produce it. I use KDE on opensuse 42.1. A number of users have been experiencing issues with KDE across a variety of hardware with nouveau. My current advice is to either not use KDE or not use nouveau_dri.so. [It's most likely not KDE's fault, but this is the present reality.] Separately, OpenSuSE included some patches of mine in their Mesa builds that address some but hardly all of the issues involved. I believe the approach to be fundamentally flawed and in need of redoing. (The latest may be that they have dropped those.)
Well, since the problem also happens on gnome 3 (a report before mine), would you have any pointer for me on how do I disable the use of nouveau_dri.so? Notice that using the proprietary nvidia driver is currently not an option, since it is currently bogus in my machine.
(In reply to Marcelo Jimenez from comment #13) > Well, since the problem also happens on gnome 3 (a report before mine), > would you have any pointer for me on how do I disable the use of > nouveau_dri.so? Notice that using the proprietary nvidia driver is currently > not an option, since it is currently bogus in my machine. "Random freezes" is not a single issue. Most likely the OP's issue is wholly unrelated to yours. locate nouveau_dri.so, and remove it.
Created attachment 137309 [details] shutdown log when the system was freezed
I have the same problem with Gnome 3 on Gentoo with nouveau driver. The freezes is randomly and with web browser, mail client and so on. When I shutdown the system for a reboot I can see the message that I attached I search this file [gpfifogf100.c] on internet and I find this one patch: https://patchwork.kernel.org/patch/9502079/ I restore the previous value of ret with: "ret = -EBUSY;" in the gpfifogf100.c and gpfifogk104.c And the problem seam solved This is the fourth day of test without a freeze.
Created attachment 137310 [details] [review] reset variable ret for return EBUSY in gpfifogf100.c and gpfifogk104.c Patch for testing stability after freeze nouveau driver
It freezes again :-( I try to set the waiting timer from 2 to 3 seconds but the system freeze randomly file: drivers/gpu/drm/nouveau/nvkm/engine/fifo/gpfifogf100.c ... if (nvkm_msec(device, 3000, if (nvkm_rd32(device, 0x002634) == chan->base.chid) break; ...
Created attachment 142692 [details] [review] Handle INTR 0x00800000 in gf100_fifo_intr Attached is a patch I applied to kernel 4.19.5 to desperately thwart my DELL E6420 from randomly getting its video busted (very similar symptons as Comment #3 of this ticket, and is why I'm posting here). I don't have any experience with such low-level programming but I just pretended I knew what I was doing and cut and pasted a condition for that INTR 0x00800000 error which pops up every time that catastrophic random event happens. So far, my E6420 is working great despite receiving some of those INTRs, thanks to this patch. I am posting this in hopes it might be on the right track towards getting this fixed by someone who knows what they're doing...
(In reply to Nic Soudée from comment #19) > Created attachment 142692 [details] [review] [review] > Handle INTR 0x00800000 in gf100_fifo_intr > > Attached is a patch I applied to kernel 4.19.5 to desperately thwart my DELL > E6420 from randomly getting its video busted (very similar symptons as > Comment #3 of this ticket, and is why I'm posting here). I don't have any > experience with such low-level programming but I just pretended I knew what > I was doing and cut and pasted a condition for that INTR 0x00800000 error > which pops up every time that catastrophic random event happens. > > So far, my E6420 is working great despite receiving some of those INTRs, > thanks to this patch. I am posting this in hopes it might be on the right > track towards getting this fixed by someone who knows what they're doing... That's a little surprising. The existing logic will mask out further interrupts by writing a 0 into the relevant bit of 2140 (which is the INTR_EN register, which controls which intr's get surfaced). Your logic removes that, which means that you'll keep getting the unknown intr's, and also you add a read from 258c. That's unlikely to matter though. However now if we *do* ever get an interrupt for that bit in 2100 after disabling the bit in 2140, then it'll be stuck forever. I suspect that the "& mask" should be removed at the beginning of that function [and thus the read from 2140].
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/driver/xf86-video-nouveau/issues/235.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.