Bug 175422
| Summary: | Battery related FC4 ACPI error on Acer Ferrari 4005 laptop | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Josh <islifefun1975> | ||||||
| Component: | kernel | Assignee: | Dave Jones <davej> | ||||||
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Brian Brock <bbrock> | ||||||
| Severity: | medium | Docs Contact: | |||||||
| Priority: | medium | ||||||||
| Version: | 4 | CC: | acpi-bugzilla, alex, kylepablo, pfrields, wtogami | ||||||
| Target Milestone: | --- | ||||||||
| Target Release: | --- | ||||||||
| Hardware: | x86_64 | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | 2.6.16-1.2069_FC4 | Doc Type: | Bug Fix | ||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2006-05-05 02:03:12 UTC | Type: | --- | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Bug Depends On: | |||||||||
| Bug Blocks: | 165150 | ||||||||
| Attachments: |
|
||||||||
|
Description
Josh
2005-12-10 00:39:11 UTC
any improvement with the test kernel from http://people.redhat.com/davej/kernels/Fedora/FC4/ ? Created attachment 122190 [details]
dmesg for test kernel 2.6.14_1651-FC4-x86_64
Still get same errors. Created attachment for dmesg output for 2.6.14_1651-FC4-x86_64 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
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/ 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. 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. Created attachment 124264 [details]
Original DSDT from BIOS version 3A23
Gotten from /proc/acpi/dsdt
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.
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?
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
}
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. Same here. I will help. I can confirm that the recent upgrade to kernel-2.6.16-1.2069_FC4 resolves this issue. Same here on FC5. |