Bug 5962

suspend went oops in the acpi code.   Maybe
a bug in Len's devel tree?

>soft lockup
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:
http://homepage.hispeed.ch/hb9xcg/suspend-2.6.16-rc2.JPG

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?

>>soft lockup
>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:
http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-
2.6.git;a=commit;h=0dd2ea9af8f0eca43cf6200baa182b3aba307049

I suppose it's fixed in 2.6.16-rc3. if not, please reopen this bug and provide 
the dmesg. Thanks!

Hi
Unfortunately 2.6.16-rc3 doesn't work different than the rc2 did.
Dmesg after booting looks like this:
     
    http://homepage.hispeed.ch/hb9xcg/linux-2.6.16-rc3.dmesg

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.

lsmod:
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:
   http://homepage.hispeed.ch/hb9xcg/without_usb_before_pressing_key.jpg

After pressing carriage return suspend continues with this screen:
   http://homepage.hispeed.ch/hb9xcg/without_usb_after_pressing_key.jpg

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
suspend/resume?

Markus,

Please verify if patch to #5534 fixes your problem as well.

Hi Alexey
My first try applying your 2nd version of the patch to a 2.6.16.14 kernel and
trying to suspend didn't solve the problem. The machine kept hanging as on
earlier tries.
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.