| Bug ID | 92961 |
|---|---|
| Summary | Xorg freezes (only mouse and ssh are still working) |
| Product | xorg |
| Version | unspecified |
| Hardware | x86-64 (AMD64) |
| OS | Linux (All) |
| Status | NEW |
| Severity | critical |
| Priority | high |
| Component | Driver/nouveau |
| Assignee | nouveau@lists.freedesktop.org |
| Reporter | nahoo82@gmail.com |
| QA Contact | xorg-team@lists.x.org |
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 >=20 > The desktop freezes consistently after a few minutes using the nouveau > driver. >=20 > Only the mouse can still be used. The system is still fully operation= al 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 fre= eze, like starting a browser,=20 > running some OpenGL application, or even some fancy compositor animati= on? 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 0x0080000= 0 most of the time preceaded by: > nouveau W[ PFIFO][0000:01:00.0] INTR 0x0100000= 0: 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 suppo= rt (on > gentoo, requiring the while QT+KDE stack to be built with gles2). >=20 > A very similar freeze occurs with enlightenment/wayland, so I assume i= t'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 m= oves 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 prod= uce 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=3D100= 4311
(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 befo= re 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 cur= rently > not an option, since it is currently bogus in my machine. "Random freezes" is not a single issue. Most likely the OP's issu= e 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 dr= iver. 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 attach= ed I search this file [gpfifogf100.c] on internet and I find this one patch: https://patchwork.k= ernel.org/patch/9502079/ I restore the previous value of ret with: "ret =3D -EBUSY;" in the gpfifogf100.c and gpfifogk104.c And the problem seam solved This is the fourth day of test without a freeze.
| What | Removed | Added |
|---|---|---|
| CC | deprisco.davide@gmail.com |
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=20
file:
drivers/gpu/drm/nouveau/nvkm/engine/fifo/gpfifogf100.c
...
if (nvkm_msec(device, 3000,
if (nvkm_rd32(device, 0x002634) =3D=3D chan->base.chid)
break;
...
| What | Removed | Added |
|---|---|---|
| CC | nsoudee@gmail.com |
Created [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 Comm=
ent
#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, th=
anks
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=C3=A9e from comment #19) > Created attachment 142692 [de= tails] [review] [review] > Handle INTR 0x00800000 in gf100_fifo_intr >=20 > Attached is a patch I applied to kernel 4.19.5 to desperately thwart m= y 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 er= ror > which pops up every time that catastrophic random event happens. >=20 > So far, my E6420 is working great despite receiving some of those INTR= s, > thanks to this patch. I am posting this in hopes it might be on the ri= ght > track towards getting this fixed by someone who knows what they're doi= ng... That's a little surprising. The existing logic will mask out further interr= upts 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 th= e read from 2140].
| What | Removed | Added |
|---|---|---|
| Status | NEW | RESOLVED |
| Resolution | --- | MOVED |
-- 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/iss= ues/235.