Resuming from S3 suspend causes a reboot

Bug #86099 reported by Sitsofe Wheeler
6
Affects Status Importance Assigned to Milestone
Linux
Invalid
Medium
Ubuntu
Invalid
Undecided
Unassigned
Hardy
Invalid
Undecided
Unassigned
Intrepid
Invalid
Undecided
Unassigned
linux (Ubuntu)
Fix Released
Undecided
Unassigned
Hardy
Invalid
Undecided
Unassigned
Intrepid
Fix Released
Undecided
Unassigned
linux-source-2.6.17 (Ubuntu)
Won't Fix
Medium
Unassigned
Hardy
Invalid
Undecided
Unassigned
Intrepid
Won't Fix
Medium
Unassigned
linux-source-2.6.20 (Ubuntu)
Won't Fix
Medium
Unassigned
Hardy
Invalid
Undecided
Unassigned
Intrepid
Won't Fix
Medium
Unassigned
linux-source-2.6.22 (Ubuntu)
Won't Fix
Undecided
Unassigned
Hardy
Invalid
Undecided
Unassigned
Intrepid
Won't Fix
Undecided
Unassigned

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)

Actual results:
Video BIOS posts itself, warms the monitor up, powersaves it, posts itself again and goes to the regular BIOS post indicating a reboot.

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.

Revision history for this message
Sitsofe Wheeler (sitsofe) wrote :

Linux galvatron 2.6.17-11-generic #2 SMP Thu Feb 1 19:52:28 UTC 2007 i686 GNU/Linux

Revision history for this message
Sitsofe Wheeler (sitsofe) wrote :
Revision history for this message
Sitsofe Wheeler (sitsofe) wrote :
Revision history for this message
Sitsofe Wheeler (sitsofe) wrote :
Revision history for this message
Sitsofe Wheeler (sitsofe) wrote :

I did a minimal test by booting into single user/recovery mode with init=/bin/sh on the command line . By nobbling /etc/default/acpi-support and rerunning update-initramfs -u I was able to reduce the loaded modules to the following:
Module Size Used by
thermal 15624 0
processor 31560 1 thermal
fan 6020 0
fbcon 41504 0
tileblit 3840 1 fbcon
font 9344 1 fbcon
bitblit 7168 1 fbcon
softcursor 3328 1 bitblit
vesafb 9244 0
capability 5896 0
commoncap 8704 1 capability
ide_generic 2432 0
ide_disk 18560 3
ext3 142856 1
jbd 62228 1 ext3

A few modprobe -rs removed in that list down to this:
ide_disk 18560 3
ext3 142856 1
jbd 62228 1 ext3

and the problem still occurred.

Revision history for this message
Cristian Aravena Romero (caravena) wrote :

It would also be helpful if you could try to hibernate/suspend and after that fails, restart your system and attach /var/log/kern.log.0 as well. Thanks again for your contribution.

Revision history for this message
Sitsofe Wheeler (sitsofe) wrote :

/var/log/kern.log.0 was too old (it doesn't rotate after every boot) so I am attaching /var/log/kern.log instead. Nothing useful is logged (I'm not even convinced the FS is remounted):

Feb 19 09:09:20 kernel: [17179663.764000] pcc_acpi: loading...
Feb 19 09:12:51 kernel: Inspecting /boot/System.map-2.6.17-11-generic
Feb 19 09:12:51 kernel: Loaded 22866 symbols from /boot/System.map-2.6
.17-

Revision history for this message
Sitsofe Wheeler (sitsofe) wrote :

I also just want to state that hibernation works - it is S3 suspend to ram that does not.

Revision history for this message
Gabriel Ambuehl (gabriel-ambuehl) wrote :

Not sure if this applies here, but I have seen that when powersaved was active but I suspended the machine manually (i.e. not with powersave utility but for example s2ram directly).

Revision history for this message
Sitsofe Wheeler (sitsofe) wrote :

Gabriel:
That probably doesn't apply here because when I booted using init=/bin/sh very few daemons were running (probably none but kernel ones...)

I also don't have powersaved installed on this system...

Revision history for this message
Matthew Garrett (mjg59) wrote :

Any chance you can test with a feisty pre-release? The live CD ought to do. This matches a bug that affects some VIA systems - a few were fixed in edgy, but not all of them.

Revision history for this message
Sitsofe Wheeler (sitsofe) wrote :

OK I'll set off a download now and try and test tomorrow morning...

Revision history for this message
Sitsofe Wheeler (sitsofe) wrote :

Same issue with feisty herd4 live CD, kernel
Linux ubuntu 2.6.20-8-generic #2 SMP Tue Feb 13 05:18:42 UTC 2007 i686 GNU/Linux

Revision history for this message
Sitsofe Wheeler (sitsofe) wrote :

I forgot to mention that this new test was done from the live CD with X and all the defaults running.

Revision history for this message
Sitsofe Wheeler (sitsofe) wrote :

Same problem in single mode with as much as I could modprobe -r removed:
lsmod
Module Size Used by
ide_cd 32672 0
cdrom 37664 1 ide_cd
ipv6 261920 8
via_agp 11136 1
agpgart 33480 1 via_agp
squashfs 46340 1
loop 17800 2
unionfs 74148 1
ext3 133128 1
jbd 59816 1 ext3
mbcache 9604 1 ext3
ide_disk 17024 2
usbcore 134152 1
via82cxxx 10372 0 [permanent]
generic 6148 0 [permanent]

