Bug 9399 - Method .. failed [...BAT0._STA] AE_TIME - no battery status - ASUS L4500R
Summary: Method .. failed [...BAT0._STA] AE_TIME - no battery status - ASUS L4500R
Status: CLOSED CODE_FIX
Alias: None
Product: ACPI
Classification: Unclassified
Component: EC (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: Alexey Starikovskiy
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-11-17 06:55 UTC by Milo Casagrande
Modified: 2009-04-01 04:15 UTC (History)
6 users (show)

See Also:
Kernel Version: 2.6.24-rc2
Tree: Mainline
Regression: Yes


Attachments
dmesg output (18.52 KB, text/plain)
2007-11-17 06:56 UTC, Milo Casagrande
Details
output from dmesg (31.13 KB, text/plain)
2007-11-19 12:08 UTC, Milo Casagrande
Details
output from acpidump (96.54 KB, text/plain)
2007-11-19 12:10 UTC, Milo Casagrande
Details
Kernel .config file (69.60 KB, text/plain)
2007-11-20 12:16 UTC, Milo Casagrande
Details
test the debug patch (1.92 KB, patch)
2008-08-07 00:19 UTC, ykzhao
Details | Diff
dmesg from the 2.6.27-rc1 with patch from comment #26 (ASUS M6R) (29.22 KB, text/plain)
2008-08-07 04:01 UTC, Jan "Yenya" Kasprzak
Details
dmidecode from ASUS M6r (7.90 KB, text/plain)
2008-08-08 01:17 UTC, Jan "Yenya" Kasprzak
Details
dmidecode of ASUS L4500R (7.85 KB, text/plain)
2008-08-08 04:27 UTC, Milo Casagrande
Details
the workaround patch (2.24 KB, patch)
2008-08-10 20:38 UTC, ykzhao
Details | Diff
fill ec details from DSDT (1.32 KB, patch)
2008-09-18 11:36 UTC, Alexey Starikovskiy
Details | Diff
EC device is also parsed in DSDT table to check whether ECDT table gives the correct ifno (1.98 KB, patch)
2008-10-27 01:39 UTC, ykzhao
Details | Diff
patch vs 2.6.29-rc1 (4.50 KB, patch)
2009-01-16 11:05 UTC, Len Brown
Details | Diff

Description Milo Casagrande 2007-11-17 06:55:58 UTC
Most recent kernel where this bug did not occur: 2.6.24-rc2
Distribution: Ubuntu 7.10
Hardware Environment: Pentium M 1.4Ghz, 512MB RAM, ATI 9100IGP
Software Environment: gcc 4.1.3
Problem Description:

Frequecy scaling works; LCD, brightness and audio buttons with Fn keys work.

The battery status is not discovered, the system says is always on AC power. If I unplug the AC power the brightness is dimmed correctly but not the battery status.
Comment 1 Milo Casagrande 2007-11-17 06:56:40 UTC
Created attachment 13587 [details]
dmesg output
Comment 2 Anonymous Emailer 2007-11-17 09:24:59 UTC
Reply-To: akpm@linux-foundation.org

On Sat, 17 Nov 2007 06:55:58 -0800 (PST) bugme-daemon@bugzilla.kernel.org wrote:

>      KernelVersion: 2.6.24-rc2
> ...
> Most recent kernel where this bug did not occur: 2.6.24-rc2

These are contradictory ;)

Which is the most recent kernel which did not have this bug?

Thanks.
Comment 3 Milo Casagrande 2007-11-17 10:44:53 UTC
Ooops... sorry... :)

I misunderstood the sentence! :)

Last kernel without this error is 2.6.20.9, from this up till 2.6.23 the system cannot boot without ACPI=OFF.

Cheers! :)
Comment 4 Zhang Rui 2007-11-18 21:31:52 UTC
>The battery status is not discovered
Please make sure CONFIG_ACPI/PROCFS and CONFIG_ACPI_BATTERY is set.
>Last kernel without this error is 2.6.20.9
You mean linux runs with the right ac/battery status, right?

