Bug 4967 - S3 wakeup - "Failed to acquire semaphore" AE_TIME
S3 wakeup - "Failed to acquire semaphore" AE_TIME
Status: REJECTED DUPLICATE of bug 5008
Product: ACPI
Classification: Unclassified
Component: Power-Thermal
i386 Linux
: P2 normal
Assigned To: Konstantin Karasyov
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-07-29 18:44 UTC by Sanjoy Mahajan
Modified: 2005-09-06 04:14 UTC (History)
2 users (show)

See Also:
Kernel Version: 2.6.13-rc3-mm2
Tree: Mainline
Regression: ---


Attachments
acpidmp output (206.32 KB, application/octet-stream)
2005-07-29 18:46 UTC, Sanjoy Mahajan
Details
acpi debug output with debug_level=0x31F (413.47 KB, text/x-log)
2005-07-30 15:37 UTC, Sanjoy Mahajan
Details

Description Sanjoy Mahajan 2005-07-29 18:44:55 UTC
Distribution: Debian testing ('etch')
Hardware Environment: TP 600X Pentium III 650 MHz, 576 MB, w/ prism54 wireless
                       PCMCIA card in slot
Software Environment: acpidmp output attached
Problem Description: Waking up from S3 sleep produces

osl-0915 [45] acpi_os_wait_semaphore: Failed to acquire semaphore[e3fce660|1|0],
AE_TIME

