Most recent kernel where this bug did not occur: dunno, laptop is new Distribution: Debian stable/testing mix Hardware Environment: Acer TravelMate 2310 Problem Description: Battery charge status is not available. Steps to reproduce: acpid + gnome's Battery Charge Monitor Applet
Created attachment 5870 [details] tar bz2 w/ dmesg dmi intr pci acpidump
What further info can I provide for diagnostics? BTW, echoing 'mem' or 'disk' to /sys/power/state doesn't work either.
Please test patch at bug 3851. Please try ec_burst=0 and 1.
Which patch? I tried the the ec patch against linux-2.6.13-rc6 but it didn't apply cleanly at all. All hunks failed except the last one. Can you be more specific?
the patch is at http://bugzilla.kernel.org/show_bug.cgi?id=3851#c73 patch ec driver with: patch ec.c < ~/ec-2.6.10-rc6.patch
I applied the patch, recompiled. When booting with both ec_burst=1 and ec_burst=0, problem remains: cat /proc/acpi/battery/BAT1/state present: yes ERROR: Unable to read battery status See attached dmesg output. What more info can I provide?
Created attachment 5895 [details] tar bz2 of dmesg output with ec_burst=[01]
Do you have this issue before? please provide more debug info by doing : echo -n 0x10 > /proc/acpi/debug_layer echo -n 0x10 > /proc/acpi/debug_level before reading battery. Then attach the dmesg, thanks.
> Do you have this issue before? This is a brand new Acer TravelMate 2310. This is the first kernel I've built with ACPI. If the BIOS had APM then I'd just use it. I suspect a bug in the BIOS but there is no support for APM. The next attachment is dmesg w/ ACPI debug spew.
Created attachment 5899 [details] dmesg + acpi debug spew caused by reading the battery status
It's bios bug because I didn't find the definition of object Z004 in your acpidump. But there are 2 references in PBST: Name (PBST, Package (0x04) { 0x00, Z004, Z004, 0x2710 }) Does MS windows work?
Windows XP (with any service packs) works fine. It shows battery charge percentage and AC power status. On the other hand, Windows XP does not offer the option of suspend-to-ram so I don't know if that works or not.
I meant "without any service packs".
I suggest you to override DSDT with a customer one that replace Z004 with 0 to see if battery work? For sleep state support, please cat /proc/acpi/sleep
I'm not sure if Bob could accept the idea of ignoring undefined Z004 object, and continue.
I found this page: http://forums.gentoo.org/viewtopic.php?t=122145 I haven't had time to try it yet though. I realize it is better to follow the ACPI spec to the letter, but it occurred to me that you might want to add a kernel option "Enable buggy ACPI workarounds" since such a high percentage of laptops have slightly bad DSDT.
Completing Region/Field/Buffer/Package initialization:............................................................. psargs-0362: *** Error: Looking up [Z004] in namespace, AE_NOT_FOUND search_node cbdc76e8 start_node cbdc76e8 return_node 00000000 nsinit-0316 [06] ns_init_one_object : Could not execute arguments for [PBST] (Package), AE_NOT_FOUND ......... Initialized 10/10 Regions 5/5 Fields 33/33 Buffers 22/30 Packages (504 nodes) Executing all Device _STA and_INI methods:............................................ ---------- Actually Linux default policy is to work around bugs in BIOS that are common in the field. If you want Linux to obey the letter of the ACPI spec, then boot with "acpi=strict" and watch many BIOS ACPI spec violations make systems useless. -------- Although the laptop is new, it would be helpful if you could try some older kernels to see if this used to work, eg 2.6.10 - 12, as they are generally known to be stable.
I tried 2.6.10 and 2.6.12. I got the same error. Any other info you need? If we're stuck, I'll try fiddling with the DSDT.
Sure enough, Z004 does not exist in either the DSDT or SSDT -- code from the disassembled DSDT below: Name (PBST, Package (0x04) { 0x00, Z004, Z004, 0x2710 }) dsdt.dsl 2689: Z004, Error 1061 - ^ Object does not exist (Z004) dsdt.dsl 2690: Z004, Error 1061 - ^ Object does not exist (Z004) The contents of PBST apparently get overwritten during execution of the _BST method, but the static structure has this error. I'm not sure what the interpreter should attempt to do when faced with this exception during a namespace lookup, if it were to attempt to ignore the error. Fake it and return an integer? of value 0? -1? 42?
It would in fact be interesting to see if replacing Z004 with integer 0 fixes the problem.
Yes! Replacing Z004 with 0x00 appears to solve the problem. Is it possible to integrate this fix into the standard kernel or will I be stuck with a custom dsdt?
You could ask your bios vendor to fix the DSDT. Again, I'm not sure what a general solution to this should be. Ignoring an unresolved symbol is about the same as ignoring a divide-by-zero exception. Perhaps we can allow slack while building packages, and insert an integer if a namespace reference comes up unresolved. Will require further investigation.
I get what seems to be the same problem on a new Toshiba L25-1196. I've tested with kernels 2.6.14-r2 and 2.6.12-r6 from Gentoo 2005.1. --- cat /proc/acpi/battery/BAT1/state present: yes ERROR: Unable to read battery status --- dmesg with acp debugging turned on gets the following: --- ACPI: Battery Slot [BAT1] (battery present) ACPI-0339: *** Error: Looking up [Z00D] in namespace, AE_NOT_FOUND search_node c1237ba0 start_node c1237ba0 return_node 00000000 ACPI-0508: *** Error: Method execution failed [\_SB_.BAT1._BST] (Node c1237aa0), AE_NOT_FOUND --- I'm attaching all debugging info (lspci dmesg dmidecode acpidump iasl). In particular, iasl-tc produces (among many other errors) --- dsdt.dsl 3867: Z00D, Error 1022 - ^ Object does not exist (Z00D) dsdt.dsl 3868: Z00D, Error 1022 - ^ Object does not exist (Z00D) --- As for how to handle it: I really don't care whether my BIOS is buggy or not. I'd like it to be nice and standards-compliant, obviously, but if it isn't, there is precisely zero chance that I can get the vendor to fix it. I just want to be able to check battery status. If ignoring undefined values gets that to work, then I (and probably 99.9% of users out there) want that to be the default behaviour. Therefore, I'd like to emphatically second Len Brown's suggestion to add an "acpi=strict" option, and ignore undefned values by defaut. That should keep everyone happy. Can we please assign some priority to this? I think it is a somewhat widespread problem, it's not just the Acer, and it's not just Z004 ;) Joshua - could you post a patch for how you got it to work? Thanks. Robert - once we have that patch and have tested it, could you clean it up and apply it? Thanks.
Created attachment 6785 [details] (tar.gz) debugging info (lspci dmesg dmidecode acpidump dsdt.dsl) from a Toshiba Satellite L25-1196
We are in fact looking at this with a fairly high priority. It does not appear to be a simple fix, since it goes against the existing architecture of the ACPICA AML parser and namespace manager. In the meantime, a workaround is to diassemble the DSDT, fix the error, recompile, and install the new table in the kernel. I think the fix is to just replace the invalid references with an integer 0. This type of code appears to be the result of cutting and pasting ASL code to different machines.
A fix for this has been released in version 20051216: Implemented optional support to allow unresolved names within ASL Package objects. A null object is inserted in the package when a named reference cannot be located in the current namespace. Enabled via the interpreter slack flag, this should eliminate AE_NOT_FOUND exceptions seen on machines that contain such code.
Woohoo! Will this fix be merged in 2.6.15 or 2.6.16?
I can confirm this is fixed. I used Gentoo's gentoo-sources-2.6.15 kernel, applied the acpica 20051216 patch from http://www.kernel.org/pub/linux/kernel/people/lenb/acpi/patches/test/2.6.15/acpi-acpica-20051216-2.6.15-rc5.diff.gz, (which didn't apply cleanly and broke the compilation of libsata btw, but that's probably ok since I was mixing versions here) and now I can see my battery charge status (and I have also checked that the information it shows is correct). Nice. Thank you!
ACPICA 20060127 shipped in Linux-2.6.16-rc1-git6 -- closing.
I also confirm that the fix works.