Notebook: ThinkPad T40 (2373 94G) .config, acpidmp output and dsdt patch: http://nanocrew.net/linux/t40/ Panic during boot: http://w3studi.informatik.uni-stuttgart.de/~rauar/IMG_1120.JPG https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=98849 https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=93319&action=view With that patch, the kernel does not panic, but hangs after this: 58 Devices found containing: 58 _STA, 6 _INI methods ACPI: Interpreter enabled ACPI: Using PIC for interrupt routing ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 *9 10 11) ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 *5 6 7 9 10 11) ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 9 *10 11) ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 9 10 *11) ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 9 10 11, disabled) ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 7 9 10 11, disabled) ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 7 9 10 11, disabled) ACPI: PCI Interrupt Link [LNKH] (IRQs *3 4 5 6 7 9 10 11) ACPI: PCI Root Bridge [PCI0] (00:00) PCI: Probing PCI hardware (bus 00) PCI: Ignoring BAR0-3 of IDE controller 0000:00:1f.1 Transparent bridge - 0000:00:1e.0 ACPI: Embedded Controller [EC] (gpe 28) ACPI: Power Resource [PUBS] (on) Linux Plug and Play Support v0.97 (c) Adam Belay
After recompiling without CONFIG_X86_LOCAL_APIC and CONFIG_X86_IO_APIC, the system now boots successfully.
Would you please post .config that was used for building kernel that exhibits hang problem?
Created attachment 804 [details] kernel .config
I test it. And find that system can boot with SMP off, regardless of LOCAL_APIC or IO_APIC option. This a UP, so I think the root reason is that your config file open SMP on.
Created attachment 897 [details] My SMP config file without hang I tried your config with 2.6.0-test5 kernel on T23. Boot hang right after message "Linux Plug and Play Support v0.97 (c) Adam Belay". But the attached config works for me on T23. Would you have it a try? I think it could be a config problem. Thanks a lot.
Created attachment 913 [details] serial-line console capture of the failure
Created attachment 914 [details] GPE context error patch Please try this workaround patch. With this patch my T40 can boot with SMP on. I will continue to invistigate the problem and give a more reasonable solution. The comment in the patch explaind what it did.
With Luming's config file, my T40 boots successfully. My T40 boots successfully with this config file as well: http://nanocrew.net/linux/t40/config2 However, if I enable CONFIG_ACPI_DEBUG in config2, the hang occurs. With Shaohua's workaround patch, the hang does not occur.
Created attachment 1282 [details] a proposed patch for this error previous is error. and now the new patch has passed in IBM T40 and ASUS M2400. please try it. it's against 2.6-test7. Thanks
Created attachment 1297 [details] patch for this error updated patch for the error.
Created attachment 1329 [details] patch against 2.4
With the new patch, 2.6-test8 boots successfully.
*** Bug 823 has been marked as a duplicate of this bug. ***
*** Bug 1997 has been marked as a duplicate of this bug. ***
hi with kernel-2.4.26-pre6 + acpi-20040326-2.4.26.diff.gz + this patch against 2.4 (http://bugme.osdl.org/show_bug.cgi?id=1171#c11) hangs my laptop after 5 minutes of up time. without this patch, laptop runs ok. thanks
Created attachment 2447 [details] updated patch for 2.6
Created attachment 2448 [details] updated patch for 2.4
hi with kernel-2.4.26-pre6 + acpi-20040326-2.4.26.diff.gz + this updated patch against 2.4 laptop runs ok, at least fisrt 51 min :). btw with also patch from bug http://bugme.osdl.org/show_bug.cgi?id=1690 referenced by BERNARD S
I was taking a look at the proposed patch and in acpi_os_wait_events_complete () function, if multiple threads call this function, then in each of those thread we try to execute acpi_do_task_queue() which in turn removes an item from the queue and starts executing. There are two problems doing this. 1) We are trying to execute the queued function from the thread which called acpi_os_wait_events_complete. This thread could be very well a user mode thread and we are trying to execute the queued function from this thread and not from keventd thread. This might have a bad behaviors. 2) Since multiple thread calling acpi_os_wait_events_complete() try to execute the queued function, if another thread calls acpi_os_wait_events_complete( *contxt), that context could be in the process of execution from another thread and we simply return without waiting for that function to complete there by violating what we were suppose to do, i.e wait till the context function completes. I would strongly suggest to take a look at this fix again. -Anil
Anil, I just remembered that why I let 'acpi_os_wait_events_complete' executed not in keventd is the function may be called before keventd is initialized in 2.4 kernel. But if ACPI has itself queue as you did in Bug 2515, it will not occur.
usually newer bugs are closed as duplicates of older ones, but the latest fix for this is at bug 2515, so we're closing this bug as a duplicate of that. *** This bug has been marked as a duplicate of 2515 ***