Bug 4150

Created attachment 4499 [details]
Binary DSDT from Asus M6R

Created attachment 4500 [details]
Source DSDT from Asus M6R

I was able to fix the AE_AML_BUFFER_LIMIT error using the following patch on my
DSDT:

--- dsdt.dsl.orig       2005-01-07 22:22:47.000000000 +0100
+++ dsdt.dsl    2005-02-02 18:39:53.000000000 +0100
@@ -97,6 +97,10 @@
         {
             Return (Zero)
         }
+        If (LLess (SizeOf (Arg1), SizeOf (Arg0)))
+        {
+            Return (Zero)
+        }

         Add (SizeOf (Arg0), 0x01, Local0)
         Name (BUF0, Buffer (Local0) {})

However, the AE_TIME errors remain:

Initializing Cryptographic API
    ACPI-0405: *** Error: Handler for [EmbeddedControl] returned AE_TIME
    ACPI-1138: *** Error: Method execution failed [\_SB_.PCI0.SBRG.EC0_.RDC3]
(Node ddf09840), AE_TIME
    ACPI-1138: *** Error: Method execution failed [\ECIO] (Node ddf09380), AE_TIME
    ACPI-1138: *** Error: Method execution failed [\_SB_.PCI0.SBRG.EC0_.ACPS]
(Node ddf078e0), AE_TIME
    ACPI-1138: *** Error: Method execution failed [\ACPS] (Node ddf03220), AE_TIME
    ACPI-1138: *** Error: Method execution failed [\_SB_.PCI0.AC0_._PSR] (Node
ddf07160), AE_TIME
    ACPI-0405: *** Error: Handler for [EmbeddedControl] returned AE_TIME
    ACPI-1138: *** Error: Method execution failed [\_SB_.PCI0.SBRG.EC0_.SMBR]
(Node ddf09540), AE_TIME
    ACPI-1138: *** Error: Method execution failed [\_SB_.PCI0.SBRG.EC0_.BIF0]
(Node ddf07c40), AE_TIME
    ACPI-1138: *** Error: Method execution failed [\_SB_.PCI0.BAT0._BIF] (Node
ddf07e20), AE_TIME

Hmm, it seems my AE_AML_BUFFER_LIMIT fix was not correct, and it is in fact the
kernel bug - the fix is described by Robert Moore at
http://sourceforge.net/mailarchive/message.php?msg_id=10775149.

The "Handler for [EmbeddedControl] returned AE_TIME" error remains unfixed,
though. I have found that 2.6.10-rc1-bk11 is OK, but 2.6.10-rc1-bk12 has this
problem.

Created attachment 4534 [details]
Part of diff between 2.6.10-rc1-bk11 and -bk12

I've diffed the linux-2.6.10-rc1-bk11 and -bk12 trees, deleted most of the
diff, and now I have the attached patch, which, when applied to 2.6.10-rc1-bk11
makes ACPI on my laptop not working (AE_TIME errors), and, when removed (patch
-R) from 2.6.10-rc1-bk12, makes ACPI working on my laptop.

I just don't see what is the problem - the patch itself is a
sysfs/uevent/hotplug update. Nothing related to ACPI, I think.

It seems to be some kind of race condition or what - with
CONFIG_ACPI_DEBUG my ACPI does not work even with 2.6.8.1 and 2.6.9,
without CONFIG_ACPI_DEBUG it is OK up to 2.6.10-rc1-bk11. A pretty
Heisenbergish behaviour, isn't it?

can you reproduce the problem still wit the latest kernel? 
(ACPICA 20050211) 

