Bug 4150 - AE_AML_BUFFER_LIMIT: EC (battery) failures [AE_TIME] - Asus M6R
AE_AML_BUFFER_LIMIT: EC (battery) failures [AE_TIME] - Asus M6R
Status: REJECTED DUPLICATE of bug 6111
Product: ACPI
Classification: Unclassified
Component: ACPICA-Core
i386 Linux
: P2 normal
Assigned To: Luming Yu
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-02-02 09:00 UTC by Jan "Yenya" Kasprzak
Modified: 2006-09-28 13:19 UTC (History)
4 users (show)

See Also:
Kernel Version: 2.6.x
Tree: Mainline
Regression: ---


Attachments
Binary DSDT from Asus M6R (22.11 KB, application/octet-stream)
2005-02-02 09:02 UTC, Jan "Yenya" Kasprzak
Details
Source DSDT from Asus M6R (187.35 KB, text/x-dsl)
2005-02-02 09:06 UTC, Jan "Yenya" Kasprzak
Details
Part of diff between 2.6.10-rc1-bk11 and -bk12 (39.04 KB, patch)
2005-02-10 04:07 UTC, Jan "Yenya" Kasprzak
Details | Diff
dmesg of 2.6.11-rc4+ACPICA 20050211 (15.17 KB, text/plain)
2005-03-01 05:07 UTC, Jan "Yenya" Kasprzak
Details
dmesg of 2.6.11+acpi-20050303 without CONFIG_ACPI_DEBUG (15.11 KB, text/plain)
2005-03-04 04:00 UTC, Jan "Yenya" Kasprzak
Details
kernel .config difference (1.02 KB, text/plain)
2005-03-09 10:56 UTC, Jan "Yenya" Kasprzak
Details
kernel config for 2.6.13 (33.47 KB, text/plain)
2005-09-05 09:08 UTC, Jan "Yenya" Kasprzak
Details

Description Jan "Yenya" Kasprzak 2005-02-02 09:00:38 UTC
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.
Comment 1 Jan "Yenya" Kasprzak 2005-02-02 09:02:38 UTC
Created attachment 4499 [details]
Binary DSDT from Asus M6R
Comment 2 Jan "Yenya" Kasprzak 2005-02-02 09:06:32 UTC
Created attachment 4500 [details]
Source DSDT from Asus M6R
Comment 3 Jan "Yenya" Kasprzak 2005-02-02 09:54:58 UTC
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
Comment 4 Jan "Yenya" Kasprzak 2005-02-10 02:09:01 UTC
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.
Comment 5 Jan "Yenya" Kasprzak 2005-02-10 04:07:44 UTC
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.
Comment 6 Jan "Yenya" Kasprzak 2005-02-10 08:33:29 UTC
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?
Comment 7 Len Brown 2005-02-18 15:05:42 UTC
can you reproduce the problem still wit the latest kernel? 
(ACPICA 20050211) 
Comment 8 Jan "Yenya" Kasprzak 2005-02-23 09:55:03 UTC
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).
Comment 9 Len Brown 2005-03-01 00:10:22 UTC
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? 
 
Comment 10 Jan "Yenya" Kasprzak 2005-03-01 05:07:21 UTC
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)).
Comment 11 Len Brown 2005-03-03 19:56:55 UTC
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) 
 
 
Comment 12 Jan "Yenya" Kasprzak 2005-03-04 03:36:55 UTC
> 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.
Comment 13 Jan "Yenya" Kasprzak 2005-03-04 04:00:51 UTC
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
Comment 14 Jan "Yenya" Kasprzak 2005-03-09 10:56:12 UTC
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.
Comment 15 Jan "Yenya" Kasprzak 2005-03-11 01:08:35 UTC
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.
Comment 16 Jan "Yenya" Kasprzak 2005-06-21 14:09:49 UTC
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).
Comment 17 Piotr Keplicz 2005-06-23 04:39:42 UTC
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?
Comment 18 Srinivasa Ragavan 2005-06-30 00:15:45 UTC
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?
Comment 19 Owen Marshall 2005-07-14 22:21:10 UTC
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.
Comment 20 Damien Bellegueulle 2005-07-30 06:46:13 UTC
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 
 
Comment 21 Piotr Keplicz 2005-07-30 07:02:29 UTC
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.
Comment 22 Luming Yu 2005-07-30 07:39:39 UTC
Please test ec_polling patch at http://bugzilla.kernel.org/show_bug.cgi?id=4665
Note: boot kernel with ec_polling option
Comment 23 Jan "Yenya" Kasprzak 2005-07-31 06:39:08 UTC
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!
Comment 24 Piotr Keplicz 2005-08-01 05:58:37 UTC
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.
Comment 25 Mark Lipscombe 2005-08-01 20:54:12 UTC
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.
Comment 26 Piotr Keplicz 2005-08-02 07:39:56 UTC
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).
Comment 27 N 2005-09-03 07:41:31 UTC
In stable 2.6.13 the bug come back? (debian, Asus m6r)
Comment 28 Jan "Yenya" Kasprzak 2005-09-04 07:11:43 UTC
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.
Comment 29 N 2005-09-05 08:52:34 UTC
2.6.13 works without patch?
Can i get a .config and a lilo or a grub config file please?
Comment 30 Jan "Yenya" Kasprzak 2005-09-05 09:08:49 UTC
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
Comment 31 N 2005-09-05 11:54:30 UTC
Thanks! Works with gcc 4.0.1 and Debian Sarge.
Comment 32 Luming Yu 2005-10-23 00:14:49 UTC
Please also try latest base kernel with ec_burst=1 and 0 combined with preempt 
enabled.
Comment 33 Piotr Keplicz 2006-01-04 11:46:35 UTC
2.6.15 with ec_burst=1 brings AE_TIME errors back.
Comment 34 Jiri Slaby 2006-02-26 14:57:07 UTC
*** Bug 6111 has been marked as a duplicate of this bug. ***
Comment 35 Jiri Slaby 2006-02-26 15:07:23 UTC
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.
Comment 36 Luming Yu 2006-02-26 17:36:48 UTC
Please post dmesg for your latest report.
Any difference with ec_intr=0 and ec_intr=1?
Comment 37 Luming Yu 2006-02-26 17:42:01 UTC
I got dmesg at bug# 6111
Comment 38 Luming Yu 2006-03-01 17:41:31 UTC
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 ***
Comment 39 Owen Marshall 2006-06-09 20:03:06 UTC
Just informing anyone trying to find a solution to this problem that the patch
in bug 6111 fixes the issue.

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