en en en en en en ceb yue en en en en mk en hbs_lat es en en en en es en en en en en en en en en en en ru en en ro en en en en en en pt es en en en fi en en en pt en en en en ca en en en en en en en en en en en en pl en en en en en en en en en ceb yue en en en en mk en hbs_lat
Comment 1 Rafael J. Wysocki 2010-01-12 21:44:18 UTC
Comment 2 akwatts 2010-01-13 14:57:07 UTC
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
Comment 3 Rafael J. Wysocki 2010-01-13 20:57:34 UTC
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.
Comment 4 akwatts 2010-01-14 15:27:25 UTC
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).
Comment 5 Rafael J. Wysocki 2010-01-14 20:27:42 UTC
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.
Comment 6 Rafael J. Wysocki 2011-01-16 22:14:26 UTC
Is the problem still present in 2.6.37?
Comment 7 Zhang Rui 2012-01-18 01:57:20 UTC
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.