Bug 4926
Summary: | S3: hang in 2nd suspend -- Thinkpad 600X | ||
---|---|---|---|
Product: | ACPI | Reporter: | Sanjoy Mahajan (sanjoy) |
Component: | Power-Sleep-Wake | Assignee: | Shaohua (shaohua.li) |
Status: | REJECTED DUPLICATE | ||
Severity: | high | CC: | acpi-bugzilla |
Priority: | P2 | ||
Hardware: | i386 | ||
OS: | Linux | ||
Kernel Version: | 2.6.13-rc3 | Subsystem: | |
Regression: | --- | Bisected commit-id: | |
Attachments: | Modified 600X DSDT |
Description
Sanjoy Mahajan
2005-07-22 12:45:19 UTC
Created attachment 5362 [details]
Modified 600X DSDT
Here's the DSDT I compiled into the kernel. With 2.6.11.4 plus this DSDT, S3
mostly worked.
Correction: The disk light goes on only after I try to wake it up (e.g. by pressing the Fn key). The screen flashes briefly, the disk light turns on (though the disk doesn't spin), then the screen goes blank and nothing happens. In order to reboot, I have to fully power cycle by removing the batteries and AC cord. -Sanjoy With 2.6.13-rc3-mm2, it now goes to sleep (S3) and wakes up once, but the second time I suspend, it will hang after the 'stopping tasks ===== ...' message. This hang happens whether or not I boot with acpi_sleep=s3_bios The console display is still messed up upon wake up (using XFree86 server), but X works fine (as long as it wakes up). did repeated suspend/resume cycles work with a previous kernel? If yes, what is the most recent version before it broke? Is this still an issue in 2.6.13-rc6? > did repeated suspend/resume cycles work with a previous kernel? 2.6.11.4 and 2.6.12.3. > If yes, what is the most recent version before it broke? Before 2.6.11, S3 sleep/wake didn't work at all. Repeated slep/wake cycles work with 2.6.13-rc6, if I don't use a preemptible kernel. The 2.6.11.4 and 2.6.12.3 kernels above were not preemptible. Definitely the non-preemtible are okay, and the fully pre-emptible 2.6.13-rc6 breaks. I'm still not sure whether a medium-preemptible (voluntary preempt) 2.6.13-rc6 breaks. I have been using it for the last 24 hours and stressing it out to try and break it but it's still doing fine. See Bug #5037 for the details and ongoing testing. thanks for re-testing. I'm glad to hear the latest kernel w/o preempt works fine. Seems like there is no unique failure described in this bug report -- shall we close it as a duplicate of bug 5037? > shall we close it as a duplicate of bug 5037?
Yes.
|