Bug 6111

Summary: Acpi defunct -- buttons, battery
Product: ACPI Reporter: Jiri Slaby (jirislaby)
Component: Config-OtherAssignee: acpi_config-other
Severity: normal CC: acpi-bugzilla, kas, keplicz, trenn
Priority: P2    
Hardware: i386   
OS: Linux   
Kernel Version: 2.6.16-rc4 Tree: Mainline
Regression: ---
Attachments: acpidump
dmesg with intr (no argument) acpi ec handling
dmesg with poll (no argument) acpi ec handling
DSDT as hex file to compile into kernel via kernel .config option
Byte Code DSDT for placing into intitrd
`Error evaluating _BIF' dismissed, but `Error reading AC Adapter state' still present
part of dmesg
part of dmesg II
patch against 2.6.16-rc5-mm2
patch against 2.6.16-rc5-mm2

Description Jiri Slaby 2006-02-20 12:58:04 UTC
Most recent kernel where this bug did not occur: 2.6.12?
Distribution: FC5 test2

Hardware Environment:
asus m6r laptop

Software Environment:
asus acpi specifics enabled in kernel

Problem Description:
Acpi says no matter what is enabled/disabled from ec_intr and noapic:
ACPI: write EC, IB not empty
ACPI: write EC, IB not empty
ACPI: write EC, IB not empty
ACPI Exception (evregion-0409): AE_TIME, Returned by Handler for
[EmbeddedControl] [20060127]
ACPI Error (psparse-0517): Method parse/execution failed
[\_SB_.PCI0.SBRG.EC0_.RDC3] (Node ddf13fa8), AE_TIME
ACPI Error (psparse-0517): Method parse/execution failed [\ECIO] (Node
ddf13628), AE_TIME
ACPI Error (psparse-0517): Method parse/execution failed
[\_SB_.PCI0.SBRG.EC0_.ACPS] (Node ddf11228), AE_TIME
ACPI Error (psparse-0517): Method parse/execution failed [\ACPS] (Node
ddf0b368), AE_TIME
ACPI Error (psparse-0517): Method parse/execution failed [\_SB_.PCI0.AC0_._PSR]
(Node ddf10228), AE_TIME
 acpi_ac-0095 [10] ac_get_state          : Error reading AC Adapter state

Steps to reproduce:
simply boot

Problems were solved by using ec_burst and patch from bug 4980 before -rc2.
Comment 1 Jiri Slaby 2006-02-20 13:00:38 UTC
Created attachment 7419 [details]

# ./acpidump >adump 
Wrong checksum for generic table!
Comment 2 Jiri Slaby 2006-02-20 13:02:07 UTC
Created attachment 7420 [details]
dmesg with intr (no argument) acpi ec handling
Comment 3 Jiri Slaby 2006-02-20 13:02:56 UTC
Created attachment 7421 [details]
dmesg with poll (no argument) acpi ec handling
Comment 4 Jiri Slaby 2006-02-20 13:04:42 UTC
Created attachment 7422 [details]
Comment 5 Thomas Renninger 2006-02-22 13:48:41 UTC
Created attachment 7442 [details]
DSDT as hex file to compile into kernel via kernel .config option

I wonder if the sleep in RDC3 which seem to cause execution to fail also cause
all the other grief as follow up errors.
Can you try and override yours with attached DSDT, please.
I will also attach another DSDT to add via initrd if you have a distro
supporting this. Let me know (maybe by private email) if you have questions
about overriding DSDT.
Comment 6 Thomas Renninger 2006-02-22 15:19:23 UTC
Created attachment 7445 [details]
Byte Code DSDT for placing into intitrd

If you are not sure about your kernel supports overriding or you are using a
plane vanilla kernel, better compile the DSDT into the kernel with the previous
attached one. Tell me if you have a SUSE system, our kernel of the day is
2.6.16-rc4 based and provides DSDT overriding via initrd what can save you some
Comment 7 Jiri Slaby 2006-02-22 16:47:43 UTC
Created attachment 7448 [details]
`Error evaluating _BIF' dismissed, but `Error reading AC Adapter state' still present

