Created attachment 35138 [details] Nouveau dmesg chatter Hard hang on suspend. X not involved; happens in single-user with nouveau loaded and providing framebuffer console, suspend done via pm-suspend (also hangs in X if suspend attempted). System locked up, no response to alt-sysrq magic keys, full CPU burn (judging from fan). Nouveau-related dmesg chatter attached; more info on request. Other than that, driver performs well for ordinary use. Chip runs hotter and fan-speed stays higher, but visuals are about the same as the proprietary nvidia driver. Machine is an Everex laptop, Turion X2 x68-64, nvidia chipset.
Created attachment 35139 [details] Nouveau dmesg chatter, text format Also: all components including kernel pulled from git and built today.
Can't you see the full kernel logs in /var/log/ after rebooting ? Complete logs from boot up to to the point where the machine locked up could be useful.
Created attachment 35141 [details] Complete dmesg, minimal kernel, some debugging enabled I made a minimal-testbed kernel, with some debugging enabled, brought it up to single-user, copied the dmesg, did pm-suspend, waited a while, pushed reboot.
Created attachment 35142 [details] pm-suspend.log Found pm-suspend.log in /var/log. dmesg and kernal messages apparently aren't saved to disk in single-user before the pm-suspend hangs the system.
I booted with the "no_console_suspend" parameter and got a little more info: [DRM] nouveau <suspend chatter> [DRM] nouveau 0000:05:00.0 And we're gone! nouveau 0000:05:00.0 PCI INT A Disabled (machine hangs with full cpu burn) This is with a minimal testbed kernel. I tried putting a return(-ENODEV) in the top of nouveau_drv.c::pm_suspend(), and the machine still hung.
Created attachment 35192 [details] [review] Very crude hacks that appear to sort of work I have done some printk-debugging, and come up with some preliminary results and a patch that works in my minimal testbed kernel, suspending the fb-console in single-user and resuming multiple times. It appears that acquire_console_sem() may be hanging things, and it is pretty clear that one or more of the pci calls, such as pci_set_power_state(pdev, PCI_D3hot), are hanging. I'll see if this works multi-user suspending from X. This is *not* recommended as a patch, just as an indication of where the problems may lie.
I applied this patch to my working nouveau git kernel, and it is working well enough that I suspended and resumed after the comma in this sentence, which makes nouveau fully usable for my purposes. Hopefully a proper fix will be developed at some point.
It appears that this bug report has laid dormant for quite a while. Sorry we haven't gotten to it. Since we fix bugs all the time, chances are pretty good that your issue has been fixed with the latest software. Please give it a shot. (Linux kernel 3.10.7, xf86-video-nouveau 1.0.9, mesa 9.1.6, or their git versions.) If upgrading to the latest isn't an option for you, your distro's bugzilla is probably the right destination for your bug report. In an effort to clean up our bug list, we're pre-emptively closing all bugs that haven't seen updates since 2011. If the original issue remains, please make sure to provide fresh info, see http://nouveau.freedesktop.org/wiki/Bugs/ for what we need to see, and re-open this one. Thanks, The Nouveau Team
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.