Suspend to ram (echo mem > /sys/power/state) has not worked on this hardware as far as I have been able to test (2.6.29; .30; .31; .32 kernels). It enters suspend mode (power led flashes, screens turns off, and drive spins down) but upon resume (pressing power key) drive spins up and screen remains black. No keyboard functionality exists and a hard reboot (pressing power key for several seconds) is needed. Diagnostics: PM_TEST RESULT -------- ------- freezer SUCCESS devices SUCCESS platform SUCCESS processor SUCCESS core SUCCESS Suspending with "echo 1 > /sys/power/pm_trace" gives the following in dmesg (though sometimes there is no hash matches line in dmesg after a forced reboot -- hardware clock has not been written to): [ 3.805991] Magic number: 0:168:740 [ 3.813068] hash matches drivers/base/power/main.c:430 Tests have been done from X, from console (with and without a framebuffer), and with a minimal system (init=/bin/bash). Current results (above) are on 2.6.32.2. Additionally the following have been tested (with init=/bin/bash) and failed on each: s2ram -f s2ram -f -a 3 s2ram -f -a 2 s2ram -f -a 1 s2ram -f -p -m s2ram -f -p -s s2ram -f -m s2ram -f -s s2ram -f -p s2ram -f -a 1 -m s2ram -f -a 1 -s s2ram -f -p -v This machine successfully suspends on Windows XP. Thoughts? Advice? ~Andy
Not really. Probably BIOS-related, hard to say how exactly. You can try the acpi_sleep= kernel command line option as described in Documentation/kernel-parameters.txt in the kernel sources, but please use the latest Linus' tree for that.
I tried all possibilities for acpi_sleep on 2.6.32.3 (s3_bios, s3_mode, s4_nohwsig, old_ordering, s4_nonvs) and no luck. The results were the same: seemingly enters suspend mode but upon resume it hangs. By the way, on "resume" the screen is actually on with a blinking underscore cursor in the top left corner (I said black screen in my initial post). KB is totally unresponsive though and a hard restart is needed. Is there any information that I can provide or any tests I can do on this side that might help us get closer to working suspend? ~Andy
Basically, you'd have to figure out where exactly it hangs. The pm_trace test doesn't tell us anything, so I'm afraid the only way to debug this is to put a piece of code causing a reboot into various places in the resume code path and see which of them triggers. If there's an ATI graphics in the box, you can try to comment out the instructions (except for the final return 0) in kernel/power/console.c:pm_prepare_console() and kernel/power/console.c:pm_restore_console(). Then, boot with radeon.modeset=1 and see what happens. Anyway, please use 2.6.33-rc4 (or later) for further testing.
I would like to start debugging with trip points as you suggest but I need a little help from you to get started. What is the appropriate way to trigger a reboot in this situation? Should I use emergency_restart(), or kernel_restart(), or something else? Also, I am not familiar with the resume code path so I need a push in the right direction. Where in the kernel code should I be placing the different trip points (ie what are the important events to test before/after on)? I will use 2.6.33-rc4 for all tests from here on as you've requested. ~Andy PS the machine does have ATI graphics but using KMS and commenting out the body of pm_restore_console() and all but the return 0 on pm_prepare_console() did not work (used 2.6.32.3 for that test).
First, the resume code path. It starts in arch/x86/kernel/acpi/realmode/wakeup.S Then, on 32-bit it goes directly to arch/x86/kernel/acpi/wakeup_32.S, while on 64-bit it re-uses the SPM trampoline code to get into wakeup_64.S. From there, it calls restore_processor_state() and returns to acpi_suspend_enter(), right after the do_suspend_lowlevel() call. In turn, this returns to kernel/power/suspend.c:suspend_enter(), which returns to suspend_devices_and_enter(), which returns to enter_state(). Second, whatever you use to force a reboot is OK as long as it works at this particular point. The assembly parts are especially hard in that respect and I'm not aware of any 100%-reliable universal instant reboot method for them. It would be helpful to figure out if the code in realmode/wakeup.S is actually called (you have to invent a method working on your machine, but there are a few possibilities, like speaker beeps, sending data directly to the VGA graphics, sending data directly to the standard serial ports). Also, it would be helpful to verify that we get into acpi_suspend_enter(). Disclaimer: I haven't said it's easy.
Is the problem still present in 2.6.37?
Bug closed as there is no response from the bug reporter. Please feel free to re-open it if the bug still exists in the latest upstream kernel.