Red Hat Bugzilla – Bug 249007
kernel-188.8.131.52-27.fc7 hangs at "ACPI: Using PIC for interrupt routing"
Last modified: 2007-11-30 17:12:10 EST
Description of problem:
kernel-184.108.40.206-27.fc7 from updates-testing halts during boot at
ACPI: Using PIC for interrupt routing.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Boot the kernel.
Kernel also notes "Local APIC not detected. Using dummy APIC emulation."
Previous kernels have noted that the local APIC was disabled by the BIOS.
Command line options:
ro root=/dev/VolGroup00/LogVol00 acpi_serialize pci=assign-busses ec_intr=0
Does booting with the kernel option:
give any additional information?
I'm attaching photos of the screen at the time the notebook halts, both with and
without the initcall_debug option. The machine locks solid in either case and
must be forcibly powered down. This also happens with vanilla a 220.127.116.11 kernel.
(I've also attached a "healthy" dmesg from the kernel I'm currently, based off
vanilla, using for comparison.) Would you like me to e-mail the notebooks Smolt
Created attachment 159693 [details]
Image of the screen at the time the kernel halts.
Created attachment 159694 [details]
Kernel halting with initcall_debug cmdline option.
Created attachment 159695 [details]
Healthy dmesg output from 18.104.22.168
(In reply to comment #2)
> Would you like me to e-mail the notebooks Smolt
Yes, that might help.
We might be lucky and alt-sysrq could be working by the time it hangs.
Try booting with "sysrq_always_enabled" option and pressing alt-sysrq-p
(hold down Alt and SysRq while pressing T.) This can be hard to do on
notebooks where SysRq also requires the Fn key as well. Maybe trying it
on a working kernel in runlevel 3 would help figuring out the exact
Created attachment 159697 [details]
Created attachment 159699 [details]
[Re: comment #7] No response from any of the Magic SysRq combinations. I don't
think it's caught in a loop, since the fan doesn't go berserk; it seems to just
Same thing happens with the latest, kernel-22.214.171.124-33.fc7.
Still happens with kernel-126.96.36.199-41.fc7, stops at same place as before.
Still no luck with kernel-188.8.131.52-57.fc7. Any idea on what's changed between
184.108.40.206 and 2.6.22?
(In reply to comment #13)
> Any idea on what's changed between
> 220.127.116.11 and 2.6.22?
~550000 lines of code. There are some ACPI fixes in 2.6.23 that might apply to
this problem, they got merged in CVS today.
18.104.22.168-59 is building -- it has some ACPI patches that might fix the problem.
It will be available here when it finishes:
Tried 22.214.171.124-59 (i686), same thing again. This is really bizarre, I'm sure
this notebook has nothing exotic about it. Is there any way to get any more
debug info out of it?
(In reply to comment #16)
> Tried 126.96.36.199-59 (i686), same thing again. This is really bizarre, I'm sure
> this notebook has nothing exotic about it. Is there any way to get any more
> debug info out of it?
188.8.131.52-61 is building with ACPI debugging enabled in the -debug kernels.
Get the i686-debug kernel and play with the acpi.debug_layer and
acpi.debug_level parameters. See
[from the kernel-doc RPM package.]
Chuck, I've found out what was preventing the kernel from booting. I'd been
booting previous kernels with acpi_serialize and ec_intr=0 since about 2.6.18 to
acquiesce a bug where the interpreter would sometimes get stuck in an infinite
loop. Removing these allows the kernel to boot. So I'll close this as NOTABUG
for now and keep trying the latest builds in Koji to see if any of the troubles
that necessitated the problematic cmdline options return.