Bug 7185 - ACPI fails after resume from disk
Summary: ACPI fails after resume from disk
Status: REJECTED UNREPRODUCIBLE
Alias: None
Product: Drivers
Classification: Unclassified
Component: Platform (show other bugs)
Hardware: i386 Linux
: P2 normal
Assignee: Rafael J. Wysocki
URL:
Keywords:
Depends on:
Blocks: 7216
  Show dependency tree
 
Reported: 2006-09-22 10:48 UTC by Soenke Huels
Modified: 2010-10-08 18:17 UTC (History)
1 user (show)

See Also:
Kernel Version: 2.6.17
Subsystem:
Regression: ---
Bisected commit-id:


Attachments
dmesg output with custom DSDT (15.19 KB, application/octet-stream)
2006-09-22 10:58 UTC, Soenke Huels
Details
dmesg output with shipped DSDT (15.20 KB, text/plain)
2006-09-22 10:58 UTC, Soenke Huels
Details
acpidump of freshly booted system (75.17 KB, text/plain)
2006-09-22 10:59 UTC, Soenke Huels
Details
acpidump after error occured (75.17 KB, text/plain)
2006-09-22 11:02 UTC, Soenke Huels
Details
acpidump when suspend worked (75.17 KB, text/plain)
2006-09-22 11:04 UTC, Soenke Huels
Details

Description Soenke Huels 2006-09-22 10:48:55 UTC
Most recent kernel where this bug did not occur: precise version unknown, < 2.6.15 
Distribution: Debian unstable
Hardware Environment: Samsung X05 XTC 1400c BIOS version 11QK
Software Environment: custom 2.6.17 kernel (without and with suspend2 patch),
hibernate script, laptop-mode
Problem Description:

When suspending to disk (tried suspend2 as well as in-kernel swsusp), ACPI stops
working after resume with the following errors:

Sep 22 19:46:49 paula kernel:      osl-0822 [30] os_wait_semaphore     : Failed
to acquire semaphore[c145e6a0|1|0], AE_TIME
Sep 22 19:46:49 paula kernel:      osl-0822 [30] os_wait_semaphore     : Failed
to acquire semaphore[c145e6a0|1|1000], AE_TIME
Sep 22 19:46:49 paula kernel:      osl-0822 [30] os_wait_semaphore     : Failed
to acquire semaphore[c145e6a0|1|0], AE_TIME
Sep 22 19:46:49 paula kernel:      osl-0822 [30] os_wait_semaphore     : Failed
to acquire semaphore[c145e6a0|1|1000], AE_TIME
Sep 22 19:46:49 paula kernel:      osl-0822 [30] os_wait_semaphore     : Failed
to acquire semaphore[c145e6a0|1|0], AE_TIME
Sep 22 19:46:49 paula kernel:      osl-0822 [30] os_wait_semaphore     : Failed
to acquire semaphore[c145e6a0|1|1000], AE_TIME
Sep 22 19:46:49 paula kernel:      osl-0822 [30] os_wait_semaphore     : Failed
to acquire semaphore[c145e6a0|1|0], AE_TIME
Sep 22 19:46:49 paula kernel:      osl-0822 [30] os_wait_semaphore     : Failed
to acquire semaphore[c145e6a0|1|1000], AE_TIME
Sep 22 19:46:49 paula kernel: ACPI Exception (evregion-0409): AE_NOT_FOUND,
Returned by Handler for [EmbeddedControl] [20060127]
Sep 22 19:46:49 paula kernel: ACPI Exception (dswexec-0458): AE_NOT_FOUND, While
resolving operands for [ShiftRight] [20060127]
Sep 22 19:46:49 paula kernel: ACPI Error (psparse-0517): Method parse/execution
failed [\_WAK] (Node df6d5168), AE_NOT_FOUND

After this it is no more possible to use the "acpi" program. Also, the system
hangs on reboot while diasabling the laptop-mode.

Steps to reproduce:
suspend to disk, resume

Further info:
Suspend to RAM works very well on this machine. Also it seems that if the system
is put into S3, woken up and suspended to disk later, the error does not occur.

The error is reproduceable with several kernel versions from 2.6.15 to
2.6.18-rc7. I tried the DSDT for the most recent bios (11QK) from acpi.sf.net,
but without success.
Comment 1 Soenke Huels 2006-09-22 10:58:10 UTC
Created attachment 9074 [details]
dmesg output with custom DSDT

dmesg output of error with DSDT form acpi.sf.net
Comment 2 Soenke Huels 2006-09-22 10:58:53 UTC
Created attachment 9075 [details]
dmesg output with shipped DSDT
Comment 3 Soenke Huels 2006-09-22 10:59:35 UTC
Created attachment 9076 [details]
acpidump of freshly booted system
Comment 4 Soenke Huels 2006-09-22 11:02:04 UTC
Created attachment 9077 [details]
acpidump after error occured

The output of acpidump changes slightly in the "FACS" part when the error
occurs.
Is this normal?
Comment 5 Soenke Huels 2006-09-22 11:04:12 UTC
Created attachment 9078 [details]
acpidump when suspend worked

The output of acpidump is also different if suspend to disk worked (sometimes,
under the conditions mentioned above). 
I hope all this info is helpful, if more is needed I will gladly supply it.
Comment 6 Soenke Huels 2006-09-27 01:41:46 UTC
In the last days, I did a bit of further testing on my problem.
I observed that the error occurs when I exchanged the battery while the system
was running. If it is suspended to disk after that, it produces the error
mentioned before on resume.
If the battery is exchanged while the machine is powered off or suspended, there
is no acpi error. 
Perhaps this behavior yields some clues as to what could be wrong?
Comment 7 Robert Moore 2006-10-11 12:02:11 UTC
Looks like an embedded controller issue
Sep 22 19:46:49 paula kernel:      osl-0822 [30] os_wait_semaphore     : Failed
to acquire semaphore[c145e6a0|1|1000], AE_TIME
Sep 22 19:46:49 paula kernel: ACPI Exception (evregion-0409): AE_NOT_FOUND,
Returned by Handler for [EmbeddedControl] [20060127]
Comment 8 Paul Lauria 2006-10-13 12:48:05 UTC
I too am affected by this bug, on an Acer laptop using a custom DSDT that works
on older kernels.

Basically for me, after suspend the gnome power daemon would erroneously report
a 100% battery supply forever. dmesg | grep acpi shows:

[17189385.076000] ACPI Exception (acpi_ac-0097): AE_TIME, Error reading AC
Adapter state [20060707]
[17189385.128000] ACPI Exception (acpi_battery-0208): AE_TIME, Evaluating _BST
[20060707]
[17270581.992000] ACPI Exception (acpi_ac-0097): AE_TIME, Error reading AC
Adapter state [20060707]
[17270582.044000] ACPI Exception (acpi_battery-0208): AE_TIME, Evaluating _BST
[20060707]


Is there any workaround? Is it fixed in 2.6.18? 
Comment 9 Rafael J. Wysocki 2007-08-09 09:19:37 UTC
This bug looks pretty old.  Has there been any progress since last October?
Comment 10 Rafael J. Wysocki 2007-08-20 10:17:22 UTC
Can anyone please confirm that the bug is still present in the newest kernels (preferably 2.6.23-rc2)?

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