Bug 11810

Summary: ACPI errors just after resuming from s2disk
Product: ACPI Reporter: Dmitry Nezhevenko (dion)
Component: ACPICA-CoreAssignee: Alexey Starikovskiy (astarikovskiy)
Status: CLOSED CODE_FIX    
Severity: normal CC: acpi-bugzilla, astarikovskiy
Priority: P1    
Hardware: All   
OS: Linux   
Kernel Version: 2.6.27 Subsystem:
Regression: Yes Bisected commit-id:
Attachments: Clean 2.6.27.2 boot dmesg
dmesg just after this issue is happens
acpidump output
revert msleep()

Description Dmitry Nezhevenko 2008-10-23 00:13:48 UTC 
Latest working kernel version: 2.6.25 (not sure)
Earliest failing kernel version: 2.6.27
Distribution: Debian Unstable
Hardware Environment: MSI M673 laptop (AMD Turion + NVIDIA chipset)

Followed errors messages floods dmesg sometimes just after resuming from hibernate (approx. every second):

[42016.520062] ACPI: EC: acpi_ec_wait timeout, status = 0x1a, event = "b1=0"
[42016.520079] ACPI: EC: input buffer is not empty, aborting transaction
[42017.025050] ACPI: EC: acpi_ec_wait timeout, status = 0x1a, event = "b1=0"
[42017.025197] ACPI: EC: input buffer is not empty, aborting transaction
[42017.025254] ACPI Exception (evregion-0419): AE_TIME, Returned by Handler for [EmbeddedControl] [20080609]
[42017.025350] ACPI Error (psparse-0530): Method parse/execution failed [\_SB_.PCI0.SBRG.EC__.BAT1.UPBS] (Node f78353b0), AE_TIME
[42017.025546] ACPI Error (psparse-0530): Method parse/execution failed [\_SB_.PCI0.SBRG.EC__.BAT1._BST] (Node f7835400), AE_TIME
[42017.025715] ACPI Exception (battery-0360): AE_TIME, Evaluating _BST [20080609]

Battery state is not updating after this. So if it was charged to "90%" it will be displayed 90% forever.. Charger plugged/unplugged status is not updated too. (However display backlight is automatically adjusted after plugging it. Looks like this is hardware feature or is done by BIOS)

Rebooting/turing off/on causes system freeze before displaying BIOS splash. So I got just blank screen (with turned off backlight in case of turning off). I can turn laptop off again by pressing power button for ~3 seconds, however after turning it on it will not boot. The only way to make it working again is removing battery with unplugged charger for 4-5 seconds.

I can't test v2.6.26 kernel, since it was unbootable here at all for some other reason that was fixed in 2.6.27-rc7. I think that there was no such problem with 2.6.25 however I'm not 100% sure.

Issue is very difficult to reproduce (this is just second case for ~2-3 weeks). So I think, that bisecting is impossible (or will take years).

I don't use msi-laptop module (however I can load it with force=1 and it will work). 

Alexey Starikovskiy at lkml suggested to replace msleep(1) with udelay(50) in drivers/acpi/ec.c. I've dont this and tried ~15 hibernate/resume cycles.. There were no errors. Since it's very difficult to reproduce issue I will wait some time with this patched kernel. (CC'ing here)

s2disk is done via TOI patch (applied on top of 2.6.27.2).
Comment 1 Dmitry Nezhevenko 2008-10-23 00:15:03 UTC 
Created attachment 18411 [details]
Clean 2.6.27.2 boot dmesg
Comment 2 Dmitry Nezhevenko 2008-10-23 00:15:53 UTC 
Created attachment 18412 [details]
dmesg just after this issue is happens
Comment 3 ykzhao 2008-10-23 18:36:17 UTC 
Hi, Dmitry
    Will you please attach the output of acpidump?
    Thanks.
Comment 4 Dmitry Nezhevenko 2008-10-23 22:19:20 UTC 
Created attachment 18422 [details]
acpidump output

Attaching...
Comment 5 ykzhao 2008-10-24 00:02:48 UTC 
Will you please confirm whether early version kernel can work well ? If so, you are appreciated to identify which is OK.

    From the problem description it seems that the EC problem occurs when accessing the info of the battery. (_BST object of the battery). 
    Before the EC internal register is accessed, OS will check the IBF bit of status register. Unfortunately the EC status register is not what OS expected, so it will report the following info.
    >ACPI: EC: acpi_ec_wait timeout, status = 0x1a, event = "b1=0"
    
    Thanks.
Comment 6 Dmitry Nezhevenko 2008-10-24 01:01:20 UTC 
There were no such problems with kernels <= 2.6.25.x. At least I don't remember them. I own this laptop since times of 2.6.23-rc, so I think that 2.6.23-2.6.25 are good.

As I said, issue is difficult to reproduce, since it happens sometimemes (rarely enough). 2.6.27 release works usually too. For example I can do 5, 10 or even 20 hibernate -> resume cycles without such problems. It just happens sometimes.

Alexey suggested to replace msleep(1) with udelay(50) in drivers/acpi/ec.c (there is only one place to change). I've done it. And now I got ~15-18 successful hibernate->resume cycles without any problems.

msleep(1) was introduced by followed commit (according to git annotate):

commit 1b7fc5aae8867046f8d3d45808309d5b7f2e036a
Author: Alexey Starikovskiy <astarikovskiy@suse.de>
Date:   Fri Jun 6 11:49:33 2008 -0400

    ACPI: EC: Use msleep instead of udelay while waiting for event.

    http://bugzilla.kernel.org/show_bug.cgi?id=10724

    Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de>
    Signed-off-by: Len Brown <len.brown@intel.com>
Comment 7 Dmitry Nezhevenko 2008-10-27 14:36:19 UTC 
I'm still using 2.6.27 kernel with msleep(1) replaced to udelay(50). (So specified commit is reverted). Looks like such kernel is stable.. So I think that this commit is cause of regression.
Comment 8 Alexey Starikovskiy 2008-10-27 14:36:54 UTC 
Created attachment 18475 [details]
revert msleep()

Here is the revert patch.
Comment 9 Len Brown 2008-11-11 10:29:27 UTC 
patch in comment #8 is in the acpi tree
Comment 10 Len Brown 2008-11-12 21:33:38 UTC 
shipped in 2.6.28-rc4-git3

closed.

commit 1cfe62c8010ac56e1bd3827e30386a87cc2f3594
Author: Alexey Starikovskiy <astarikovskiy@suse.de>
Date:   Tue Oct 28 00:35:30 2008 +0300

    ACPI: EC: revert msleep patch