Bug 249007 - kernel-2.6.22.1-27.fc7 hangs at "ACPI: Using PIC for interrupt routing"
kernel-2.6.22.1-27.fc7 hangs at "ACPI: Using PIC for interrupt routing"
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
7
All Linux
low Severity high
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-07-20 06:52 EDT by James
Modified: 2007-11-30 17:12 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-08-22 04:24:11 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Image of the screen at the time the kernel halts. (175.44 KB, image/jpeg)
2007-07-20 16:49 EDT, James
no flags Details
Kernel halting with initcall_debug cmdline option. (246.81 KB, image/jpeg)
2007-07-20 16:49 EDT, James
no flags Details
Healthy dmesg output from 2.6.21.5 (20.53 KB, text/plain)
2007-07-20 16:50 EDT, James
no flags Details
biosdecode output (1.07 KB, text/plain)
2007-07-20 17:04 EDT, James
no flags Details
dmidecode output (11.05 KB, text/plain)
2007-07-20 17:05 EDT, James
no flags Details

  None (edit)
Description James 2007-07-20 06:52:35 EDT
Description of problem:
kernel-2.6.22.1-27.fc7 from updates-testing halts during boot at

ACPI: Using PIC for interrupt routing.

Version-Release number of selected component (if applicable):
kernel-2.6.22.1-27.fc7

How reproducible:
Always.

Steps to Reproduce:
1. Boot the kernel.
  
Actual results:
Kernel halts.

Expected results:
Completes booting.

Additional info:
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
Comment 1 Chuck Ebbert 2007-07-20 15:30:02 EDT
Does booting with the kernel option:

   initcall_debug

give any additional information?
Comment 2 James 2007-07-20 16:48:25 EDT
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 2.6.22.1 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
UUID?
Comment 3 James 2007-07-20 16:49:13 EDT
Created attachment 159693 [details]
Image of the screen at the time the kernel halts.
Comment 4 James 2007-07-20 16:49:58 EDT
Created attachment 159694 [details]
Kernel halting with initcall_debug cmdline option.
Comment 5 James 2007-07-20 16:50:58 EDT
Created attachment 159695 [details]
Healthy dmesg output from 2.6.21.5
Comment 6 Chuck Ebbert 2007-07-20 16:55:05 EDT
(In reply to comment #2)
> Would you like me to e-mail the notebooks Smolt
> UUID?

Yes, that might help.
Comment 7 Chuck Ebbert 2007-07-20 17:03:35 EDT
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
sequence needed.
Comment 8 James 2007-07-20 17:04:45 EDT
Created attachment 159697 [details]
biosdecode output
Comment 9 James 2007-07-20 17:05:32 EDT
Created attachment 159699 [details]
dmidecode output
Comment 10 James 2007-07-20 17:15:22 EDT
[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
stop.
Comment 11 James 2007-07-29 04:48:41 EDT
Same thing happens with the latest, kernel-2.6.22.1-33.fc7.
Comment 12 James 2007-08-02 14:42:35 EDT
Still happens with kernel-2.6.22.1-41.fc7, stops at same place as before.
Comment 13 James 2007-08-15 11:28:55 EDT
Still no luck with kernel-2.6.22.2-57.fc7. Any idea on what's changed between
2.6.21.5 and 2.6.22?
Comment 14 Chuck Ebbert 2007-08-15 15:26:35 EDT
(In reply to comment #13)
> Any idea on what's changed between
> 2.6.21.5 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.
Comment 15 Chuck Ebbert 2007-08-15 18:46:08 EDT
2.6.22.3-59 is building -- it has some ACPI patches that might fix the problem.
It will be available here when it finishes:

http://koji.fedoraproject.org/koji/buildinfo?buildID=13845
Comment 16 James 2007-08-16 05:31:34 EDT
Tried 2.6.22.3-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?
Comment 17 Chuck Ebbert 2007-08-16 13:27:45 EDT
(In reply to comment #16)
> Tried 2.6.22.3-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?

2.6.22.3-61 is building with ACPI debugging enabled in the -debug kernels.
http://koji.fedoraproject.org/koji/buildinfo?buildID=13938
Get the i686-debug kernel and play with the acpi.debug_layer and
acpi.debug_level parameters.  See
/usr/share/doc/kernel-doc-2.6.22/Documentation/kernel-parameters.txt
[from the kernel-doc RPM package.]
Comment 18 James 2007-08-22 04:24:11 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.