Bug 6278

Summary: ACPI error messages in 2.6.16 - HP Pavilion ze5616ea, HP nc6000
Product: ACPI Reporter: Francesco Biscani (bluescarni)
Component: Power-BatteryAssignee: Luming Yu (luming.yu)
Status: CLOSED PATCH_ALREADY_AVAILABLE    
Severity: normal CC: acpi-bugzilla, bunk, trenn
Priority: P2    
Hardware: i386   
OS: Linux   
Kernel Version: 2.6.16 Subsystem:
Regression: --- Bisected commit-id:
Attachments: dmesg _without_ the "ec_intr=0" boot option
dmesg _with_ the "ec_intr=0" boot option
Very verbose dmesg with debug enabled
dmes with debug and ec_intr=0
dmesg + acpi_serialize + ec_intr=0
dmesg + acpi_serialize + ec_intr=1
dmesg + acpi_serialize + patch + ec_intr=0
grep ACPI /var/log/syslog
acpidump, HP nc6000
dmesg after wakeup from suspend
dmesg after reboot, hp nc6000

Description Francesco Biscani 2006-03-23 14:23:52 UTC
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.
Comment 1 Francesco Biscani 2006-03-23 14:31:25 UTC
Created attachment 7652 [details]
dmesg _without_ the "ec_intr=0" boot option

Attached dmesg _without_ the "ec_intr=0" boot option
Comment 2 Francesco Biscani 2006-03-23 14:32:24 UTC
Created attachment 7653 [details]
dmesg _with_ the "ec_intr=0" boot option

Attached dmesg _with_ the "ec_intr=0" boot option
Comment 3 Francesco Biscani 2006-03-24 05:10:33 UTC
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 
Comment 4 Luming Yu 2006-03-24 05:59:50 UTC
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?
Comment 5 Francesco Biscani 2006-03-24 06:08:51 UTC
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... :/ 
Comment 6 Luming Yu 2006-03-24 06:30:13 UTC
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.
Comment 7 Francesco Biscani 2006-03-24 06:41:09 UTC
Yu: 
 
do you mean that I should boot with _both_ 
 
"ec_burst=0" 
 
and 
 
"acpi_dbg_layer=0xffffffff acpi_dbg_level=0x1f" 
 
? 
Comment 8 Luming Yu 2006-03-24 06:43:52 UTC
right
Comment 9 Francesco Biscani 2006-03-24 07:26:20 UTC
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
Comment 10 Luming Yu 2006-03-24 07:39:32 UTC
From this dmesg (ec_intr=1), I found NO error.

BTW, i'm sorry, it should be ec_intr=0
Comment 11 Francesco Biscani 2006-03-24 07:47:38 UTC
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". 
Comment 12 Luming Yu 2006-03-26 23:42:26 UTC
>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.
Comment 13 Francesco Biscani 2006-03-31 04:57:36 UTC
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.
Comment 14 Luming Yu 2006-04-05 01:01:02 UTC
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 ?

Comment 15 Francesco Biscani 2006-04-05 05:22:12 UTC
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?
Comment 16 Francesco Biscani 2006-04-05 05:24:44 UTC
Ok, I just took a look at kernel-parameters.txt

Apparently appending acpi_serialize will do the trick.
Comment 17 Francesco Biscani 2006-04-05 05:50:02 UTC
Created attachment 7770 [details]
dmesg + acpi_serialize + ec_intr=0
Comment 18 Francesco Biscani 2006-04-05 05:50:34 UTC
Created attachment 7771 [details]
dmesg + acpi_serialize + ec_intr=1
Comment 19 Luming Yu 2006-04-05 06:11:10 UTC
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
Comment 20 Francesco Biscani 2006-04-05 08:24:55 UTC
Created attachment 7774 [details]
dmesg + acpi_serialize + patch + ec_intr=0

Luming,

done as requested, but apparently the battery is still not recognized
initially.
Comment 21 Thomas Renninger 2006-04-19 04:47:46 UTC
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? 
Comment 22 Francesco Biscani 2006-04-25 07:06:07 UTC
Thomas: I'm a bit busy at the moment, I'll try asap and report back here. 
Thanks for the hint
Comment 23 Gerhard Killesreiter 2006-05-24 03:22:48 UTC
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).
Comment 24 Gerhard Killesreiter 2006-05-24 03:23:49 UTC
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.
Comment 25 Thomas Renninger 2006-05-24 04:01:17 UTC
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.
Comment 26 Gerhard Killesreiter 2006-05-24 06:54:24 UTC
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.
Comment 27 Thomas Renninger 2006-05-24 08:51:28 UTC
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)?
Comment 28 Gerhard Killesreiter 2006-05-24 11:10:35 UTC
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.
Comment 29 Gerhard Killesreiter 2006-05-25 09:23:58 UTC
Created attachment 8205 [details]
dmesg after wakeup from suspend

dmesg after resume. After resume the fan is in howl-mode again.
Comment 30 Gerhard Killesreiter 2006-05-25 11:29:21 UTC
Created attachment 8206 [details]
dmesg after reboot, hp nc6000
Comment 31 Gerhard Killesreiter 2006-05-26 08:15:19 UTC
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.
Comment 32 Len Brown 2006-08-10 02:12:29 UTC
Can you summarize exactly what still fails with a recent kernel,
say 2.6.18-rc?
Comment 33 Francesco Biscani 2006-11-01 03:18:16 UTC
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.