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).
Created attachment 18411 [details] Clean 2.6.27.2 boot dmesg
Created attachment 18412 [details] dmesg just after this issue is happens
Hi, Dmitry Will you please attach the output of acpidump? Thanks.
Created attachment 18422 [details] acpidump output Attaching...
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.
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>
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.
Created attachment 18475 [details] revert msleep() Here is the revert patch.
patch in comment #8 is in the acpi tree
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