> Although I could re-open the bugzilla report the problem is, the first > question asked is "does this affect the latest > version?" and the answer is "NO" - not since 2.6.25-rc9 that I know about, > and possibly earlier. With that I doubt > there will be much interest in solving this since it'll be a case of "use the > latest kernel".
Yes, I realized later that this would very likely be happening. > It seems to show that the init_subsys for acpi_init() and acpi_scan_init() are overlapping. I can't see this from your data. Where do you think they overlap? [ 23.109039] ACPI: bus type pci registered [ 23.109168] PCI: Using configuration type 1 [ 23.110342] ACPI: acpi_ec_ecdt_probe() [ 23.110345] ACPI: EC: Look up EC in DSDT <there is no _INI method for EC, so boot_ec stays but handlers are not installed (-ENODEV)> [ 23.117192] ACPI: Interpreter enabled [ 23.117254] ACPI: (supports S0 S3 S4 S5) [ 23.117510] ACPI: Using IOAPIC for interrupt routing <up to here it is bus_init> <after that it should be scan_init> [ 23.117676] ACPI: acpi_boot_ec_enable() [ 23.117677] ACPI: ec_install_handlers(<ec>) <maybe it makes sense to print the adresses? The space handler would be called when something else tries to read or write to the EC adress space, right? Could this be a result of the _REG functions?> [ 23.117713] ACPI: acpi_ec_space_handler(<args...>) [ 23.117714] ACPI: acpi_ec_read(<ec>, <addres>, <data>) [ 23.117715] ACPI: acpi_ec_transaction(<ec>, 128, <wdata>, 1, <rdata>, 1, 0) [ 23.117717] ACPI: acpi_ec_wait(<ec>, 2, 0) [ 23.117718] ACPI: acpi_ec_wait() else [ 23.117720] ACPI: acpi_ec_transaction_unlocked(<ec>, 128, <wdata>, 1, <rdata>, 1, 0) [ 23.117723] ACPI: acpi_ec_wait(<ec>, 2, 0) [ 23.117724] ACPI: acpi_ec_wait() else [ 23.117940] ACPI: acpi_ec_wait(<ec>, 1, 0) [ 23.117941] ACPI: acpi_ec_wait() else [ 23.117999] ACPI: acpi_ec_gpe_handler(<data>) [ 23.118002] ACPI: EC: non-query interrupt received, switching to interrupt mode [ 23.118310] ACPI: acpi_ec_gpe_handler(<data>) [ 23.118322] ACPI: acpi_ec_space_handler(<args...>) [ 23.118323] ACPI: acpi_ec_read(<ec>, <addres>, <data>) [ 23.118324] ACPI: acpi_ec_transaction(<ec>, 128, <wdata>, 1, <rdata>, 1, 0) <The following message I would suspect comes from acpi_bus_scan() in scan_ini()> [ 23.118325] ACPI: PCI Root Bridge [PCI0] (0000:00) [ 23.140534] ACPI: EC: GPE = 0x17, I/O: command/status = 0x66, data = 0x62 [ 23.140598] ACPI: EC: driver started in interrupt mode > I've been thinking there's a clue in the log output when it fails: > ACPI: EC: acpi_ec_wait timeout, status=0, expect_event=1 // event 1 = > ACPI_EC_EVENT_OBF_1 = > output buffer full > ACPI: EC: read timeout, command=128 // 128 = 0x80 = ACPI_EC_COMMAND_READ So something wanted to read from EC but nothing comes back. Adding a BUG() statement in that case should give the answer to the question where the call comes from. And probably it makes sense to printk/debug the exact addresses that was requested. -- [Hardy] ACPI Embedded Controller (EC) stops boot when kernel boot 'quiet' option is enabled or AC power is connected https://bugs.launchpad.net/bugs/191137 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
