Bug 6278
| Summary: | ACPI error messages in 2.6.16 - HP Pavilion ze5616ea, HP nc6000 | ||
|---|---|---|---|
| Product: | ACPI | Reporter: | Francesco Biscani (bluescarni) |
| Component: | Power-Battery | Assignee: | 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
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. |