ps auxw
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 1 0.4 0.1 1712 668 ? Ss 00:55 0:02 /sbin/init
root 2 0.0 0.0 0 0 ? S 00:55 0:00 [migration/0]
root 3 0.0 0.0 0 0 ? SN 00:55 0:00 [ksoftirqd/0]
root 4 0.0 0.0 0 0 ? S 00:55 0:00 [watchdog/0]
root 5 0.0 0.0 0 0 ? S< 00:55 0:00 [events/0]
root 6 0.0 0.0 0 0 ? S< 00:55 0:00 [khelper]
root 7 0.0 0.0 0 0 ? S< 00:55 0:00 [kthread]
root 30 0.0 0.0 0 0 ? S< 00:55 0:00 [kblockd/0]
root 31 0.0 0.0 0 0 ? S< 00:55 0:00 [kacpid]
root 32 0.0 0.0 0 0 ? S< 00:55 0:00 [kacpi_notify]
root 97 0.0 0.0 0 0 ? S< 00:55 0:00 [kseriod]
root 119 0.0 0.0 0 0 ? S 00:55 0:00 [pdflush]
root 120 0.0 0.0 0 0 ? S 00:55 0:00 [pdflush]
root 121 0.0 0.0 0 0 ? S< 00:55 0:00 [kswapd0]
root 122 0.0 0.0 0 0 ? S< 00:55 0:00 [aio/0]
root 1917 0.0 0.0 0 0 ? S< 00:55 0:00 [ksuspend_usbd]
root 1918 0.0 0.0 0 0 ? S< 00:55 0:00 [khubd]
root 2343 0.0 0.0 0 0 ? S< 00:55 0:00 [kjournald]
root 2391 0.0 0.0 0 0 ? S< 00:55 0:00 [loop0]
root 5070 0.2 0.1 2812 1204 ? S<s 00:56 0:00 /sbin/udevd --daemon
root 6863 0.0 0.0 1716 488 tty1 Ss 00:56 0:00 /bin/sh -e -c ?runlevel --set S >/dev/null || true??/sbin/sulogin???if [ -r /etc/inittab ]; then?? RL="$(sed -n -e "/^id:[0-9]*:initdefault:/{s/^id://;s/:.*//;p}" /etc/inittab || true)"?? if [ -n "$RL" ]; then???telinit $RL?? else???telinit 2?? fi??else?? telinit 2??fi? /bin/sh S
root 6865 0.0 0.2 2940 1724 tty1 S 00:56 0:00 bash
root 7766 0.0 0.1 2316 900 tty1 R+ 01:02 0:00 ps auxw

Revision history for this message
Sitsofe Wheeler (sitsofe) wrote :

Still happens with Feisty Herd 5 so changing package version to 2.6.20

Changed in linux-source-2.6.17:
assignee: nobody → ubuntu-kernel-team
importance: Undecided → Medium
status: Unconfirmed → Confirmed
Changed in linux-source-2.6.20:
assignee: nobody → ubuntu-kernel-team
importance: Undecided → Medium
status: Unconfirmed → Confirmed
Revision history for this message
Sitsofe Wheeler (sitsofe) wrote :

Still happens with the Gutsy final release so changing package version to 2.6.22

Revision history for this message
Leann Ogasawara (leannogasawara) wrote :

Hi Sitsofe,

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.

Changed in linux:
status: New → Incomplete
Revision history for this message
Leann Ogasawara (leannogasawara) wrote :

Also note this report will remain open against the actively developed kernel, but against 2.6.22, 2.6.20, and 2.6.17 this will be closed. Thanks.

Changed in linux-source-2.6.22:
status: New → Won't Fix
Changed in linux-source-2.6.20:
status: Confirmed → Won't Fix
Changed in linux-source-2.6.17:
status: Confirmed → Won't Fix
Revision history for this message
Sitsofe Wheeler (sitsofe) wrote :

Still happens with Hardy (development branch) 2.6.24-7-generic. Opening a 2.6.24 component.

Revision history for this message
Sitsofe Wheeler (sitsofe) wrote :

Setting back to new after testing Hardy Alpha hard drive install.

Changed in linux:
status: Incomplete → Confirmed
Revision history for this message
Sitsofe Wheeler (sitsofe) wrote :

Setting to confirmed after testing Hardy Alpha hard drive install.

Revision history for this message
Leann Ogasawara (leannogasawara) wrote :

Hi Sitsofe,

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.

Revision history for this message
Sitsofe Wheeler (sitsofe) wrote :

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.

Changed in linux:
status: Unknown → In Progress
Changed in linux:
status: In Progress → Invalid
Revision history for this message
Sitsofe Wheeler (sitsofe) wrote :

Good news. A fix ( http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=4b4f7280d7fd1feeff134c2cf2db32fd583b6c29 ) which works around for this issue went into 2.6.26 that resolves this issue. Obviously this problem is still seen on current Hardy kernels.

Revision history for this message
Leann Ogasawara (leannogasawara) wrote :

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.

Changed in linux:
status: Confirmed → Fix Released
Changed in linux-source-2.6.17:
status: New → Invalid
Changed in linux-source-2.6.20:
status: New → Invalid
Changed in linux-source-2.6.22:
status: New → Invalid
Changed in linux-source-2.6.24:
status: New → Invalid
Revision history for this message
Launchpad Janitor (janitor) wrote : Kernel team bugs

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.

Changed in linux:
status: Invalid → Unknown
Changed in linux:
importance: Unknown → Medium
Changed in linux:
status: Unknown → Invalid
Revision history for this message
Julian Wiedmann (jwiedmann) wrote :

This release has reached end-of-life [0].

[0] https://wiki.ubuntu.com/Releases

Changed in linux (Ubuntu Hardy):
status: New → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.