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 -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1342775875.4434.27.ca...@p76-nom-gd.cnrs-imn.fr