Most recent kernel where this bug did not occur: somewhere in 2.6.16-rc series Distribution: Gentoo Hardware Environment: Laptop HP Pavilion ze5616ea Software Environment: not relevant Problem Description: I noticed that after the upgrade to a release candidate of kernel 2.6.16 _sometimes_ at boot I get some ACPI error messages, like: ------------- Mar 22 22:20:30 kurtz ACPI: write EC, IB not empty Mar 22 22:20:30 kurtz ACPI Exception (evregion-0409): AE_TIME, Returned by Handler for [EmbeddedControl] [20060127] Mar 22 22:20:30 kurtz ACPI Error (psparse-0517): Method parse/execution failed [\_SB_.PCI0.ISA_.EC0_.SMRD] (Node c13ecd40), AE_TIME Mar 22 22:20:30 kurtz ACPI Error (psparse-0517): Method parse/execution failed [\_SB_.BAT1.UPBI] (Node dbf42720), AE_TIME Mar 22 22:20:30 kurtz ACPI Error (psparse-0517): Method parse/execution failed [\_SB_.BAT1.CHBP] (Node dbf42660), AE_TIME Mar 22 22:20:30 kurtz ACPI Error (psparse-0517): Method parse/execution failed [\_SB_.PCI0.ISA_.EC0_.SMSL] (Node c13ecce0), AE_TIME Mar 22 22:20:30 kurtz ACPI Error (psparse-0517): Method parse/execution failed [\_SB_.PCI0.ISA_.EC0_._Q09] (Node c13ecc40), AE_TIME ------------- and ------------- Mar 23 03:48:50 kurtz ACPI: read EC, IB not empty Mar 23 03:48:50 kurtz ACPI: read EC, OB not full Mar 23 03:48:50 kurtz ACPI Exception (evregion-0409): AE_TIME, Returned by Handler for [EmbeddedControl] [20060127] Mar 23 03:48:50 kurtz ACPI Exception (dswexec-0458): AE_TIME, While resolving operands for [AE_NOT_CONFIGURED] [20060127] Mar 23 03:48:50 kurtz ACPI Error (psparse-0517): Method parse/execution failed [\_SB_.PCI0.ISA_.EC0_._Q20] (Node c13ecbc0), AE_TIME ------------- The bug appears quite at random times, even if it seems that it happens only when rebooting (i.e., when the machine is powered on from a power-off state the problem does not manifest). From my logs it seems that the problem first appeared in 2.6.16-rc5. From a suggestion on lkml it seems (so far!) that booting with the "ec_intr=0" option solves the problem. Probably I should also mention that the kernel is not a vanilla one, since usually I apply some extra patches, albeit unrelated to ACPI: reiser4, fbsplash, vesafb-tng, etc... However the problem manifested for the first time in the 2.6.16-rc series, whereas I'm using those patches from much earlier. So I tend to consider them not relevant to this bugreport. I'm attaching two dmesg, one with and one without the "ec_intr=0" boot optio, as requested by Yu Luming on lkml. Steps to reproduce: Boot with kernel 2.6.16. Cross your fingers.
Created attachment 7652 [details] dmesg _without_ the "ec_intr=0" boot option Attached dmesg _without_ the "ec_intr=0" boot option
Created attachment 7653 [details] dmesg _with_ the "ec_intr=0" boot option Attached dmesg _with_ the "ec_intr=0" boot option
I should probably mention that the only practical consequence of this bug is that when it is triggered the battery is not detected by the ACPI subsystem. HTH
I found this in the dmesg with ec_intr=0: >Mar 23 14:36:33 kurtz ACPI: Battery Slot [BAT1] (battery absent) Do you think ec_intr=0 really work for you?
Yu: that messge has been there forever on this laptop, but nevertheless the battery is there after bootup (that is, when the bug reported here is not triggered). Yes I know, I should have reported this discrepancy earlier... :/
For kernel with ec_burst=0 , please try boot with acpi_dbg_layer=0xffffffff acpi_dbg_level=0x1f. Please post dmesg . I want to see if _Q09 could be invoked or not.
Yu: do you mean that I should boot with _both_ "ec_burst=0" and "acpi_dbg_layer=0xffffffff acpi_dbg_level=0x1f" ?
right
Created attachment 7660 [details] Very verbose dmesg with debug enabled Yu: I've recompiled the kernel with ACPI debug and increased ring buffer size, and booted with the options you requested. The output is pretty verbose. HTH
From this dmesg (ec_intr=1), I found NO error. BTW, i'm sorry, it should be ec_intr=0
Yu, so I'm supposed to add "ec_intr=0" to boot options and reboot until I can reproduce the problem? Or just reboot once and post the dmesg? FYI, I've never been able to reproduce the problem with "ec_intr=0".
>FYI, I've never been able to reproduce the problem with "ec_intr=0". But I found "battery absent" in the dmesg with ec_intr=0: Please just boot kernel one time,with ec_intr=0. I want to check if_Q09 could be invoked or not, I believe _Q09 tigger EC error for ec_intr=1, not sure if it could trigger same EC error fo ec_intr=0 too.
Created attachment 7730 [details] dmes with debug and ec_intr=0 Yu, sorry for the delay, I've been away. I've done as you requested, HTH.
Do you have battery installed? all dmesg show battery absent. Also, AE_TIME error seems to appear randomly with ec_intr=1. Could you please try acpi_serialize ?
Yu: yes, I have battery installed. Even if it is not seen at boot-time, when boot is complete the battery is indeed there. I can see it right now from kde's powersave manager. What do you mean with "acpi_serialize"? Boot with "acpi_serialize=1" boot option?
Ok, I just took a look at kernel-parameters.txt Apparently appending acpi_serialize will do the trick.
Created attachment 7770 [details] dmesg + acpi_serialize + ec_intr=0
Created attachment 7771 [details] dmesg + acpi_serialize + ec_intr=1
Hmmm, is it due to that ec_intr=1 doesn't disable interrupt? Let's try this patch: http://bugzilla.kernel.org/show_bug.cgi?id=5764#c1 which doesn't disalbe interrupt for ec_intr=0. --Luming
Created attachment 7774 [details] dmesg + acpi_serialize + patch + ec_intr=0 Luming, done as requested, but apparently the battery is still not recognized initially.
I also heard of some machines throwing AE_TIME messages here and there with the result of some non-working ACPI parts (e.g. thermal critical shutdown even the machine is not hot, and other weird things). AFAIK this happens more often when the machine is on load? Just and idea: Could it be possible that these AE_TIME errors and this bug is related to the fact that ACPI control methods are not executed threaded and that this bug is related http://bugzilla.kernel.org/show_bug.cgi?id=5534 Francesco: Does the patch stated there work for you?
Thomas: I'm a bit busy at the moment, I'll try asap and report back here. Thanks for the hint
Created attachment 8196 [details] grep ACPI /var/log/syslog grep ACPI /var/log/syslog is attached, the first boot process (May 21 11:20) is with the old kernel (2.6.9), the next one with the new (2.6.16).
Hi there! I just want to report that I have similar issues on a HP nc6000. cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 13 model name : Intel(R) Pentium(R) M processor 1.60GHz stepping : 6 cpu MHz : 1600.000 cache size : 2048 KB grep ACPI /var/log/syslog is attached, the first boot process (May 21 11:20) is with the old kernel, the next one with the new. http://bugzilla.kernel.org/attachment.cgi?id=8196 The fan does work ok. However, when the load increases only for a short time, it often switches on and then off again only a dew seconds afterwards, often multiple times in a row. This had not happened for me on a 2.6.9 kernel, but happens now after I updated to 2.6.16: Linux theo-dhcp-42 2.6.16-suspend2-1 #3 PREEMPT Mon May 22 18:03:00 CEST 2006 i686 GNU/Linux Also, the primary battery is not found. The second slot (which is empty) is correctly found. I have only applied the suspend2 patch. The problem is not serious, but annoying.
Can you try this patch: http://bugzilla.kernel.org/show_bug.cgi?id=6111 comment #31 Does it make the AE_TIME errors go away? Better fan behaviour? If you do not see any difference you may want to try Konstantin's and/or Peter's patch from: http://bugzilla.kernel.org/show_bug.cgi?id=5534 Be aware that there are reports that suspend to disk/ram may not work properly any more with these patches. If one helps, please report to bug #5534 and help the guys to get the last things fixed.
http://bugzilla.kernel.org/show_bug.cgi?id=6111#c31 This patch indeed fixes the "howling fan" problem, thanks a lot! it doesn't change its state that often anymore. However, I still see the ACPI errors in the syslog and the battery isn't found either.
The battery is only not found with this patch? http://bugzilla.kernel.org/show_bug.cgi?id=6111#c31 Can you try whether the AE_TIME errors go away with the other patch (better only try one patch per test...). Could you also attach whole dmesg output and acpidump, please. Are these AE_TIME errors 100% reproducable (always the same error messages on every boot)?
Created attachment 8199 [details] acpidump, HP nc6000 The battery wasn't found since I upgraded to 2.6.16. The ACPI errors are mostly the same, some only appear since I got the suspend2 patch to work. acpidump is attached, will test patches later.
Created attachment 8205 [details] dmesg after wakeup from suspend dmesg after resume. After resume the fan is in howl-mode again.
Created attachment 8206 [details] dmesg after reboot, hp nc6000
http://bugzilla.kernel.org/show_bug.cgi?id=6111#c31 Sorry, this patch does not fix the problem, even after a reboot. I've just rebooted and the problem is back.
Can you summarize exactly what still fails with a recent kernel, say 2.6.18-rc?
Hello, this seems to be solved in 2.6.19-rc*. I'm running 2.6.19-rc4 at the moment and: 1) I have yet to see ACPI errors on boot 2) the battery of my laptop gets detected correctly 3) ACPI events (such as plug/unplug AC) are always reported (quickly). I don't know what you did in 2.6.18 but ACPI has definitely improved on this laptop :) Thanks, for me the bug is closed.