Bug 6906
Summary: | S1 and S3 resume: Shuttle SN41G2 NForce2 | ||
---|---|---|---|
Product: | ACPI | Reporter: | David Brownell (dbrownell) |
Component: | Power-Sleep-Wake | Assignee: | acpi_power-sleep-wake |
Status: | REJECTED INSUFFICIENT_DATA | ||
Severity: | high | CC: | acpi-bugzilla, bunk, pavel |
Priority: | P2 | ||
Hardware: | i386 | ||
OS: | Linux | ||
Kernel Version: | 2.6.10 through 2.6.18-rc2 | Subsystem: | |
Regression: | --- | Bisected commit-id: | |
Attachments: | Pavel's beep patch |
Description
David Brownell
2006-07-26 01:14:47 UTC
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. |