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.
Created attachment 13587 [details] dmesg output
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.
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! :)
>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.
Created attachment 13627 [details] output from dmesg
Created attachment 13628 [details] output from acpidump
(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.
>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.
(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.
Created attachment 13655 [details] Kernel .config file
That's weird. :) Please attach the content of /proc/acpi/battery/bat0/*. Please attach the dmesg output after battery driver is loaded.
(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.
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 ...
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?
(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).
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.
Please check if patch from 9916 helps.
(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).
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?
Thanks Jan for your input, I will try it ASAP.
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.
I did try with all possible combination of kernels... but the problem is still present.
still an issue in 2.6.25?
(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.
I see the same problem with 2.6.26-rc5, so it is still presumably present even in the recent development kernels.
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.
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.
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.
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).
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.
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.
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.
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.
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.
Created attachment 17865 [details] fill ec details from DSDT Jan, could you please test this patch?
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.
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.
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.
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".
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.
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?
Hi,Alexey How about this bug? Any progress? Thanks.
the common patch to handle all broken ECDT on ASUS notebooks is in Len's queue.
Created attachment 19836 [details] patch vs 2.6.29-rc1 ACPI-EC-Don-t-trust-ECDT-tables-from-ASUS.patch applied to acpi tree
len, patch already available?
commit c6cb0e878446c79f42e7833d7bb69ed6bfbb381f
c6cb0e878446c79f42e7833d7bb69ed6bfbb381f ACPI: EC: Don't trust ECDT tables from ASUS shipped in 2.6.29-rc2 closed.