Buggy nouveau driver in recent kernels; resume from hibernate fails

ordealbyfire83 · 11-08-2014, 11:15 AM

There seems to be some serious problems with the nouveau driver in recent (since 2012) kernels. It is sometimes impossible to resume from hibernating.

If I boot LFS, hibernate, and resume again, everything works as it should. I have not encountered any issues with this in kernel 3.14.4. I have read numerous threads from 2012 from people stating that hibernating is unreliable for them. However, in this instance I don't seem to have any issue.

The issue is when I boot LFS, hibernate; boot some other OS, hibernate; try to resume LFS. It NEVER works. I get the half of my screen purple with some assorted other colored pixels thrown in at random, and the other half white. The keyboard is unresponsive. However if I press CTRL+ALT+F1 enough times (sometimes even holding those keys in for a few seconds) it "might" bring me to the terminal. I can see messages like

nouveau E[X[10179]] reloc wait_idle_failed: -16

as well as ... apply: -16

If I try to kill X and restart it from the terminal, it may very well start but the screen goes back to purple/white, and it will never take me back to the terminal regardless of how long I wait pressing CTRL+ALT+F1.

It doesn't seem like people have reported issues like this for a while, but clearly something isn't right. My graphics card is NVidia GeForce GO 7300. I really don't want to use the proprietary NVidia driver on LFS but it looks like it might come to that.

I've browsed some of the forums and even some of the source code. It seems like there were problems where the nouveau driver was "expecting" the graphics card to be in the same state that it was when it hibernated. But something still isn't right.

Is there anything else I can do shy of using NVidia's driver? Thanks.

ReaperX7 · 11-08-2014, 07:15 PM

Which versions of xf86-video-nouveau, libdrm, libmesa, kernel, and x-session are you using?

ordealbyfire83 · 11-08-2014, 11:04 PM

It looks like

xf86-video-nouveau-1.0.10
libdrm-2.4.54
MesaLib-10.1.4
Linux-3.14.4

I'm not sure about x-session though. Is this part of another package?

ReaperX7 · 11-09-2014, 03:09 AM

I would try and rebuild those packaging using the updates from the Development book of BLFS. That might fix your problem.

The updated versions are:

Libmesa-10.3.2
libdrm-2.4.58
xf86-video-nouveau-1.0.11
Linux-3.17.2
Xorg-Server-1.16.1

You also should optionally look into resolving these dependencies and including these packages:

libclc - adds OpenCL support. Works more for Radeon, but should be supported by nouveau.

libtxc-dxtn - adds S3TC support. Circular dependency to libmesa which must be rebuilt against it. Be warned that this prevents non-personal deployment due to license restriction. You'll need to rebuild with the flags for it. No link provided but it can be Google searched.

Driconf - Configuration tool for DRI and Mesa. Effective replacement for Nvidia Controls for the free driver.

ordealbyfire83 · 11-11-2014, 04:47 PM

Thanks for the suggestions. I tried a couple combinations of things, but unfortunately updating these things makes the problem a whole lot worse.

First, I tried updating just xf86-video-nouveau. This causes failure on every resume (not just after hibernating, booting another os, and then resuming LFS). Upon resuming, the backlight turns on and I can see the mouse pointer which moves freely. Typically I would be presented with the unlock screen box, as I'm using Mate. Taking a shot in the dark, I typed my password and pressed enter. The mouse pointer turned into the little "toothed" wheel from the DMZ theme and then back to the regular arrow but the screen stayed dark. Perhaps my desktop is actually there, but it just isn't visible. I can then press CTRL+ALT+F1, log in, and issue a clean shutdown. I don't see any X/nouveau errors on the console this time. Also, Restarting X/gdm just presents me with another blank screen.

Then I tried updating drm/mesa/xf86-video-nouveau. I ran "make uninstall" from the old versions first to cleanly remove them. There seems to be some regressions, as 3D effects do not work. glxgears does not start and compiz loads everything but the gl plugin.

