This problem was originally reported here: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/754711 The system works correctly with the Ubuntu-patched 2.6.35 Kernel as shipped with Ubuntu 10.10, but fails with the 2.6.38 kernel from Ubuntu 11.04. While tracking down this problem, I tested several mainline kernels, all of which also fail to suspend/resume on this system, as I describe below. Steps to reproduce: - try to enter suspend mode (I used sudo pm-suspend) Expected result: - The system enters sleep mode and upon pressing the power switch, resumes successfully Actual result: I tried this with the following kernels (all mainline): 2.6.39-999.201104080911 - The system enters suspend mode, but upon trying to resume, the system is unresponsive: backlight doesn't come on, there is no display, keyboard is unresponsive, and system doesn't respond to pings on the network. 2.6.38-3-natty mainline kernel. The system boots and is usable, enters suspend mode, but upon attempting to resume is unresponsive, the backlight doesn't come up, no display, keyboard is unresponsive and system doesn't respond to pings on the network. At some point I saw capslock flashing but it stopped after a bit. v2.6.35.12-maverick mainline kernel, with this kernel the system boots but when trying to enter graphical mode becomes unresponsive, no keyboard, network ping or display (screen is black). Here is some relevant information on the system, please let me know if any more tests are needed. dmi.bios.date: 09/08/2009 dmi.bios.vendor: Dell Inc. dmi.bios.version: A11 dmi.board.name: 0K183D dmi.board.vendor: Dell Inc. dmi.board.version: A11 dmi.chassis.asset.tag: 1234567890 dmi.chassis.type: 8 dmi.chassis.vendor: Dell Inc. dmi.chassis.version: A11 dmi.modalias: dmi:bvnDellInc.:bvrA11:bd09/08/2009:svnDellInc.:pnStudioXPS1340:pvrA11:rvnDellInc.:rn0K183D:rvrA11:cvnDellInc.:ct8:cvrA11: dmi.product.name: Studio XPS 1340 dmi.product.version: A11 dmi.sys.vendor: Dell Inc. GraphicsCard: 02:00.0 VGA compatible controller [0300]: nVidia Corporation G98 [GeForce 9200M GS] [10de:06e8] (rev a1) (prog-if 00 [VGA controller]) Subsystem: Dell Device [1028:0271] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 23 Region 0: Memory at ae000000 (32-bit, non-prefetchable) [size=16M] Region 1: Memory at d0000000 (64-bit, prefetchable) [size=256M] Region 3: Memory at ac000000 (64-bit, non-prefetchable) [size=32M] Region 5: I/O ports at 4000 [size=128] Capabilities: <access denied> Kernel driver in use: nouveau Kernel modules: nouveau, nvidiafb 03:00.0 VGA compatible controller [0300]: nVidia Corporation C79 [GeForce 9400M G] [10de:0866] (rev b1) (prog-if 00 [VGA controller]) Subsystem: Dell Device [1028:0271] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 18 Region 0: Memory at aa000000 (32-bit, non-prefetchable) [size=16M] Region 1: Memory at b0000000 (64-bit, prefetchable) [size=256M] Region 3: Memory at cc000000 (64-bit, prefetchable) [size=32M] Region 5: I/O ports at 5000 [size=128] [virtual] Expansion ROM at c0000000 [disabled] [size=128K] Capabilities: <access denied> Kernel driver in use: nouveau Kernel modules: nouveau, nvidiafb
I've got the same graphic card on Dell studio XPS 1330, and exactly the same frozen configurations after a wake up from suspend-to-ram (no problem with suspend-to-disc). I tried with several older kernels (debian sid), and I had everytime the same bug. The /var/log/pm-suspend.log do not contain any line corresponding to the wake-up.
Just to update on this, I tested with a 3.2-rc2 kernel, where this problem is still present as described originally. Thanks!
Can you provide dmesg from failed suspend on 64-bit kernel? I bet it will fail differently than 32-bit kernel. 2 256MB cards + 32-bit kernel without CONFIG_HIGHMEM4G (only 876 MB of RAM directly accessible) = fail. Maybe it's fixable, but I wouldn't count on it.
(In reply to comment #3) > Can you provide dmesg from failed suspend on 64-bit kernel? I bet it will fail > differently than 32-bit kernel. > > 2 256MB cards + 32-bit kernel without CONFIG_HIGHMEM4G (only 876 MB of RAM > directly accessible) = fail. Maybe it's fixable, but I wouldn't count on it. Marcin: I take it you are referring to failure to suspend due to vmalloc failures in the nouveau driver? Indeed, Daniel has verified that this problem can be avoided by using a 64-bit kernel or by passing vmalloc=128M to the kernel (see the reference bug in Launchpad for details). When that issue is avoided the system does appear to suspend successfully, but then hangs when resuming.
According to the latest dmesg (in comment #47) Nouveau fails to "Suspend the GPU objects" due to NOMEM (-12 reported in the log), I.e. nouveau fails to vmalloc(gpuobj->size), that is needed to store current gpu objects (so that they can be restored after resume)
With the 3.9.x kernel, this bug is fixed on my computer.
Marking as fixed per the last comment. If this is still an issue, feel free to reopen with fresh logs/etc from a new kernel.
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.