Latest working kernel version: 2.6.24.1 Earliest failing kernel version: 2.6.27.4 or earlier Distribution: Debian Hardware Environment: ASUS X50GL laptop Software Environment: Problem Description: Under 2.6.24.1, ACPI is working fine (battery, brightness controls, freq. scaling...). Under 2.6.27.4 I get the following errors: kernel: ACPI: EC: acpi_ec_wait timeout, status = 0xa0, event = "b0=1" kernel: ACPI: EC: read timeout, command = 128 kernel: ACPI Exception (evregion-0419): AE_TIME, Returned by Handler for [EmbeddedControl] [20080609] kernel: ACPI Error (psparse-0530): Method parse/execution failed [\_TZ_.RTMP] (Node f743eef0), AE_TIME kernel: ACPI Error (psparse-0530): Method parse/execution failed [\_TZ_.THRM._TMP] (Node f743efb8), AE_TIME kernel: ACPI: EC: acpi_ec_wait timeout, status = 0x04, event = "b0=1" kernel: ACPI: EC: read timeout, command = 130 kernel: ACPI: EC: acpi_ec_wait timeout, status = 0x82, event = "b0=1" kernel: ACPI: EC: read timeout, command = 130 kernel: ACPI: EC: acpi_ec_wait timeout, status = 0x82, event = "b0=1" kernel: ACPI: EC: read timeout, command = 130 kernel: ACPI Error (psparse-0530): Method parse/execution failed [\_SB_.PCI0.SBRG.EC0_.SADC] (Node f743e5f4), AE_TIME Oct 28 21:15:04 gravity execution failed [\_SB_.PCI0.SBRG.EC0_.STBR] (Node f743e644), AE_TIME kernel: ACPI Error (psparse-0530): Method parse/execution failed [\_SB_.PCI0.IXVE.VGA_.LCDD._BCM] (Node f74373ec), AE_TIME (and many more) Any attempt to acess files under /proc/acpi outputs the same ACPI: EC: read tiemouts. I have fixed it in 2.6.27.4 replacing drivers/acpi/ec.c with the one shipped with 2.6.24.1 Steps to reproduce:
Where I said «Any attempt to acess files under /proc/acpi outputs the same ACPI: EC: read tiemouts.» I meant it outputs this EC read errors and nothing ACPI related works, of course. No battery info, no special buttons, no poweroff...
Will you please attach the output of acpidump, full dmesg? Thanks.
It will be great if you can add the boot option of "printk.time=1" when you attach the output of full dmesg. Thanks.
Will you please try the debug patch in http://bugzilla.kernel.org/show_bug.cgi?id=9399#C38 on the latest stable kernel(2.6.27.4) and see whether the problem still exists? Thanks.
Created attachment 18500 [details] 2.6.27.4 dmesg
Created attachment 18501 [details] acpidump from 2.6.27.4 I attach both dmesg and acpidump from the failing 2.6.27.4 kernel. Tried the patch that you proposed but results on a kernel panic early in the boot process. Also, I changed the bug description. The laptop seems to report itself as a F5GL model, though I had X50GL on some sticker around here. Who knows.
So stupid BIOS. From the acpidump log there exists the ECDT table, which contains too many errors. >Both Command and Data I/O port address are zero. >The GPE is also zero. >EC Namepath is incorrect. The namepath in ECDT is "\\_SB.PCI0.SBRG.EC". But the correct namepath should be "\_SB.PCI0.SBRG.EC". Will youp please try the patch in http://bugzilla.kernel.org/show_bug.cgi?id=11737#C8 on the 2.6.27.4 kernel and see whether the issue still exists? (Of course the patch in comment #4 is still required). After the test, please attach the output of dmesg. Thanks.
Applied both patches and keep having a kernel panic. It goes (... maybe missing lines that don't fit the screen ... ) acpi_ns_get_node acpi_ns_lookup acpi_ns_evaluate acpi_ut_evaluate_object ec_parse_io_ports acpi_rs_get_method_data acpi_walk_resources acpi_init ec_parse_device acpi_ec_ecdt_probe acpi_init kset_create_and_add _stext register_irq_proc kernel_init kernel_init kernel_thread_helper CODE: 24 40 C7 00 00 00 00 00 ff 05 6c 96 5e c0 a1 90 96 [...] Kernel panic in acpi_ns_lookup+54h
Maybe the kernel panic is related with that the two patches are not applied correctly. Will you please try the two patches on the latest kernel and see whether the problem still exists? Thanks.
Please try the two patches on 2.6.28-rc3 kernel. After the system is booted, please attach the output of dmesg. Thanks.
Tried on 2.6.28-rc3. Patches applied perfectly, but I get exactly the same kernel panic as in #8.
Thanks for the test. So stupid BIOS. Poor people. From the acpidump info it seems that the info in ECDT table is totally wrong. >Both Command and Data I/O port address are zero. >The GPE is also zero. >EC Namepath is incorrect. The namepath in ECDT is "\\_SB.PCI0.SBRG.EC". There exists the redundant rootprefix. At the same time the path of EC device in DSDT table is "\_SB.PCI0.ISA.EC".
Created attachment 18652 [details] try the debug patch in which the EC defined in ECDT table will be compared with that in DSDT table Will you please try the attached debug patch on the latest kernel and see whether the problem still exists?(The patch in comment #7 is still required. But the patch in comment #4 is not needed). Thanks.
New 2.6.28-rc3 with patches from #7 and #13. Nothing new. The printk()'s introduced in #13 don't get executed because: status = acpi_get_handle(ACPI_ROOT_OBJECT,"\_SB.PCI0.ISA.EC",...); fails. I've added some printk()'s inside this function and some others it calls. It calls acpi_ns_lookup() which walks the path \_SB.PCI0.ISA.EC. It goes _SB_ then PCI0 then it fails with ISA_. I modified it so it tries \_SB.PCI0.SBRG.EC upon failure, then it fails when looking for the last component, EC (EC__). Also, I see that patch in #7 tries to skip redundant \ after calling acpi_ns_valid_root_prefix(). To do some testing, I did the same in all places where acpi_ns_valid_root_prefix() is called, but nothing new happened.
Created attachment 18733 [details] dmesg from 2.6.28-rc3 plus your patches, nothing mine in here.
Thanks for the test. I am sorry for my fault. The EC namepath in DSDT table should be "\\_SB.PCI0.SBRG.EC0".The EC namepath in ECDT table is "\\\\_SB.PCI0.ISA.EC". It is incorrect. There exists the redundant rootprefix. And the namepath is totally incorrect. Will you please update it and try it ? Sorry for my fault. Now I am writing a new patch for this issue. But it needs some time. After the patch is finished, will you please try it again? Thanks.
Hi, thanks, it's working now with "\\_SB.PCI0.SBRG.EC0". Your lines appear in the log: [0.187177] ACPI: EC: BIOS Bug. ECDT table gives the incorrect Command/Data I/O Port. [0.187250] ACPI: EC: BIOS Bug. Incorrect GPE is provided by ECDT table And I can access files under /proc/acpi/ without having this timeout errors anymore. Also, keyboard keys for brightness/volume/etc. are working. I'm open to do further testing if you need so. Thanks again.
Created attachment 18768 [details] Patch : try the debug patch in wich the EC device in DSDT has higher priority than that in ECDT table Will you please try the debug patch on the latest kernel(2.6.28-rc3) and see whether the problem still exists? No extra patch is required. thanks.
Created attachment 18798 [details] Log from 2.6.28-rc3 plus patch in #18 Here you have the dmesg from 2.6.28-rc3 plus patch in #18. Everything is working.
Created attachment 18906 [details] Add basic check against empty tables Please check if this patch helps.
Hi, Alexey Can the issue of bug 9399 be considered together? On the laptops of bug 9399 the command/status I/O port is different with the data I/O port. But they are incorrect. Thanks.
Created attachment 18910 [details] Dmesg for patch #20 under 2.6.28-rc5 Hi I tested patch on #20 under 2.6.28-rc5 which is the latest kernel right now. Again, ACPI stuff is working, just have some missing button features (Volume Up/Down) but thats problem of the asus_acpi module and already where missing since 2.6.27.5
Thanks, marking as resolved. Please open another bug report for other issues.
patch in comment #20 checkec into acpi test branch
*** Bug 12116 has been marked as a duplicate of this bug. ***
shipped in 2.6.28-git14, so it should appear in 2.6.29-rc1