Created attachment 706209 [details] syslog (/var/log/messages) Description of problem: gdm greeter dialog (choose user, enter password) does not appear at boot to multi-user graphical environment, and syslog contains complaint of kernel: [ 77.657180] nouveau E[ DRM] GPU lockup - switching to software fbcon Version-Release number of selected component (if applicable): kernel-PAE-3.9.0-0.rc1.git0.3.fc19.i686 libdrm-2.4.42-1.fc19.i686 gdm-3.7.90-3.fc19.i686 mesa-dri-drivers-9.1-0.4.fc19.i686 xorg-x11-drv-nouveau-1.0.6-5.fc19.i686 How reproducible: every time Steps to Reproduce: 1. boot to multi-user graphical environment 2. 3. Actual results: gdm greeter dialog (choose user, enter password) does not appear. Screen has dark gray background, day and time in white in center of top line, UI status icons at right of top line, tiny "Fedora" and logo at left of top line. Pointer tracks mouse, but there is no response to clicking. Switching to text console via <Ctrl><Alt><F2> does not work: the same graphical screen remains, but the pointer has disappeared. [Detailed diagnosis was performed via ssh from another machine.] syslog (/var/log/messages) has: Mar 6 10:04:41 localhost kernel: [ 41.174243] nouveau E[ PFIFO][0000:05:00.0] CACHE_ERROR - ch 1 [DRM] subc 0 mthd 0x0014 data 0x2001201 0 Mar 6 10:04:41 localhost kernel: [ 41.174263] nouveau E[ PFB][0000:05:00.0] trapped write at 0x0020014104 on channel 0x0001fca0 [unkno wn] PFIFO/PFIFO_READ/SEMAPHORE reason: NULL_DMAOBJ Mar 6 10:05:40 localhost kernel: [ 100.534876] nouveau E[ DRM] GPU lockup - switching to software fbcon Expected results: gdm greeter dialog displayed and working as usual; no complaints in syslog. Additional info:
$ lspci 00:00.0 Memory controller: NVIDIA Corporation CK804 Memory Controller (rev a3) 00:01.0 ISA bridge: NVIDIA Corporation CK804 ISA Bridge (rev a3) 00:01.1 SMBus: NVIDIA Corporation CK804 SMBus (rev a2) 00:02.0 USB controller: NVIDIA Corporation CK804 USB Controller (rev a2) 00:02.1 USB controller: NVIDIA Corporation CK804 USB Controller (rev a3) 00:04.0 Multimedia audio controller: NVIDIA Corporation CK804 AC'97 Audio Controller (rev a2) 00:06.0 IDE interface: NVIDIA Corporation CK804 IDE (rev f2) 00:07.0 IDE interface: NVIDIA Corporation CK804 Serial ATA Controller (rev f3) 00:09.0 PCI bridge: NVIDIA Corporation CK804 PCI Bridge (rev a2) 00:0a.0 Bridge: NVIDIA Corporation CK804 Ethernet Controller (rev a3) 00:0b.0 PCI bridge: NVIDIA Corporation CK804 PCIE Bridge (rev a3) 00:0c.0 PCI bridge: NVIDIA Corporation CK804 PCIE Bridge (rev a3) 00:0d.0 PCI bridge: NVIDIA Corporation CK804 PCIE Bridge (rev a3) 00:0e.0 PCI bridge: NVIDIA Corporation CK804 PCIE Bridge (rev a3) 00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration 00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map 00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller 00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control 01:07.0 Multimedia audio controller: C-Media Electronics Inc CMI8738/CMI8768 PCI Audio (rev 10) 01:09.0 Mass storage controller: Silicon Image, Inc. SiI 3512 [SATALink/SATARaid] Serial ATA Controller (rev 01) 05:00.0 VGA compatible controller: NVIDIA Corporation GT218 [GeForce 8400 GS] (rev a2) 05:00.1 Audio device: NVIDIA Corporation High Definition Audio Controller (rev a1) $ lspci -n 00:00.0 0580: 10de:005e (rev a3) 00:01.0 0601: 10de:0050 (rev a3) 00:01.1 0c05: 10de:0052 (rev a2) 00:02.0 0c03: 10de:005a (rev a2) 00:02.1 0c03: 10de:005b (rev a3) 00:04.0 0401: 10de:0059 (rev a2) 00:06.0 0101: 10de:0053 (rev f2) 00:07.0 0101: 10de:0054 (rev f3) 00:09.0 0604: 10de:005c (rev a2) 00:0a.0 0680: 10de:0057 (rev a3) 00:0b.0 0604: 10de:005d (rev a3) 00:0c.0 0604: 10de:005d (rev a3) 00:0d.0 0604: 10de:005d (rev a3) 00:0e.0 0604: 10de:005d (rev a3) 00:18.0 0600: 1022:1100 00:18.1 0600: 1022:1101 00:18.2 0600: 1022:1102 00:18.3 0600: 1022:1103 01:07.0 0401: 13f6:0111 (rev 10) 01:09.0 0180: 1095:3512 (rev 01) 05:00.0 0300: 10de:10c3 (rev a2) 05:00.1 0403: 10de:0be3 (rev a1)
Created attachment 706210 [details] Xorg.0.log
Created attachment 708469 [details] syslog (/var/log/messages0 gdm functionality has returned (initial symptom of this bug has gone away) using: kernel-PAE-3.9.0-0.rc1.git2.1.fc19.i686 libdrm-2.4.42-1.fc19.i686 gdm-3.7.91-1.fc19.i686 mesa-dri-drivers-9.1-0.4.fc19.i686 xorg-x11-drv-nouveau-1.0.6-6.fc19.i686 However there is a related locking warning: Mar 11 08:16:08 localhost kernel: [ 7.396727] ============================================= Mar 11 08:16:08 localhost kernel: [ 7.396728] [ INFO: possible recursive locking detected ] Mar 11 08:16:08 localhost kernel: [ 7.396731] 3.9.0-0.rc1.git2.1.fc19.i686.PAE #1 Not tainted Mar 11 08:16:08 localhost kernel: [ 7.396732] --------------------------------------------- Mar 11 08:16:08 localhost kernel: [ 7.396733] systemd-udevd/131 is trying to acquire lock: Mar 11 08:16:08 localhost kernel: [ 7.396788] (&dmac->lock){+.+...}, at: [<f809d004>] evo_wait+0x34/0xd0 [nouveau] Mar 11 08:16:08 localhost kernel: [ 7.396790] Mar 11 08:16:08 localhost kernel: [ 7.396790] but task is already holding lock: Mar 11 08:16:08 localhost kernel: [ 7.396830] (&dmac->lock){+.+...}, at: [<f809d004>] evo_wait+0x34/0xd0 [nouveau] Mar 11 08:16:08 localhost kernel: [ 7.396830] Mar 11 08:16:08 localhost kernel: [ 7.396830] other info that might help us debug this: Mar 11 08:16:08 localhost kernel: [ 7.396831] Possible unsafe locking scenario: Mar 11 08:16:08 localhost kernel: [ 7.396831] Mar 11 08:16:08 localhost kernel: [ 7.396832] CPU0 Mar 11 08:16:08 localhost kernel: [ 7.396832] ---- Mar 11 08:16:08 localhost kernel: [ 7.396834] lock(&dmac->lock); Mar 11 08:16:08 localhost kernel: [ 7.396835] lock(&dmac->lock); Mar 11 08:16:08 localhost kernel: [ 7.396836] Mar 11 08:16:08 localhost kernel: [ 7.396836] *** DEADLOCK *** Mar 11 08:16:08 localhost kernel: [ 7.396836] Mar 11 08:16:08 localhost kernel: [ 7.396836] May be due to missing lock nesting notation Mar 11 08:16:08 localhost kernel: [ 7.396836] Mar 11 08:16:08 localhost kernel: [ 7.396838] 10 locks held by systemd-udevd/131: Mar 11 08:16:08 localhost kernel: [ 7.396846] #0: (&__lockdep_no_validate__){......}, at: [<c07ea2d8>] __driver_attach+0x38/0x80 Mar 11 08:16:08 localhost kernel: [ 7.396851] #1: (&__lockdep_no_validate__){......}, at: [<c07ea2e4>] __driver_attach+0x44/0x80 Mar 11 08:16:08 localhost kernel: [ 7.396870] #2: (drm_global_mutex){+.+.+.}, at: [<f7eccc63>] drm_get_pci_dev+0xa3/0x270 [drm] Mar 11 08:16:08 localhost kernel: [ 7.396876] #3: (registration_lock){+.+.+.}, at: [<c072b7fc>] register_framebuffer+0x1c/0x2d0 Mar 11 08:16:08 localhost kernel: [ 7.396881] #4: (&fb_info->lock){+.+.+.}, at: [<c072aa78>] lock_fb_info+0x18/0x40 Mar 11 08:16:08 localhost kernel: [ 7.396885] #5: (console_lock){+.+.+.}, at: [<c072b970>] register_framebuffer+0x190/0x2d0 Mar 11 08:16:08 localhost kernel: [ 7.396890] #6: ((fb_notifier_list).rwsem){.+.+.+}, at: [<c0482fe7>] __blocking_notifier_call_chain+0x37/0xa0 Mar 11 08:16:08 localhost kernel: [ 7.396903] #7: (&dev->mode_config.mutex){+.+.+.}, at: [<f7ecfaba>] drm_modeset_lock_all+0x1a/0x60 [drm] Mar 11 08:16:08 localhost kernel: [ 7.396915] #8: (&crtc->mutex){+.+.+.}, at: [<f7ecfae2>] drm_modeset_lock_all+0x42/0x60 [drm] Mar 11 08:16:08 localhost kernel: [ 7.396957] #9: (&dmac->lock){+.+...}, at: [<f809d004>] evo_wait+0x34/0xd0 [nouveau]
Created attachment 714096 [details] The crash messages from the console when the X server crashes.
Created attachment 714102 [details] This is the Xorg log for the X session with the crash.
I lost my original comments when I added attachments. Live and learn. I use startx from a console to start LXDE. I see this error when X crashes and dumps me back to the console. It happens when I am playing a video with mplayer or watching a stream with firefox, and I either move workspaces or open a new application. Once it happens I haven't found a way to restart X from a console again other than a reboot. I can still play video in a console using -vo fbdev2 in mplayer, so nouveau resets. But restarting X gives an unable to attach to screen :0 message (from memory), I didn't save that. I don't recall seeing this error in the 3.7.xxx series kernels, but both 3.8.2-10x kernels have had this problem. Everything seems to be fine, then there is a crash. The Xorg log has a crash traceback in it, from a segmentation fault.
Created attachment 714268 [details] This is the run description of abrt from ps alx after the problem occurs. The comment from the abrt entry is long and colorful. The problem happened again and I thought I would add this additional information.
I have the similar problem on Fedora 17 with kernel-3.8.4-102.fc17.x86_64. kernel-3.7.9-105.fc17.x86_64 is OK.
I am running the kernel-3.8.4-102.fc17.x86_64 in F17, and have *not* seen the problem since I started. I run custom compiled kernels from the Fedora src.rpm. I turned off single depth wchan, and moved the desktop from low-latency desktop to standard desktop. There have also been updates since the last kernel, many updates. In particular, glibc was updated. I keep updates-testing turned on, so perhaps H.J. Lu in comment 8 hasn't seen these updates yet, and they will fix the problem when they get to updates for him too. So, I don't know whether it is the movement from 3.8.3 to 3.8.4 that fixed this, but for me it isn't happening anymore. Touch wood.
(In reply to comment #9) > > So, I don't know whether it is the movement from 3.8.3 to 3.8.4 that fixed > this, but for me it isn't happening anymore. Touch wood. Have you run 3.8.3/3.8.2 kernel to verify that it is 3.8.4 kernel which fixes the issue?
Just rebooted 3.8.3-103 and tried to make it crash. Nothing I tried caused a crash, but since this is intermittent, and I'm not sure of the actual cause, that isn't definitive. I'll try it for a while, see if I can get a crash.
Watching a livestream via Firefox. After 3.8.3-103 crashed, I rebooted and on the same livestream 3.8.4-102 crashed. So, just like H.J. Lu, kernel kernel-3.8.4-102.fc17.x86_64 still has the issue for me. Darn.
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle. Changing version to '19'. (As we did not run this process for some time, it could affect also pre-Fedora 19 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19
Just for fun, I grabbed the kernel-3.9.0-0.rc6.git1.1.fc20 src.rpm from koji, and compiled it on f17 using the custom configuration I usually use. It still had the problem. Though it runs fine otherwise. Seems there is an intermittent bug for video using nouveau in kernels after the 3.7 series.
Still happening. I also grabbed the latest X-server and glibc and freeglut from koji. xorg-x11-server-common-1.12.4-8.fc17.x86_64 glibc-2.17-6.fc17.x86_64.rpm freeglut-2.8.1-1.fc17.x86_64 I compiled and installed them, still having the problem, though everything works fine otherwise. The glibc rpm had some problem building because it wanted to build 32 bit locale information on x86_64. Commenting allowed it to complete. As a side benefit, the addition of a custom compiled glibc seems to have made response time noticeably faster, especially in the console. But whatever is causing the X crashes is still there in the latest packages available for Fedora. I might have to go back to a 3.7 series kernel to fix this. :-( On a positive note, I found a convenient way to recover instead of rebooting. The problem was that every time I tried to restart X using startx, it would bring up the restored session and crash again. I read on the web that session management was now being done by dbus, and that a SIGHUP or a systemd restart would clear old information. Nope. Instead, in the /run directory there is a file called messagebus.pid left after the crash. It has to be deleted. And I stop and start xrdp.service and xrdp-sesman.service in systemd using systemctl. I can then restart X using startx. To make it easier to see what is going on, I changed the startx script to always use tty10 for the graphical server to run on. That way I can see the messages that are thrown off by X on tty1, the tty I invoke startx from. There are lots of messages like this, ** (zeitgeist-datahub:4806): CRITICAL: **: file utils.c : line 118: uncaught error: Error opening file: Permission denied (g-io-error-quark, 14) I don't think they're connected with the X crash problem, and X still seems to run OK other than the video crashes, but they can't be good.
Spoke too soon. It must have been a fluke that deleting the messagebus.pid file worked. Just had another crash, and nothing worked, had to reboot. The error messages seemed to be different, so I'm posting them here. This was the initial crash: X: nouveau_pushbuf.c:274: nouveau_pushbuf_flush: Assertion `0' failed. [ 6381.558031] nouveau E[X[26886]] failed to idle channel 0xcccc0000 [X[26886]] [ 6381.559737] [sched_delayed] sched: RT throttling activated [ 6384.580025] nouveau E[X[26886]] failed to idle channel 0xcccc0000 [X[26886]] gdesklets-daemon: Fatal IO error 11 (Resource temporarily unavailable) on X server :0. xinit: connection to X server lost xscreensaver: 16:02:36: SIGHUP received: restarting... XIO: fatal IO error 11 (Resource temporarily unavailable) on X server ":0" [ 6387.633058] nouveau E[mplayer[28006]] failed to idle channel 0xcccc0000 [mplayer[28006]] pcmanfm: Fatal IO error 11 (Resource temporarily unavailable) on X server :0. xscreensaver: 16:02:39: running as stan/stan (9999/9999) [ 6390.704043] nouveau E[mplayer[28006]] failed to idle channel 0xcccc0000 [mplayer[28006]] after 11634 requests (11631 known processed) with 0 events remaining. [ 6390.730508] nouveau E[ PFIFO][0000:01:00.0] CACHE_ERROR - ch 1 [unknown] subc 0 mthd 0x0060 data 0x8000000f xscreensaver: 16:02:42: Can't open display: :0 xscreensaver: 16:02:42: running as stan/stan (9999/9999) xscreensaver: 16:02:42: Errors at startup are usually authorization problems. But you're not logging in as root (good!) so something else must be wrong. Did you read the manual and the FAQ? http://www.jwz.org/xscreensaver/faq.html http://www.jwz.org/xscreensaver/man.html This was the first restart after deleting the messagebus.pid file. Backtrace: 0: /usr/bin/X (xorg_backtrace+0x36) [0x465446] 1: /usr/bin/X (0x400000+0x6a459) [0x46a459] 2: /lib64/libpthread.so.0 (0x3ba0c00000+0xf070) [0x3ba0c0f070] 3: /usr/lib64/xorg/modules/drivers/nouveau_drv.so (0x7fe15a4b3000+0x67c2) [0x7fe15a4b97c2] 4: /usr/lib64/xorg/modules/libexa.so (0x7fe1593aa000+0xafaf) [0x7fe1593b4faf] 5: /usr/bin/X (0x400000+0x1606c3) [0x5606c3] 6: /usr/bin/X (0x400000+0xc9d70) [0x4c9d70] 7: /usr/bin/X (0x400000+0xfa928) [0x4fa928] 8: /usr/bin/X (0x400000+0x3458a) [0x43458a] 9: /usr/bin/X (0x400000+0x23595) [0x423595] 10: /lib64/libc.so.6 (__libc_start_main+0xf5) [0x3ba0021ce5] 11: /usr/bin/X (0x400000+0x2386d) [0x42386d] Segmentation fault at address (nil) Fatal server error: Caught signal 11 (Segmentation fault). Server aborting Please consult the Fedora Project support at http://wiki.x.org for help. Please also check the log file at "/var/log/Xorg.1.log" for additional information. [ 6644.245289] nouveau W[ PFIFO][0000:01:00.0] unknown intr 0x00010000, ch 3 [ 6644.245371] nouveau W[ PFIFO][0000:01:00.0] unknown intr 0x00010000, ch 0 [ 6644.245573] nouveau W[ PFIFO][0000:01:00.0] unknown intr 0x00010000, ch 3 [ 6644.245782] nouveau W[ PFIFO][0000:01:00.0] unknown intr 0x00010000, ch 3 [ 6644.245994] nouveau W[ PFIFO][0000:01:00.0] unknown intr 0x00010000, ch 3 [ 6644.246206] nouveau W[ PFIFO][0000:01:00.0] unknown intr 0x00010000, ch 3 [ 6644.246416] nouveau W[ PFIFO][0000:01:00.0] unknown intr 0x00010000, ch 3 [ 6644.246625] nouveau W[ PFIFO][0000:01:00.0] unknown intr 0x00010000, ch 3 [ 6644.246834] nouveau W[ PFIFO][0000:01:00.0] unknown intr 0x00010000, ch 3 [ 6644.247009] nouveau W[ PFIFO][0000:01:00.0] unknown intr 0x00010000, ch 3 [ 6644.247252] nouveau W[ PFIFO][0000:01:00.0] unknown intr 0x00010000, ch 3 [ 6644.247463] nouveau W[ PFIFO][0000:01:00.0] unknown intr 0x00010000, ch 3 [ 6644.247675] nouveau W[ PFIFO][0000:01:00.0] unknown intr 0x00010000, ch 3 [ 6644.247884] nouveau W[ PFIFO][0000:01:00.0] unknown intr 0x00010000, ch 3 [ 6644.248050] nouveau W[ PFIFO][0000:01:00.0] unknown intr 0x00010000, ch 3 [ 6644.248307] nouveau W[ PFIFO][0000:01:00.0] unknown intr 0x00010000, ch 3 [ 6644.248516] nouveau W[ PFIFO][0000:01:00.0] unknown intr 0x00010000, ch 3 [ 6644.248728] nouveau W[ PFIFO][0000:01:00.0] unknown intr 0x00010000, ch 3 [ 6644.248728] nouveau W[ PFIFO][0000:01:00.0] unknown intr 0x00010000, ch 3 [ 6644.248940] nouveau W[ PFIFO][0000:01:00.0] unknown intr 0x00010000, ch 3 [ 6644.249102] nouveau W[ PFIFO][0000:01:00.0] unknown intr 0x00010000, ch 3 [ 6644.249364] nouveau W[ PFIFO][0000:01:00.0] unknown intr 0x00010000, ch 3 [ 6644.249574] nouveau W[ PFIFO][0000:01:00.0] unknown intr 0x00010000, ch 3 [ 6644.249785] nouveau W[ PFIFO][0000:01:00.0] unknown intr 0x00010000, ch 3 [ 6644.249994] nouveau W[ PFIFO][0000:01:00.0] unknown intr 0x00010000, ch 3 [ 6644.250206] nouveau W[ PFIFO][0000:01:00.0] unknown intr 0x00010000, ch 3 [ 6644.250292] nouveau W[ PFIFO][0000:01:00.0] unknown intr 0x00010000, ch 0 [ 6644.253587] nouveau W[ PFIFO][0000:01:00.0] unknown intr 0x00010000, ch 0 [ 6644.255788] nouveau W[ PFIFO][0000:01:00.0] unknown intr 0x00010000, ch 0 [ 6644.257948] nouveau W[ PFIFO][0000:01:00.0] unknown intr 0x00010000, ch 0 [ 6644.260935] nouveau W[ PFIFO][0000:01:00.0] unknown intr 0x00010000, ch 0 [ 6644.263758] nouveau W[ PFIFO][0000:01:00.0] unknown intr 0x00010000, ch 0 [ 6644.266462] nouveau W[ PFIFO][0000:01:00.0] unknown intr 0x00010000, ch 0 [ 6644.268213] nouveau W[ PFIFO][0000:01:00.0] unknown intr 0x00010000, ch 0 [ 6644.271358] nouveau W[ PFIFO][0000:01:00.0] unknown intr 0x00010000, ch 0 [ 6644.273619] nouveau W[ PFIFO][0000:01:00.0] unknown intr 0x00010000, ch 0 [ 6644.276176] nouveau W[ PFIFO][0000:01:00.0] unknown intr 0x00010000, ch 0 [ 6644.278575] nouveau W[ PFIFO][0000:01:00.0] unknown intr 0x00010000, ch 0 [ 6644.281285] nouveau W[ PFIFO][0000:01:00.0] unknown intr 0x00010000, ch 0 Server terminated with error (1). Closing log file. [ 6644.283485] nouveau W[ PFIFO][0000:01:00.0] unknown intr 0x00010000, ch 0 [ 6647.293026] nouveau E[X[28124]] failed to idle channel 0xcccc0001 [X[28124]] [ 6650.306023] nouveau E[X[28124]] failed to idle channel 0xcccc0001 [X[28124]] [ 6653.316020] nouveau E[X[28124]] failed to idle channel 0xcccc0000 [X[28124]] [ 6653.317006] nouveau E[ DRM] GPU lockup - switching to software fbcon [ 6656.498023] nouveau E[X[28124]] failed to idle channel 0xcccc0000 [X[28124]] XIO: fatal IO error 2 (No such file or directory) on X server ":1" after 22 requests (22 known processed) with 0 events remaining. xinit: connection to X server lost
More information. I tried to update libdrm, and the nouveau driver to the latest driver from rawhide. Unfortunately, in F17 the nouveau driver was split in two, with an so.1 and an so.2, with names nouveau and nouveau2 respectively. Many programs are dependent on so.1, the old .16.x version. The new version of nouveau, 1.x, becomes the default library after F17. Bottom line, I hit a dead end. Any forced install would be using an incompatible version of the library for all those dependencies. That could have meant an unuseable system, a risk I wasn't willing to take. I'll see what happens when I install F19 or F20. In the meantime, I used the most recent akmod nvidia driver from rpmfusion. All of the crashes have gone away, which strongly points to nouveau as the source of the problem, to me anyway. I would rather have the nouveau driver since it seems to be better integrated with Fedora. There are pauses now where there never used to be, and the boot process takes a lot longer. Video performance is the same as far as I can tell.
Created attachment 755676 [details] /var/log/messages
Created attachment 755677 [details] lspci
Created attachment 755678 [details] lspci -n
Created attachment 755679 [details] Xorg.0.log.old
Have same problem with new videoadapter. Problem occurs in F17 and now, in F19. Linux bb.lan 3.9.4-300.fc19.x86_64 #1 SMP Fri May 24 22:17:06 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux Could not find regularities in its rise. It happens 1-2 times a day.
I'm also seeing this on F18 on 3.9.2-200.fc18.x86_64 (have ended up having to fall back this far due to issues with newer kernels) with the following video card: 01:00.0 VGA compatible controller: NVIDIA Corporation GT216 [Quadro FX 880M] (rev a2) My kernel console messages: [94223.223815] nouveau E[ DRM] GPU lockup - switching to software fbcon [94227.359895] nouveau E[Xorg[7789]] failed to idle channel 0xcccc0001 [Xorg[7789]] [94230.364458] nouveau E[Xorg[7789]] failed to idle channel 0xcccc0001 [Xorg[7789]] [94232.368999] nouveau E[ PFIFO][0000:01:00.0] channel 3 [Xorg[7789]] unload timeout [94235.372205] nouveau E[Xorg[7789]] failed to idle channel 0xcccc0000 [Xorg[7789]] [94238.374718] nouveau E[Xorg[7789]] failed to idle channel 0xcccc0000 [Xorg[7789]] [94240.379038] nouveau E[ PFIFO][0000:01:00.0] channel 2 [Xorg[7789]] unload timeout [94243.488597] nouveau E[cinnamon[8160]] failed to idle channel 0xcccc0000 [cinnamon[8160]] [94246.491176] nouveau E[cinnamon[8160]] failed to idle channel 0xcccc0000 [cinnamon[8160]] [94248.494206] nouveau E[ PFIFO][0000:01:00.0] channel 4 [cinnamon[8160]] unload timeout [94281.287778] nouveau E[ PFIFO][0000:01:00.0] CACHE_ERROR - ch 4 [gnome-session-c[8672]] subc 1 mthd 0x0500 data 0x00000000 [94281.287807] nouveau E[ PFIFO][0000:01:00.0] DMA_PUSHER - ch 4 [gnome-session-c[8672]] get 0x002000ad58 put 0x002000ad58 ib_get 0x000002b1 ib_put0 [94281.290346] nouveau E[ PGRAPH][0000:01:00.0] magic set 0: [94281.290358] nouveau E[ PGRAPH][0000:01:00.0] 0x00408604: 0x2028bf01 [94281.290373] nouveau E[ PGRAPH][0000:01:00.0] 0x00408608: 0x00009980 [94281.290376] nouveau E[ PGRAPH][0000:01:00.0] 0x0040860c: 0x80000432 [94281.290380] nouveau E[ PGRAPH][0000:01:00.0] 0x00408610: 0x9e000e00 [94281.290383] nouveau E[ PGRAPH][0000:01:00.0] TRAP_TEXTURE - TP0: Unhandled ustatus 0x00000009 [94281.290388] nouveau E[ PGRAPH][0000:01:00.0] TRAP [94281.290395] nouveau E[ PGRAPH][0000:01:00.0] ch 2 [0x003fb3a000 Xorg[8337]] subc 2 class 0x502d mthd 0x08dc data 0x00000000 [94281.296031] nouveau E[ PGRAPH][0000:01:00.0] TRAP_TPDMA_2D - TP 0 - Unknown fault at address 00202ff000 [94281.296038] nouveau E[ PGRAPH][0000:01:00.0] TRAP_TPDMA_2D - TP 0 - e0c: 00000000, e18: 00000000, e1c: 00000000, e20: 00000011, e24: 0c030000 [94281.296044] nouveau E[ PGRAPH][0000:01:00.0] TRAP [94281.296051] nouveau E[ PGRAPH][0000:01:00.0] ch 2 [0x003fb3a000 Xorg[8337]] subc 2 class 0x502d mthd 0x0860 data 0x00000000 [94281.296065] nouveau E[ PFB][0000:01:00.0] trapped write at 0x00202ff000 on channel 0x0003fb3a [Xorg[8337]] PGRAPH/PROP/DST2D reason: PAGE_NOT_T [94281.296350] nouveau E[ PGRAPH][0000:01:00.0] TRAP_M2MF IN [94281.296366] nouveau E[ PGRAPH][0000:01:00.0] TRAP_M2MF 00320051 205aae40 00000000 04000432 [94281.296372] nouveau E[ PGRAPH][0000:01:00.0] TRAP [94281.296381] nouveau E[ PGRAPH][0000:01:00.0] ch 2 [0x003fb3a000 Xorg[8337]] subc 0 class 0x5039 mthd 0x0328 data 0x00000000 [94281.296397] nouveau E[ PFB][0000:01:00.0] trapped write at 0x00202ffa00 on channel 0x0003fb3a [Xorg[8337]] PGRAPH/PROP/DST2D reason: PAGE_NOT_T [94281.296884] nouveau E[ PGRAPH][0000:01:00.0] TRAP_M2MF IN [94281.296894] nouveau E[ PGRAPH][0000:01:00.0] TRAP_M2MF 00320051 205aae40 00000000 04000432 [94281.296898] nouveau E[ PGRAPH][0000:01:00.0] TRAP [94281.296903] nouveau E[ PGRAPH][0000:01:00.0] ch 2 [0x003fb3a000 Xorg[8337]] subc 0 class 0x5039 mthd 0x0328 data 0x00000000 [94281.296916] nouveau E[ PFB][0000:01:00.0] trapped write at 0x00202ff000 on channel 0x0003fb3a [Xorg[8337]] PGRAPH/PROP/DST2D reason: PAGE_NOT_T [94281.297360] nouveau E[ PGRAPH][0000:01:00.0] TRAP_M2MF IN [94281.297370] nouveau E[ PGRAPH][0000:01:00.0] TRAP_M2MF 00320051 205aae40 00000000 04000432 [94281.297374] nouveau E[ PGRAPH][0000:01:00.0] TRAP [94281.297380] nouveau E[ PGRAPH][0000:01:00.0] ch 2 [0x003fb3a000 Xorg[8337]] subc 0 class 0x5039 mthd 0x0328 data 0x00000000 [94281.297392] nouveau E[ PFB][0000:01:00.0] trapped write at 0x00202ff800 on channel 0x0003fb3a [Xorg[8337]] PGRAPH/PROP/DST2D reason: PAGE_NOT_T [94281.297836] nouveau E[ PGRAPH][0000:01:00.0] TRAP_M2MF IN [94281.297846] nouveau E[ PGRAPH][0000:01:00.0] TRAP_M2MF 00320051 205aae40 00000000 04000432 [94281.297850] nouveau E[ PGRAPH][0000:01:00.0] TRAP [94281.297855] nouveau E[ PGRAPH][0000:01:00.0] ch 2 [0x003fb3a000 Xorg[8337]] subc 0 class 0x5039 mthd 0x0328 data 0x00000000 [94281.297868] nouveau E[ PFB][0000:01:00.0] trapped write at 0x00202ff800 on channel 0x0003fb3a [Xorg[8337]] PGRAPH/PROP/DST2D reason: PAGE_NOT_T [94281.298360] nouveau E[ PGRAPH][0000:01:00.0] TRAP_M2MF IN [94281.298370] nouveau E[ PGRAPH][0000:01:00.0] TRAP_M2MF 00320051 205aae40 00000000 04000432 [94281.298374] nouveau E[ PGRAPH][0000:01:00.0] TRAP [94281.298380] nouveau E[ PGRAPH][0000:01:00.0] ch 2 [0x003fb3a000 Xorg[8337]] subc 0 class 0x5039 mthd 0x0328 data 0x00000000 [94281.298391] nouveau E[ PFB][0000:01:00.0] trapped write at 0x00202ff800 on channel 0x0003fb3a [Xorg[8337]] PGRAPH/PROP/DST2D reason: PAGE_NOT_T [94281.298884] nouveau E[ PGRAPH][0000:01:00.0] TRAP_M2MF IN [94281.298894] nouveau E[ PGRAPH][0000:01:00.0] TRAP_M2MF 00320051 205aae40 00000000 04000432 [94281.298898] nouveau E[ PGRAPH][0000:01:00.0] TRAP [94281.298903] nouveau E[ PGRAPH][0000:01:00.0] ch 2 [0x003fb3a000 Xorg[8337]] subc 0 class 0x5039 mthd 0x0328 data 0x00000000 [94281.298915] nouveau E[ PFB][0000:01:00.0] trapped write at 0x00202ff800 on channel 0x0003fb3a [Xorg[8337]] PGRAPH/PROP/DST2D reason: PAGE_NOT_T [94281.299398] nouveau E[ PGRAPH][0000:01:00.0] TRAP_M2MF IN [94281.299409] nouveau E[ PGRAPH][0000:01:00.0] TRAP_M2MF 00320051 205aae40 00000000 04000432 Happy to provide any additional information needed.
I am not sure this the same issue, but I had been seeing the "nouveau E[ DRM] GPU lockup - switching to software fbcon" error a lot with recent kernels, that usually happens when I am powering off or rebooting the machine (this is with plymouth uninstalled/disabled altogether). I added nouveau.nofbaccel=1 to the kernel cmdline, and that seems to fix this issue for me, no more lockups when powering off / rebooting.
I forgot to post the details: - This is with kernels 3.8.x, 3.9.x, 3.10.x - fc19 (had the same issue in fc18), with an nvidia GTX 260
I recently started running F20 Alpha, with the nouveau driver. I'm using a custom compiled kernel 3.12.0.rc2 from koji. It seemed this was fixed, as I didn't see the problem for a few days. But I was mostly in consoles while I customized and tuned the install. Unfortunately, this lockup is still happening. I tried the fix recommended by Ahmad Samir above, but no improvement. Everything will be going along perfectly, and then X just locks up. Sometimes, the mouse still works, and sometimes it doesn't. Sometimes I can get to a console, and sometimes not. When I can, there seems to be a long delay. This happens about once an hour. When it happens and I can get to a console, I see this error on the screen. I much prefer the nouveau driver. Instant switch between console and X, no slow scrolling in some apps, and boot is fast without the akmod compile. And now, even the brightness and contrast work in X with nouveau. But, having to reboot every hour is just too trying. I'll probably install the nvidia driver, with all its faults. Just for the stability. I ran it for months in F17 without a single lockup in X. I'll give nouveau a few more days. Maybe the lockups will reduce to one a day, a rate I could live with. It must be a race condition, triggered by something obscure. It doesn't seem to be load, as it can happen when the machine is nearly idle. Threading deadlock?
> I'll probably install the nvidia driver, with all its faults. Just for the stability. I ran it for months in F17 without a single lockup in X. Just in case, I have something similar (bug 979537) and tried to switch to proprietary driver too. I was surprised that the situation is much more worse there. Seems like proprietary driver can recover from lockup but it happens every 1-2 minutes and gives a lot of freezes. I used this driver a couple of years ago and it didn't have such a problems that time. Hw issue maybe but I'm not sure. Related for me: https://bugs.freedesktop.org/show_bug.cgi?id=69375 BTW, does anybody know what happened with these patches and what's the perspectives of this functionality? http://lists.freedesktop.org/archives/nouveau/2012-April/010199.html > Threading deadlock? Did you try to boot a debug kernel? For me it tells something related.
> Did you try to boot a debug kernel? Good idea, I might try that in the future. I do have the debuginfo packages installed for the kernels I'm running, so it should at least give some reasonable information when it crashes. For now, I am trying some older kernels to see if they have the problem. There are no old kernel packages in koji, but I had a src.rpm for 3.7.10, the last kernel that worked with nouveau for me without problems. And 3.8.8, the first kernel series where I saw the problem. I want to confirm that I wasn't just imagining there were no problems, and that the problems started with 3.8. If it is confirmed, then I can run a diff on the nouveau driver to see changes. I suppose I could just go to the git repository for the kernel and look at the commit messages too. But it could be X, or an application like firefox. Hard to track. At least that will give a time frame. I'm currently running the 3.7 kernel on F20 Alpha, custom compiled for my hardware. So far, so good. Some other observations. I notice that if I start X, and applications, and then go to the console, there is never a crash in X. No matter how long I'm away, I can go back and everything is fine. So, it seems that I have to be active in X for the crash to occur. Also, I *think* that whenever a crash occurs, firefox is active. I don't have to be using it, but I think it is active. I'm going to try closing firefox, and see if I can create a lockup when it isn't running. Later, with a kernel that I know has the problem. > I used this driver a couple of years ago and it didn't have such a problems that time. Hw issue maybe but I'm not sure. I'm running older hardware, and I think that does contribute to problems. The developers are usually running latest, greatest hardware, and so they focus development efforts there. But also, if they make a change, and the change causes problems for older hardware, they won't notice, as long as it works on their new hardware. So, with time and development effort, there is more and more chance of an error for old hardware creeping into the code. That suggests one workaround is to upgrade hardware to something closer to that which the developers are using. :-)
Well, kernel 3.7.10 works without problem. It has been up for 24 hours now, used as the other kernels were, and there have been no lockups. I'm reluctant to give up my working system, but sometime today I'll boot into 3.8.8 and see if the problems reappear as they did in the past. If you want to try this, there are instructions on how to compile a custom kernel in the fedora wiki, https://fedoraproject.org/wiki/Building_a_custom_kernel I'm not sure where you would get the fedora src.rpm for the 3.7.10 kernel, though you can definitely get the source from kernel.org. There are reports in the users mailing list of people running stock kernels with no problems in Fedora. I could upload the old 3.7.10-101 src.rpm as an attachment, but it's 70 MB, so I'm reluctant to do that.
(In reply to stan from comment #29) Just in case, "fedora" repo (not "updates") contains kernel 3.6.10 for F19. Another point is that my similar problem is reproducible wery well with launching more or less heavy 3D game.
Well, 3.8.8 fails by lockup. So the change that is causing this problem for me occurred in the 3.7 to 3.8 kernel transition. I don't have 3.8.0 src.rpm anymore, but when I originally used it, this problem started. I haven't looked at the code differences for the nouveau driver yet. That could be a while. @30, Andrew, if you can reliably induce your problem by heavy load, then it is probably due to a different cause than the freezes I experience. Maybe threads aren't synchronizing properly, leading to deadlock. The freezes I experience are more like a buffer overflow problem or a pointer going haywire and writing somewhere it shouldn't. Even when I can bring up a console and kill everything related to X, I still can't restart X. Something is altered internally, and it just exits back to the console I try to start X from. Needs a reboot to reset things before X will work again.
(In reply to stan from comment #31) > @30, Andrew, if you can reliably induce your problem by heavy load, then it > is probably due to a different cause than the freezes I experience. I don't know, but just in case: it reproduces after just launching the game. Waiting at the start menu for ~10s is enough. The another point is that the menu is rendered very bad, just a color mess. I don't think it's related though. > Even when I can bring up a > console and kill everything related to X, I still can't restart X. > Something is altered internally, and it just exits back to the console I try > to start X from. Needs a reboot to reset things before X will work again. Same for me. However I didn't check if any processes related to X survive the lockup.
I've run a diff of the .c and .h files in the nouveau directory of the kernel, between Fedora 3.7.10 and Fedora 3.8.8. Nothing jumps out at me as the cause. Most of the changes seem to concern nv50 and later, but I have an nv40 card. But it's like watching a foreign movie without subtitles. I can see the actions on the screen, but I don't understand what is happening because I don't understand the dialog. I'll try reverting some of the changes in a newer kernel and see what happens. The diff is attached above.
Created attachment 806772 [details] diff -U5 -p of nouveau directory between Fedora 3.7.10 and Fedora 3.8.8
fc19 is unusable for me with this bug, I had to reboot every few hours - I switched back to fc18 where I've never seen such freezes. > Also, I *think* that whenever a crash occurs, firefox is active. Me too, but I also experienced the lockups when Thunderbird and/or eclipse was running. As long as only KDE shell konsoles were open fc19 seemed to be stable. Installing the native akmod driver didn't solve the issue. My (quite old) nvidia card is: [root@sula]# /sbin/lspci | grep VGA 01:00.0 VGA compatible controller: NVIDIA Corporation NV43GL [Quadro FX 540] (rev a2)
To add my two cents. I do have these lockups on two identical machines (which was bought to install F18), but *very* seldom, from the beginning. Most of the time it does not lead to a lock, but yesterday, with 3.11.4-101.fc18.x86_64, I had to reboot the system. There were also some more messages: Oct 20 20:35:38 nepomuk kernel: [18415.774599] nouveau E[ DRM] GPU lockup - switching to software fbcon Oct 20 20:37:44 nepomuk kernel: [18541.287896] nouveau E[Xorg[970]] failed to idle channel 0xcccc0001 [Xorg[970]] Oct 20 20:37:59 nepomuk kernel: [18556.278117] nouveau E[Xorg[970]] failed to idle channel 0xcccc0001 [Xorg[970]] Oct 20 20:38:01 nepomuk kernel: [18558.297241] nouveau E[ PFIFO][0000:01:00.0] playlist update failed Oct 20 20:38:16 nepomuk kernel: [18573.287009] nouveau E[Xorg[970]] failed to idle channel 0xcccc0000 [Xorg[970]] Oct 20 20:38:31 nepomuk kernel: [18588.277240] nouveau E[Xorg[970]] failed to idle channel 0xcccc0000 [Xorg[970]] Oct 20 20:38:34 nepomuk kernel: [18590.276533] nouveau E[ PFIFO][0000:01:00.0] channel 2 [Xorg[970]] kick timeout Oct 20 20:38:35 nepomuk kernel: [18592.275856] nouveau E[ PFIFO][0000:01:00.0] playlist update failed Oct 20 20:38:39 nepomuk kernel: [18596.071818] nouveau E[ PFIFO][0000:01:00.0] playlist update failed Oct 20 20:38:41 nepomuk kernel: [18598.228965] nouveau E[ PFIFO][0000:01:00.0] playlist update failed 01:00.0 VGA compatible controller: NVIDIA Corporation GF119 [GeForce GT 610] (rev a1) I always have firefox active, but I think this happens when switching between virtual desktops
I have this problem almost daily. The result is a completely frozen GUI, and ALT+CTL+F* does not respond. I can log in with ssh. kernel: 3.11.4-201.fc19.x86_64 #1 SMP video card: 01:00.0 VGA compatible controller: NVIDIA Corporation GK106 [GeForce GTX 650 Ti] (rev a1) relevant parts of dmesg after freeze: [80694.869736] do_IRQ: 2.196 No irq handler for vector (irq -1) [91130.843425] do_IRQ: 5.104 No irq handler for vector (irq -1) [96117.717112] nouveau E[ DRM] GPU lockup - switching to software fbcon [96121.884875] nouveau W[ PFIFO][0000:01:00.0] unknown status 0x00000100 [96126.184473] nouveau W[ PFIFO][0000:01:00.0] unknown status 0x00000100 [96130.484070] nouveau W[ PFIFO][0000:01:00.0] unknown status 0x00000100 [96133.166484] nouveau E[Xorg[30479]] failed to idle channel 0xcccc0001 [Xorg[30479]] [96134.783667] nouveau W[ PFIFO][0000:01:00.0] unknown status 0x00000100 [96139.083264] nouveau W[ PFIFO][0000:01:00.0] unknown status 0x00000100 [96143.382863] nouveau W[ PFIFO][0000:01:00.0] unknown status 0x00000100 [96147.682461] nouveau W[ PFIFO][0000:01:00.0] unknown status 0x00000100 [96148.182370] nouveau E[Xorg[30479]] failed to idle channel 0xcccc0001 [Xorg[30479]] [96150.188396] nouveau E[ PFIFO][0000:01:00.0] playlist 0 update timeout [96151.982061] nouveau W[ PFIFO][0000:01:00.0] unknown status 0x00000100 [96156.281660] nouveau W[ PFIFO][0000:01:00.0] unknown status 0x00000100 [96160.581257] nouveau W[ PFIFO][0000:01:00.0] unknown status 0x00000100 [96164.880857] nouveau W[ PFIFO][0000:01:00.0] unknown status 0x00000100 [96165.204380] nouveau E[Xorg[30479]] failed to idle channel 0xcccc0000 [Xorg[30479]] [96169.180455] nouveau W[ PFIFO][0000:01:00.0] unknown status 0x00000100 [96173.480053] nouveau W[ PFIFO][0000:01:00.0] unknown status 0x00000100 [96177.779650] nouveau W[ PFIFO][0000:01:00.0] unknown status 0x00000100 [96180.220269] nouveau E[Xorg[30479]] failed to idle channel 0xcccc0000 [Xorg[30479]] [96182.079246] nouveau W[ PFIFO][0000:01:00.0] unknown status 0x00000100 [96182.222761] nouveau E[ PFIFO][0000:01:00.0] channel 2 [Xorg[30479]] kick timeout [96182.222799] nouveau W[ PFIFO][0000:01:00.0] unknown status 0x00000100 [96184.224957] nouveau E[ PFIFO][0000:01:00.0] channel 2 [Xorg[30479]] kick timeout [96184.227548] nouveau W[ PFIFO][0000:01:00.0] unknown status 0x00000100 [96186.229703] nouveau E[ PFIFO][0000:01:00.0] playlist 0 update timeout [96186.229746] nouveau ![ PFIFO][0000:01:00.0] unhandled status 0x00000001 [96201.307582] nouveau E[gnome-shell[30856]] failed to idle channel 0xcccc0000 [gnome-shell[30856]]
Since switching to 3.11 on Fedora 18 we have this lockup very often. Actually, work is not possible again. Trying 3.10 again
With kernel-3.11.8-200.fc19.x86_64, I got [78222.285207] nouveau E[gnome-shell[1481]] failed to idle channel 0xcccc0000 [gnome-shell[1481]] [78237.281972] nouveau E[gnome-shell[1481]] failed to idle channel 0xcccc0000 [gnome-shell[1481]] [78239.281590] nouveau E[ PFIFO][0000:01:00.0] channel 4 [gnome-shell[1481]] unload timeout [78273.717032] nouveau E[gnome-session-c[26388]] failed to idle channel 0xcccc0000 [gnome-session-c[26388]] [78288.713671] nouveau E[gnome-session-c[26388]] failed to idle channel 0xcccc0000 [gnome-session-c[26388]] [78303.710491] nouveau E[gnome-session-c[26388]] failed to idle channel 0xcccc0000 [gnome-session-c[26388]] [78305.710032] nouveau E[ PFIFO][0000:01:00.0] channel 5 [gnome-session-c[26388]] unload timeout [78320.706707] nouveau E[gnome-session-c[26388]] failed to idle channel 0xcccc0000 [gnome-session-c[26388]] [78335.703398] nouveau E[gnome-session-c[26388]] failed to idle channel 0xcccc0000 [gnome-session-c[26388]] [78350.700080] nouveau E[gnome-session-c[26388]] failed to idle channel 0xcccc0000 [gnome-session-c[26388]] [78351.293457] [drm] Got external EDID base block and 0 extensions from "edid/HP-LP2465.bin" for connector "DVI-I-1" [78351.343203] [drm] Got external EDID base block and 0 extensions from "edid/HP-LP2465.bin" for connector "DVI-I-1" [78351.626347] [drm] Got external EDID base block and 0 extensions from "edid/HP-LP2465.bin" for connector "DVI-I-1" [78352.092678] [drm] Got external EDID base block and 0 extensions from "edid/HP-LP2465.bin" for connector "DVI-I-1" [78352.459102] [drm] Got external EDID base block and 0 extensions from "edid/HP-LP2465.bin" for connector "DVI-I-1" [78352.525630] [drm] Got external EDID base block and 0 extensions from "edid/HP-LP2465.bin" for connector "DVI-I-1" I have no problems with Fedora 18 + kernel 3.10 on the same machine.
Hi, i've a Aspire 9420, with a 01:00.0 VGA compatible controller: NVIDIA Corporation G72M [Quadro NVS 110M/GeForce Go 7300] (rev a1) I'm running fedora 20, with kernel 3.12.10 everything is fine but with 3.13.{3,4,5} and 3.14.0-0.rc5.git2.1.fc21.x86_64 password prompt never show, and i have (in journalctl): kernel: nouveau E[ DRM] GPU lockup - switching to software fbcon While shutdowning kernel: nouveau E[Xorg[635]] failed to idle channel 0xcccc0001 [Xorg[635]] kernel: nouveau E[gnome-shell[1190]] failed to idle channel 0xcccc0000 [gnome-shell[1190]] kernel: nouveau E[Xorg[635]] failed to idle channel 0xcccc0001 [Xorg[635]] kernel: nouveau E[gnome-shell[1190]] failed to idle channel 0xcccc0000 [gnome-shell[1190]] kernel: nouveau E[Xorg[635]] failed to idle channel 0xcccc0001 [Xorg[635]] ... kernel: nouveau E[Xorg[635]] failed to idle channel 0xcccc0000 [Xorg[635]] ...
Hi, 3.12.10-300.fc20 and 3.13.0-0.rc0.git1.3.fc21.x86_64 are working for me. I'll continue to narrow down when did it happen later
hi, kernel-3.13.0-0.rc1.git0.1.fc21.x86_64 isn't working, so last version working is 3.13.0-0.rc0.git1.3.fc21.x86_64
3.13.0-0.rc0.git4.1.fc21.x86_64 working 3.13.0-0.rc0.git5.1.fc21.x86_64 not working
Hi, after some time bisecting: 3c792a15ec799c27d634b102b605f3ec32c033c3 is the first bad commit commit 3c792a15ec799c27d634b102b605f3ec32c033c3 Author: Ben Skeggs <bskeggs> Date: Fri Oct 11 14:56:39 2013 +1000 drm/nouveau/mc: fetch NV_PMC_INTR again after re-arming MSI Signed-off-by: Ben Skeggs <bskeggs> :040000 040000 4ddfe2602412ff37217b60b8a28c7594db6e1cf2 206d1ce23e7d756a88db9da9965e70da9150ac0b M drivers
Hi, Using linux 3.14-rc8, with this small patch, my computer is working again. There must be a small race condition. diff --git a/drivers/gpu/drm/nouveau/core/subdev/mc/base.c b/drivers/gpu/drm/nouveau/core/subdev/mc/base.c index b4b9943..4979c4e 100644 --- a/drivers/gpu/drm/nouveau/core/subdev/mc/base.c +++ b/drivers/gpu/drm/nouveau/core/subdev/mc/base.c @@ -46,8 +46,10 @@ nouveau_mc_intr(int irq, void *arg) nv_wr32(pmc, 0x000140, 0x00000000); nv_rd32(pmc, 0x000140); intr = nouveau_mc_intr_mask(pmc); - if (pmc->use_msi) + if (pmc->use_msi){ oclass->msi_rearm(pmc); + printk("rearm"); + } if (intr) { u32 stat = intr = nouveau_mc_intr_mask(pmc);
also working 3.14-rc8 with this patch diff --git a/drivers/gpu/drm/nouveau/core/subdev/mc/base.c b/drivers/gpu/drm/nouveau/core/subdev/mc/base.c index b4b9943..719db60 100644 --- a/drivers/gpu/drm/nouveau/core/subdev/mc/base.c +++ b/drivers/gpu/drm/nouveau/core/subdev/mc/base.c @@ -49,6 +49,8 @@ nouveau_mc_intr(int irq, void *arg) if (pmc->use_msi) oclass->msi_rearm(pmc); + udelay(1); + if (intr) { u32 stat = intr = nouveau_mc_intr_mask(pmc); while (map->stat) {
This bug exists on F20 as well (kernel-3.13.7-200.fc20.x86_64). Do need to clone this bug report for F20?
I downloaded the latest rawhide kernel src.rpm from koji, 3.14.0-1, and compiled it on my F20 box. When I tried to patch it, it failed because the change is already in it. I installed it, and it has been running flawlessly with nouveau for hours. I used to get at least 1 lockup an hour in X. It might be that this is a lull, and the lockups will start again. But for now, it is working without issue. Thanks Etienne, for your diligence.
I forgot to mention that nouveau_mc_intr is called many many times, like more than 2400 times in 50 minutes. For me kernel-3.14.0-1.fc21.x86_64 from koji isn't working, but 3.14 (linus tag) + my udelay with config-3.14.0-1.fc21.x86_64 is working
hi stan, I don't see my patch in kernel-3.14.0-1.fc21.src.rpm, are you sure? Can you you post the exact step that you've followed (cmd lines)
Sure. Go to http://koji.fedoraproject.org/koji/builds?state=1&order=-build_id and put kernel in the search box. Click on the latest 3.14 kernel, click on src.rpm download. Once its on your box, run rpm -ivh kernelXXX.src.rpm That will install it in the ~/rpmbuild environment. Go into rpmbuild/SPECS and run rpmbuild -bp kernel.spec. That will unpack it into the BUILD directory under kernelXXX/linuxXXX. Here, that is BUILD/kernel-3.14.fc20/linux-3.14.0-1.20140331.fc20.x86_64. I then went into the directory that your patch points to, drivers/gpu/drm/nouveau/core/subdev/mc, copied the base.c to base.c.orig, edited the base.c to put in your changes, and did a diff. [1] I edited that diff to add the a/drivers/gpu/drm/nouveau/core/subdev/mc/base.c and b/drivers/gpu/drm/nouveau/core/subdev/mc/base.c and copied it to SOURCES as rpmbuild/SOURCES/linux-3.14-nouveau_delay_fix.patch . Here it is: --- a/drivers/gpu/drm/nouveau/core/subdev/mc/base.c 2014-03-31 13:33:39.185254273 -0700 +++ b/drivers/gpu/drm/nouveau/core/subdev/mc/base.c 2014-03-31 13:34:38.264931640 -0700 @@ -47,10 +47,12 @@ nouveau_mc_intr(int irq, void *arg) nv_rd32(pmc, 0x000140); intr = nouveau_mc_intr_mask(pmc); if (pmc->use_msi) oclass->msi_rearm(pmc); + udelay (1); + if (intr) { u32 stat = intr = nouveau_mc_intr_mask(pmc); while (map->stat) { if (intr & map->stat) { unit = nouveau_subdev(pmc, map->unit); The faulty indentation is because I set my editor to translate tabs as 2 spaces. So it is out of sync with the file, though it looks perfect in my editor. I then went into the SPECS directory and added the following lines in kernel.spec. # Try the fix suggested in the bugzilla for nouveau Patch50000: linux-3.14-nouveau_delay_fix.patch # END OF PATCH DEFINITIONS and # Try the nouveau patch as suggested in the bugzilla ApplyPatch linux-3.14-nouveau_delay_fix.patch # END OF PATCH APPLICATIONS I ran the usual command I do to build then, after changing the local line to add the date, rpmbuild -bb --without debug --target=`uname -m` kernel.spec > build_output 2> error_output And it failed with the error that the chunk failed because it would be a reversion. When I commented out the patch lines I'd added to the spec file, it worked just fine, and that is the kernel I am running. 1. As I was writing this, I realized that you are right. I would never have been able to create the patch if the change was already there. I changed the unpacked code from rpmbuild -bp. But when I run rpmbuild -bb, it erases existing directories in BUILD and it unpacks the archive file into a brand new directory from the tar archive, and applies the patches afresh. At least it always has done since I started customizing kernels for my box years ago. So, I'm not sure how the patch got into the source when I told the spec file not to patch. I left the patch in SOURCES. Maybe because it was marked for kernel 3.14 it picked it up automatically? I've never seen that behavior before, but maybe it's a new feature. It's been running now for almost 2 days without a glitch. The only thing I've noticed is that mplayer is slow when I go to full screen. I don't see how a 1 usec delay could cause that unless the function is being called *many* times per second. I can't compare to the proprietary NVIDIA driver I have been using because it doesn't work for 3.14. At least the akmod version from rpmfusion doesn't. It doesn't have this issue in mplayer with the rpmfusion akmod and kernel 3.13. Full screen videos play as fast as encoded size videos. It's been a while since I have run nouveau since I started getting too many lockups to use it around 3.9 or 3.10, I think. I don't remember seeing this kind of slowing. And I used to be able to run video full screen at 8x and 16x with the old nv driver when X supported it. Great for deciding if something is worth watching. With a little skipping around and some 4x, it is possible to determine if a video is worth watching in a few minutes. With nouveau in 3.14, it plays at the encoded size for the video normally. But in full screen, it slows down enough that there is a heart beat to the video as it plays each frame. frame pause frame pause etc. This seems like a really complicated procedure, but I have a screen configuration file for kernel compilation that allows me to flip between all these directories with a few keystrokes. Thanks again for taking the trouble to track this down. It means I can use the newest Fedora kernels as they become available, and there is no delay when switching between consoles and X.
I was able to fix this by: 1) Installing the nvidia proprietary driver. 2) Configuring PowerMizer (the adaptive GPU throttler) for maximum performance. Does that work for anyone else? Or do I appear to have an unrelated problem?
I was able to work around the problem by adding " nouveau.noaccel=1" to the end of "GRUB_CMDLINE_LINUX" in "/etc/default/grub" and running "grub2-mkconfig" on Fedora 19 and 20 up through kernel 3.13.7 on a system with a NVIDIA Corporation G72 [GeForce 7300 LE] (rev a1).
i also get this problem in F21 Rawhide LiveCD's , i only need to open a Browser for a minute or so an i get this error as reported. doesnt surprise me that the blob driver would fix it though. goes to show you how crap an opensource driver is
(In reply to Greg` from comment #54) > i also get this problem in F21 Rawhide LiveCD's , i only need to open a > Browser for a minute or so an i get this error as reported. doesnt surprise > me that the blob driver would fix it though. goes to show you how crap an > opensource driver is thats with x-server 1.15.99.902 an Kernel 3.15 rc4
(In reply to Dean Hunter from comment #53) > I was able to work around the problem by adding " nouveau.noaccel=1" to the > end of "GRUB_CMDLINE_LINUX" in "/etc/default/grub" and running > "grub2-mkconfig" on Fedora 19 and 20 up through kernel 3.13.7 on a system > with a NVIDIA Corporation G72 [GeForce 7300 LE] (rev a1). I'm having the same problem with a NVIDIA MCP79 [GeForce 8200M G] (rev b1) in an MSI laptop running Fedora 20 3.14.4-200 x86_64, and Dean's workaround seems to be working for me. Thanks, Dean!
installing the Nvidia blob driver works for me. i no longer get lockups 01:00.0 VGA compatible controller: NVIDIA Corporation GF116 [GeForce GTX 550 Ti] (rev a1)
(In reply to Greg` from comment #57) > installing the Nvidia blob driver works for me. i no longer get lockups > 01:00.0 VGA compatible controller: NVIDIA Corporation GF116 [GeForce GTX 550 > Ti] (rev a1) Same problem in fedora 20. Greg: what do you mean for "Nvidia blob driver"? the one downloaded from nvidia site? I got same of your graphic card: 01:00.0 VGA compatible controller: NVIDIA Corporation GF116 [GeForce GTX 550 Ti] (rev a1) Bye SR
(In reply to Stefano Romano from comment #58) > (In reply to Greg` from comment #57) > > installing the Nvidia blob driver works for me. i no longer get lockups > > 01:00.0 VGA compatible controller: NVIDIA Corporation GF116 [GeForce GTX 550 > > Ti] (rev a1) > > Same problem in fedora 20. > > Greg: what do you mean for "Nvidia blob driver"? the one downloaded from > nvidia site? > > I got same of your graphic card: > 01:00.0 VGA compatible controller: NVIDIA Corporation GF116 [GeForce GTX 550 > Ti] (rev a1) > > Bye > > SR you can use both, either from Nvidia site or the one in RPMFusion which will fix the problem
This message is a notice that Fedora 19 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 19. It is Fedora's policy to close all bug reports from releases that are no longer maintained. Approximately 4 (four) weeks from now this bug will be closed as EOL if it remains open with a Fedora 'version' of '19'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 19 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
I am on this bug because I used to run nvidia. When I got a new MB, I decided to go with radeon instead, because of all the problems with nouveau. This isn't a knock on the nouveau developers. Considering the hurdles they faced, they did amazing things. But my old hardware wasn't at the cutting edge of development, and so it wasn't part of testing, and subject to cruft causing problems. In the end, I had to go with the closed source driver from rpmfusion, because my system was locking up so frequently with the nouveau driver (i.e. this bug). But I don't need any cutting edge graphics hardware. And radeon seems to be pretty cut and dried for older cards, where bugs have been worked out and the card specs are all publicly available, rather than being reverse engineered. I went with a cheap radeon 6450, and have been happy with its performance under the open source radeon driver. I see in the kernel code that it says it supports up to R5. I think the latest radeons are R9, so for those it is probably necessary to use the closed source catalyst driver. All of this is a long winded way of saying, that for my part, you can close this bugzilla. And thanks for all the work you did over the years on nouveau. It worked well for me until the last few years, when the sweet spot of development passed my hardware by, and development for newer hardware bled instability back into older cards.
I am also seeing this problem on Fedora 21. I am using an Nvidia NV104 card, specifically an Asus GeForce GTX 760. I also saw the problem on my previous board, an Asus GeForce GT 640. I upgraded my graphics card because I suspected the old card was defective.
nouveau.noaccel=1 has successfully worked around this issue for me. Fortunately I don't need the acceleration at $WORKPLACE. 01:00.0 VGA compatible controller: NVIDIA Corporation NV44 [GeForce 6200 LE] (rev a1)
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
As noted in comment 62, this bug is also present in Fedora 21.
I'm seeing this problem on a system upgraded from F20 to F21. According to lspci: 01:00.0 VGA compatible controller: NVIDIA Corporation G72GLM [Quadro FX 350M] (rev a1) I've rebooted 3 times and it has locked up every time. System worked fine under F20. Paolo
I'm also seeing this problem on a system upgraded from F21 to F22. I have updated my F22 system with all the latest updates and have rebooted the system 4 times and it has locked up every time. I'm running 4.0.4-303.fc22.x86_64
Hi, I had this same issue today with a fresh install of Fedora 22, just downloaded (and verified with checksum) from Fedora website and installed from scratch on a brand new disk. The OS would boot and reach the GDM log window without issue. Then I enter the login and password, enter, the screen changes, and… screen freeze. By switching to a TTY console immediately a split second before the crash, I could see the error: > nouveau E[ drm] gpu lockup switching to software fbcon" error … which led me here. The solution to the problem was to install the rpmfusion directory and installing kmod-nvidia. The graphics card is a NVIDIA GeForce GTX 780. Nouveau indeed seems to be the problem, but that's strange because that computer used to have a linux Mint just before; and even though it was using Nvidia proprietary drivers lately, I think there was a time when it would have used Nouveau, and I don't remember such freezes.
Though I wonder… the live CD must use Nouveau as well (I assume it does not have the proprietary drivers, does it?). What is the difference? Why did it work in the live CD, not in the installed system?
This message is a reminder that Fedora 21 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 21. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '21'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 21 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
As noted in comment 68, this bug is also present in Fedora 22.
I made a clean install of Fedora 23 today and can say this bug appears in Fedora 23 too.
Try doing a full update. I am also running Fedora 23, and I have not seen the problem recently.
Oh I did the full update after setting the nvidia driver, indeed (I think). Unfortunately, I can't redo it. This is a user computer (who managed to break her Fedora 23 installation) and I am not going to reinstall it just for testing, because she has work to do (also because I certainly don't enjoy reinstalling again and again, though I would have done it for the sake of the bug testing). :-/ Sorry, I guess I won't be able to test if making a full update before trying to log in graphically fixes the issue. At least not now.
To clarify, I have been using the nouveau driver with nouveau.noaccel=1 to work around the problem. Whenever there is an update to nouveau, I try booting with nouveau.noaccel=0 to see if the problem is fixed. I haven't seen the problem in about a month. I believe if you were to switch your user's computer to nouveau, it would work.
That's "lucky" (if one may say) because we managed to break again Fedora 23 so much that I reinstalled it. This time, I ran a `dnf update` directly after the installation,… and it works! So I think we can say this is fixed (or improved, since I cannot ensure it won't crash with other cases).
Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
I am getting a similar problem after a fresh install of fedora 25, several programs open on taskbar suddenly unable to access them with mouse whilst using libre office writer. system = intel i7 6Gb ram ssd drive attached to a pci-e sataIII adapter card Nvidia G8 Can alt+tab between them but can't start other (such as ksystemlog) programs because launcher menu doesn't respond to mouse. System monitor resource use = between 1% & 8% cpu (intel i7) & 2.0 Gb memory (34%) & 0.1% swap. Konsole: # qdbus org.kde.plasmashell Could not connect to D-Bus server: org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. # xrandr Screen 0: minimum 320 x 200, current 1440 x 900, maximum 8192 x 8192 DVI-I-1 disconnected primary (normal left inverted right x axis y axis) VGA-1 connected 1440x900+0+0 (normal left inverted right x axis y axis) 410mm x 256mm 1440x900 59.89*+ 74.98 1152x864 75.00 1024x768 75.03 70.07 60.00 800x600 72.19 75.00 60.32 640x480 75.00 72.81 59.94 720x400 70.08 [root@localhost simon]# dmesg | grep nouveau [ 3.814015] nouveau 0000:02:00.0: NVIDIA G98 (298200a2) [ 3.927913] nouveau 0000:02:00.0: bios: version 62.98.71.00.05 [ 3.948470] nouveau 0000:02:00.0: bios: M0203T not found [ 3.948471] nouveau 0000:02:00.0: bios: M0203E not matched! [ 3.948472] nouveau 0000:02:00.0: fb: 512 MiB DDR2 [ 4.610407] nouveau 0000:02:00.0: DRM: VRAM: 512 MiB [ 4.610408] nouveau 0000:02:00.0: DRM: GART: 1048576 MiB [ 4.610410] nouveau 0000:02:00.0: DRM: TMDS table version 2.0 [ 4.610411] nouveau 0000:02:00.0: DRM: DCB version 4.0 [ 4.610413] nouveau 0000:02:00.0: DRM: DCB outp 00: 02000300 00000028 [ 4.610414] nouveau 0000:02:00.0: DRM: DCB outp 01: 01000302 00020030 [ 4.610415] nouveau 0000:02:00.0: DRM: DCB outp 02: 04011310 00000028 [ 4.610417] nouveau 0000:02:00.0: DRM: DCB conn 00: 00001030 [ 4.610418] nouveau 0000:02:00.0: DRM: DCB conn 01: 00000200 [ 4.662394] nouveau 0000:02:00.0: DRM: MM: using M2MF for buffer copies [ 4.730340] nouveau 0000:02:00.0: DRM: allocated 1440x900 fb: 0x70000, bo ffff9ac4343e1000 [ 4.730455] fbcon: nouveaufb (fb0) is primary device [ 4.802146] nouveau 0000:02:00.0: fb0: nouveaufb frame buffer device [ 4.815245] [drm] Initialized nouveau 1.3.1 20120801 for 0000:02:00.0 on minor 0 [67832.526226] nouveau 0000:02:00.0: fifo: CACHE_ERROR - ch 7 [kwin_x11[1642]] subc 0 mthd 0060 data beef0201 [68371.783566] nouveau 0000:02:00.0: fifo: CACHE_ERROR - ch 7 [kwin_x11[1642]] subc 0 mthd 0060 data beef0201 called ksystemlog from konsole: journalctl has loads of these: 05/12/2016 11:05 kwin_x11 QXcbConnection: XCB error: 3 (BadWindow), sequence: 1003, resource id: 56894850, major code: 20 (GetProperty), minor code: 0 and these: 05/12/2016 10:26 plasmashell QPainter::end: Painter not active, aborted I uncommented wayland in custom.conf because system was very unstable with it. Xorg.log (had to remove lots to enable post): Information [178054.580] (II) NOUVEAU(0): Hardware support for Present enabled Information [178054.580] (II) NOUVEAU(0): [DRI2] Setup complete Information [178054.580] (II) NOUVEAU(0): [DRI2] DRI driver: nouveau Information [178054.580] (II) NOUVEAU(0): [DRI2] VDPAU driver: nouveau Information [178054.580] (II) Loading sub module "exa" Information [178054.580] (II) LoadModule: "exa" Information [178054.580] (II) Loading /usr/lib64/xorg/modules/libexa.so Information [178054.580] (II) Module exa: vendor="X.Org Foundation" Information [178054.580] compiled for 1.19.0, module version = 2.6.0 Information [178054.580] ABI class: X.Org Video Driver, version 23.0 Information [178054.580] (II) EXA(0): Driver allocated offscreen pixmaps Information [178054.580] (II) EXA(0): Driver registered support for the following operations: Information [178054.580] (II) Solid Information [178054.580] (II) Copy Information [178054.580] (II) Composite (RENDER acceleration) Information [178054.580] (II) UploadToScreen Information [178054.580] (II) DownloadFromScreen Information [178054.580] (==) NOUVEAU(0): Backing store enabled Information [178054.580] (==) NOUVEAU(0): Silken mouse enabled Information [178054.580] (II) NOUVEAU(0): [XvMC] Associated with Nouveau GeForce 8/9 Textured Video. Information [178054.580] (II) NOUVEAU(0): [XvMC] Extension initialized. Information [178054.580] (==) NOUVEAU(0): DPMS enabled Information [178054.580] (II) NOUVEAU(0): RandR 1.2 enabled, ignore the following RandR disabled message. Information [178054.581] (--) RandR disabled Information [178054.584] (II) SELinux: Disabled by boolean Information [178054.606] (II) AIGLX: enabled GLX_MESA_copy_sub_buffer Information [178054.606] (II) AIGLX: enabled GLX_ARB_create_context Information [178054.606] (II) AIGLX: enabled GLX_ARB_create_context_profile Information [178054.606] (II) AIGLX: enabled GLX_EXT_create_context_es{,2}_profile Information [178054.606] (II) AIGLX: enabled GLX_INTEL_swap_event Information [178054.606] (II) AIGLX: enabled GLX_SGI_swap_control Information [178054.606] (II) AIGLX: enabled GLX_EXT_framebuffer_sRGB--------------------------------------------------------- Information [178068.302] (II) NOUVEAU(0): EDID vendor "SAM", prod id 836 Information [178068.302] (II) NOUVEAU(0): Using EDID range info for horizontal sync Information [178068.302] (II) NOUVEAU(0): Using EDID range info for vertical refresh Information [178068.302] (II) NOUVEAU(0): Printing DDC gathered Modelines: Information [178068.302] (II) NOUVEAU(0): Modeline "1440x900"x0.0 106.50 1440 1520 1672 1904 900 903 909 934 -hsync +vsync (55.9 kHz eP) Information [178068.302] (II) NOUVEAU(0): Modeline "1024x768"x0.0 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (48.4 kHz e) Information [178068.302] (II) NOUVEAU(0): Modeline "800x600"x0.0 40.00 800 840 968 1056 600 601 605 628 +hsync +vsync (37.9 kHz e) Information [178068.302] (II) NOUVEAU(0): Modeline "640x480"x0.0 31.50 640 656 720 840 480 481 484 500 -hsync -vsync (37.5 kHz e) Information [178068.302] (II) NOUVEAU(0): Modeline "640x480"x0.0 31.50 640 664 704 832 480 489 492 520 -hsync -vsync (37.9 kHz e) Information [178068.302] (II) NOUVEAU(0): Modeline "640x480"x0.0 25.18 640 656 752 800 480 490 492 525 -hsync -vsync (31.5 kHz e) Information [178068.302] (II) NOUVEAU(0): Modeline "720x400"x0.0 28.32 720 738 846 900 400 412 414 449 -hsync +vsync (31.5 kHz e) Information [178068.302] (II) NOUVEAU(0): Modeline "1024x768"x0.0 78.75 1024 1040 1136 1312 768 769 772 800 +hsync +vsync (60.0 kHz e) Information [178068.302] (II) NOUVEAU(0): Modeline "1024x768"x0.0 75.00 1024 1048 1184 1328 768 771 777 806 -hsync -vsync (56.5 kHz e) Information [178068.302] (II) NOUVEAU(0): Modeline "800x600"x0.0 49.50 800 816 896 1056 600 601 604 625 +hsync +vsync (46.9 kHz e) Information [178068.302] (II) NOUVEAU(0): Modeline "800x600"x0.0 50.00 800 856 976 1040 600 637 643 666 +hsync +vsync (48.1 kHz e) Information [178068.302] (II) NOUVEAU(0): Modeline "1440x900"x0.0 136.75 1440 1536 1688 1936 900 903 909 942 -hsync +vsync (70.6 kHz e) Information [178068.302] (II) NOUVEAU(0): Modeline "1152x864"x0.0 108.00 1152 1216 1344 1600 864 865 868 900 +hsync +vsync (67.5 kHz e) Information [178069.858] (II) NOUVEAU(0): EDID vendor "SAM", prod id 836 Information [178069.858] (II) NOUVEAU(0): Using hsync ranges from config file Information [178069.858] (II) NOUVEAU(0): Using vrefresh ranges from config file Information [178069.858] (II) NOUVEAU(0): Printing DDC gathered Modelines: Information [178069.858] (II) NOUVEAU(0): Modeline "1440x900"x0.0 106.50 1440 1520 1672 1904 900 903 909 934 -hsync +vsync (55.9 kHz eP) Information [178069.858] (II) NOUVEAU(0): Modeline "1024x768"x0.0 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (48.4 kHz e) Information [178069.858] (II) NOUVEAU(0): Modeline "800x600"x0.0 40.00 800 840 968 1056 600 601 605 628 +hsync +vsync (37.9 kHz e) Information [178069.858] (II) NOUVEAU(0): Modeline "640x480"x0.0 31.50 640 656 720 840 480 481 484 500 -hsync -vsync (37.5 kHz e) Information [178069.858] (II) NOUVEAU(0): Modeline "640x480"x0.0 31.50 640 664 704 832 480 489 492 520 -hsync -vsync (37.9 kHz e) Information [178069.858] (II) NOUVEAU(0): Modeline "640x480"x0.0 25.18 640 656 752 800 480 490 492 525 -hsync -vsync (31.5 kHz e) Information [178069.858] (II) NOUVEAU(0): Modeline "720x400"x0.0 28.32 720 738 846 900 400 412 414 449 -hsync +vsync (31.5 kHz e) Information [178069.858] (II) NOUVEAU(0): Modeline "1024x768"x0.0 78.75 1024 1040 1136 1312 768 769 772 800 +hsync +vsync (60.0 kHz e) Information [178069.858] (II) NOUVEAU(0): Modeline "1024x768"x0.0 75.00 1024 1048 1184 1328 768 771 777 806 -hsync -vsync (56.5 kHz e) Information [178069.858] (II) NOUVEAU(0): Modeline "800x600"x0.0 49.50 800 816 896 1056 600 601 604 625 +hsync +vsync (46.9 kHz e) Information [178069.858] (II) NOUVEAU(0): Modeline "800x600"x0.0 50.00 800 856 976 1040 600 637 643 666 +hsync +vsync (48.1 kHz e) Information [178069.858] (II) NOUVEAU(0): Modeline "1440x900"x0.0 136.75 1440 1536 1688 1936 900 903 909 942 -hsync +vsync (70.6 kHz e) Information [178069.858] (II) NOUVEAU(0): Modeline "1152x864"x0.0 108.00 1152 1216 1344 1600 864 865 868 900 +hsync +vsync (67.5 kHz e) Information [179160.966] (II) NOUVEAU(0): EDID vendor "SAM", prod id 836 Information [179160.966] (II) NOUVEAU(0): Using hsync ranges from config file Information [179160.966] (II) NOUVEAU(0): Using vrefresh ranges from config file Information [179160.966] (II) NOUVEAU(0): Printing DDC gathered Modelines: Information [179160.966] (II) NOUVEAU(0): Modeline "1440x900"x0.0 106.50 1440 1520 1672 1904 900 903 909 934 -hsync +vsync (55.9 kHz eP) Information [179160.966] (II) NOUVEAU(0): Modeline "1024x768"x0.0 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (48.4 kHz e) Information [179160.966] (II) NOUVEAU(0): Modeline "800x600"x0.0 40.00 800 840 968 1056 600 601 605 628 +hsync +vsync (37.9 kHz e) Information [179160.966] (II) NOUVEAU(0): Modeline "640x480"x0.0 31.50 640 656 720 840 480 481 484 500 -hsync -vsync (37.5 kHz e) Information [179160.966] (II) NOUVEAU(0): Modeline "640x480"x0.0 31.50 640 664 704 832 480 489 492 520 -hsync -vsync (37.9 kHz e) Information [179160.966] (II) NOUVEAU(0): Modeline "640x480"x0.0 25.18 640 656 752 800 480 490 492 525 -hsync -vsync (31.5 kHz e) Information [179160.967] (II) NOUVEAU(0): Modeline "720x400"x0.0 28.32 720 738 846 900 400 412 414 449 -hsync +vsync (31.5 kHz e) Information [179160.967] (II) NOUVEAU(0): Modeline "1024x768"x0.0 78.75 1024 1040 1136 1312 768 769 772 800 +hsync +vsync (60.0 kHz e) Information [179160.967] (II) NOUVEAU(0): Modeline "1024x768"x0.0 75.00 1024 1048 1184 1328 768 771 777 806 -hsync -vsync (56.5 kHz e) Information [179160.967] (II) NOUVEAU(0): Modeline "800x600"x0.0 49.50 800 816 896 1056 600 601 604 625 +hsync +vsync (46.9 kHz e) Information [179160.967] (II) NOUVEAU(0): Modeline "800x600"x0.0 50.00 800 856 976 1040 600 637 643 666 +hsync +vsync (48.1 kHz e) Information [179160.967] (II) NOUVEAU(0): Modeline "1440x900"x0.0 136.75 1440 1536 1688 1936 900 903 909 942 -hsync +vsync (70.6 kHz e) Information [179160.967] (II) NOUVEAU(0): Modeline "1152x864"x0.0 108.00 1152 1216 1344 1600 864 865 868 900 +hsync +vsync (67.5 kHz e) Kernel.log (truncated so I can post): 02/12/2016 15:28 pci 0000 0:1e.0: System wakeup disabled by ACPI 02/12/2016 15:28 pci 0000 0:1f.0: [8086:3a16] type 00 class 0x060100 02/12/2016 15:28 pci 0000 0:1f.0: quirk: [io 0x0800-0x087f] claimed by ICH6 ACPI/GPIO/TCO 02/12/2016 15:28 pci 0000 0:1f.0: quirk: [io 0x0500-0x053f] claimed by ICH6 GPIO ------------------------------------------------------------------------------ 02/12/2016 15:28 scsi host0 ahci 02/12/2016 15:28 scsi host1 ahci 02/12/2016 15:28 scsi host2 ahci 02/12/2016 15:28 scsi host3 ahci 02/12/2016 15:28 scsi host4 ahci 02/12/2016 15:28 scsi host5 ahci 02/12/2016 15:28 ata1 SATA max UDMA/133 abar m2048@0xf7ffc000 port 0xf7ffc100 irq 28 02/12/2016 15:28 ata2 SATA max UDMA/133 abar m2048@0xf7ffc000 port 0xf7ffc180 irq 28 02/12/2016 15:28 ata3 SATA max UDMA/133 abar m2048@0xf7ffc000 port 0xf7ffc200 irq 28 02/12/2016 15:28 ata4 SATA max UDMA/133 abar m2048@0xf7ffc000 port 0xf7ffc280 irq 28 02/12/2016 15:28 ata5 SATA max UDMA/133 abar m2048@0xf7ffc000 port 0xf7ffc300 irq 28 02/12/2016 15:28 ata6 SATA max UDMA/133 abar m2048@0xf7ffc000 port 0xf7ffc380 irq 28 02/12/2016 15:28 ahci 0000 3:00.0: AHCI 0001.0200 32 slots 8 ports 6 Gbps 0xff impl SATA mode ---------------------------------------------------------------------------- 02/12/2016 15:28 Loaded X.509 cert 'Fedora kernel signing key: 2d70f64f8fe6e48202fcc78b2f4ef3aa95acc7b6' 02/12/2016 15:28 zswap loaded using pool lzo/zbud 02/12/2016 15:28 Key type big_key registered 02/12/2016 15:28 Magic number 12:702:486 02/12/2016 15:28 rtc_cmos 00 1: setting system clock to 2016-12-02 15:28:08 UTC (1480692488) 02/12/2016 15:28 PM Hibernation image not present or could not be loaded. 02/12/2016 15:28 input AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input2 02/12/2016 15:28 random fast init done 02/12/2016 15:28 ata13 SATA link down (SStatus 0 SControl 310) 02/12/2016 15:28 ata11 SATA link down (SStatus 0 SControl 310) 02/12/2016 15:28 ata7 SATA link up 6.0 Gbps (SStatus 133 SControl 330) 02/12/2016 15:28 ata12 SATA link down (SStatus 0 SControl 310) 02/12/2016 15:28 ata8 SATA link down (SStatus 0 SControl 310) 02/12/2016 15:28 ata9 SATA link down (SStatus 0 SControl 310) 02/12/2016 15:28 ata14 SATA link up 1.5 Gbps (SStatus 113 SControl 330) 02/12/2016 15:28 ata10 SATA link down (SStatus 0 SControl 310) 02/12/2016 15:28 ata14.00 ATAPI: MARVELL VIRTUALL, 1.09, max UDMA/66 ------------------------------------------------------------------------------- 02/12/2016 15:28 ata2 SATA link up 3.0 Gbps (SStatus 123 SControl 300) 02/12/2016 15:28 ata2.00 ATA-8: SAMSUNG HD103SJ, 1AJ10001, max UDMA/133 02/12/2016 15:28 ata2.00 1953525168 sectors, multi 0: LBA48 NCQ (depth 31/32), AA 02/12/2016 15:28 ata2.00 configured for UDMA/133 02/12/2016 15:28 scsi 1 :0:0: Direct-Access ATA SAMSUNG HD103SJ 0001 PQ: 0 ANSI: 5 02/12/2016 15:28 usb 8-1 new low-speed USB device number 2 using uhci_hcd 02/12/2016 15:28 tsc Refined TSC clocksource calibration: 2672.726 MHz 02/12/2016 15:28 clocksource tsc: mask: 0xffffffffffffffff max_cycles: 0x26869978d87, max_idle_ns: 440795234823 ns 02/12/2016 15:28 sd 1 :0:0: Attached scsi generic sg1 type 0 02/12/2016 15:28 sd 1 :0:0: [sdb] 1953525168 512-byte logical blocks: (1.00 TB/932 GiB) 02/12/2016 15:28 sd 1 :0:0: [sdb] Write Protect is off 02/12/2016 15:28 sd 1 :0:0: [sdb] Mode Sense: 00 3a 00 00 02/12/2016 15:28 sd 1 :0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA 02/12/2016 15:28 sd 1 :0:0: [sdb] Attached SCSI disk ---------------------------------------------------------------------------- 02/12/2016 15:28 ata3 SATA link down (SStatus 0 SControl 300) 02/12/2016 15:28 ata4 SATA link down (SStatus 0 SControl 300) 02/12/2016 15:28 ata5 SATA link down (SStatus 0 SControl 300) 02/12/2016 15:28 clocksource Switched to clocksource tsc 02/12/2016 15:28 ata6 SATA link down (SStatus 0 SControl 300) 02/12/2016 15:28 scsi 6 :0:0: Direct-Access ATA SanDisk Ultra II 00RL PQ: 0 ANSI: 5 02/12/2016 15:28 sd 6 :0:0: Attached scsi generic sg2 type 0 02/12/2016 15:28 sd 6 :0:0: [sdc] 1875385008 512-byte logical blocks: (960 GB/894 GiB) 02/12/2016 15:28 sd 6 :0:0: [sdc] Write Protect is off 02/12/2016 15:28 sd 6 :0:0: [sdc] Mode Sense: 00 3a 00 00 02/12/2016 15:28 scsi 13 :0:0: Processor Marvell 91xx Config 1.01 PQ: 0 ANSI: 5 02/12/2016 15:28 sd 6 :0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA 02/12/2016 15:28 scsi 13 :0:0: Attached scsi generic sg3 type 3 02/12/2016 15:28 sdc sdc1 sdc2 02/12/2016 15:28 sd 6 :0:0: [sdc] Attached SCSI disk 02/12/2016 15:28 Freeing unused kernel memory: 1608K (ffffffffb8f64000 - ffffffffb90f6000) 02/12/2016 15:28 Write protecting the kernel read-only data: 14336k 02/12/2016 15:28 Freeing unused kernel memory: 2004K (ffff9ac39880b000 - ffff9ac398a00000) 02/12/2016 15:28 Freeing unused kernel memory: 756K (ffff9ac398d43000 - ffff9ac398e00000) 02/12/2016 15:28 x86/mm Checked W+X mappings: passed, no W+X pages found. 02/12/2016 15:28 systemd[1] systemd 231 running in system mode. (+PAM +AUDIT +SELINUX +IMA -APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN) ------------------------------------------------------------------------------ 02/12/2016 15:28 ahc_pci :1:0: Host Adapter Bios disabled. Using default SCSI device parameters 02/12/2016 15:28 MXM GUID detected in BIOS 02/12/2016 15:28 nouveau 0000 2:00.0: NVIDIA G98 (298200a2) 02/12/2016 15:28 nouveau 0000 2:00.0: bios: version 62.98.71.00.05 02/12/2016 15:28 nouveau 0000 2:00.0: bios: M0203T not found 02/12/2016 15:28 nouveau 0000 2:00.0: bios: M0203E not matched! 02/12/2016 15:28 nouveau 0000 2:00.0: fb: 512 MiB DDR2 02/12/2016 15:28 firewire_core 0000 8:02.0: created device fw0: GUID 001e8c0001c13fe7, S400 02/12/2016 15:28 [TTM] Zone kernel Available graphics memory: 3050326 kiB 02/12/2016 15:28 [TTM] Zone dma32 Available graphics memory: 2097152 kiB 02/12/2016 15:28 [TTM] Initializing pool allocator 02/12/2016 15:28 [TTM] Initializing DMA pool allocator 02/12/2016 15:28 nouveau 0000 2:00.0: DRM: VRAM: 512 MiB 02/12/2016 15:28 nouveau 0000 2:00.0: DRM: GART: 1048576 MiB 02/12/2016 15:28 nouveau 0000 2:00.0: DRM: TMDS table version 2.0 02/12/2016 15:28 nouveau 0000 2:00.0: DRM: DCB version 4.0 02/12/2016 15:28 nouveau 0000 2:00.0: DRM: DCB outp 00: 02000300 00000028 02/12/2016 15:28 nouveau 0000 2:00.0: DRM: DCB outp 01: 01000302 00020030 02/12/2016 15:28 nouveau 0000 2:00.0: DRM: DCB outp 02: 04011310 00000028 02/12/2016 15:28 nouveau 0000 2:00.0: DRM: DCB conn 00: 00001030 02/12/2016 15:28 nouveau 0000 2:00.0: DRM: DCB conn 01: 00000200 02/12/2016 15:28 [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). 02/12/2016 15:28 [drm] Driver supports precise vblank timestamp query. 02/12/2016 15:28 nouveau 0000 2:00.0: DRM: MM: using M2MF for buffer copies 02/12/2016 15:28 nouveau 0000 2:00.0: DRM: allocated 1440x900 fb: 0x70000, bo ffff9ac4343e1000 02/12/2016 15:28 fbcon nouveaufb (fb0) is primary device 02/12/2016 15:28 Console switching to colour frame buffer device 180x56 02/12/2016 15:28 nouveau 0000 2:00.0: fb0: nouveaufb frame buffer device 02/12/2016 15:28 [drm] Initialized nouveau 1.3.1 20120801 for ------------------------------------------------------------------------------ 05/12/2016 05:52 ksystemlog[26847] segfault at 18 ip 00007f675f16c60f sp 00007fff95167e20 error 4 in libQt5Gui.so.5.7.0[7f675f096000+489000] I'm no expert interpreting these logs so any would be much appreciated