Bug Description

Binary package hint: linux-source-2.6.17

Description of the problem:
Attempting to resume from an S3 "mem" suspend results in the computer rebooting itself.

Steps to reproduce:
1. Set S3 rather than S1 as the suspend method in the BIOS.
2. Boot edgy.
3. Click on power symbol and click Suspend.
4. Wait for computer to "power off".
5. Press the power button and wait for computer to resume.

Expected results:
X to start back up, desktop to reappear as it was at stage 4 (possibly for the screensaver to start depending on various options)

Additional information:
S1 suspend works (but then it's got less to do) if I flip the appropriate bits of the BIOS and set the ACPI_SLEEP_MODE=strandby and then "force" sleep.sh .
S3 resumes correctly under Windows 98 .
Attempting to boot to a minimal console with minimal modules loaded did not make any difference - the system still rebooted.

Care to confirm if this issue still exists in the latest Hardy Alpha release which contains an updated version of the kernel. You can download and try the new Hardy Heron Alpha release from http://cdimage.ubuntu.com/releases/hardy/ . You should be able to then test the new kernel via the LiveCD. Please note you can only test Suspend from the LiveCD, not Hibernate. General information regarding the release can also be found here: http://www.ubuntu.com/testing/ . Thanks.

Sorry for the delayed response. Care to test the latest 2.6.24-11 kernel and assuming the issue still exists, then attach your dmesg output after a failed suspend/resume cycle as outlined here: https://wiki.ubuntu.com/DebuggingKernelSuspend. Thanks.

Leann:
Sorry, I REALLY don't want to retest this until the next "major" (2.6.x) kernel revision change or final Hardy release. I have seen nothing that suggests this is going to have changed so arbitrarily retesting minor kernel revisions just isn't worth the effort I'm afraid.

What I should have also noted is that I have tried everything on http://people.freedesktop.org/~hughsient/quirk/quirk-suspend-advanced.html (which includes trying to using pm_trace - when the system restarts no hash is ever matched). I can also assure you that there is nothing of interest in dmesg... because the system reboots when you try to resume. The output of the post suspend boot from later kernels is pretty similar to the kern.log that was posted earlier in this bug.

Thanks for the update Sitsofe. I'm going to mark this "Fix Released" for Intrepid. I'll also open a Hardy nomination but will leave this to the discretion of the kernel team if they'll choose to backport this patch or not. Thanks.

Per a decision made by the Ubuntu Kernel Team, bugs will longer be assigned to the ubuntu-kernel-team in Launchpad as part of the bug triage process. The ubuntu-kernel-team is being unassigned from this bug report. Refer to https://wiki.ubuntu.com/KernelTeamBugPolicies for more information. Thanks.