Bug 26472 - [noapic] Kernel panic during install on Compaq CL380
[noapic] Kernel panic during install on Compaq CL380
Status: CLOSED RAWHIDE
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
7.1
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Michael K. Johnson
Brock Organ
Florence Gold
:
: 28305 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-02-07 11:25 EST by Barry Roberts
Modified: 2007-04-18 12:31 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-03-19 10:35:10 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Barry Roberts 2001-02-07 11:25:44 EST
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
better way)

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


Reproducible: Always
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:
PIII 800
128MB RAM
Comment 1 Matt Wilson 2001-02-07 15:05:57 EST
there should be a "trace" line with numbers like <0x8123f010>.  Could you copy
that into this report?
Comment 2 Barry Roberts 2001-02-07 18:27:17 EST
I'm not sure this is what you're asking for, so I copied a couple of lines:

[<c015702a>] [<c015eb22>] [<c0157165>] [<c012f536>] [<c0157c9>] [<c0157423>]
[<c01312e8>] [<c0131509>]
[<c01074fe>] [<c0131490>]

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.
Comment 3 Glen Foster 2001-02-08 11:01:11 EST
We (Red Hat) should really try to resolve this before next release.
Comment 4 Need Real Name 2001-02-09 01:34:11 EST
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.
Comment 5 Arjan van de Ven 2001-02-09 06:27:10 EST
"very slow booting" is an ACPI bug.
Comment 6 Nathaniel Daw 2001-02-12 01:22:17 EST
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, daw@cs.cmu.edu
Comment 7 Matt Wilson 2001-02-14 11:31:05 EST
this _may_ be fixed in the latest kernel build.
Comment 8 Barry Roberts 2001-02-14 12:48:29 EST
Is there, or will there be an updated boot.img or iso that I can try before the
next release?
Comment 9 Arjan van de Ven 2001-02-14 15:54:48 EST
daw@cs.cmu.edu:
Could you tell me which of the two ncr/symbios drivers you are using
in the working case ?
Comment 10 Barry Roberts 2001-02-14 16:41:08 EST
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).
Comment 11 Nathaniel Daw 2001-02-14 23:30:08 EST
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
wrong.
Comment 12 Nathaniel Daw 2001-02-14 23:49:14 EST
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.
Comment 13 Nathaniel Daw 2001-02-15 13:35:30 EST
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

http://linux01.gwdg.de/~alatham

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.
Comment 14 Barry Roberts 2001-02-26 13:38:49 EST
I just tried wolverine, and it says "no valid devices were found on which to
create new filesystems"
Comment 15 Michael K. Johnson 2001-02-27 19:38:23 EST
Could you try booting with "noapic" and see if it works around the bug?
Comment 16 Michael K. Johnson 2001-02-28 14:08:22 EST
*** Bug 28305 has been marked as a duplicate of this bug. ***
Comment 17 Michael K. Johnson 2001-02-28 14:22:27 EST
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.
Comment 18 Michael K. Johnson 2001-02-28 14:42:00 EST
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.
Comment 19 Arjan van de Ven 2001-03-27 11:12:15 EST
The  Compaq CL380 noapic bug is fixed as of kernel 0.1.35

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