2.6.11-rc4 + <kernel.org
mirror>/people/lenb/acpi/patches/release/2.6.11/acpi-20050211-2.6.11-rc4.diff.bz2,
AE_TIME errors still there (and no /proc/acpi/battery/BAT0/* files available).

Sorry for the delay - my laptop just returned from a repair (broken external VGA
port).

Thanks for verifying that with ACPICA 20050211 that the AE_AML_BUFFER_LIMIT 
error messages are gone. 
 
Please attach the complete dmesg -s64000 showing the remaining AE_TIME 
error messages. 
 
If you take the same .config and change only the CONFIG_ACPI_DEBUG line 
from 'y' to 'n' these warnings messages go away and /proc/acpi/battery/ 
appers as normal?  This is true for the latest kernel and also all the way 
back to 2.6.8.1? 
 

Created attachment 4622 [details]
dmesg of 2.6.11-rc4+ACPICA 20050211

Dmesg attached.

> If you take the same .config and change only the CONFIG_ACPI_DEBUG line 
> from 'y' to 'n' these warnings messages go away and /proc/acpi/battery/ 
> appers as normal?  This is true for the latest kernel and also all the way 
> back to 2.6.8.1? 

No. With CONFIG_ACPI_DEBUG I get those failures with all kernels I have tested
- from 2.6.8.1 to 2.6.11-rc4+ACPICA 20050211. Without CONFIG_ACPI_DEBUG it
works from 2.6.8.1 to 2.6.10-rc1-bk11 (and -bk11 + the patch mentioned above).
With anything newer, I am getting the AE_TIME errors.

And it is not only a "battery" falure, because even more things does not work
(ASUS modem LED/wireless LED, reading centrino speed/voltage tables from ACPI
(so speedstep-centrino does not work)).

please test the patch in bug #3967 -- a fix for a similar, 
though not identical, failure. 
 
Note that the error messages are disabled when CONFIG_ACPI_DEBUG=n 
(I think one could argue that this in itself is yet another bug...) 
so when we talk about the AE_TIME failure, we need to focus on features 
not working (or always build with CONFIG_ACPI_DEBUG=y) 
 
 

> please test the patch in bug #3967 -- a fix for a similar, 
> though not identical, failure. 

I've noticed that this patch is included in acpi-20050303-2.6.11.diff.bz2.
However, it does not fix my problem (neither 2.6.11+the patch from bug #3967 nor
2.6.11+whole acpi-20050303-2.6.11.diff.bz2).
 
> Note that the error messages are disabled when CONFIG_ACPI_DEBUG=n 
> so when we talk about the AE_TIME failure, we need to focus on features 
> not working (or always build with CONFIG_ACPI_DEBUG=y).

OK, but for me it seems to corellate - the AC adapter status, battery status,
ASUS MLED/WLED, and Centrino voltage/frequency tables do not work for me if and
only if the AE_TIME error is printed. And it is printed both with
CONFIG_ACPI_DEBUG=y and CONFIG_ACPI_DEBUG=n on 2.6.10-rc1-bk12 and newer.

It is entirely possible that I have a faulty hardware or what. I've seen some
users of Asus M6R which have post-2.6.9 kernel with working ACPI on their
laptops. But I have also seen laptops labeled "Asus M6R" with a different WiFi
adapter, so maybe there are different variants of Asus M6R.

Created attachment 4660 [details]
dmesg of 2.6.11+acpi-20050303 without CONFIG_ACPI_DEBUG

Just FWIW, I've added dmesg of 2.6.11+latest ACPICA without CONFIG_ACPI_DEBUG

Created attachment 4702 [details]
kernel .config difference

I have found that with CONFIG_PREEMPT=y ACPI works for me even on
2.6.11+ACPICA-20050303. I have attached the diff between two .configs - the
non-working one (-) and working one (+).

Wasn't CONFIG_PREEMPT=n supposed to be the "safer" option?

Thanks to Arne Brys who sent me a working .config which I was able to compare
to my .config.

Another observation is that with CONFIG_ACPI_DEBUG=y ACPI does not work for me
even with CONFIG_PREEMPT=y (2.6.11+ACPICA-20050303).

And with CONFIG_PREEMPT=y the network card driver seems to drop connection from
time to time (RTL8139), so it is not a long-term option for me.

It may be related to the in_atomic() use problem which Andrew Morton describes in
http://sourceforge.net/mailarchive/message.php?msg_id=11129317.

I have also verified that on other users' Asus M6R laptops the CONFIG_PREEMPT=n
makes the problem appear.

Any progress in this case?

I've upgraded to Fedora Core 4 (gcc-4), and I have the above problem regardless
of CONFIG_PREEMPT settings. I have recompiled exactly the same 2.6.11.3 kernel
which worked for me under FC3, and with gcc-4 it does not work. 2.6.12 does not
work for me (the same AE_TIME errors). 2.6.9 compiled with gcc-4 is OK.

So this is definitely a race/timing condition (even compiler dependent one).

Just to confirm, 2.6.12 compiled with gcc 3.4.3 works fine with CONFIG_PREEMPT
as long it is built with "only needed modules" config. With Mandriva's config
(on a vanilla kernel) errors appear again.

I also use Asus M6R with the latest BIOS.

Any way I could help to sort out this issue?

Im using Suse 9.3, kernel-default-2.6.11.4-20a

i keep getting this error 
    ACPI-0405: *** Error: Handler for [EmbeddedControl] returned AE_TIME
    ACPI-0446: *** Warning: [AE_NOT_CONFIGURED]: Could not resolve operands, AE_TIME
    ACPI-1140: *** Error: Method execution failed [\_SB_.PCI0.BAT0._BST] (Node
dffebb60), AE_TIME
    ACPI-0208: *** Warning: Error evaluating _BST
    ACPI-0405: *** Error: Handler for [EmbeddedControl] returned AE_TIME
    ACPI-0446: *** Warning: [AE_NOT_CONFIGURED]: Could not resolve operands, AE_TIME
    ACPI-1140: *** Error: Method execution failed [\_SB_.PCI0.BAT0._BIF] (Node
dffebba0), AE_TIME
    ACPI-0147: *** Warning: Error evaluating _BIF
    ACPI-0405: *** Error: Handler for [EmbeddedControl] returned AE_TIME
    ACPI-0446: *** Warning: [AE_NOT_CONFIGURED]: Could not resolve operands, AE_TIME
    ACPI-1140: *** Error: Method execution failed [\_SB_.PCI0.BAT0._BST] (Node
dffebb60), AE_TIME
    ACPI-0208: *** Warning: Error evaluating _BST


Also, im not able to use my battery manager. It keeps switching betn 0 & 100%.
Any soln/workaround for this?

I also have an Asus M6R, and can confirm the presence of this bug as previously
described.  I have ACPI working OK on kernel builds up to 2.6.13-rc2 provided I
disable CONFIG_ACPI_DEBUG.

However, 2.6.13-rc3 breaks ACPI, even when CONFIG_ACPI_DEBUG=n ... with that
kernel, I get the following errors:

Jul 15 15:05:45 localhost kernel:     ACPI-0423: *** Error: Handler for
[EmbeddedControl] returned AE_TIME
Jul 15 15:05:45 localhost kernel:     ACPI-1175: *** Error: Method execution
failed [\_SB_.PCI0.SBRG.EC0_.RDC3] (Node ddf0a820), AE_TIME
Jul 15 15:05:45 localhost kernel:     ACPI-1175: *** Error: Method execution
failed [\ECIO] (Node ddf0a360), AE_TIME
Jul 15 15:05:45 localhost kernel:     ACPI-1175: *** Error: Method execution
failed [\_SB_.PCI0.SBRG.EC0_.ACPS] (Node ddf088c0), AE_TIME
Jul 15 15:05:45 localhost kernel:     ACPI-1175: *** Error: Method execution
failed [\ACPS] (Node ddf04200), AE_TIME
Jul 15 15:05:45 localhost kernel:     ACPI-1175: *** Error: Method execution
failed [\_SB_.PCI0.AC0_._PSR] (Node ddf08140), AE_TIME

And that's enough to completely disable any ACPI functions on my laptop.

Just to repeat, using identical .configs on 2.6.13-rc2 and 2.6.13-rc3, -rc2
works fine and boots without errors, whereas -rc3 gives the above messages.

Kernel 2.6.12.3 & Apci 20050729 :  
 
    ACPI-0509: *** Error: Method execution failed [\_SB_.BAT0._BST] (Node 
b19b23c0), AE_OWNER_ID_LIMIT 
    ACPI-0105: *** Error: Could not allocate new owner_id (32 max), 
AE_OWNER_ID_LIMIT 
    ACPI-0509: *** Error: Method execution failed [\_SB_.AC__._PSR] (Node 
b19affc0), AE_OWNER_ID_LIMIT 
    ACPI-0105: *** Error: Could not allocate new owner_id (32 max), 
AE_OWNER_ID_LIMIT 
    ACPI-0509: *** Error: Method execution failed [\_TZ_.THRM._TMP] (Node 
b19b7f20), AE_OWNER_ID_LIMIT 
    ACPI-0105: *** Error: Could not allocate new owner_id (32 max), 
AE_OWNER_ID_LIMIT 
    ACPI-0509: *** Error: Method execution failed [\_SB_.AC__._PSR] (Node 
b19affc0), AE_OWNER_ID_LIMIT 
 

With 2.6.13-rc1 and -rc4 "insmod battery" never returns - it rests in the
"uninterruptible sleep" state. The system is still alive, but when loading ACPI
modules during boot, it prevents execution of other init scripts.

Tested with CONFIG_PREEMPT_NONE=y.

Please test ec_polling patch at http://bugzilla.kernel.org/show_bug.cgi?id=4665
Note: boot kernel with ec_polling option

I can confirm that the ec_polling patch (modified to apply to 2.6.13-rc4) works
for me, even with CONFIG_PREEMPT_NONE=y and gcc-4 from Fedora Core 4. Thanks!

With "ec_polling" enabled insmod now works fine, but AE_TIME errors are still
here. I've also tried Jan Kasprzak's .config that works fine with his M6R but
without any success.

Note that my M6R has a different CPU: it's a Celeron M 1.4 GHz.

My M6R, which is a Pentium-M 1.70GHz, also still has the same AE_TIME errors
with this patch.

Under FreeBSD, it returns AE_NO_HARDWARE_RESPONSE, so it's something common
between the two, and isn't affected by raising hw.acpi.ec.timeout on FreeBSD
from 100ms to 1000ms.

I've tested Jan Kasprzak's .config with gcc-4.0.1 and the errors are gone.

They appear again if you use Mandriva .config (I can attach it if it's of any use).

In stable 2.6.13 the bug come back? (debian, Asus m6r)

2.6.13 works for me (with "ec_polling acpi_specific_hotkey" boot options).
Even better, with 2.6.13 the sw suspends work reliably, unlike the previous
releases, where 25-50% of all resumes locked up during switching back to X.

2.6.13 works without patch?
Can i get a .config and a lilo or a grub config file please?

Created attachment 5909 [details]
kernel config for 2.6.13

Attached .config for 2.6.13. However - the above reports indicate that the
compiler version can matter as well. I have "gcc version 4.0.1 20050727 (Red
Hat 4.0.1-5)".

My grub.conf has the following:
title Linux 2.6.13
	root (hd0,0)
	kernel /boot/linux-2.6.13 ro root=/dev/hda1 resume=/dev/hda2 ec_polling
acpi_specific_hotkey

Thanks! Works with gcc 4.0.1 and Debian Sarge.

Please also try latest base kernel with ec_burst=1 and 0 combined with preempt 
enabled.

2.6.15 with ec_burst=1 brings AE_TIME errors back.

*** Bug 6111 has been marked as a duplicate of this bug. ***

2.6.16-rc2 + later, no kernel params not even any patches help :(. Burst code is
ifdeffed due to bug 4980.
Each method that fails seems to want to acquire mutex as you can see in my
duplicate bug's attachements.

Please post dmesg for your latest report.
Any difference with ec_intr=0 and ec_intr=1?

I got dmesg at bug# 6111

This bug is re-opened due to bug# 6111 which is due to unexpected call to 
acpi_ec_remve due to failure in acpi_ec_start. 


*** This bug has been marked as a duplicate of 6111 ***

Just informing anyone trying to find a solution to this problem that the patch
in bug 6111 fixes the issue.