Please attach the acpidump output.
Please do the following test:
echo 0x04 > /sys/module/acpi/parameters/debug_layer
echo 0x8800001f > /sys/module/acpi/parameters/debug_level
unplug/plug AC and attach the dmesg output.
Comment 5 Milo Casagrande 2007-11-19 12:08:55 UTC
Created attachment 13627 [details]
output from dmesg
Comment 6 Milo Casagrande 2007-11-19 12:10:03 UTC
Created attachment 13628 [details]
output from acpidump
Comment 7 Milo Casagrande 2007-11-19 12:10:41 UTC
(In reply to comment #4)
> You mean linux runs with the right ac/battery status, right?

Yes, with that kernel.

> Please attach the acpidump output.
> Please do the following test:
> echo 0x04 > /sys/module/acpi/parameters/debug_layer
> echo 0x8800001f > /sys/module/acpi/parameters/debug_level
> unplug/plug AC and attach the dmesg output.

Done! :)

Thanks.
Comment 8 Zhang Rui 2007-11-19 18:41:34 UTC
>evmisc-0215 [00] ev_queue_notify_reques: No notify handler for Notify(BAT0,
>80)
This indicates that your battery driver is probably not loaded.
Hmm, please make a double check.
You can send me the kernel configuration as well.
Comment 9 Milo Casagrande 2007-11-20 12:15:31 UTC

