Re: Suspend to RAM fails in Debian Wheezy 64 bits
Le jeudi 19 juillet 2012 à 17:21 +0000, Camaleón a écrit :
> Hi, but better if you don't hijack threads,
Sorry about that.
> > I can't suspend to RAM anymore in my (up to date) Debian Wheezy (64
> > bits).
> >
> > Everything was fine until last week: each time I recover from the
> > suspending state, it seems that the X server fails. The screen becomes
> > black with a white cursor blinking on the top left corner.
>
> What are the logs saying? What kind of vga card/driver are you using?
> What desktop environment?
>
1) pm-suspend.log
The actual suspend part was successful: every '/usr/lib/pm-utils/sleep.d/' script was either marked with "success" or "not applicable"
In the resume part, I have got this:
Fri Jul 20 10:40:41 CEST 2012: Awake.
Fri Jul 20 10:40:41 CEST 2012: Running hooks for resume
Running hook /usr/lib/pm-utils/sleep.d/99video resume suspend:
/usr/lib/pm-utils/sleep.d/99video resume suspend: success.
Running hook /usr/lib/pm-utils/sleep.d/98video-quirk-db-handler resume suspend:
/usr/lib/pm-utils/sleep.d/98video-quirk-db-handler resume suspend: success.
Running hook /usr/lib/pm-utils/sleep.d/98video-quirk-db-handler resume suspend:
/usr/lib/pm-utils/sleep.d/98video-quirk-db-handler resume suspend: success.
Running hook /usr/lib/pm-utils/sleep.d/95led re
(Note the incomplete line; I waited 3 (real) minutes before rebooting)
2) Xorg.0.log
No error.
Some unrelated warnings (fonts)
3) Syslog
Before suspend:
Jul 20 10:40:26 localhost NetworkManager[2140]: <info> sleep requested (sleeping: no enabled: yes)
Jul 20 10:40:26 localhost NetworkManager[2140]: <info> sleeping or disabling...
Jul 20 10:40:26 localhost NetworkManager[2140]: <info> (eth0): now unmanaged
Jul 20 10:40:26 localhost NetworkManager[2140]: <info> (eth0): device state change: activated -> unmanaged (reason 'sleeping') [100 10 37]
Jul 20 10:40:26 localhost NetworkManager[2140]: <info> (eth0): deactivating device (reason 'sleeping') [37]
Jul 20 10:40:26 localhost NetworkManager[2140]: <info> (eth0): canceled DHCP transaction, DHCP client pid 2371
Jul 20 10:40:26 localhost NetworkManager[2140]: <info> (eth0): cleaning up...
Jul 20 10:40:26 localhost NetworkManager[2140]: <info> (eth0): taking down device.
Jul 20 10:40:26 localhost dbus[2115]: [system] Activating service name='org.freedesktop.nm_dispatcher' (using servicehelper)
Jul 20 10:40:26 localhost NetworkManager[2140]: <info> (wlan0): now unmanaged
Jul 20 10:40:26 localhost NetworkManager[2140]: <info> (wlan0): device state change: unavailable -> unmanaged (reason 'sleeping') [20 10 37]
Jul 20 10:40:26 localhost NetworkManager[2140]: <info> (eth0): carrier now OFF (device state 10)
Jul 20 10:40:26 localhost dbus[2115]: [system] Successfully activated service 'org.freedesktop.nm_dispatcher'
Jul 20 10:40:27 localhost anacron[6102]: Anacron 2.3 started on 2012-07-20
Jul 20 10:40:27 localhost anacron[6102]: Normal exit (0 jobs run)
Jul 20 10:40:28 localhost kernel: [ 757.629596] dell_wmi: Received unknown WMI event (0x11)
Jul 20 10:40:29 localhost acpid: client 2252[0:0] has disconnected
Jul 20 10:40:29 localhost acpid: client 2252[0:0] has disconnected
Jul 20 10:40:29 localhost kernel: [ 759.322204] dell_wmi: Received unknown WMI event (0x11)
After resume:
Jul 20 10:40:41 localhost kernel: [ 759.681909] PM: Syncing filesystems ... done.
Jul 20 10:40:41 localhost kernel: [ 759.695354] PM: Preparing system for mem sleep
Jul 20 10:40:41 localhost kernel: [ 759.695369] Freezing user space processes ... (elapsed 0.01 seconds) done.
Jul 20 10:40:41 localhost kernel: [ 759.708067] Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done.
Jul 20 10:40:41 localhost kernel: [ 759.724065] PM: Entering mem sleep
Jul 20 10:40:41 localhost kernel: [ 759.724081] Suspending console(s) (use no_console_suspend to debug)
Jul 20 10:40:41 localhost kernel: [ 759.724670] sd 0:0:0:0: [sda] Synchronizing SCSI cache
Jul 20 10:40:41 localhost kernel: [ 759.742925] sd 0:0:0:0: [sda] Stopping disk
Jul 20 10:40:41 localhost kernel: [ 759.745901] parport_pc 00:0b: disabled
Jul 20 10:40:41 localhost kernel: [ 759.748169] serial 00:0a: disabled
Jul 20 10:40:41 localhost kernel: [ 759.752652] serial 00:09: disabled
Jul 20 10:40:41 localhost kernel: [ 759.754734] sdhci-pci 0000:03:01.2: PCI INT C disabled
Jul 20 10:40:41 localhost kernel: [ 759.756190] uhci_hcd 0000:00:1d.0: PCI INT A disabled
Jul 20 10:40:41 localhost kernel: [ 759.756253] uhci_hcd 0000:00:1a.2: PCI INT C disabled
Jul 20 10:40:41 localhost kernel: [ 759.756507] e1000e 0000:00:19.0: PCI INT A disabled
Jul 20 10:40:41 localhost kernel: [ 759.756512] e1000e 0000:00:19.0: PME# enabled
Jul 20 10:40:41 localhost kernel: [ 759.756519] pci0000:00: wake-up capability enabled by ACPI
Jul 20 10:40:41 localhost kernel: [ 759.764138] uhci_hcd 0000:00:1d.2: PCI INT C disabled
Jul 20 10:40:41 localhost kernel: [ 759.764148] uhci_hcd 0000:00:1d.1: PCI INT B disabled
Jul 20 10:40:41 localhost kernel: [ 759.764157] uhci_hcd 0000:00:1a.1: PCI INT B disabled
Jul 20 10:40:41 localhost kernel: [ 759.764166] uhci_hcd 0000:00:1a.0: PCI INT A disabled
Jul 20 10:40:41 localhost kernel: [ 759.764210] ACPI handle has no context!
Jul 20 10:40:41 localhost kernel: [ 759.792046] ehci_hcd 0000:00:1d.7: PCI INT A disabled
Jul 20 10:40:41 localhost kernel: [ 759.804050] ehci_hcd 0000:00:1a.7: PCI INT C disablJul 20 10:42:30 localhost kernel: imklog 5.8.11, log source = /proc/kmsg started.
(perfect copy: the overlapping last lines are in my log file)
After reboot:
Jul 20 10:44:30 localhost rsyslogd: [origin software="rsyslogd" swVersion="5.8.11" x-pid="2138" x-info="http://www.rsyslog.com";] start
[...]
2) Hardware
I am using a Nvidia Quadro NVS 160M (G98M) with Nvidia proprietary drivers. I'd like to use nouveau but I need ~4 hours of battery life and good 3D (which nouveau did not provide last time I checked).
3) DE
Typical Gnome 3.4 install.
> > I can't write a thing, I can't switch to another TTY.
>
> Can you still ssh to the machine and issue commands from there?
Could not try (have to wait for this week-end).
> I would do a bit more debugging first but well, if something has been
> working and now starts failing it can deserve for a bug report (you can
> also search if there's already any bug opened for a similar problem).
>From what I found, there are people complaining about suspend mode not working with their hardware... but it never did. Nothing about such a regression.
Cheers,
Gaël
Reply to: