Created attachment 5417 [details]
acpidmp output

Did any previous 2.6 kernel work OK?  2.6.13-rc4?

> 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?

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.

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

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

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

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.

still an issue with 2.6.13-rc6?

(changing category to power-thermal, since the simple test
 case causes the failure there)

> 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.

> 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

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