Distribution: Fedora Core 3 Hardware Environment: Asus M6R Laptop (http://www.fi.muni.cz/~kas/m6r/ Software Environment: Problem Description: I am experiencing various ACPI problems with my Asus M6R laptop: 1. When using 2.6.8.1 or 2.6.9, I can use ACPI (read battery status, switch the modem LED on/off using echo [01] >/proc/acpi/asus/mled, etc.). With newer kernels (tried some 2.6.10-rcX, 2.6.10, 2.6.11-rc2-bk9 I get ACPI errors on boot and I am not able to read battery status or switch modem LED on/off. The relevant part of the "dmesg" of 2.6.11-rc2-bk9 during boot is the following: PCI: Using ACPI for IRQ routing ** PCI interrupts are no longer routed automatically. If this ** causes a device to stop working, it is probably because the ** driver failed to call pci_enable_device(). As a temporary ** workaround, the "pci=routeirq" argument restores the old ** behavior. If this argument makes the device work again, ** please email the output of "lspci" to bjorn.helgaas@hp.com ** so I can fix the driver. ACPI-1138: *** Error: Method execution failed [\MCTH] (Node ddf006e0), AE_AML_BUFFER_LIMIT ACPI-1138: *** Error: Method execution failed [\OSFL] (Node ddf00700), AE_AML_BUFFER_LIMIT ACPI-1138: *** Error: Method execution failed [\_SB_.RMEM._CRS] (Node ddf043c0), AE_AML_BUFFER_LIMIT ACPI-0158: *** Error: Method execution failed [\_SB_.RMEM._CRS] (Node ddf043c0), AE_AML_BUFFER_LIMIT Machine check exception polling timer started. Initializing Cryptographic API ACPI-0405: *** Error: Handler for [EmbeddedControl] returned AE_TIME ACPI-1138: *** Error: Method execution failed [\_SB_.PCI0.SBRG.EC0_.RDC3] (Node ddf09680), AE_TIME ACPI-1138: *** Error: Method execution failed [\ECIO] (Node ddf091c0), AE_TIME ACPI-1138: *** Error: Method execution failed [\_SB_.PCI0.SBRG.EC0_.ACPS] (Node ddf09720), AE_TIME ACPI-1138: *** Error: Method execution failed [\ACPS] (Node ddf04ee0), AE_TIME ACPI-1138: *** Error: Method execution failed [\_SB_.PCI0.AC0_._PSR] (Node ddf07e80), AE_TIME ACPI-0405: *** Error: Handler for [EmbeddedControl] returned AE_TIME ACPI-1138: *** Error: Method execution failed [\_SB_.PCI0.SBRG.EC0_.SMBR] (Node ddf09380), AE_TIME ACPI-1138: *** Error: Method execution failed [\_SB_.PCI0.SBRG.EC0_.BIF0] (Node ddf07a80), AE_TIME ACPI-1138: *** Error: Method execution failed [\_SB_.PCI0.BAT0._BIF] (Node ddf07c60), AE_TIME ACPI: Power Button (FF) [PWRF] ACPI: Lid Switch [LID] ACPI: Sleep Button (CM) [SLPB] ACPI: Video Device [VGA] (multi-head: yes rom: no post: no) ACPI-0405: *** Error: Handler for [EmbeddedControl] returned AE_TIME ACPI-1138: *** Error: Method execution failed [\_SB_.PCI0.SBRG.EC0_.RDC3] (Node ddf09680), AE_TIME ACPI-1138: *** Error: Method execution failed [\ECIO] (Node ddf091c0), AE_TIME ACPI-1138: *** Error: Method execution failed [\_SB_.PCI0.SBRG.EC0_.ACPS] (Node ddf09720), AE_TIME ACPI-1138: *** Error: Method execution failed [\ACPS] (Node ddf04ee0), AE_TIME ACPI-1138: *** Error: Method execution failed [\_PR_.CPU1._PPC] (Node ddf16240), AE_TIME ACPI: Thermal Zone [THRM] (58 C) Asus Laptop ACPI Extras version 0.29 M6R model detected, supported 2. ACPI S3 does not work in 2.6.8.1 and 2.6.9 (the laptop suspends itself, but apparently goes to a "power off" state - no LED is on. When I power it on again, it is a normal cold boot. With 2.6.11-rc2-bk9 the S3 state works (the power LED starts blinking, but after pushing the power button the system does not resume itself) 2.6.11-rc2-bk9 with acpi_sleep=s3_bios boot parameter is the same as in 2.6.9 (the laptop goes off instead of suspending to RAM). I will attach my source and binary DSDT in a moment.
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.