Can you take a look at the 1st reported one? The second (unreported, but
present in dmesg) dismissed. Thanks.
Comment 8 Jiri Slaby 2006-02-25 12:43:02 UTC
Actually there is no change with using that DSDT, the change was only in fact
that I removed battery from slot before booting and dumping dmesg.
Comment 9 Jiri Slaby 2006-02-25 14:01:59 UTC
some additional info:
evregion-0387 [0A2A] [50] ev_address_space_dispa: Handler ddf1d72c (@c0204f85)
Address 0000000000000005 [EmbeddedControl]
ACPI Exception (evregion-0409): AE_TIME, Returned by Handler for
[EmbeddedControl] [20060127]
# gdb vmlinux /proc/kcore
(gdb) list *c0204f85
0xc0204f85 is in acpi_ec_space_handler (/usr/src/2.6.15/drivers/acpi/ec.c:836).
831     acpi_ec_space_handler(u32 function,
832                           acpi_physical_address address,
833                           u32 bit_width,
834                           acpi_integer * value,
835                           void *handler_context, void *region_context)
836     {
837             int result = 0;
838             union acpi_ec *ec = NULL;
839             u64 temp = *value;
840             acpi_integer f_v = 0;

Now, I am going to try disable preempt.
Comment 10 Jiri Slaby 2006-02-26 14:57:04 UTC

*** This bug has been marked as a duplicate of 4150 ***
Comment 11 Luming Yu 2006-02-26 17:37:49 UTC
Are you sure this bug did not occur: 2.6.12?
Could I take a look at dmesg of that kernel.
Comment 12 Jiri Slaby 2006-02-26 17:42:37 UTC
Nope, errors was there (forgot to point that out), moreover, I can't test
anything before (2.6.11*; for comparison) since my `as' doesn't compile process.c.
Comment 13 Luming Yu 2006-02-26 18:13:35 UTC
So, could I say this is NOT a regression ?
Comment 14 Jiri Slaby 2006-02-27 03:16:05 UTC
Yes it is, but I don't know which kernel was the first defunct. Till 2.6.16-rc2
I was able to apply some patches, that I found (from you from bugzilla) and it
was OK, but since 2.6.15 times, as Piotr Keplicz wrote, there is no way.
Relevant kernel versions could be found in the first post in bug 4150.

More deeper. When wait_event_timeout in ec_intr_wait (ec.c) is running,
interrupt comes, but acpi_ec_read_status ever returns 0xff, so ACPI_EC_FLAG_IBF
flag is set and it's error, because (acpi_ec_gpe_intr_handler)
        case ACPI_EC_EVENT_IBE:
                if ((value & ACPI_EC_FLAG_IBF))
                        break; <----- here
                ec->intr.expect_event = 0;
And we never wakes the queue and set expect_event to satisfy wait_event_timeout.
Comment 15 Luming Yu 2006-02-27 17:53:54 UTC
>        case ACPI_EC_EVENT_IBE:
>               if ((value & ACPI_EC_FLAG_IBF))
>                        break; <----- here
it is because that if IBF is set, it means Input Buffer Full.
So, we need to break here.

what's your laptop model? Does windows works?

Comment 16 Jiri Slaby 2006-02-28 02:01:40 UTC
I understand the code, but I don't think it's OK, that read status returns 0xff,
i. e. all bits set.

Asus M6R (M6B00R) and I do not have windows, but afaik it does work there.
Comment 17 Luming Yu 2006-02-28 04:33:09 UTC
Could you dump vaule returned from acpi_ec_read_status() for each ec 
interrupt?  If EC status regster is broken, nothing can work. 

Could you cat /proc/acpi/embedded_controller/EC0/info?
Comment 18 Jiri Slaby 2006-02-28 09:09:25 UTC
/proc/acpi/embedded_controller is empty ?!

        acpi_clear_gpe(NULL, ec->common.gpe_bit, ACPI_ISR);
        value = acpi_ec_read_status(ec);
/*this*/printk("acpi_ec_gpe_intr_handler value = %x\n", value);
        switch (ec->intr.expect_event) {
        case ACPI_EC_EVENT_OBF:
ACPI: write EC, IB not empty
acpi_ec_gpe_intr_handler value = ff
ACPI: write EC, IB not empty
acpi_ec_gpe_intr_handler value = ff
ACPI: write EC, IB not empty
ACPI Exception (evregion-0409): AE_TIME, Returned by Handler for
[EmbeddedControl] [20060127]
acpi_ec_gpe_intr_handler value = ff
ACPI Error (psparse-0517): Method parse/execution failed
[\_SB_.PCI0.SBRG.EC0_.STC5] (Node ddf13fe8), AE_TIME
ACPI Error (psparse-0517): Method parse/execution failed [\_SB_.ATKD.MLED] (Node
ddf0e568), AE_TIME
Asus ACPI: LED (MLED) write failed
ACPI: query EC, IB not empty
ACPI: query EC, IB not empty
ACPI: query EC, IB not empty
Comment 19 Jiri Slaby 2006-02-28 09:11:58 UTC
Created attachment 7483 [details]
part of dmesg

This is part of dmesg was captured after
echo 0xc00000f >debug_level
echo 1 >/proc/acpi/asus/mled
Comment 20 Jiri Slaby 2006-02-28 09:57:22 UTC
Comment to missing proc entry (relevant part of dmesg):
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P1._PRT]
dd: 00000000
dd1: c14a0740, EC0
en: c14a06c0, info
ACPI: Embedded Controller [EC0] (gpe 6) interrupt mode.
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P2._PRT]

REMOVE means calling acpi_ec_remove, so that acpi_ec_remove_fs is called too
(HELE is in acpi_ec_remove_fs).
dd, dd1 and en are in acpi_ec_add_fs, beore and after proc_mkdir and after
Comment 21 Luming Yu 2006-02-28 17:13:06 UTC
cool, the ec driver is removed!
Could you figure out who was doing that?
Just insert call to dump_stack() in acpi_ec_remove.
Comment 22 Jiri Slaby 2006-03-01 01:41:05 UTC
That's it:
 [<c01ef4fa>] acpi_ec_remove+0x30/0xf5
 [<c01f9ee4>] acpi_start_single_object+0x71/0x98
 [<c01fb0ad>] acpi_bus_scan+0x163/0x1ca
 [<c02eff36>] acpi_scan_init+0x162/0x19a
 [<c01002de>] init+0x8e/0x210 
 [<c0100250>] init+0x0/0x210
 [<c0101005>] kernel_thread_helper+0x5/0x10
Comment 23 Luming Yu 2006-03-01 17:07:02 UTC
if acpi_ec_start fail, acpi_start_single_object will call acpi_ec_remove.
Could you find out where return fail in acpi_ec_start?
Comment 24 Luming Yu 2006-03-01 17:41:36 UTC
*** Bug 4150 has been marked as a duplicate of this bug. ***
Comment 25 Jiri Slaby 2006-03-02 03:23:55 UTC
Created attachment 7496 [details]
part of dmesg II

in ec.c:
	status = acpi_install_gpe_handler(NULL, ec->common.gpe_bit,
					  &acpi_ec_gpe_handler, ec);
	if (ACPI_FAILURE(status)) {
		return_VALUE(-ENODEV); <-------- here
since AE_ALREADY_EXISTS (events/evxface.c):
	if ((gpe_event_info->flags & ACPI_GPE_DISPATCH_MASK) ==
		status = AE_ALREADY_EXISTS; <------ here
		goto unlock_and_exit;

dump_stack is in acpi_install_gpe_handler at the beginning (see the
Comment 26 Luming Yu 2006-03-03 19:15:43 UTC
Could you investigate if ec_ecdt is removed in acpi_ec_burst_add?
If NOT, then please unconditionally remove ec_ecdt and related ec gpe handler.
and re-test.
Comment 27 Jiri Slaby 2006-03-04 10:11:37 UTC
Yup!! That's it! ACPI is working without
        ec_ecdt->common.uid == uid
condition. The former is equal to 0 and uid is 0xc027e857.
It is 0 since acpi_ec_intr_get_real_ecdt:
        ec_ecdt->common.uid = ecdt_ptr->uid;
and it's zero.
Comment 28 Jiri Slaby 2006-03-05 11:46:26 UTC
embedded_controller/EC/info is now
gpe bit:                0x06
ports:                  0x66, 0x62
use global lock:        no
if it helps
Comment 29 Luming Yu 2006-03-05 18:07:23 UTC
  I think we need to find out the value of ecdt_ptr->uid in BIOS ECDT table by 
checking acpidump output. If the value is zero, then , this is BIOS issue.
Otherwise, this is kernel bug.
  Anyway, we must unconditionally remove ec_ecdt and its handler in 
ec_intr_add, and ec_poll_add to make sure the ec device and its handler
can be installed correctly.
  So, would you like to write a patch for this? Because, you can test it on 
real platform with this issue. Thanks!
Comment 30 Jiri Slaby 2006-03-06 09:13:15 UTC
Created attachment 7512 [details]
patch against 2.6.16-rc5-mm2

Less "destructive" patch (preserves conditions)
Comment 31 Jiri Slaby 2006-03-06 09:13:49 UTC
Created attachment 7513 [details]
patch against 2.6.16-rc5-mm2

Remove conditions at all
Comment 32 Jiri Slaby 2006-03-06 09:22:41 UTC
I don't know if I understood you correctly. There are two patches, could you
decide if you want one of them (guessing, the second one?), if yes, I'll post it
to lkml and Len to discuss and put in acpi tree. If not, please tell me more
concrete, what you meant.
Of course, uid in ecdt table is 0.
Both patches are against -mm, but both were successfully tested on 2.6.16-rc5
(some line offsets).
Comment 33 Luming Yu 2006-03-07 01:08:11 UTC
I prefer the patch at comment# 31, please send it to linux-acpi ML,
CC: Len Brown,  Robert Moore, and akpm

Comment 34 Luming Yu 2006-03-07 01:09:03 UTC
we close bug iff patch is in released kernel.
Comment 35 Len Brown 2006-04-01 19:33:25 UTC
patch in comment #31 applied to acpi-test
Comment 36 Jan "Yenya" Kasprzak 2006-05-14 07:01:41 UTC
It seems that even after >2 months since the patch has been put there,
this patch is still not in the current kernel (2.6.17-rc4). Do you intent to
push it upstream?
Comment 37 Jiri Slaby 2006-05-14 07:06:47 UTC
It's in acpi-devel tree for all this time. I don't know what went wrong, nothing
from acpi git was merged into mainline. I'll ask.
Comment 38 Owen Marshall 2006-06-09 19:59:51 UTC
Confirmed that the patch in comment #31 works against and 
Finally, I'm able to use a linux kernel newer than 2.6.12! :)

Is there any news about the inclusion of this patch in the kernel?  This bug
causes a lot of pain for users of this laptop, as it means that no acpi
functions are available on any modern distro by default, effectively preventing
anyone without the ability to recompile the kernel from using linux on this
model of laptop.

ps - Yenya: your page is the top hit for googling "linux asus M6R" - could you
perhaps include a note about the patch on your site?  The only way I found this
was by following bug 4150, which itself could do with a note pointing to this
fix.  Just knowing that there's a solution available would help a *lot* of
people ...
Comment 39 Jiri Slaby 2006-06-10 01:31:22 UTC
It won't be in 2.6.17, I expect including in 2.6.18-rc1.
Comment 40 Jiri Slaby 2006-06-23 08:48:48 UTC
Commit 37224470c8c6d90a4062e76a08d4dc1fcf91fc89 contains this fix.
Thanks all!
Comment 41 Len Brown 2006-06-25 21:11:29 UTC
shipped in 2.6.17-git9