Red Hat Bugzilla – Bug 26472
[noapic] Kernel panic during install on Compaq CL380
Last modified: 2007-04-18 12:31:16 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; 0.7) Gecko/20010109
Just before installing packages, I get:
Code: f6 01 01 0f 85 d9 fd ff ff 8b 00 a9 01 00 00 00 0f 84 cc fd
Kernel panic: Aiee, killing interrupt handler!
In interrupt handler - not syncing
(or something really close -- I hand copied it because I don't know any
This machine was running RH 7.0, and it's twin currently is.
I tried normal install, text, and nofb with different install types
(custom, server, workstation), and all do the same.
Dunno if it makes any difference, but in the first stage, it seems like it
takes a LONG time (more than a minute) telling me it's loading the
sym53c8xx driver. Hmm. lsmod shows ncr53c8xx on the running 7.0 machine,
but no sym53c8xx
Steps to Reproduce:
1. Boot fisher CD from fisher-i386-disc1.iso
2. Select lang, mouse, time zone, eth0, eth1, config X, packages, etc.
3. Briefly see message like "about to install packages"
4. Stare in dismay at kernel panic
Actual Results: kernel panic
Expected Results: Packages install
Standard cl380 hardware:
there should be a "trace" line with numbers like <0x8123f010>. Could you copy
that into this report?
I'm not sure this is what you're asking for, so I copied a couple of lines:
[<c015702a>] [<c015eb22>] [<c0157165>] [<c012f536>] [<c0157c9>] [<c0157423>]
The screen is full of this kind of output, and and I see more scroll off before
it stops. If this is not what you need, I'll try to get it if you can tell me how.
We (Red Hat) should really try to resolve this before next release.
I have *exact* same problem except that mine occurs even earlier in the
install. I've tried nofb, text, and graphic install, they all end at about the
same way, The system boots up *very* slowly and I get a kernel panic during the
hardware detection phase. It sees my video card, and mouse, and then fails as
above when anaconda goes to look for additional hardware.
I'm running Pentium III 450, 256 Meg Ram, 8 Gig HD, Microsoft Intellimouse
Explorer, and a Vodoo 5, running RH 7.
"very slow booting" is an ACPI bug.
I have yet another similar problem with a kernel panic freezing the installer on
my sort of homemade generic k6-3 computer, just after the point I hit "update"
(after detecting mouse & keyboard). The panic screen looks about the same as
described above (if I'm running in text mode -- in graphics mode I just get a
lockup) - it starts with "Oops: 0002" and ends with "Kernel panic: Aieee,
killing interrupt handler, etc." I could copy down the rest of the numbers if
any of them are useful.
Fwiw, I have 128mb ram, k6-3 450, asus p5a motherboard, onboard ess solo1 sound,
voodoo 3 video, logitech ps2 trackman marble+, creative dxr3 dvd decoder w/ ide
dvd, and a chepo tekram scsi card w/yamaha cdrw.
I also get the very slow boot with the message about the sym53c8xx driver
(twice!) even though my scsi is AM53C974. kernel 2.4.0 (homebuilt) works great
for me in redhat 7.
Please let me know if I can provide any further information that would be
helpful, or run further tests, email@example.com
this _may_ be fixed in the latest kernel build.
Is there, or will there be an updated boot.img or iso that I can try before the
Could you tell me which of the two ncr/symbios drivers you are using
in the working case ?
I'm not sure I understand what you're asking for. The working identical
hardware is running 7.0. lsmod in 7.0 shows the ncr53c8xx driver, NOT the
sym53c8xx driver that fisher loads (at least for installation).
Hey, if you're asking me -- I don't have either ncr or symbios scsi; I have a
tekram adapter (tk370 I think). Shows up in /proc/pci as:
Advanced Micro Devices [AMD] 53c974 [PCscsi]
which I'm driving with AM53C974.o when I run kernel 2.4 under Redhat 7.0. I
believe that when I run the 7.1 installer, it talks about loading the symbios
scsi driver (even though I dont have one) a couple of times during the VERY LONG
boot process, just as others here have noted in this thread. I don't know
whether this is related to the later crash of course, but it seems common among
the other posts here. I will reboot to verify this fact and post again if I am
Sorry -- I was wrong in my previous posts. My scsi adapter is a Tekram DC390 and
the module the installer talks about loading -- tmscsim.o -- is in fact a
legitimate alternative to the generic AMD driver I am using to drive the card. I
just tried that module under redhat 7.0, kernel 2.4 and it seems to work just
fine, no panic. So I don't know what is causing my installer panic, though the
fact that they're choosing a different scsi driver than I customarily use is
still a bit suspicious I guess. If it would be helpful I can try the install
with the scsi adapter unplugged to rule out that possbility.
I have discovered the cause of my panic. It goes away if I unplug one of my hard
drives, which contains a single raw disk partition encrypted with ppdd, which is
a loopback-based filesystem encryption program
So I guess what happens is that when I hit update and anaconda searches for
candidate partitions to update, it sees the encrypted one and for some reason
the kernel mishandles it and panics.
Should I open a separate bug on this? FWIW this partition causes no problem for
me in linux 2.4 normally, even though i don't have the ppdd driver installed --
I can even try to mount it and I just get an error message about the magic number.
I just tried wolverine, and it says "no valid devices were found on which to
create new filesystems"
Could you try booting with "noapic" and see if it works around the bug?
*** Bug 28305 has been marked as a duplicate of this bug. ***
Sorry, "noapic" won't help at install time.
We are testing on a 380 right now. It worked on a 580
except that the SMP kernel required "noapic" to work,
but that should be a completely separate issue.
With our current QA tree we have made progress, the 380 that used
to fail with the "no valid devices were found..." message now
fails the same way as our 580 does with that tree; that is, it
does not work in SMP mode unless "noapic" is selected.
The Compaq CL380 noapic bug is fixed as of kernel 0.1.35