I then uninstalled these and recompiled the original versions that I had initially. Upon my first hibernate/resume cycle, I had to do a hard reset because the cpu was presumably at 100% and the disk activity light was solid. Checking the kernel logs from a live cd, I saw many hundreds (if not over a thousand) entries of

Nov 11 16:26:20 <hostname> kernel: [ 235.394846] nouveau E[ PGRAPH][0000:01:00.0] ERROR nsource: METHOD_CNT nstatus: INVALID_STATE
Nov 11 16:26:20 <hostname> kernel: [ 235.394853] nouveau E[ PGRAPH][0000:01:00.0] ch 0 [0x00041020 DRM] subc 3 class 0x004a mthd 0x0c90 data 0x00000000

Then I booted up and hibernated, and resumed and it worked just once. Since then I've been suspending instead of hibernating.

I guess I can't expect too much from this. Debian Wheezy was the first distro that actually gave me 3D effects with the nouveau driver for this graphics card. It looks like these problems are even worse in kernels > 3.15.

ReaperX7 · 11-12-2014, 02:07 AM

Usually, nouveau will kick out a few warnings on boot. It varies card to card over what exact features are used, but generally those are harmless because they are features failing to register because they don't exist.

Suspend has always been very fickle on Linux, though Hibernation tends to work better.

If it's any consolation, if Nouveau doesn't work for you, you could give the Nvidia OEM driver a try.

ordealbyfire83 · 11-16-2014, 11:37 AM

My apologies for the delay. This doesn't look too promising. Installing the nvidia driver has been nothing short of a nightmare. Aside from figuring out how to "configure" the kernel headers (nowhere do they tell you to run 'make scripts') I had some difficulty with a couple patches. This is always a pain when the directory is designed to delete itself any time something does wrong.

I am trying to use version 304.88 which the Nvidia site says is the recommended or latest driver for this card but it is from last year. After a lot of rigamarole the module finally installed, but upon trying to start, it complains of not supporting X server >= 1.15. There is an option to disable this ABI check, but using this option makes everything hang with a black screen. The only way out is a hard reset.

So, I tried downgrading X server from 1.15.1 to 1.14.5 which seems to have been released around the same time as the nvidia driver. (First, I uninstalled all of the X drivers, and afterward recompiled them against the older X server.) Then I reinstalled the nvidia driver and tried to boot. Everything looks good booting up, but after the display manager tries to start, the screen goes dark and everything locks.

