Bug 6111

Created attachment 7419 [details]
acpidump

# ./acpidump >adump 
Wrong checksum for generic table!

Created attachment 7420 [details]
dmesg with intr (no argument) acpi ec handling

Created attachment 7421 [details]
dmesg with poll (no argument) acpi ec handling

Created attachment 7422 [details]
.config

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.

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
time...

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.

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.

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.

*** This bug has been marked as a duplicate of 4150 ***

Are you sure this bug did not occur: 2.6.12?
Could I take a look at dmesg of that kernel.

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.

So, could I say this is NOT a regression ?

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;
                wake_up(&ec->intr.wait);
And we never wakes the queue and set expect_event to satisfy wait_event_timeout.

>        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?

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.

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?

/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:
cause
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

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 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.
REMOVE
HELE
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
create_proc_entry

cool, the ec driver is removed!
Could you figure out who was doing that?
Just insert call to dump_stack() in acpi_ec_remove.

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

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?

*** Bug 4150 has been marked as a duplicate of this bug. ***

Created attachment 7496 [details]
part of dmesg II

in ec.c:
	status = acpi_install_gpe_handler(NULL, ec->common.gpe_bit,
					  ACPI_GPE_EDGE_TRIGGERED,
					  &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) ==
	    ACPI_GPE_DISPATCH_HANDLER) {
		status = AE_ALREADY_EXISTS; <------ here
		goto unlock_and_exit;
	}

dump_stack is in acpi_install_gpe_handler at the beginning (see the
attachement).

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.

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.
Thanks.

embedded_controller/EC/info is now
gpe bit:                0x06
ports:                  0x66, 0x62
use global lock:        no
if it helps

  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!

Created attachment 7512 [details]
patch against 2.6.16-rc5-mm2

Less "destructive" patch (preserves conditions)

Created attachment 7513 [details]
patch against 2.6.16-rc5-mm2

Remove conditions at all

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).

I prefer the patch at comment# 31, please send it to linux-acpi ML,
CC: Len Brown,  Robert Moore, and akpm

Thanks,
Luming

we close bug iff patch is in released kernel.

patch in comment #31 applied to acpi-test

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?

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.

Confirmed that the patch in comment #31 works against 2.6.15.7 and 2.6.16.20. 
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 ...

It won't be in 2.6.17, I expect including in 2.6.18-rc1.

Commit 37224470c8c6d90a4062e76a08d4dc1fcf91fc89 contains this fix.
Thanks all!

shipped in 2.6.17-git9