Kernel Bug Tracker – Bug 5962
CPU lock up during suspend to disk
Last modified: 2007-04-28 12:49:14 UTC
Most recent kernel where this bug did not occur: ?
*CPU: AMD Turion(tm) 64 Mobile ML-34 stepping: 2
*gcc version 4.0.2 20050901 (prerelease) (SUSE Linux)
During suspend to disk the system hangs for a while and reports after a few
moments a callstack:
After the callstack suspend to disk completes and can even be resumed.
Steps to reproduce:
1) boot in single user mode
2) enable the swap partition,
3) echo 4 > /proc/acpi/sleep
May be irrelevant, but during normal operation I get also this messages in the
" osl-0822  os_wait_semaphore : Failed to acquire
On the SuSE kernel 2.6.13-15.7-default, this message appears as well. Especially
when accessing the proc fs by f.e. "cat /proc/acpi/thermal_zone/TZ1/temperature"
after accessing the proc kacpi spins up to 100% cpu usage for a while. This may
be connected to http://bugzilla.kernel.org/show_bug.cgi?id=5534
suspend went oops in the acpi code. Maybe
a bug in Len's devel tree?
This should has been fixed in 2.6.16-rc2. Please try!
With plain 2.6.16-rc2 dmesg still reports messages like:
"os_wait_semaphore : Failed to acquire semaphore[ffff81005733ad40|1|0], AE_TIME"
Suspend to disk locks up as well with 2.6.16-rc2 but with just a few debug messages:
Andrew, is there special debug code enabled in your kernel? Obviously
2.6.16-rc1-mm3 is much more verbose during suspend even though the same .config
was used. If yes, is there a way to enable this on the vanilla 2.6.16-r2?
>This should has been fixed in 2.6.16-rc2. Please try!
Ha, the patch is in latest git tree, but not in 2.6.16-rc2. sorry. please try
latest git tree. or you could try the patch at:
I suppose it's fixed in 2.6.16-rc3. if not, please reopen this bug and provide
the dmesg. Thanks!
Unfortunately 2.6.16-rc3 doesn't work different than the rc2 did.
Dmesg after booting looks like this:
During suspend (not resume) the system hangs as described in #3.
The rc-1-mm3 at least reported the lock up while the vanilla rc's remain silent.
Keyboard events get still processed, e.g. switching back to vt1 and pressing CR
works. So obviously the system isn't hard locked.
How about unload the USB driver before suspend?
...hm, interessting things are happening without usb modules loaded.
Module Size Used by
usbcore 132220 1
reiserfs 232560 1
fan 7304 0
thermal 23884 0
ide_cd 40864 0
cdrom 36344 1 ide_cd
processor 42392 1 thermal
atiixp 6288 0 [permanent]
ide_disk 16384 3
ide_core 142616 3 ide_cd,atiixp,ide_disk
suspend hangs with screen like:
After pressing carriage return suspend continues with this screen:
Having usb loaded, pressing any key doesn't make it possible to continue.
After resuming. the system is in a strange state, e.g. non stopping bell,
but that's a different story.
Do you have any ideas how to nail down this bug furthermore?
So the suspend is hang in shutdown processing.
Does shutdown work in the system?
Yes normal shutdown work on the system. But I suppose this bug is very close
connected to the bug http://bugzilla.kernel.org/show_bug.cgi?id=5534. There seems
to be trouble with processing acpi events with this bios.
In http://bugzilla.kernel.org/show_bug.cgi?id=5534#c65 and
http://bugzilla.kernel.org/show_bug.cgi?id=5534#c66 are some interessing
investigation described. Couldn't this also lock-up other acpi subsystems during
Please verify if patch to #5534 fixes your problem as well.
My first try applying your 2nd version of the patch to a 18.104.22.168 kernel and
trying to suspend didn't solve the problem. The machine kept hanging as on
After changing back to a 32bit installation I tried again. The result was the
same hanger as always.
After setting the parameter noapic suspending worked suddenly. I've no clue why
"noapic" is working suddenly, but I'm sure that I tried "noapic" with earlier
kernels on the 64bit installation. Those kernels never even booted.
A lot changed between the two tries: compiler 4.0/4.1 and 32bit/64bit. What I
could do is to install again a 64bit/gcc4.1 version and take a look if "noapic"
would still work.
Markus, can you please verify if this is a duplicate of Bug #5534 and if the
final patches for that bug fix your problem?
I'm closing this entry. Please reopen if you think that's necessary.