|Summary:||ACPI: EC: acpi_ec_wait timeout - AE_TIME - ASUS X50GL laptop|
|Component:||EC||Assignee:||Alexey Starikovskiy (astarikovskiy)|
|Severity:||high||CC:||acpi-bugzilla, scream1988, yakui.zhao|
acpidump from 220.127.116.11
try the debug patch in which the EC defined in ECDT table will be compared with that in DSDT table
dmesg from 2.6.28-rc3 plus your patches, nothing mine in here.
Patch : try the debug patch in wich the EC device in DSDT has higher priority than that in ECDT table
Log from 2.6.28-rc3 plus patch in #18
Add basic check against empty tables
Dmesg for patch #20 under 2.6.28-rc5
Description admin 2008-10-28 15:20:35 UTC
Comment 1 admin 2008-10-28 15:24:19 UTC
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...
Comment 2 ykzhao 2008-10-28 18:38:15 UTC
Will you please attach the output of acpidump, full dmesg? Thanks.
Comment 3 ykzhao 2008-10-28 18:40:14 UTC
It will be great if you can add the boot option of "printk.time=1" when you attach the output of full dmesg. Thanks.
Comment 4 ykzhao 2008-10-28 18:46:32 UTC
Will you please try the debug patch in http://bugzilla.kernel.org/show_bug.cgi?id=9399#C38 on the latest stable kernel(18.104.22.168) and see whether the problem still exists? Thanks.
Comment 5 admin 2008-10-29 15:06:43 UTC
Created attachment 18500 [details] 22.214.171.124 dmesg
Comment 6 admin 2008-10-29 15:10:02 UTC
Created attachment 18501 [details] acpidump from 126.96.36.199 I attach both dmesg and acpidump from the failing 188.8.131.52 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.
Comment 7 ykzhao 2008-10-29 18:00:41 UTC
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 184.108.40.206 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.
Comment 8 admin 2008-10-31 20:53:10 UTC
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
Comment 9 ykzhao 2008-11-03 07:00:59 UTC
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.
Comment 10 ykzhao 2008-11-03 07:01:59 UTC
Please try the two patches on 2.6.28-rc3 kernel. After the system is booted, please attach the output of dmesg. Thanks.
Comment 11 admin 2008-11-04 03:20:47 UTC
Tried on 2.6.28-rc3. Patches applied perfectly, but I get exactly the same kernel panic as in #8.
Comment 12 ykzhao 2008-11-04 06:00:18 UTC
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".
Comment 13 ykzhao 2008-11-04 06:21:16 UTC
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.
Comment 14 admin 2008-11-07 11:22:12 UTC
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.
Comment 15 admin 2008-11-07 11:24:59 UTC
Created attachment 18733 [details] dmesg from 2.6.28-rc3 plus your patches, nothing mine in here.
Comment 16 ykzhao 2008-11-08 04:22:34 UTC
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.
Comment 17 admin 2008-11-08 05:14:08 UTC
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.
Comment 18 ykzhao 2008-11-09 21:30:59 UTC
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.
Comment 19 admin 2008-11-11 03:16:37 UTC
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.
Comment 20 Alexey Starikovskiy 2008-11-18 00:03:03 UTC
Created attachment 18906 [details] Add basic check against empty tables Please check if this patch helps.
Comment 21 ykzhao 2008-11-18 01:39:11 UTC
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.
Comment 22 admin 2008-11-18 04:43:03 UTC
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 220.127.116.11
Comment 23 Alexey Starikovskiy 2008-11-24 11:26:55 UTC
Thanks, marking as resolved. Please open another bug report for other issues.
Comment 24 Len Brown 2008-11-26 14:13:46 UTC
patch in comment #20 checkec into acpi test branch
Comment 25 Alexey Starikovskiy 2008-11-28 16:25:32 UTC
*** Bug 12116 has been marked as a duplicate of this bug. ***
Comment 26 Len Brown 2009-01-09 14:04:44 UTC
shipped in 2.6.28-git14, so it should appear in 2.6.29-rc1