Distribution: Fedora Core 3 (with plain vanilla 2.6.10 kernel) Hardware Environment: Asus W3479NLP (aka W3400N aka W3000N aka W3N) Software Environment: cat /proc/acpi/battery/BAT0/state Problem Description: The status of the battery is unreadable on Asus W3400N series laptops. The Steps to reproduce: Type cat /proc/acpi/battery/BAT0/state returns nothing, the following is emitted to /var/log/messages: kernel: dswstate-0277 [83] ds_result_pop_from_bot: No result objects! State=f7c8a428 kernel: dsutils-0547 [83] ds_create_operand : Missing or null operand, \ AE_AML_NO_RETURN_VALUE kernel: dsutils-0640 [82] ds_create_operands : While creating Arg 2 - \ AE_AML_NO_RETURN_VALUE kernel: psparse-1138: *** Error: Method execution failed [\_SB_.BAT0._BST] (Node \ f7f8b328), AE_AML_NO_RETURN_VALUE kernel: acpi_battery-0208 [73] acpi_battery_get_statu: Error evaluating _BST (Other ACPI features like temperature reading or LED enabling work fine)
Created attachment 4553 [details] DSDT and various output of log files
Comment on attachment 4553 [details] DSDT and various output of log files .tar.gz archive including binary DSDT and content of various log files documenting the problem
Please post the DSDT binary as a single file, thanks
Created attachment 4555 [details] dsdt as-a-single file (no, the tar did not contain a trojan :-)
Maybe I should mention another ACPI feature that is not working: Entering S5 (off) by software does not work, a message that the appropriate ACPI function has been called is issued, but nothing happens.
Here is the offending method gr.asl 63: Store (BST0 (Local0), Index (BFB0, 0x00)) Error 1029 - ^ Called method returns no value It looks like there is a case here that is not handled by the "implicit return" support. Investigating.
It seems that it is the very same bug as reported for other Asus Notebooks before, as explained in http://www.petitiononline.com/M6NBIOS/petition.html However, while this would be easy to fix in the .dsl file, there's a big obstacle to try it: While "iasl -d dsdt.bin" happily disassembles the DSDT into something human readable, "iasl -tc dsdt.dsl" emits hundreds of errors and refuses to create a binary DSDT again. I'm not familiar with that ASL language, though it looks not too diffent from some assembler dialects I once programmed, but sorting out hundreds of bizarre error messages in an unfamiliar language is a little dangerous given that mistakes could harm my hardware... I wonder how a disassembler can produce something that it cannot assembler back afterwards :-)
Looking at the output of compiler (hundreds of error messages), I would say that it looks like a bug in either the disassembler or compiler itself. There is something about the disassembled file that seriously confuses the compiler. I will investigate further.
Any new idea what might confuse iasl? Is there something more I can do to help getting this problem fixed?
I have a prototype fix for the original AE_AML_NO_RETURN_VALUE issue. I still don't really understand why ASL/BIOS writers (who have presumably had a few courses in programming) assume that a procedure will return a value if not explicitly told to do so. I don't get it. Bob
Asus released a new BIOS version "0201A", however, I have not seen any kind of release notes or announcement text for it: ftp://ftp.asus.com/pub/ASUS/nb/W3N/W3N0201A.zip As it would be hard to "go back" from this version if it is broken (there is no older version available) - is there a way to extract the DSDT without installing the new BIOS? Or any way to extract the old BIOS release from ROM to have at least a fall-back option?
Alas, what seemed to be a "new" BIOS was in fact an old one, even older than the already installed version. So no solution that way... If there's any kind of iasl dev-release available which is able to compile the DSDT, I'd be willing to give it a try...
Created attachment 4665 [details] Fixed DSDT, compiles OK
There were three main issues with the DSDT. 1) "IO" was used as an OpRegion name, but it is a reserved word. iASL is not context-sensitive about names. However, the error recovery is broken in this case. 2) There was executable code at the module level, this is not allowed. Moved to _SB_._INI. 3) Two instances of the BAT0 method did not return a value, required to do so. You should be able to compile this new version of the DSDT. Bob
Should be fixed in version 20050309; the implicit return support was reworked to handle the general case.
Thanks for the iasl and DSDT fix! Reading the battery now works. One adverse effect of using the changed DSDT is that S3 and S4 are not supported anymore. The result of "cat /proc/acpi/sleep" shows only S0 and S5 as supported. Entering S5 does not work, but that is the same as before the patch. Entering S3/S4 worked before, though waking up again was somehow incomplete, probably due to some drivers not "sleep-aware". Another thing that is bothering me is that kacpid consumes unreasonable amounts of time, up to 30% of the CPU when there are lots of I/O operations. According to the oprofile/opreport output, most of the time is spend in the function acpi_ut_find_allocation, another significant contributor is acpi_ps_parse_aml. I understand that the issues mentioned above are certainly beyond the scope of this ticket, but maybe you can point me in the right direction where to report these...?
I recently realized that the _SB_._INI won't do what we want, because the objects created by a method are deleted at method exit. The only thing I can think of right now is to move the _INI object declarations to the mainline of the DSDT (such as right at the beginning.) This will cause the objects to be created permanently, and should enable s1, s3, and s4. (For the record, the "official" endorsed method for this is to conditionally load one or more SSDTs.) Try adding this code, and removing the _SB_._INI method: /* SS1 */ Name (\_SB.PCI0._S1D, 0x02) Name (\_SB.PCI0.P0P1._S1D, 0x02) Name (\_SB.PCI0.USB1._S1D, 0x02) Name (\_SB.PCI0.USB2._S1D, 0x02) Name (\_SB.PCI0.USB3._S1D, 0x02) /* SS3 */ Name (\_SB.PCI0._S3D, 0x02) Name (\_SB.PCI0.P0P1._S3D, 0x02) Name (\_SB.PCI0.USB1._S3D, 0x02) Name (\_SB.PCI0.USB2._S3D, 0x02) Name (\_SB.PCI0.USB3._S3D, 0x02) /* SS4 */ Name (\_SB.PCI0._S4D, 0x02) Name (\_SB.PCI0.P0P1._S4D, 0x02) /* SS3 */ Name (_S3, Package (0x04) { 0x05, 0x00, 0x00, 0x00 }) /* SS4 */ Name (_S4, Package (0x04) { 0x06, 0x00, 0x00, 0x00 })
The change proposed above makes S3/S4 available again - but I had to put the code in the end of the .dsl file, not the beginning, because the iasl compiler seemed to miss some references otherwise. Reading the battery still works with those changes. However, there are still some messages during the boot process that seem to indicate some trouble: ... ACPI: Subsystem revision 20050309 evgpeblk-0979 [06] ev_create_gpe_block : GPE 00 to 1F [_GPE] 4 regs on int 0x9 evgpeblk-0987 [06] ev_create_gpe_block : Found 7 Wake, Enabled 8 Runtime GPEs in this block Completing Region/Field/Buffer/Package initialization:.................................................................. ................................................................ Initialized 27/28 Regions 34/35 Fields 44/44 Buffers 25/25 Packages (962 nodes) Executing all Device _STA and_INI methods:.............................................evregion-0309 [20] ev_address_spa ce_dispa: No handler for Region [ECOR] (c18da528) [EmbeddedControl] exfldio-0265: *** Error: Region EmbeddedControl(3) has no handler psparse-1138: *** Error: Method execution failed [\_SB_.PCI0.SBRG.EC0_.ACS_] (Node c18d64a8), AE_NOT_EXIST psparse-1138: *** Error: Method execution failed [\_SB_.AC__._INI] (Node c18d59e8), AE_NOT_EXIST nsinit-0414 [06] ns_init_one_device : \_SB_.AC__._INI._INI failed: AE_NOT_EXIST ..evregion-0309 [22] ev_address_space_dispa: No handler for Region [ECOR] (c18da528) [EmbeddedControl] exfldio-0265: *** Error: Region EmbeddedControl(3) has no handler psparse-1138: *** Error: Method execution failed [\_SB_.PCI0.SBRG.EC0_.BATS] (Node c18d6468), AE_NOT_EXIST psparse-1138: *** Error: Method execution failed [\_SB_.BAT0._STA] (Node f7f812e8), AE_NOT_EXIST uteval-0158: *** Error: Method execution failed [\_SB_.BAT0._STA] (Node f7f812e8), AE_NOT_EXIST ............. 60 Devices found containing: 59 _STA, 3 _INI methods ACPI: Interpreter enabled ACPI: Using PIC for interrupt routing ACPI: PCI Root Bridge [PCI0] (0000:00) ... And, alas, the kacpid with 2.6.11+acpi-20050309 patches still consumes unreasonable amounts of CPU time, as mentioned above.
Sounds like you don't have an EC driver loaded, I don't know the details of how to make this happen.
*** Bug 4243 has been marked as a duplicate of this bug. ***
With linux-2.6.12 or newer does the AE_AML_NO_RETURN_VALUE issue go away? (that is when we had the new implicit return workaround -- you'd be able to disable the workaround by booting with "acpi=strict").
Yes, it seems the issue is fixed with the 2.6.12 kernels - thanks a lot! The (other, persisting) problem that the kacpid is consuming so much CPU time is probably better addressed in a separate ticket.