(In reply to comment #8)
> >evmisc-0215 [00] ev_queue_notify_reques: No notify handler for Notify(BAT0,
> 80)
> This indicates that your battery driver is probably not loaded.
> Hmm, please make a double check.

If it's the ACPI_BATTERY option, it is set...

> You can send me the kernel configuration as well.

I'll attach the config.

Thanks.
Comment 10 Milo Casagrande 2007-11-20 12:16:19 UTC
Created attachment 13655 [details]
Kernel .config file
Comment 11 Zhang Rui 2007-11-20 17:42:46 UTC
That's weird. :)
Please attach the content of /proc/acpi/battery/bat0/*.
Please attach the dmesg output after battery driver is loaded.
Comment 12 Milo Casagrande 2007-11-21 05:11:08 UTC
(In reply to comment #11)
> That's weird. :)
> Please attach the content of /proc/acpi/battery/bat0/*.

I tried... but I don't have a bat0/ directory... I do have /proc/acpi/battery/ but it's empty...

> Please attach the dmesg output after battery driver is loaded.

I tried an "lsmod | grep battery" (I recompiled yesterday with ACPI_BATTERY as a module) and I have it loaded...

Oh... I'm trying with the AC unplugged, I'm at the office and brought the laptop with me so I don't have AC adapter 'till tonight UTC.

Cheers.
Comment 13 Vladimir Lebedev 2007-11-22 15:28:11 UTC
Dmesg output (attachment #1 [details]) contains error message:
---------------------
18.125549] ACPI Error (psparse-0537): Method parse/execution failed
[\_SB_.PCI0.BAT0._STA] (Node c143db80), AE_TIME
---------------------

STA method for BAT0 failed ...
Comment 14 Zhang Rui 2008-01-02 00:29:52 UTC
Hi, Milo,
does the problem still exists in the latest -rc kernel?
Alexey, this seems to be an EC issue to me, can you have a look at this prlbem?
Comment 15 Milo Casagrande 2008-01-03 01:33:08 UTC
(In reply to comment #14)
> Hi, Milo,
> does the problem still exists in the latest -rc kernel?
> Alexey, this seems to be an EC issue to me, can you have a look at this
> prlbem?

Sorry, I'm travelling abroad 'till mid January and can't get very often to the net. I'll try the new -rc ASAP (as I get back home).
Comment 16 Milo Casagrande 2008-02-15 13:18:16 UTC
Sorry guys for the late response. I tryed with 2.6.24.2 and the problem still persists.

I've opened a bug also on Launchpad with latest Ubuntu (Hardy), the bug there is 191477.
Comment 17 Alexey Starikovskiy 2008-02-15 13:40:17 UTC
Please check if patch from 9916 helps.
Comment 18 Milo Casagrande 2008-02-16 04:56:04 UTC
(In reply to comment #17)
> Please check if patch from 9916 helps.
> 

Tryed with patch from comment #3 on that bug, but I still get the EC messages at boot (by the way, looks like ACPI isn't working at all with that kernel for my computer).
Comment 19 Jan "Yenya" Kasprzak 2008-03-18 13:03:20 UTC
I have an ASUS M6R laptop and I see the same problem. I have git bisected the source, and the commit which causes this is the following one:

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=208c70a45624400fafd7511b96bc426bf01f8f5e

The following commit fixes the problem for me:

ttp://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=4af8e10a6c57e7292862bd1703712f0565c7e429

The diff is here:

ttp://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blobdiff;f=drivers/acpi/ec.c;h=7222a18a03198d0bc70121d1246dc27af1d0629e;hp=caf873c14bfb244a89ba9c322ada05c3c2b3c04e;hb=4af8e10a6c57e7292862bd1703712f0565c7e429;hpb=2f44bbb495dd3e6d0209eff2257438ab9c570e5b

Milo, can you test the above patch?
Comment 20 Milo Casagrande 2008-03-18 14:13:50 UTC
Thanks Jan for your input, I will try it ASAP.
Comment 21 Milo Casagrande 2008-03-20 14:31:17 UTC
I retried 2.6.24.3 and checked ec.c file, but it looks like the one in the patch. Anyway, it's not working. I tried patch-2.6.25-rc6 but I get errors at compile time. I will check better in the next days.
Comment 22 Milo Casagrande 2008-04-25 08:38:07 UTC
I did try with all possible combination of kernels... but the problem is still present.
Comment 23 Len Brown 2008-06-13 19:45:12 UTC
still an issue in 2.6.25?
Comment 24 Milo Casagrande 2008-06-14 07:55:30 UTC
(In reply to comment #23)
> still an issue in 2.6.25?
> 

Yes, recompiled 2.6.25.6 but still the same problem, battery looks like not present.
Comment 25 Jan "Yenya" Kasprzak 2008-06-15 05:39:09 UTC
I see the same problem with 2.6.26-rc5, so it is still presumably present even in the recent development kernels.
Comment 26 ykzhao 2008-08-07 00:19:26 UTC
Created attachment 17114 [details]
test the debug patch

Will you please try the latest kernel(2.6.27-rc1) and see whether the problem still exists?
Please try the debug patch on the kernel of 2.6.27-rc1 and see whether the problem still exists.
After test, please attach the output of dmesg.

Thanks.
Comment 27 Jan "Yenya" Kasprzak 2008-08-07 04:01:02 UTC
Created attachment 17119 [details]
dmesg from the 2.6.27-rc1 with patch from comment #26 (ASUS M6R)

The problem still exists in 2.6.27-rc1 and the 2.6.27-rc1+patch from the comment #26. Dmesg from the later version attached.
Comment 28 ykzhao 2008-08-08 01:01:46 UTC
Hi, Jan && Milo
    The root cause is caused by the broken BIOS.
    There exists ECDT table on your laptop. And from the ECDT table we can know that the EC command/status address is 0x62 and EC data register address is 0x66.
    At the same time there exists the register definition for the same EC device in DSDT table. The data/command register definition is parsed from the following object. The data register address is 0x62 and the command/status address is 0x66.
    >Name (_CRS, ResourceTemplate ()
                        {
                            IO (Decode16,
                                0x0062,             // Range Minimum
                                0x0062,             // Range Maximum
                                0x00,               // Alignment
                                0x01,               // Length
                                )
                            IO (Decode16,
                                0x0066,             // Range Minimum
                                0x0066,             // Range Maximum
                                0x00,               // Alignment
                                0x01,               // Length
                                )
                        })
    Based on the above analysis it seems that the I/O register definition for the same EC device is totally contradicted. In fact the definition in DSDT table should be correct. It is an obvious BIOS bug. And in current kernel the register definition in ECDT table is used for the initialization of EC device. In such case it seems that EC device can't be initialized correctly.
    IMO this bug had better be fixed by upgrading BIOS. And I will reject this bug.
    
    Of course if you can attach the output of dmidecode I will write a workaround patch for you. But I won't push it into upstream kernel.

    Thanks.
    
    
Comment 29 Jan "Yenya" Kasprzak 2008-08-08 01:17:15 UTC
Created attachment 17140 [details]
dmidecode from ASUS M6r

OK, here is my dmidecode - thanks in advance for a fix. I have just checked on the ASUS website, and there is no newer BIOS than I have for M6R (0207).
Comment 30 Milo Casagrande 2008-08-08 04:27:53 UTC
Created attachment 17143 [details]
dmidecode of ASUS L4500R

I'm attaching my dmidecode here... BTW, with 2.6.27-rc1 I couldn't even boot and even for me no more BIOS update (this laptop is more a problem now...).

Thanks for your work.
Comment 31 ykzhao 2008-08-10 20:38:23 UTC
Created attachment 17175 [details]
the workaround patch

The attached is the workaround patch. If the laptop falls into the EC DMI check table, it means that the ECDT table gives the incorrect command/data I/O address. In such case the command/data I/O address will be fixed.

Thanks.
Comment 32 Jan "Yenya" Kasprzak 2008-08-11 05:01:46 UTC
OK, looks readable. With s/DMI_BIOS_VENDOR/DMI_BIOS_VERSION/ it works on my ASUS M6R. Thanks!

As for comment #28: can you reconsider pushing the fix to the upstream kernel? The kernel is already full of workarounds and quirks for various hardware/firmware bugs.

Of course for the upstream a different approach could be better - probably we should check whether the ECDT gives the exactly opposite values for the command and data registers than DSDT, print big fat warning, and if the DMI_SYS_VENDOR is "ASUSTeK Computer Inc.", use the values from DSDT.
 
Comment 33 ykzhao 2008-08-11 19:17:50 UTC
Hi, Jan
    Thanks for your test. It is my fault that there exists an error in the workround patch. 
    Maybe what you said is right. It is a good ided to compare the command/data I/O address defined in ECDT table with that defined in DSDT table. But it will be more complex. In fact this is an obvious BIOS bug. It will be more appropriate to fix it by upgrading BIOS.
    Of course it will be OK to push the patch in comment #31 to upstream kernel. And I will try it. (The DMI_BIOS_VENDOR will be replaced by DMI_BIOS_VERSION).
    Thanks.
Comment 34 Jan "Yenya" Kasprzak 2008-08-12 01:29:36 UTC
Thanks for reconsidering pushing the patch upstream.

As for the BIOS being buggy. Of course, I fully agree. The system way would be to fix BIOS. However, I think the probability of ASUS publishing a new BIOS for the 4+ years old device (which has even worked with Linux so far) is close to zero.

Anyway, thanks again for writing this patch.
Comment 35 Alexey Starikovskiy 2008-09-18 11:36:56 UTC
Created attachment 17865 [details]
fill ec details from DSDT

Jan,
could you please test this patch?
Comment 36 ykzhao 2008-09-18 18:26:22 UTC
Hi, Alexey
    Why not revert my patch?
    If your patch is applied, the ec_parse_device will be executed twice for the laptops without the ECDT table. Maybe it is harmless. But it seems very superfulous.
    At the same time the EC Data/Command port is corrected when loading the EC driver. But it is too late. Maybe EC will be accessed in _INI object  and in the course of scanning ACPI device.
    For example: On the laptop of this bug the EC will be accessed in the _STA object of BAT0.
    
    
Comment 37 ykzhao 2008-09-18 18:39:59 UTC
Hi, Alexey
    Maybe the issue on some Asus laptops can be fixed by your patch.(Of course there still exist some warning messages before EC driver is loaded).
    But maybe other laptops will be broken by your patch. If the EC I/O definition in ECDT table is corrected and that in DSDT is incorrect, it will be broken by your patch. In theory there is no such a laptop. But who knows.
    
Comment 38 ykzhao 2008-10-27 01:39:30 UTC
Created attachment 18462 [details]
EC device is also parsed in DSDT table to check whether ECDT table gives the correct ifno

Hi, Alexey
    How about this issue?
    Please ignore the case in comment #37. It is only assumed in theory and it should not exist. If it exists, we have to say that it is a stupid BIOS.
    How about the attached patch? In this patch the EC device is also parsed in DSDT table to check whether the ECDT table gives the correct info.
    For example: Command I/O address, Data I/O Address, GPE number.
    If the info is inconsistent with that in DSDT table, it is replaced by the info in DSDT table.
    thanks.
Comment 39 Alexey Starikovskiy 2008-10-27 01:54:02 UTC
Yakui,
With your patch checking for ECDT becomes completely redundant, we _always_ get information from DSDT. All our workarounds should not punish "good vendors", for this only reason for them being "good".
Comment 40 ykzhao 2008-10-27 19:51:44 UTC
Hi, Alexey
    As I said in comment #37, the issue on Asus laptops can be fixed by your patch. The remaing issue is that there still exists the warning messages before EC driver is loaded. The function of ec_parse_device is called in the acpi_ec_add. Before it is called, the EC I/O port is incorrect. So when EC is accessed, there exists the warning message. Right?
    >ACPI: EC: input buffer is not empty, aborting transaction
    >[18.125459] ACPI Exception (evregion-0420): AE_TIME, Returned by Handler for [EmbeddedControl] [20070126]
   
    In theory the info obtained from ECDT table should be consistent with that obtained from DSDT table(For example: I/O address; GPE number). If they are inconsistent, maybe there exists the problem. For example: Some Asus laptops.
    In the patch of comment #38 the info obtained from ECDT table will be compared with that obtained from DSDT table when there exists the ECDT table. If they are not consistent, it is superseded by the info obtained from DSDT table. I don't know how this punish the "good vendors".
    At the same time it is still necessary to check the ECDT table. When ECDT table exists, the EC device can be initialized earlier.
    
    Welcome your comments.
    thanks.
Comment 41 Jan "Yenya" Kasprzak 2008-11-18 07:09:20 UTC
Hello, the patch from comment #38 works for me (ASUS M6R, 2.6.28-rc5). The patch from comment #35 does not.

Sorry for the delayed reply, having got a new laptop I don't boot my old M6R too often :-)

Can the patch from comment #38 be pushed upstream?
Comment 42 ykzhao 2009-01-04 22:30:41 UTC
Hi,Alexey
   How about this bug? Any progress?
   Thanks.
Comment 43 Alexey Starikovskiy 2009-01-05 02:36:26 UTC
the common patch to handle all broken ECDT on ASUS notebooks is in Len's queue.
Comment 44 Len Brown 2009-01-16 11:05:17 UTC
Created attachment 19836 [details]
patch vs 2.6.29-rc1

ACPI-EC-Don-t-trust-ECDT-tables-from-ASUS.patch
applied to acpi tree
Comment 45 Zhang Rui 2009-03-01 21:39:51 UTC
len,
patch already available?
Comment 46 Alan 2009-03-26 16:18:49 UTC
commit c6cb0e878446c79f42e7833d7bb69ed6bfbb381f
Comment 47 Len Brown 2009-04-01 04:15:15 UTC
c6cb0e878446c79f42e7833d7bb69ed6bfbb381f
ACPI: EC: Don't trust ECDT tables from ASUS

shipped in 2.6.29-rc2
closed.

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