From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030314 Description of problem: I get a "Kernel Panic: Attempted to kill the idle task!" when booting the 2.4.20-8smp kernel. The system boots fine using the non-smp kernel. I am using the stock kernel binaries shipped with RH9 on a dual Pentium III 733Mhz machine. It booted fine using the smp kernel shipped with RH8 (I hadn't upgraded kernel from what shipped initially with RH8). This was a clean install of RH9, replacing 8. It says: "Kernel Panic: Attempted to kill the idle task!" it also says on a separate line "In idle task - not syncing". It also printed a call trace, which had cpu_idle, call_console_drivers, and printk in it. The motherboard is an MSI model 694D Pro (MS-6321). The manual says it is based on the VIA Apollo Pro133A VT82C694X (510BGA) chipset. It also uses a VT82C686A (352BGA) PSIPC PCI Super-I/O Integrated Peripheral Controller. Since output quickly scrolls off the screen... it is hard to tell what exactly it was doing at the time... but I think the panic was shortly after printing out the "Floppy drive(s): fd0 is 1.44M" line. I can try to provide more details of the error, or my system, if someone can indicate what is needed. Version-Release number of selected component (if applicable): 2.4.20-8smp How reproducible: Always
Created attachment 90862 [details] dmesg output from working non-smp kernel.
As reported by chris, I encountered the same problem with my Dual-PIII 733MHz, MSI 694D Pro MS-6321. Also, the system runs stable with the (single CPU) 2.4.20-8 kernel. RH9 runs stable for me with a 2.4.21-pre3-ac5 with smp support. Michael
Confirming 2.4.21-pre3-ac5 smp works. I first tried vanilla kernel.org 2.4.20, which did NOT work, same problem. So I tried the AC kernel Michael recommended, which seems to be working fine so far.
Created attachment 90930 [details] dmesg from working 2.4.21-pre3-ac5 smp kernel
Unfortunately, the kernel panic does also occur with the new 2.4.20-9smp kernel
Created attachment 91514 [details] The oops This is the oops I get when booting (and then a panic since the kernel tries to kill the idle task). After a couple of tries I was able to boot the SMP kernel without getting a panic. I'm not a kernel expert but it sounds like some sort of race condition to me
(Sorry about the spam) After some further investigation, I was able to successfully boot without getting a panic when specifying "idle=poll" to the kernel.
what modules are in use ? it looks like something installed an idle handler and then unloaded it, incorrectly.
How do I check what modules are in use? (When I debugged this some time ago I renamed the module directory temporary so I'd be sure that no modules were loaded, but I still got the oops)
You can get a list of the loaded modules with the command "/sbin/lsmod".
Does "apm=off" help as an option here ?
Some more points: - The kernel panic still happens with kernel-smp-2.4.20-18.9 - boot option "apm=off" does not help, nor does "noapic" - the "idle=poll" as mentioned by Anders Carlsson works for me as well - the only modules on the initrd are jdb.o and ext3.o - my machine has 1.5GB of memory, another afflicted machine has 1GB booting with less than 1GB of memory, e.g. with mem=960M also works!
I encountered the same problem with my Dual-PIII 800MHz, MSI 694D Pro MS-6321. Both the 2.4.20-8smp and 2.4.20-31.9smp Kernel got oops during boot. "idle=poll" works fine without oops. I also tried disabling BIOS USB keyboard and USB mouse support as mentioned in "http://kerneltrap.org/node/view/2943". And this time both smp kernel boot and worked fine without the need of "idle=poll". Also, by disabling BIOS USB keyboard and USB mouse support, I sovled the Fedora Core 2.4.22-1.2115nptlsmp kernel booting oops.
Thanks for the bug report. However, Red Hat no longer maintains this version of the product. Please upgrade to the latest version and open a new bug if the problem persists. The Fedora Legacy project (http://fedoralegacy.org/) maintains some older releases, and if you believe this bug is interesting to them, please report the problem in the bug tracker at: http://bugzilla.fedora.us/