Not sure if this problem is a precursor to the more serious problem that I can
S3 sleep only once (bug #4926)

Here's a bit more from the syslog:

[4295331.270000] PM: Finishing wakeup.
[4295331.270000] PCI: Found IRQ 11 for device 0000:00:02.0
[4295331.272000] PCI: Sharing IRQ 11 with 0000:00:06.0
[4295331.272000] PCI: Sharing IRQ 11 with 0000:01:00.0
[4295331.303000] PCI: Found IRQ 11 for device 0000:00:02.1
[4295332.006000] PCI: Found IRQ 11 for device 0000:00:06.0
[4295332.006000] PCI: Sharing IRQ 11 with 0000:00:02.0
[4295332.006000] PCI: Sharing IRQ 11 with 0000:01:00.0
[4295333.996000] acpi_bus-0077 [18] acpi_bus_get_device   : No context for
object [c1573ac8]
[4295337.083000] Restarting tasks... done
[4295341.479000]      osl-0915 [45] acpi_os_wait_semaphore: Failed to acquire
semaphore[e3fce660|1|0], AE_TIME
[4295341.479000]      osl-0915 [47] acpi_os_wait_semaphore: Failed to acquire
semaphore[e3fce660|1|100], AE_TIME

Steps to reproduce:

Boot into X and run:

ifdown eth0 ; modprobe -r prism54
/etc/init.d/hotplug stop > /dev/null
/etc/init.d/chrony stop  > /dev/null
sync
sleep 2

echo -n mem > /sys/power/state
# to get the X display restored (vga display is always hosed, alas)
chvt 1
sleep 1
chvt 7
Comment 1 Sanjoy Mahajan 2005-07-29 18:46:37 UTC
Created attachment 5417 [details]
acpidmp output
Comment 2 Andrew Morton 2005-07-29 21:11:52 UTC
Did any previous 2.6 kernel work OK?  2.6.13-rc4?

Comment 3 Sanjoy Mahajan 2005-07-29 21:25:02 UTC
> Did any previous 2.6 kernel work OK?  2.6.13-rc4?

2.6.11.4 has been S3 sleeping and waking happily (after I hacked the DSDT to
have an S3 sleep object).  With the same DSDT, 2.6.13-rc3 would hang when waking
up from sleep (see bug #4926), so I was quite pleased to see S3 working better
with -mm2.

Is the 2.6.13-rc4 the next one I should try, or 2.6.13-rc3-mm3?

A general question on the kernel test-patch-compile cycle: Is it safe to
add/subtract patches, say going betweeen -mm2 and -mm3 and then do 'make', or
does one have to do 'make clean && make' (which of course takes much longer)? 
i.e. Are the makefiles robust enough?
Comment 4 Andrew Morton 2005-07-29 21:56:23 UTC
I guess you should try 2.6.13-rc4 because it's out release candidate.
And you should try 2.6.13-rc3-mm3 because it has a monster acpi
patch in it ;)

And yes, the 2.6 makefiles will cope with that.  The 2.5 makefiles
are much less robust though.

Comment 5 Sanjoy Mahajan 2005-07-29 23:58:15 UTC
I just tried 2.6.13-rc4 and it's less happy than rc3-mm2.  It hangs trying to
sleep (after the 'stopping tasks').  

I just found out that I can generate the semaphore errors without even trying
sleep; I just need to run the following 'quiet-fan' script:

#!/bin/bash
# make fan turn on only at higher temps in the TP 600X
trip=${1:-50}
cd /proc/acpi/thermal_zone
echo 120:0:40:${trip}:0 > THM2/trip_points
echo 10 > THM2/polling_frequency
# to work around TP600X DSDT bug where only THM0 polls
echo 10 > THM0/polling_frequency

The errors from running quiet-fan may not be new to -rc4.  In the rc3-mm2 syslog
I found two more of the sempahore errors not related to sleep, and I think I had
told the fan to quiet down then.

2.6.11.4 doesn't produce errors with quiet-fan.

(Still compiling rc3-mm3 to test its huge acpi patch...)

Anyway here are a few more of the sempahore errors, this time all from quiet-fan
with 2.6.13-rc4 (the first two or three are from the first use of quiet-fan, the
others are from a 2nd use):

Linux version 2.6.13-rc4-200507301 (root@sanjoy) (gcc version 3.3.5 (Debian
1:3.3.5-13)) #1 Sat Jul 30 01:10:23 EDT 2005
      osl-0961 [38] os_wait_semaphore     : Failed to acquire
semaphore[e3fce600|1|0], AE_TIME
      osl-0961 [40] os_wait_semaphore     : Failed to acquire
semaphore[e3fce600|1|100], AE_TIME
      osl-0961 [38] os_wait_semaphore     : Failed to acquire
semaphore[e3fce600|1|0], AE_TIME
      osl-0961 [39] os_wait_semaphore     : Failed to acquire
semaphore[e3fce600|1|0], AE_TIME
      osl-0961 [39] os_wait_semaphore     : Failed to acquire
semaphore[e3fce600|1|100], AE_TIME
      osl-0961 [37] os_wait_semaphore     : Failed to acquire
semaphore[e3fce600|1|0], AE_TIME
      osl-0961 [37] os_wait_semaphore     : Failed to acquire
semaphore[e3fce600|1|100], AE_TIME
Comment 6 Sanjoy Mahajan 2005-07-30 07:59:51 UTC
Just did the rc3-mm3 tests. Here's a summary so far:

Generic kernel command line:
   idebus=66 apm=off acpi=force pci=noacpi

sleep/wake sort of works only with rc3-mm2, so the logs are complete
there.  For the other versions, it half works or less, but from the
evidence that did get into the syslogs:

2.6.13-rc3-mm3: 
    The 'quiet-fan' script from Additonal Comment #5 (setting trip point) does 
         not produce them
    WITH acpi_sleep=s3_bios: going to sleep produces them
    W/O  acpi_sleep=s3_bios: not in the log, but their absence may be
         because the system hangs earlier in the sleep than with s3_bios

2.6.13-rc3-mm2: waking up produces them (almost surely from 'quiet-fan')

2.6.13-rc4: quiet-fan produces them
            going to sleep produces them, with or without acpi_sleep=s3_bios
Comment 7 Sanjoy Mahajan 2005-07-30 15:31:32 UTC
The semaphore failure is easy to reproduce with 2.6.13-rc4, but it's slippery. 
With acpi_debug set to 0xF, the 2nd run of this line will produce them:

echo 10 > /proc/acpi/thermal_zone/THM2/polling_frequency

If I turn on a lot more debugging, then I can't get it to occur.  With
debug_level=0x1F, it will happen after six or seven runs.  In particular, to
reproduce, I run the script below, which keeps redoing the echo until a 'Failed'
message appears in the syslog.  I'll attach the section of the syslog with the
resulting output.

#!/bin/bash

# to clear out the syslog
/etc/cron.daily/logrotate
logger MARKER_0
echo 0x0000031F > /proc/acpi/debug_level
/etc/init.d/acpid restart > /dev/null
while ! grep -qs 'Failed to acquire semaphore' /var/log/syslog > /dev/null ; do
  logger -t acpidbg About to change polling frequency
  echo 10 > /proc/acpi/thermal_zone/THM2/polling_frequency
  sleep 0.5
  echo .
done
echo 0x0000000F > /proc/acpi/debug_level
Comment 8 Sanjoy Mahajan 2005-07-30 15:37:59 UTC
Created attachment 5429 [details]
acpi debug output with debug_level=0x31F

In the attached piece of the syslog, these lines are logged when the script is
about to 'echo 10' to the polling frequency:

  acpidbg: About to change polling frequency

The 44th occurence (line 4141) produces the semaphore error (line 4168).

Let me know if I should try a different set of debug flags.
Comment 9 Len Brown 2005-08-14 21:53:52 UTC
still an issue with 2.6.13-rc6?

(changing category to power-thermal, since the simple test
 case causes the failure there)
Comment 10 Sanjoy Mahajan 2005-08-14 22:16:03 UTC
> still an issue with 2.6.13-rc6?

It is.  I've now put the semaphore error in its own report (Bug
#5008).  Compiling without preempts gets rid of the error, so I'm not
sure whether it's only a thermal error.

Comment 11 Sanjoy Mahajan 2005-08-14 22:20:40 UTC
> I'm not sure whether it's only a thermal error.

It's definitely not just a thermal error.  I can produce those
messages by running 'acpi' (so just checking battery status) or
by running in the shell (bash):

  while true ; do cat /proc/acpi/battery/BAT*/info ; done

-Sanjoy

Comment 12 Konstantin Karasyov 2005-09-06 04:14:49 UTC

*** This bug has been marked as a duplicate of 5008 ***

Note You need to log in before you can comment on or make changes to this bug.