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
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>] [<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.
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, daw.edu
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 next release?
daw.edu: 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 wrong.
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 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.
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