I have to do a hard reset. I went through this twice, and each time there was some damage to the file system. Both times the Xorg.0.log files got hosed and moved to /lost+found (strangely only files in /var/log were damaged). Examining them in /lost+found (or what's left of them), they don't show anything out of the ordinary but they seem to have not finished. Examining the kernel logs, it looks like some nouveau "stuff" is still trying to load, and there is a warning saying to unload any conflicting modules. I did of course disable nouveau on boot, and booting without the nvidia module does not load any nouveau drivers and does not show this warning in the kernel log.

Using the older X server has some effect on nouveau, though. Hibernate seems more reliable when booting another OS has not occurred. I was able to get 10 successful resumes out of this. However, when another OS has been booted, I only get the purple/white screen about a third of the time while the other times the screen is black with a responsive keyboard. On one attempt resuming actually worked. When the screen is black, I could still change terminals and issue a clean shutdown even despite not seeing anything on the screen.

What about just using the vesa driver? If I could coax it into giving me more colors and 1280x800 I would just use that.

ordealbyfire83 · 11-16-2014, 02:23 PM

I just noticed there is another (newer) driver 304.123 which supports this card that is available if I tell their site to show all available drivers instead of the recommended one. This compiles without needing patched but does much the same thing. After looking at the logs, it looks like X doesn't finish starting because of a kernel paging problem. The kernel doesn't panic though - to test this I plugged in a blank flash drive and the kernel log shows this.

Code:

Nov 16 21:03:11 <hostname> kernel: [   17.727741] BUG: unable to handle kernel paging request at fffffff8
Nov 16 21:03:11 <hostname> kernel: [   17.727748] IP: [<c14c305f>] acpi_device_probe+0x45/0xca
Nov 16 21:03:11 <hostname> kernel: [   17.727758] *pde = 0224e067 *pte = 00000000 
Nov 16 21:03:11 <hostname> kernel: [   17.727762] Oops: 0002 [#1] SMP 
Nov 16 21:03:11 <hostname> kernel: [   17.727765] Modules linked in: bluetooth 6lowpan_iphc iptable_nat nf_nat_ipv4 nf_nat xt_LOG coretemp kvm_intel nvidia(PO) kvm firewire_ohci serio_raw firewire_core
Nov 16 21:03:11 <hostname> kernel: [   17.727780] CPU: 1 PID: 2021 Comm: X Tainted: P           O 3.14.4 #1
Nov 16 21:03:11 <hostname> kernel: [   17.727783] Hardware name: <hostname> Inc. MM061                           /0XD720, BIOS A17 06/13/2007
Nov 16 21:03:11 <hostname> kernel: [   17.727786] task: f6104ac0 ti: f508c000 task.ti: f508c000
Nov 16 21:03:11 <hostname> kernel: [   17.727789] EIP: 0060:[<c14c305f>] EFLAGS: 00213246 CPU: 1
Nov 16 21:03:11 <hostname> kernel: [   17.727792] EIP is at acpi_device_probe+0x45/0xca
Nov 16 21:03:11 <hostname> kernel: [   17.727795] EAX: f5ba9204 EBX: 00000000 ECX: 00000000 EDX: 00000000
Nov 16 21:03:11 <hostname> kernel: [   17.727797] ESI: 00000000 EDI: f5ba92b8 EBP: f508dca0 ESP: f508dc90
Nov 16 21:03:11 <hostname> kernel: [   17.727799]  DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
Nov 16 21:03:11 <hostname> kernel: [   17.727802] CR0: 80050033 CR2: fffffff8 CR3: 0003c000 CR4: 000007d0
Nov 16 21:03:11 <hostname> kernel: [   17.727805] Stack:
Nov 16 21:03:11 <hostname> kernel: [   17.727806]  f61b6400 f61b6544 ffffffed f5ba92b8 f508dcc4 c173590c f61b6544 f5ba92b8
Nov 16 21:03:11 <hostname> kernel: [   17.727813]  00000000 f508dcc4 f61b6544 f5ba92b8 f61b6578 f508dcd8 c1735b19 f5ba92b8
Nov 16 21:03:11 <hostname> kernel: [   17.727819]  c1735a90 00000000 f508dcf4 c1734342 f60cbb5c f61982d4 c20f43d0 f49449c0
Nov 16 21:03:11 <hostname> kernel: [   17.727826] Call Trace:
Nov 16 21:03:11 <hostname> kernel: [   17.727833]  [<c173590c>] driver_probe_device+0x5c/0x1e0
Nov 16 21:03:11 <hostname> kernel: [   17.727837]  [<c1735b19>] __driver_attach+0x89/0x90
Nov 16 21:03:11 <hostname> kernel: [   17.727841]  [<c1735a90>] ? driver_probe_device+0x1e0/0x1e0
Nov 16 21:03:11 <hostname> kernel: [   17.727845]  [<c1734342>] bus_for_each_dev+0x42/0x70
Nov 16 21:03:11 <hostname> kernel: [   17.727849]  [<c173550c>] driver_attach+0x1c/0x30
Nov 16 21:03:11 <hostname> kernel: [   17.727853]  [<c1735a90>] ? driver_probe_device+0x1e0/0x1e0
Nov 16 21:03:11 <hostname> kernel: [   17.727857]  [<c1735164>] bus_add_driver+0xd4/0x1e0
Nov 16 21:03:11 <hostname> kernel: [   17.727861]  [<c17360d4>] driver_register+0x54/0xe0
Nov 16 21:03:11 <hostname> kernel: [   17.727865]  [<c14c3964>] acpi_bus_register_driver+0x3a/0x3c
Nov 16 21:03:11 <hostname> kernel: [   17.727981]  [<f9983b01>] nv_acpi_init+0xf1/0x1b0 [nvidia]
Nov 16 21:03:11 <hostname> kernel: [   17.728064]  [<f9980768>] nv_kern_ctl_open+0x78/0xb0 [nvidia]
Nov 16 21:03:11 <hostname> kernel: [   17.728146]  [<f9980afd>] nv_kern_open+0x35d/0x6d0 [nvidia]
Nov 16 21:03:11 <hostname> kernel: [   17.728150]  [<c1737e19>] ? kobj_lookup+0xd9/0x120
Nov 16 21:03:11 <hostname> kernel: [   17.728155]  [<c11281d0>] ? mount_fs+0x160/0x160
Nov 16 21:03:11 <hostname> kernel: [   17.728159]  [<c11289e0>] chrdev_open+0x90/0x150
Nov 16 21:03:11 <hostname> kernel: [   17.728165]  [<c1122cfe>] do_dentry_open+0x20e/0x280
Nov 16 21:03:11 <hostname> kernel: [   17.728168]  [<c1128950>] ? cdev_put+0x20/0x20
Nov 16 21:03:11 <hostname> kernel: [   17.728172]  [<c1122eed>] finish_open+0x2d/0x40
Nov 16 21:03:11 <hostname> kernel: [   17.728177]  [<c11315cc>] do_last+0x4fc/0xbf0
Nov 16 21:03:11 <hostname> kernel: [   17.728180]  [<c112e601>] ? __inode_permission+0x31/0x70
Nov 16 21:03:11 <hostname> kernel: [   17.728183]  [<c112e651>] ? inode_permission+0x11/0x50
Nov 16 21:03:11 <hostname> kernel: [   17.728187]  [<c112ea61>] ? link_path_walk+0x51/0x700
Nov 16 21:03:11 <hostname> kernel: [   17.728191]  [<c1131d6b>] path_openat+0xab/0x530
Nov 16 21:03:11 <hostname> kernel: [   17.728195]  [<c113bf99>] ? notify_change+0x229/0x340
Nov 16 21:03:11 <hostname> kernel: [   17.728199]  [<c11329c0>] do_filp_open+0x30/0x80
Nov 16 21:03:11 <hostname> kernel: [   17.728204]  [<c1124300>] do_sys_open+0x110/0x200
Nov 16 21:03:11 <hostname> kernel: [   17.728208]  [<c112440d>] SyS_open+0x1d/0x20
Nov 16 21:03:11 <hostname> kernel: [   17.728214]  [<c1c4cfc6>] sysenter_do_call+0x12/0x28
Nov 16 21:03:11 <hostname> kernel: [   17.728219]  [<c1c40000>] ? add_new_disk+0x1ca/0x446
Nov 16 21:03:11 <hostname> kernel: [   17.728221] Code: 00 8b 57 f4 66 be da ff 85 d2 0f 84 96 00 00 00 8d 80 bc fe ff ff 89 45 f0 ff d2 85 c0 89 c6 0f 85 81 00 00 00 8d 87 4c ff ff ff <89> 43 f8 83 7f fc 00 74 6b 8b 83 bc fe ff ff 83 f8 04 75 0c 8b
Nov 16 21:03:11 <hostname> kernel: [   17.728228] EIP: [<c14c305f>] acpi_device_probe+0x45/0xca SS:ESP 0068:f508dc90
Nov 16 21:03:11 <hostname> kernel: [   17.728228] CR2: 00000000fffffff8
Nov 16 21:03:11 <hostname> kernel: [   17.728228] ---[ end trace 9b057f8a3c2ffe62 ]---

ReaperX7 · 11-17-2014, 12:38 AM

Are you using a custom kernel or an imported kernel configuration?

ordealbyfire83 · 11-17-2014, 04:48 PM

It's a customized configuration but not too much different from Debian's. I mainly just disabled SELinux and changed some of the crypto options.

I used this same exact .config file on 3.13 and this problem does not occur. Now I am able to load the nvidia module (304.88 with patches) just fine. I was just finally able to boot into my desktop and get GL things working. At first glxgears complained about not finding swrast (likewise, compiz complained as well and caused my desktop to go dark). I had to recompile Mesa because for some reason these were expecting to find swrast in prefix / instead of /usr. This may have been due to a time that nvidia-uninstall failed during the many attempts at installing/uninstalling.

So right now I have nvidia working and hibernate seems to be working. I have to watch this over time, and won't conclude that this sufficiently works, yet.

Using kernel 3.13, I should add that hibernate/resume (including that of booting another OS) with nouveau works "far better" than in 3.14. It seems to work approximately 5 out of 6 times. Last night I really put this through the test, booting BLFS, hibernating while glx gears was running, and the same for Ubuntu Hardy. Every time, BLFS resumed perfectly. However, this morning resuming failed immediately with purple/white screen.

This is only a qualitative observation (and I have no idea what would be the basis for this), but in testing this so many times, I find that when I let this sit for more than a few minutes (turned off) and then try to resume, it is much, much more likely to fail.

When nouveau does fail with 3.13 it is always with the following message:

Code:

nouveau E[   PFIFO][0000:01:00.0] still angry after 101 spins, halt

ReaperX7 · 11-17-2014, 08:22 PM

I'm currently using the latest kernel 3.17.3 for LFS without any issues with hibernation and I use Nouveau myself.

ordealbyfire83 · 11-29-2014, 11:41 AM

Good call on using kernel 3.17. I've been using it with the nouveau driver, hibernating and resuming successfully for about 5 days now, and it seems to work ok. It's still a bit early to tell whether this is safe enough for "production use," but things definitely look good. I am using the same kernel configuration with xf86-video-nouveau-1.0.10, libdrm-2.4.54, and MesaLib-10.1.4 (all that I originally used), but still the older XServer-1.14.5.

Compared to the NVidia driver it seems that fonts look a bit more "sharp" this time. Using the NVidia driver was not without its problems, though. While hibernate/resume worked as far as I could test it, there is a now six year-old bug that really garbles some portions of application windows, particularly when scrolling (firefox, especially) when used in conjunction with compositing (there is a CCSM option "Force complete redraw on initial damage" that makes the problem about 60% better, but still annoying). Also, I had issues with desktops going black (but still "being there," fully functional) when using fast-user-switching - to work around that, I put a launcher in the middle of my panel that ran "marco --replace" - this turns off compositing and makes everything visible again. There is a further problem when running Wine programs. Wine spits out errors with regarding "Broken NVIDIA RANDR" which causes the programs to launch but be all black. I was able to work around this by selecting the "Emulate a virtual desktop" option in winecfg. Downgrading xrandr would be their solution but suffice to say NVidia has work to do.

ordealbyfire83 · 12-11-2014, 01:54 PM

Not so fast. I had a good "run" with this but now the bug is back. I haven't installed/uninstalled anything on B/LFS for a couple weeks now so no other software changes should be at play here. Definitely not suitable for production use.

Unknown3rdParty · 04-13-2015, 07:45 AM

I have been having this same problem as well; I've found that running a screensaver exacerbates the problem. I've had to kill the xscreensaver daemon after a restart and my system now runs for days without any apparent issues:

Fedora 21
Kernel: 3.19.2-201
Card: NVIDIA Corporation G96 [GeForce 9500 GT] (rev a1)
Xorg: xorg-x11-drv-nouveau-1.0.11-1

I have not downgraded my kernel in an attempt to fix this.

ordealbyfire83 · 04-14-2015, 09:00 PM

That may or may not be the same issue, if you can otherwise resume to the point of it succeeding but only without xscreensaver. You may want to look through the nouveau bugs on freedesktop.org. It seems nouveau is in very sad shape for most people now, and that likely won't change soon. Unless you can find THE VERY LATEST kernel version that works flawlessly for you and bisect against the problematic version and undo those commits, it's very likely you'll just be at the mercy of whatever workaround happens to work for you. Linux Mint's front-page solution right now is essentially "give up and install the NVIDIA driver."