Most recent kernel where this bug did not occur: NEVER WORKED Distribution: (IRRELEVANT) Hardware Environment: NFORCE2 IGP, Athlon XP 2400 Software Environment: currently, Ubuntu 6.06 with 2.6.18-rc2 Problem Description: System doesn't resume correctly from wakeup events. This system supports ACPI S0, S1, S3, S4, and S5; the only wakeup event I've ever seen work is PS2 keyboard from swsusp, which kicks in a soft reboot from BIOS. Other wakeup events kick the system out of the an S1 or S3 state, but the system locks up almost immediately. (To be specific, the sleep state powers off two front panel LEDs, disk/orange and power/blue. On wakeup, both go on; then the power LED goes off.) Wakeup events I've tested include: USB (both OHCI controllers, EHCI) remote wakeup from S1 and S3; PS2 keyboard from S1 and S3; ACPI RTC from S1, S3, and swsusp/reset. All of them fail the same way, except for the RTC wakeup from swsusp. That swsusp wakeup worked OK until part way throught the Linux boot, at which point it wedged with the video display indicating some from Linux. (I'll have to repeat that test later, to report exactly what.) This failure mode -- wakeup works at the hardware level, then things immediately wedge (with, at best, some text on the console) -- is typical of what I've seen with multiple Linux ACPI test runs. It looks like there's some problem after ACPI receives the wakeup event, rather than something specific to ACPI on the system of $SUBJECT. Steps to reproduce: See above. Suspend using "echo ... > /sys/power/state", use one of the abovementioned wakeup event sources. Watch system lock up after hardware hands things over to software.
Revisit the RTC alarm wakeup case from swsusp: today, it worked several times. So it's just the resume from S1 and S3 that fails. Note that I've tried the resume from S1/S3 with and without a recently proposed patch for the NForce IDE; no difference.
is the problem that wakeup doesn't work from particular wakeup devices, or that wakeup doesn't work from ANY wakeup devices. ie. does wakeup using the power button work? I used to have a box like this one, but the power supply seems to have shorted out and it doesn't power on -- so you're having more luck with it than I have:-)
From S1/S3, it seems like no wakeup event works past restarting the CPU ... I've even tried with serial console. It's as if the very act of receiving the wakeup event from ACPI gets those penguin knickers irretrievably twisted up. As I noted, this is the failure I'm used to getting with ACPI on all systems over the past many years. Since I know that several of these actually resume OK with XP, the issue would appear to be somewhere in the Linux code...
Any progress on this? I repeat, the problem seems to be a general S1 and S3 resume issue, observed on ** MULTIPLE ** machines. - The NF2 box in $SUMMARY - Another Athlon box (no-name SIS, S1-only, works fine in XP) - An NF3 laptop (Compaq R3140, S1 or S3, also works fine in XP) In fact the only Linux box I've ever seen S3 work on is an ancient and dying P3/coppermine laptop. I updated the severity since, well, the the symptom is both severe on every individual system, and in my observation widespread. Right now I'm on the road with only the NF3 laptop. For the record, I've done what the "s2ram" stuff says to do, with no success.
So... swsusp works okay. S1 and S3 is b0rken. Have you ever say yellow text saying "Linux" during resume? Can you try to apply beeping patch to see if Linux's wakeup vector is reached? Debugging S1 may be even easier... if you comment out device_suspend/resume, printk should still work, and S1 needs almost no support from kernel.
Created attachment 9177 [details] Pavel's beep patch This is the beep patch Pavel sent (to LKML, not bugtraq)
Note that the system in question doesn't *have* a pc speaker, so the "beep" patch doesn't help diagnose anything! Something in the 2.6.21 patches has massively improved things, to the point where S1 resume works fine from the SN41G2, and S3 resume works from the two NVidia boards (except the framebuffer is fully AWOL) ... I can ssh into those systems. I've not yet retested on that third system, but I thought I'd report that things now work a lot better now. If that third system behaves, I'll mark this as "code fixed/closed", since the framebuffer issues are clearly separate. There is however a regression, in that the RTC wakeup from swsusp no longer works on the $SUBJECT system -- and it used to work.
Is this is still a problem in linux-2.6.22.stable or later?
Please reopen this bug if it's still present with kernel 2.6.22.