Description of problem: This seems kind of weird, but I can reliably trigger a hang of the GUI on my system by running geeqie and right-clicking on the file list. The context menu comes up, but the mouse and keyboard immediately become nonresponsive. I can ssh in and reboot, though. Version-Release number of selected component (if applicable): xorg-x11-drv-nouveau-1.0.11-2.fc22.x86_64 How reproducible: Seems to be always. Steps to Reproduce: 1. run geeqie in a directory with a number of jpg files 2. right click on one of those files in the list 3. boom Actual results: mouse and keyboard freeze Expected results: not that. Additional info: system log is full of lines like: Apr 24 21:26:22 system.example.org kernel: nouveau E[ PFIFO][0000:01:00.0] PBDMA0: ch 1 [DRM] subc 0 mthd 0x001c data 0x00001004 Apr 24 21:26:22 system.example.org systemd-journal[477]: Missed 16 kernel messages Apr 24 21:26:22 system.example.org kernel: nouveau E[ PFIFO][0000:01:00.0] PBDMA0: ch 1 [DRM] subc 0 mthd 0x001c data 0x00001004 Apr 24 21:26:22 system.example.org systemd-journal[477]: Missed 16 kernel messages Apr 24 21:26:22 system.example.org kernel: nouveau E[ PFIFO][0000:01:00.0] PBDMA0: ch 1 [DRM] subc 0 mthd 0x001c data 0x00001004 Apr 24 21:26:22 system.example.org systemd-journal[477]: Missed 19 kernel messages Apr 24 21:26:22 system.example.org kernel: nouveau E[ PFIFO][0000:01:00.0] PBDMA0: ACQUIRE And by "full", I mean about 7.6 million lines of that in a few minutes -- so much that it seems to have wiped out previous log information by sheer volume, triggering systemd's log rotation.
This is a Thinkpad W530, and the boot log says Chipset: GK107 (NVE7)
I should also add that this is a regression -- no problem in F21.
Created attachment 1018842 [details] system log from crash Recreated again and got a possibly more helpful log, including some kind of numeric dump.
Also of note: running under Gnome shell.
I can reproduce this to at least some extent on my 9600 GT (10DE:0622). The first time I tried, on a regular boot, it happened right away, and stayed frozen for some time, and I rebooted remotely via ssh. Then I booted with 'drm.debug=14', and at first I couldn't reproduce it - but after several tries, I did hit a *temporary* freeze. After some seconds, though - 15-30 - the system started responding again. I'll attach logs from both boots.
Created attachment 1019408 [details] drm.debug=14 log of a reproduction which led to a temporary (15-30 second) freeze
Created attachment 1019409 [details] trimmed log of first attempt to reproduce (without drm.debug=14)
Note, it would probably be a good idea to report this to upstream (bugs.freedesktop.org), as more devs will see it there.
Thanks Adam! https://bugs.freedesktop.org/show_bug.cgi?id=90201
This appears to be related to a regression in libdrm. See https://bugs.freedesktop.org/show_bug.cgi?id=89842
http://cgit.freedesktop.org/mesa/drm/commit/?id=812e8fe6ce46d733c30207ee26c788c61f546294 is intended to fix this, I'll backport it to Rawhide and F22 (seems like a good idea to get this fixed).
(In reply to Adam Williamson from comment #11) > http://cgit.freedesktop.org/mesa/drm/commit/ > ?id=812e8fe6ce46d733c30207ee26c788c61f546294 is intended to fix this, I'll > backport it to Rawhide and F22 (seems like a good idea to get this fixed). I plan on trying to get a libdrm 2.4.61 released today, and into Fedora.
oh cool, in that case I'll skip the backport :) there's 6 days till F22 freeze so it should be fine (and we can propose a freeze exception if needed).
I did test the backport as a scratch build and it seems to fix the problem, I couldn't reproduce it with the geeqie reproducer.
libdrm-2.4.61-3.fc22 has been submitted as an update for Fedora 22. https://admin.fedoraproject.org/updates/libdrm-2.4.61-3.fc22
libdrm-2.4.61-3.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.
The problems still persist. I'm running in to this same problem with Fedora 22 even though I have updated libdrm to version libdrm-2.4.61-3.fc22.