Bug 175422 - Battery related FC4 ACPI error on Acer Ferrari 4005 laptop
Battery related FC4 ACPI error on Acer Ferrari 4005 laptop
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
4
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Dave Jones
Brian Brock
:
Depends On:
Blocks: FCMETA_ACPI
  Show dependency treegraph
 
Reported: 2005-12-09 19:39 EST by Josh
Modified: 2015-01-04 17:23 EST (History)
5 users (show)

See Also:
Fixed In Version: 2.6.16-1.2069_FC4
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-05-04 22:03:12 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
dmesg for test kernel 2.6.14_1651-FC4-x86_64 (16.49 KB, text/plain)
2005-12-13 13:09 EST, Josh
no flags Details
Original DSDT from BIOS version 3A23 (25.17 KB, application/octet-stream)
2006-02-06 11:00 EST, Alex Tucker
no flags Details

  None (edit)
Description Josh 2005-12-09 19:39:11 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.12) Gecko/20050922 Fedora/1.0.7-1.1.fc4 Firefox/1.0.7

Description of problem:
Following ACPI errors are displayed repeatedly by the kernel. I think this prevents the GNOME battery applet from working as well.

Dec  9 18:04:53 miracle kernel:     ACPI-0508: *** Error: Method execution failed [\_SB_.BAT1._BST] (Node ffff810037ff58c0), AE_NOT_FOUND
Dec  9 18:04:55 miracle kernel:     ACPI-0339: *** Error: Looking up [Z00I] in namespace, AE_NOT_FOUND
Dec  9 18:04:55 miracle kernel: search_node ffff810037ff5ac0 start_node ffff810037ff5ac0 return_node 0000000000000000
Dec  9 18:04:55 miracle kernel:     ACPI-0508: *** Error: Method execution failed [\_SB_.BAT1._BST] (Node ffff810037ff58c0), AE_NOT_FOUND
Dec  9 18:05:23 miracle kernel:     ACPI-0339: *** Error: Looking up [Z00I] in namespace, AE_NOT_FOUND
Dec  9 18:05:23 miracle kernel: search_node ffff810037ff5ac0 start_node ffff810037ff5ac0 return_node 0000000000000000
Dec  9 18:05:23 miracle kernel:     ACPI-0508: *** Error: Method execution failed [\_SB_.BAT1._BST] (Node ffff810037ff58c0), AE_NOT_FOUND
Dec  9 18:05:25 miracle kernel:     ACPI-0339: *** Error: Looking up [Z00I] in namespace, AE_NOT_FOUND
Dec  9 18:05:25 miracle kernel: search_node ffff810037ff5ac0 start_node ffff810037ff5ac0 return_node 0000000000000000
Dec  9 18:05:25 miracle kernel:     ACPI-0508: *** Error: Method execution failed [\_SB_.BAT1._BST] (Node ffff810037ff58c0), AE_NOT_FOUND
Dec  9 18:05:54 miracle kernel:     ACPI-0339: *** Error: Looking up [Z00I] in namespace, AE_NOT_FOUND
Dec  9 18:05:54 miracle kernel: search_node ffff810037ff5ac0 start_node ffff810037ff5ac0 return_node 0000000000000000
Dec  9 18:05:54 miracle kernel:     ACPI-0508: *** Error: Method execution failed [\_SB_.BAT1._BST] (Node ffff810037ff58c0), AE_NOT_FOUND
Dec  9 18:05:55 miracle kernel:     ACPI-0339: *** Error: Looking up [Z00I] in namespace, AE_NOT_FOUND
....
....

Version-Release number of selected component (if applicable):
Linux miracle.myhome.net 2.6.14-1.1644_FC4 #1 Sun Nov 27 03:24:54 EST 2005 x86_64 x86_64 x86_64 GNU/Linux

How reproducible:
Always

Steps to Reproduce:
1. Boot Fedora 4 x86_64 on Acer Ferrari 4005
2.
3.
  

Actual Results:  Kernel repeats ACPI errors. GNOME 2.10.0 Battery applet does not recognize the battery.

Expected Results:  ACPI errors should not be reported. GNOME 2.10.0 Battery applet should work.

Additional info:
Comment 1 Dave Jones 2005-12-12 18:57:26 EST
any improvement with the test kernel from
http://people.redhat.com/davej/kernels/Fedora/FC4/  ?
Comment 2 Josh 2005-12-13 13:09:28 EST
Created attachment 122190 [details]
dmesg for test kernel 2.6.14_1651-FC4-x86_64
Comment 3 Josh 2005-12-13 13:11:33 EST
Still get same errors. Created attachment for dmesg output for
2.6.14_1651-FC4-x86_64
Comment 4 Kyle Pablo 2006-01-01 17:26:52 EST
hello,

I am running FC4 on the Acer Ferrari 4005 too.  I get these ACPI errors:

 ACPI-0362: *** Error: Looking up [Z00I] in namespace, AE_NOT_FOUND
