Bug 11880 - ACPI: EC: acpi_ec_wait timeout - AE_TIME - ASUS X50GL laptop
ACPI: EC: acpi_ec_wait timeout - AE_TIME - ASUS X50GL laptop
Status: CLOSED CODE_FIX
Product: ACPI
Classification: Unclassified
Component: EC
All Linux
: P1 high
Assigned To: Alexey Starikovskiy
:
: radoen (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-10-28 15:20 UTC by admin
Modified: 2009-01-09 14:04 UTC (History)
3 users (show)

See Also:
Kernel Version: 2.6.27.4
Tree: Mainline
Regression: Yes


Attachments
2.6.27.4 dmesg (42.20 KB, text/plain)
2008-10-29 15:06 UTC, admin
Details
acpidump from 2.6.27.4 (263.95 KB, text/plain)
2008-10-29 15:10 UTC, admin
Details
try the debug patch in which the EC defined in ECDT table will be compared with that in DSDT table (2.13 KB, patch)
2008-11-04 06:21 UTC, ykzhao
Details | Diff
dmesg from 2.6.28-rc3 plus your patches, nothing mine in here. (43.04 KB, text/plain)
2008-11-07 11:24 UTC, admin
Details
Patch : try the debug patch in wich the EC device in DSDT has higher priority than that in ECDT table (3.49 KB, patch)
2008-11-09 21:30 UTC, ykzhao
Details | Diff
Log from 2.6.28-rc3 plus patch in #18 (43.86 KB, text/plain)
2008-11-11 03:16 UTC, admin
Details
Add basic check against empty tables (2.60 KB, patch)
2008-11-18 00:03 UTC, Alexey Starikovskiy
Details | Diff
Dmesg for patch #20 under 2.6.28-rc5 (41.79 KB, text/plain)
2008-11-18 04:43 UTC, admin
Details

Description admin 2008-10-28 15:20:35 UTC
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:
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(2.6.27.4) and see whether the problem still exists?
Thanks.

Comment 5 admin 2008-10-29 15:06:43 UTC
Created attachment 18500 [details]
2.6.27.4 dmesg
Comment 6 admin 2008-10-29 15:10:02 UTC
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.
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 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.
   
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 2.6.27.5
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

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