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