search_node ffff810037ffff80 start_node ffff810037ffff80 return_node
0000000000000000
    ACPI-1172: *** Error: Method execution failed [\_SB_.BAT1._BST] (Node
ffff810037ff9e40), AE_NOT_FOUND


running this on kernel 2.6.13-1.1532
Comment 5 Linux ACPI Developers 2006-01-18 00:08:44 EST
This may be fixed up-stream.

Is it possible to re-test with a kernel.org kernel?
How about 2.6.15?
How about 2.6.15 with the latest ACPI patch?
http://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/patches/test/2.6.15/

Comment 6 Dave Jones 2006-02-03 02:09:19 EST
This is a mass-update to all currently open kernel bugs.

A new kernel update has been released (Version: 2.6.15-1.1830_FC4)
based upon a new upstream kernel release.

Please retest against this new kernel, as a large number of patches
go into each upstream release, possibly including changes that
may address this problem.

This bug has been placed in NEEDINFO_REPORTER state.
Due to the large volume of inactive bugs in bugzilla, if this bug is
still in this state in two weeks time, it will be closed.

Should this bug still be relevant after this period, the reporter
can reopen the bug at any time. Any other users on the Cc: list
of this bug can request that the bug be reopened by adding a
comment to the bug.

If this bug is a problem preventing you from installing the
release this version is filed against, please see bug 169613.

Thank you.
Comment 7 Alex Tucker 2006-02-06 10:50:25 EST
I can confirm this issue still exists with kernel-2.6.15-1.1830_FC4.

A workaround is to edit the DSDT to change the symbol Z00I to Z001, and compile
the resulting change into the kernel.

Which begs a couple of questions:

The Intel ACPI compiler complains about the symbol being undefined, but there
are other similar symbols e.g. Z001 through to Z00H scattered throughout the
disassembled DSDT -- why are they ok while Z00I is not?

If it turns out that the DSDT is indeed buggy, then how can we help the user fix
the problem, as the manufacturer is unlikely to change anything?  We could use
the initrd patch to allow updated DSDT to be appended without having to
recompile the kernel, or we could add special cases to the kernel, listing known
bad DSDTs to be patched.
Comment 8 Alex Tucker 2006-02-06 11:00:47 EST
Created attachment 124264 [details]
Original DSDT from BIOS version 3A23

Gotten from /proc/acpi/dsdt
Comment 9 Robert Moore 2006-02-06 11:08:09 EST
No errors on the other Z00* because they are actually defined:

    Name (Z000, 0x01)
    Name (Z001, 0x02)
    Name (Z002, 0x04)
    Name (Z003, 0x08)
    Name (Z004, 0x00)
    Name (Z005, 0x0F)
    Name (Z006, 0x0D)
    Name (Z007, 0x0B)
    Name (Z008, 0x09)

etc.

Comment 10 Alex Tucker 2006-02-06 11:24:04 EST
Granted.  I don't claim to be able to understand AML, but e.g. none of Z009,
Z00G or Z00H are defined but they seem to be being used.  Does their usage make
sense?  If so, I will attempt to raise some kind of bug report with Acer, but
will not hold my breath.

I notice the MSFT symbol in the DSDT, so am assuming the missing symbols are
silently ignored by their compiler and silently assumed to have some default
value by their interpreter.  Should I try changing Z00I to 0 to see whether it
works?  Should our interpreter just offer a warning over unknown symbols and
assume that they're 0 too?
Comment 11 Robert Moore 2006-02-06 11:34:14 EST
They are all defined, see below. The only truly missing one is Z00I. Yes, you 
can probably safely change the references to Z00I to 0, since the location is 
usually overwritten anyway (that is why it works on windows.)

Versions of ACPICA past 20051216 will allow an unresolved reference within a 
package at runtime:

16 December 2005. Summary of changes for version 20051216:

1) ACPI CA Core Subsystem:

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.


            Field (BAR1, ByteAcc, NoLock, Preserve)
            {
                Z009,   32
            }
            Method (Z00G, 0, NotSerialized)

                Field (K8F3, AnyAcc, NoLock, Preserve)
                {
                    Offset (0x05), 
                    Z00H,   6
                }
Comment 12 Alex Tucker 2006-02-07 11:15:27 EST
Ok, is there a simple way to patch the 2.6.15-1.1830_FC4 released kernel to use
more recent ACPICA?  The only patches I can find are either too old, or only
apply to the 2.6.16 pre-releases.  lenb's published patches under the 'test'
directory don't seem to apply cleanly to the 2.6.15-1.1830_FC4 kernel either.

I'm happy to test things out if it helps in resolving this issue.
Comment 13 Kyle Pablo 2006-02-08 21:38:14 EST
Same here. I will help.
Comment 14 Alex Tucker 2006-03-30 10:50:18 EST
I can confirm that the recent upgrade to kernel-2.6.16-1.2069_FC4 resolves this
issue.
Comment 15 Kyle Pablo 2006-03-30 13:06:58 EST
Same here on FC5.

Note You need to log in before you can comment on or make changes to this bug.