Created attachment 115775 [details] output of `dmesg` Since switching to Nouveau, a couple of hours after booting my system, the display will freeze up. I can still move the mouse, and I can still hear the sound of any media-player or YouTube still running. Sometimes, I can still go to another terminal with Ctrl-Alt-F2, sometimes not. One time when I could, I restarted X and it would just work again. (Additionally, the frame rate seems a bit 'stuttery' compared to the binary NVidia drivers, especially when moving windows around and such. That may or may not be a separate issue.) There are a bunch of nvidia errors in my dmesg output that I do not understand. I attached this output. I'd be happy to provide any extra info you need, but would also much appreciate any workaround I could use.
Created attachment 115776 [details] output of `lspci -vnn | grep VGA -A 17`
Created attachment 115777 [details] output of `glxinfo | grep OpenGL ` I added some attachments with relevant info about my system.
Another user bisected a similar issue to a change that came into 3.16. Can you try 3.15 and see if that works better for you?
Created attachment 115779 [details] packages I downgraded from v3.16.x
(In reply to Ilia Mirkin from comment #3) > Another user bisected a similar issue to a change that came into 3.16. Can > you try 3.15 and see if that works better for you? I assume you're referring to GTK/Gnome. OK. I downgraded all gnome-related packages I could find that had a 3.16-ish version. For almost all of them, I downgraded to a 3.14 version, as a 3.15 version didn't exist (using Pacman on Arch). I attached a list of packages I downgraded. Anyway, those nouveau errors have disappeared from dmesg! Whether the display will no longer freeze remains to be seen, but I'm hopeful. Thanks! Which bug report should I follow to know when it's safe to upgrade again? (PS: Another problem, which I first assumed to be related, is not yet solved. When I enter my login data in GDM, I do not login, but GDM just re-appears. I can only get into Gnome using startx.)
(In reply to Michiel Helvensteijn from comment #5) > (In reply to Ilia Mirkin from comment #3) > > Another user bisected a similar issue to a change that came into 3.16. Can > > you try 3.15 and see if that works better for you? > > I assume you're referring to GTK/Gnome. OK. I downgraded all gnome-related > packages I could find that had a 3.16-ish version. For almost all of them, I > downgraded to a 3.14 version, as a 3.15 version didn't exist (using Pacman > on Arch). I attached a list of packages I downgraded. Sorry for the confusion. I meant kernel. > > Anyway, those nouveau errors have disappeared from dmesg! Whether the > display will no longer freeze remains to be seen, but I'm hopeful. Thanks! > > Which bug report should I follow to know when it's safe to upgrade again? That's actually a bit surprising. Means that the DE is part of what's tickling the nouveau bug. > > (PS: Another problem, which I first assumed to be related, is not yet > solved. When I enter my login data in GDM, I do not login, but GDM just > re-appears. I can only get into Gnome using startx.) You'll have to figure out what's going wrong in your stack. Presumably file a bug with the gdm people?
FTR, the other bug is bug 90276.
(In reply to Ilia Mirkin from comment #6) > > > Another user bisected a similar issue to a change that came into 3.16. Can > > > you try 3.15 and see if that works better for you? > > > > I assume you're referring to GTK/Gnome. > > Sorry for the confusion. I meant kernel. That was my first guess, but 3.16 was already a while ago for me, and I'm currently running 4.0.2. On the other hand, the latest version of GTK and friends actually is 3.16, so... Funny coincidence. > > Anyway, those nouveau errors have disappeared from dmesg! Whether the > > display will no longer freeze remains to be seen, but I'm hopeful. Thanks! > > > > Which bug report should I follow to know when it's safe to upgrade again? > > That's actually a bit surprising. Means that the DE is part of what's > tickling the nouveau bug. Well, let me know if I can provide you with any further info. DE or not, this still manifests as a nouveau bug. > You'll have to figure out what's going wrong in your stack. Presumably file > a bug with the gdm people? Yeah, my system's a hot mess right now. Thanks.
OK, so... The dmesg errors are gone, but the display still freezes up. Yeah, it seems they were two independent problems. In the absence of PDISP errors, do you still suggest I downgrade the kernel to 3.15?
I was finally able to connect to my pc *after* a freeze-up using SSH. Here is the coinciding dmesg output: [ 8970.897260] nouveau E[ PFIFO][0000:01:00.0] SCHED_ERROR [ CTXSW_TIMEOUT ] [ 8970.897265] nouveau E[ PFIFO][0000:01:00.0] PGR engine fault on channel 6, recovering...
(In reply to Michiel Helvensteijn from comment #10) > I was finally able to connect to my pc *after* a freeze-up using SSH. Here > is the coinciding dmesg output: > > [ 8970.897260] nouveau E[ PFIFO][0000:01:00.0] SCHED_ERROR [ CTXSW_TIMEOUT > ] > [ 8970.897265] nouveau E[ PFIFO][0000:01:00.0] PGR engine fault on channel > 6, recovering... Hrmph... could well have been fixed by one of the ctxsw changes since 3.15 :( Sorry, this will require someone who knows what they're talking about (i.e. not me) to properly diagnose.
(In reply to Ilia Mirkin from comment #11) > > I was finally able to connect to my pc *after* a freeze-up using SSH. Here > > is the coinciding dmesg output: > > > > [ 8970.897260] nouveau E[ PFIFO][0000:01:00.0] SCHED_ERROR [ CTXSW_TIMEOUT] > > [ 8970.897265] nouveau E[ PFIFO][0000:01:00.0] PGR engine fault on channel > > 6, recovering... > > Hrmph... could well have been fixed by one of the ctxsw changes since 3.15 :( > > Sorry, this will require someone who knows what they're talking about (i.e. > not me) to properly diagnose. Then I hope someone like that will come along. This problem is really quite frustrating. :-) Thanks for your help Ilia!
During the freeze-up just now, dmesg gave me this beauty: [ 9126.410442] nouveau E[ PGRAPH][0000:01:00.0] TRAP ch 8 [0x007f2f2000 gnome-shell[1419]] [ 9126.410451] nouveau E[ PGRAPH][0000:01:00.0] GPC1/PROP trap: (unknown enum 0x00000002) [ 9126.410454] nouveau E[ PGRAPH][0000:01:00.0] x = 4560, y = 160, format = 0, storage type = 0 [ 9126.410461] nouveau E[ PGRAPH][0000:01:00.0] GPC2/PROP trap: (unknown enum 0x00000002) [ 9126.410462] nouveau E[ PGRAPH][0000:01:00.0] x = 4576, y = 152, format = 0, storage type = 0 [ 9130.744302] nouveau E[ PFIFO][0000:01:00.0] SCHED_ERROR [ CTXSW_TIMEOUT ] [ 9130.744306] nouveau E[ PFIFO][0000:01:00.0] PGRAPH engine fault on channel 9, recovering... [ 9145.526131] Peer 84.104.35.99:51165/34567 unexpectedly shrunk window 2380020382:2380048967 (repaired) [ 9146.092788] Peer 84.104.35.99:51165/34567 unexpectedly shrunk window 2380020382:2380048967 (repaired) [ 9147.229435] Peer 84.104.35.99:51165/34567 unexpectedly shrunk window 2380020382:2380048967 (repaired) [ 9164.935810] Peer 84.104.35.99:51165/34567 unexpectedly shrunk window 2380247127:2380249895 (repaired) [ 9165.382470] Peer 84.104.35.99:51165/34567 unexpectedly shrunk window 2380247127:2380249895 (repaired) [ 9172.099024] nouveau E[systemd-logind[431]] failed to idle channel 0xcccc0000 [systemd-logind[431]] [ 9187.098777] nouveau E[systemd-logind[431]] failed to idle channel 0xcccc0000 [systemd-logind[431]] [ 9187.098878] nouveau E[ PFIFO][0000:01:00.0] read fault at 0x0000023000 [PTE] from PBDMA0/HOST_CPU on channel 0x007f541000 [unknown] [ 9202.351857] nouveau E[gnome-shell[1419]] failed to idle channel 0xcccc0000 [gnome-shell[1419]] [ 9217.351609] nouveau E[gnome-shell[1419]] failed to idle channel 0xcccc0000 [gnome-shell[1419]] [ 9232.351361] nouveau E[chromium[2607]] failed to idle channel 0xcccc0000 [chromium[2607]] [ 9247.351111] nouveau E[chromium[2607]] failed to idle channel 0xcccc0000 [chromium[2607]] In case it makes a difference, this is after I tried installing the binary nvidia drivers again, failing, and going back to nouveau. This is also with all the latest gtk / gnome versions installed again (so the above errors follow the long string of PDISP errors in the dmesg output).
Oh, and by the way, this time my mouse cursor could *not* move like it could the other times, and eventually the display went back to GDM, but without responding to any input. (I'm a bit desperate here. A virtual beer to whomever can help me out with this!)
BTW, as per my suggestion in https://bugs.freedesktop.org/show_bug.cgi?id=90276#c11 you can likely "fix" the PDISP errors by changing drivers/gpu/drm/nouveau/nv50_display.c: - if (show && nv_crtc->cursor.nvbo) + if (show && nv_crtc->base.enabled && nv_crtc->cursor.nvbo) However that didn't fix the underlying issues for the other user, and it is likely not to help your hang either, I'm afraid. But perhaps worth a shot?
(In reply to Ilia Mirkin from comment #15) > BTW, as per my suggestion in > https://bugs.freedesktop.org/show_bug.cgi?id=90276#c11 you can likely "fix" > the PDISP errors by changing drivers/gpu/drm/nouveau/nv50_display.c: > > - if (show && nv_crtc->cursor.nvbo) > + if (show && nv_crtc->base.enabled && nv_crtc->cursor.nvbo) > > However that didn't fix the underlying issues for the other user, and it is > likely not to help your hang either, I'm afraid. But perhaps worth a shot? Indeed, the PDISP errors are gone. May I assume that this fix will make it into the official kernel in the near future? In the meantime, I'll keep my expectations low w.r.t. my hang. ;-)
Indeed, problem not solved. Here's a new set of errors produced during a freeze: [ 690.870744] nouveau E[ PGR][0000:01:00.0] TRAP ch 8 [0x007f2f2000 gnome-shell[2652]] [ 690.870754] nouveau E[ PGR][0000:01:00.0] GPC1/PROP trap: ZETA_STORAGE_TYPE_MISMATCH [ 690.870756] nouveau E[ PGR][0000:01:00.0] x = 1232, y = 56, format = 0, storage type = fe [ 690.870763] nouveau E[ PGR][0000:01:00.0] GPC2/PROP trap: ZETA_STORAGE_TYPE_MISMATCH [ 690.870765] nouveau E[ PGR][0000:01:00.0] x = 1056, y = 328, format = 0, storage type = fe [ 695.179294] nouveau E[ PFIFO][0000:01:00.0] SCHED_ERROR [ CTXSW_TIMEOUT ] [ 695.179298] nouveau E[ PFIFO][0000:01:00.0] PGR engine fault on channel 10, recovering... This one happened earlier than usual.
This latest instance is also interesting, and might help diagnose the problem. I was watching a YouTube video, and this time only the Chromium browser froze, and I got a 'page unresponsive' popup. For a while, I could still move the mouse and interact with other windows. After about 30 seconds, everything froze once again. dmesg output: [ 7583.945899] nouveau E[ PGR][0000:01:00.0] TRAP ch 8 [0x007f2f2000 gnome-shell[1189]] [ 7583.945909] nouveau E[ PGR][0000:01:00.0] GPC2/PROP trap: (unknown enum 0x00000002) [ 7583.945912] nouveau E[ PGR][0000:01:00.0] x = 3488, y = 104, format = 0, storage type = 0 [ 7588.249980] nouveau E[ PFIFO][0000:01:00.0] SCHED_ERROR [ CTXSW_TIMEOUT ] [ 7588.249985] nouveau E[ PFIFO][0000:01:00.0] PGR engine fault on channel 10, recovering...
Created attachment 115828 [details] long term dmesg output I left my pc on for a while after the last freeze-up, and after about 45 minutes, more stuff came pouring down dmesg. I don't know if this information is useful at all. I just thought I'd share it in case.
It seems gnome-shell triggers some bug in our OpenGL driver, which causes the hardware to raise errors (GPC1/PROP traps), which kernel fails to ack/cleanup and eventually this leads to context switching failure. If we'll fix the OpenGL driver, the other bugs won't matter (and they are much harder to fix). So the first step is figuring out how to reproduce this bug in a matter of minutes and generating an apitrace and/or mmt trace.
(In reply to Marcin Slusarz from comment #20) > If we'll fix the OpenGL driver, the other bugs won't matter (and they are > much harder to fix). So the first step is figuring out how to reproduce this > bug in a matter of minutes and generating an apitrace and/or mmt trace. In order to get some work done, I switched back to the binary nvidia drivers for now. If you have an actual plan of attack, I'll happily switch back to try it out.
I originally added my problem to bug 89912, as my original error message was not seen here. kernel: nouveau E[ PFIFO][0000:01:00.0] write fault at 0x00002a0000 [PTE] from GR/GPC0/PROP_0 on channel 0x007f96c000 [Xorg[383]] kernel: nouveau E[ PFIFO][0000:01:00.0] PGR engine fault on channel 2, recovering... However, after also getting the following: kernel: nouveau E[ PFIFO][0000:01:00.0] SCHED_ERROR [ CTXSW_TIMEOUT ] kernel: nouveau E[ PFIFO][0000:01:00.0] PGR engine fault on channel 10, recovering... I am inclined to thing the bugs are duplicates. Now, while playing a game (which actually played fine yesterday) I have had two consecutive freezes with the message: kernel: nouveau E[ DRM] GPU lockup - switching to software fbcon I, too, will be switching to the nvidia driver for the moment, however I will be happy to assist with any fix tests.
Same issue over here, it is a NVE4 too. I will be using the proprietary driver from now on until I know better how to help diagnose this. [ 7104.402763] nouveau E[ PFIFO][0000:01:00.0] SCHED_ERROR [ CTXSW_TIMEOUT ] [ 7104.402770] nouveau E[ PFIFO][0000:01:00.0] PGRAPH engine fault on channel 7, recovering... ...and video freezes forever.
(In reply to Mario Barrera from comment #23) > Same issue over here, it is a NVE4 too. I will be using the proprietary > driver from now on until I know better how to help diagnose this. > > [ 7104.402763] nouveau E[ PFIFO][0000:01:00.0] SCHED_ERROR [ CTXSW_TIMEOUT > ] > [ 7104.402770] nouveau E[ PFIFO][0000:01:00.0] PGRAPH engine fault on > channel 7, recovering... > > ...and video freezes forever. Unfortunately I'm seeing the same problem. I have been able to reproduce it very consistently under two circumstances: 1.) Starting a new X11 session when one is already running (using TDM, a fork of the older KDE 3.5 KDM) 2.) Trying to select an OpenGL screensaver. If you go through the list of OpenGL screensavers, occasionally selecting one for full-screen preview, the GPU will hang after going through no more than around a dozen savers. Reclocking status does not matter; fault occurs on both low and high clocks. Kernel 4.1: [ 914.928160] nouveau E[ PFIFO][0000:01:00.0] read fault at 0x0000490000 [PTE] from GR/SCC on channel 0x00fec92000 [matrixview[27252]] [ 914.928169] nouveau E[ PFIFO][0000:01:00.0] PGRAPH engine fault on channel 7, recovering.. Going back to the proprietary drivers is not an option here due to a serious bug in those drivers, so if there's anything I can do to help diagnose this issue please let me know. Thanks!
Hi I also have this bug (screen freeze and mouse still usable) on a my system using a nvidia 660ti [NVE4]: dmesg gives [ 112.780941] nouveau E[ PFIFO][0000:03:00.0] SCHED_ERROR [ CTXSW_TIMEOUT ] [ 112.780947] nouveau E[ PFIFO][0000:03:00.0] PGRAPH engine fault on channel 8, recovering... or [ 294.274092] nouveau E[ PFIFO][0000:03:00.0] write fault at 0x000a002000 [PTE] from GR/GPC0/PROP_0 on channel 0x007f6ab000 [systemd-logind[426]] [ 294.274103] nouveau E[ PFIFO][0000:03:00.0] PGRAPH engine fault on channel 5, recovering... I might be the same bug as I reported earlier https://bugs.freedesktop.org/show_bug.cgi?id=90276
Now on kernel 4.6 I experienced 0 freezes so far. Something improved on the 660ti NVE4 side.
Seeing something very similar on my GTX 650. Most common trigger is `xscreensaver`, but since I have set to randomly pick one, unsure whether there is a pattern. It also tends to trigger on full-screen video (display is 2560x1440 Dell 2713HM). I'm using Fedora 25, and apparently Wayland: $ echo $WAYLAND_DISPLAY wayland-0 Let me know if I can provide any more information. Thanks! Linux version: `uname -a` Linux hum 4.9.5-200.fc25.x86_64 #1 SMP Fri Jan 20 12:24:16 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux Kernel log: -- at boot: Jan 28 18:24:03 hum kernel: fb: switching to nouveaufb from EFI VGA Jan 28 18:24:03 hum kernel: Console: switching to colour dummy device 80x25 Jan 28 18:24:03 hum kernel: nouveau 0000:01:00.0: NVIDIA GK107 (0e7060a2) Jan 28 18:24:03 hum kernel: nouveau 0000:01:00.0: bios: version 80.07.35.00.04 Jan 28 18:24:03 hum kernel: nouveau 0000:01:00.0: fb: 1024 MiB GDDR5 Jan 28 18:24:03 hum kernel: [TTM] Zone kernel: Available graphics memory: 8191232 kiB Jan 28 18:24:03 hum kernel: [TTM] Zone dma32: Available graphics memory: 2097152 kiB Jan 28 18:24:03 hum kernel: [TTM] Initializing pool allocator Jan 28 18:24:03 hum kernel: [TTM] Initializing DMA pool allocator Jan 28 18:24:03 hum kernel: nouveau 0000:01:00.0: DRM: VRAM: 1024 MiB Jan 28 18:24:03 hum kernel: nouveau 0000:01:00.0: DRM: GART: 1048576 MiB Jan 28 18:24:03 hum kernel: nouveau 0000:01:00.0: DRM: TMDS table version 2.0 Jan 28 18:24:03 hum kernel: nouveau 0000:01:00.0: DRM: DCB version 4.0 Jan 28 18:24:03 hum kernel: nouveau 0000:01:00.0: DRM: DCB outp 00: 01000f02 00020030 Jan 28 18:24:03 hum kernel: nouveau 0000:01:00.0: DRM: DCB outp 01: 02000f00 00000000 Jan 28 18:24:03 hum kernel: nouveau 0000:01:00.0: DRM: DCB outp 02: 08011f82 00020030 Jan 28 18:24:03 hum kernel: nouveau 0000:01:00.0: DRM: DCB outp 03: 02022f62 00020010 Jan 28 18:24:03 hum kernel: nouveau 0000:01:00.0: DRM: DCB conn 00: 00001030 Jan 28 18:24:03 hum kernel: nouveau 0000:01:00.0: DRM: DCB conn 01: 00002131 Jan 28 18:24:03 hum kernel: nouveau 0000:01:00.0: DRM: DCB conn 02: 00010263 Jan 28 18:24:03 hum kernel: [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). Jan 28 18:24:03 hum kernel: [drm] Driver supports precise vblank timestamp query. Jan 28 18:24:04 hum kernel: nouveau 0000:01:00.0: DRM: MM: using COPY for buffer copies Jan 28 18:24:04 hum kernel: nouveau 0000:01:00.0: DRM: allocated 2560x1440 fb: 0x60000, bo ffff95135afd4000 Jan 28 18:24:04 hum kernel: fbcon: nouveaufb (fb0) is primary device Jan 28 18:24:04 hum kernel: nouveau 0000:01:00.0: fb0: nouveaufb frame buffer device Jan 28 18:24:04 hum kernel: [drm] Initialized nouveau 1.3.1 20120801 for 0000:01:00.0 on minor 0 -- when it locked up: Jan 29 13:05:45 hum kernel: nouveau 0000:01:00.0: fifo: SCHED_ERROR 06 [] Jan 29 13:05:45 hum kernel: nouveau 0000:01:00.0: fifo: CHSW_ERROR 00000002 Jan 29 13:05:48 hum kernel: nouveau 0000:01:00.0: fifo: SCHED_ERROR 06 [] Jan 29 13:05:48 hum kernel: nouveau 0000:01:00.0: fifo: CHSW_ERROR 00000002 Jan 29 13:05:49 hum kernel: nouveau 0000:01:00.0: fifo: SCHED_ERROR 06 [] Jan 29 13:05:49 hum kernel: nouveau 0000:01:00.0: fifo: CHSW_ERROR 00000002 Jan 29 13:10:13 hum kernel: nouveau 0000:01:00.0: fifo: SCHED_ERROR 06 [] Jan 29 13:10:13 hum kernel: nouveau 0000:01:00.0: fifo: CHSW_ERROR 00000002 Jan 29 13:11:55 hum kernel: nouveau 0000:01:00.0: fifo: SCHED_ERROR 08 [] Jan 29 13:11:55 hum kernel: nouveau 0000:01:00.0: fifo: SCHED_ERROR 08 [] Jan 29 13:12:29 hum kernel: nouveau 0000:01:00.0: fifo: SCHED_ERROR 08 [] Jan 29 13:13:27 hum kernel: nouveau 0000:01:00.0: fifo: SCHED_ERROR 08 [] Jan 29 13:13:27 hum kernel: nouveau 0000:01:00.0: fifo: CHSW_ERROR 00000004 Jan 29 13:16:12 hum kernel: nouveau 0000:01:00.0: fifo: CHSW_ERROR 00000004 Jan 29 13:16:13 hum kernel: nouveau 0000:01:00.0: fifo: SCHED_ERROR 08 [] Jan 29 13:16:13 hum kernel: nouveau 0000:01:00.0: fifo: CHSW_ERROR 00000004 Jan 29 13:16:39 hum kernel: nouveau 0000:01:00.0: fifo: CHSW_ERROR 00000002 Jan 29 13:16:39 hum kernel: nouveau 0000:01:00.0: fifo: FB_FLUSH_TIMEOUT Jan 29 13:16:39 hum kernel: nouveau 0000:01:00.0: fifo: PBDMA0: 00000004 [MEMACK_EXTRA] ch 1 [003fe13000 DRM] subc 0 mthd 0020 data 00000000 Jan 29 13:16:39 hum kernel: nouveau 0000:01:00.0: fifo: CHSW_ERROR 00000002 Jan 29 13:16:39 hum kernel: nouveau 0000:01:00.0: fifo: CHSW_ERROR 00000002 Jan 29 13:16:39 hum kernel: nouveau 0000:01:00.0: fifo: CHSW_ERROR 00000002 [That repeats hundreds of times per second.] `sudo lspci -vnn`: 01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GK107 [GeForce GTX 650] [10de:0fc6] (rev a1) (prog-if 00 [VGA controller]) Subsystem: Device [196e:0973] Flags: bus master, fast devsel, latency 0, IRQ 44 Memory at f3000000 (32-bit, non-prefetchable) [size=16M] Memory at d0000000 (64-bit, prefetchable) [size=256M] Memory at e0000000 (64-bit, prefetchable) [size=32M] I/O ports at e000 [size=128] Expansion ROM at 000c0000 [disabled] [size=128K] Capabilities: [60] Power Management version 3 Capabilities: [68] MSI: Enable+ Count=1/1 Maskable- 64bit+ Capabilities: [78] Express Endpoint, MSI 00 Capabilities: [b4] Vendor Specific Information: Len=14 <?> Capabilities: [100] Virtual Channel Capabilities: [128] Power Budgeting <?> Capabilities: [600] Vendor Specific Information: ID=0001 Rev=1 Len=024 <?> Capabilities: [900] #19 Kernel driver in use: nouveau Kernel modules: nouveau Packages: Installed Packages abrt-addon-xorg.x86_64 2.9.0-1.fc25 @fedora xorg-x11-drv-ati.x86_64 7.7.1-1.20160928git3fc839ff.fc25 @fedora xorg-x11-drv-evdev.x86_64 2.10.5-1.fc25 @updates xorg-x11-drv-fbdev.x86_64 0.4.3-25.fc25 @fedora xorg-x11-drv-intel.x86_64 2.99.917-26.20160929.fc25 @fedora xorg-x11-drv-libinput.x86_64 0.23.0-2.fc25 @updates xorg-x11-drv-nouveau.x86_64 1:1.0.13-1.fc25 @fedora xorg-x11-drv-openchrome.x86_64 0.5.0-2.fc25 @fedora xorg-x11-drv-qxl.x86_64 0.1.4-10.20160929gite13d28ee.fc25 @fedora xorg-x11-drv-synaptics.x86_64 1.9.0-1.fc25 @updates xorg-x11-drv-vesa.x86_64 2.3.2-25.fc25 @fedora xorg-x11-drv-vmware.x86_64 13.2.1-1.fc25 @updates xorg-x11-drv-wacom.x86_64 0.34.0-1.fc25 @updates xorg-x11-font-utils.x86_64 1:7.5-32.fc25 @fedora xorg-x11-fonts-ISO8859-1-100dpi.noarch 7.5-16.fc24 @fedora xorg-x11-proto-devel.noarch 7.7-20.fc25 @fedora xorg-x11-resutils.x86_64 7.5-13.fc24 @fedora xorg-x11-server-Xorg.x86_64 1.19.1-2.fc25 @updates xorg-x11-server-Xwayland.x86_64 1.19.1-2.fc25 @updates xorg-x11-server-common.x86_64 1.19.1-2.fc25 @updates xorg-x11-server-utils.x86_64 7.7-20.fc25 @fedora xorg-x11-utils.x86_64 7.5-21.fc24 @fedora xorg-x11-xauth.x86_64 1:1.0.9-5.fc24 @fedora xorg-x11-xinit.x86_64 1.3.4-13.fc25 @updates xorg-x11-xkb-utils.x86_64 7.7-17.fc24 @fedora
I may have reported a duplicate/related bug here: https://bugs.freedesktop.org/show_bug.cgi?id=100567 I'm also running Fedora 25 with Wayland/Gnome3 and had this crash under both the 4.9 and 4.10 kernels using the nouveau drivers. I have an nVidia NVS 510 card with 3 monitors attached.
-- 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/189.
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.