Troubles waking up from suspend (S3) - how to debug?

I'm currently trying out suspend (S3) on a few machines but none of them wakes up completely/properly (I have a few more hosts I'm planning to try suspend on once I can get useful information out of those not waking up properly).

Tested kernels: 2.6.24(-rc8), on one 2.6.23.8

To suspend I enter the following from console:
echo -n mem > /sys/power/state

Fujitsu-Siemens S7020 laptop (i915GM based):
Works fine except backlight that remains asleep and Xorg vesa driver crashing Xorg.
It looks like a suspend cycle discards the VideoBIOS shadow copy. Adjusting brightness using hotkeys or acpi-fujitsusiemens does not help waking up the backlight.
At best backlight comes back when suspending from Xorg with xf86-video-intel-2.2.x but then mode is distorded. Any attempt to fix this using xrandr or switch to/from console puts backlight asleep.

Acer Travelmate 660 laptop (i855GM based):
Laptop suspends as expected but hangs while waking up.

Desktop with MSI nforce based mainboard with Athlon CPU, onboard graphics and hdd on HighPoint RR1640 PCI card (USB mouse & keyboard):
Suspends as expected but hangs while waking up.
During wakeup I can ping the computer but userspace does not respond (e.g. no answer when trying to connect via ssh)
The display remains off if using vga text console, display comes back with garbadge when using nvidiafb (no Xorg running), USB is powered but triggers no reactions on keyboard/mouse input

I tried using netconsole on the desktop computer to capture eventual printks during resume but I got not a line during wakup. (only suspend progress messages before actual suspend)

What can I do to get more information out of those two last machines and find out why they don't wake-up properly?

I can provide more details on each of those machines if it can help (lspci, kernel config, peripherials, acpidump)

Regards,
Bruno

Bonjour, it seems for me that using echo isn't the right way. You could follow instructions at the end of: <http://community.ofset.org/index.php/Freeduc-cd17_how_to>

Bien cordialement, Stephane Ascoet, conseils pour que la technologie soit un progres respectueux de la vie.
Album photo:<http://www.flickr.com/photos/stephaneascoet/>, site:<http://community.ofset.org/wiki/User:Sascoet>

[...]

You might try this:

http://tikei.de/suspend-to-ram-debug

Regards,
Tino

Please try s2ram (http://suspend.sf.net/s2ram-support.html).

This one is on the s2ram whitelist, should work.

This might work with "s2ram -f --vbe_post --vbe_save", please try.

What kind?

Please apply the patches 01-11 from:
http://www.sisk.pl/kernel/hibernation_and_suspend/2.6.24/patches/
on top of 2.6.24, compile the kernel and install it. After booting, please do:

# echo core > /sys/power/pm_test
# echo mem > /sys/power/state

and see if the boxes survive it (this causes the suspend/resume sequence to be executed without acutally suspending, but busy-waiting for 5 sec. instead).

Greetings,
Rafael
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Thanks for the pointer, using version 0.8 as available in Gentoo portage for my tests.

Backlight comes back with vesafb using s2ram, not yet tested with intelfb or Xorg.

Ideally the kernel would be able to recover this without the hacks by s2ram (vesafb post the videobios -- intelfb (or xf86-video-intel for X) would be able to properly configure the graphics).
For the intel drivers the problem is probably missing specs from Intel...

New tests scheduled later for this host...

MSI K7N420 (with first-generation nforce chipset), AMD Athlon 1800+ on it

lspci:
00:00.0 Host bridge: nVidia Corporation nForce CPU bridge (rev b2)
00:00.1 RAM memory: nVidia Corporation nForce 220/420 Memory Controller (rev b2)
00:00.2 RAM memory: nVidia Corporation nForce 220/420 Memory Controller (rev b2)
00:00.3 RAM memory: nVidia Corporation nForce 420 Memory Controller (DDR) (rev b2) 00:01.0 ISA bridge: nVidia Corporation nForce ISA Bridge (rev c3)
00:01.1 SMBus: nVidia Corporation nForce PCI System Management (rev c1)
00:02.0 USB Controller: nVidia Corporation nForce USB Controller (rev c3)
00:03.0 USB Controller: nVidia Corporation nForce USB Controller (rev c3)
00:04.0 Ethernet controller: nVidia Corporation nForce Ethernet Controller (rev c2) 00:05.0 Multimedia audio controller: nVidia Corporation nForce Audio (rev c2)
00:06.0 Multimedia audio controller: nVidia Corporation nForce Audio (rev c2)
00:08.0 PCI bridge: nVidia Corporation nForce PCI-to-PCI bridge (rev c2)
00:09.0 IDE interface: nVidia Corporation nForce IDE (rev c3)
00:1e.0 PCI bridge: nVidia Corporation nForce AGP to PCI Bridge (rev b2)
01:04.0 RAID bus controller: Triones Technologies, Inc. HPT374 (rev 07)
01:04.1 RAID bus controller: Triones Technologies, Inc. HPT374 (rev 07)
02:00.0 VGA compatible controller: nVidia Corporation NVCrush11 [GeForce2 MX Integrated Graphics] (rev b1)

00:00.0 0600: 10de:01a4 (rev b2)
00:00.1 0500: 10de:01ac (rev b2)
00:00.2 0500: 10de:01ad (rev b2)
00:00.3 0500: 10de:01ab (rev b2)
00:01.0 0601: 10de:01b2 (rev c3)
00:01.1 0c05: 10de:01b4 (rev c1)
00:02.0 0c03: 10de:01c2 (rev c3)
00:03.0 0c03: 10de:01c2 (rev c3)
00:04.0 0200: 10de:01c3 (rev c2)
00:05.0 0401: 10de:01b0 (rev c2)
00:06.0 0401: 10de:01b1 (rev c2)
00:08.0 0604: 10de:01b8 (rev c2)
00:09.0 0101: 10de:01bc (rev c3)
00:1e.0 0604: 10de:01b7 (rev b2)
01:04.0 0104: 1103:0008 (rev 07)
01:04.1 0104: 1103:0008 (rev 07)
02:00.0 0300: 10de:01a0 (rev b1)

Seen by s2ram as:
This machine can be identified by:

    sys_vendor   = "NVIDIA Corporation."
    sys_product  = "nFORCE-MCP"
    sys_version  = " "
    bios_version = "6.00 PG"

This test passed (K7N420) with minimal amount of modules loaded (text-mode graphics). Real suspend worked as well (s2ram -f --vbe_post) but it's not the right tuning to get usable console back. Currently results in scrambled output with half of the character placeholders flickering at cursor speed. (will test other options of this version of s2ram, possibly upgrading to latest to get more options as descibed on suspend.sf.net).
It takes about 1 minute between the moment when the first ping reply and userspace/display wakeup or netconsole messages.
More details to come as I get time to do more complete tests with all drivers.

Regards,
Bruno