Red Hat Bugzilla – Bug 87857
Kernel Panic: Attempted to kill the idle task! - 2.4.20-8smp
Last modified: 2007-04-18 12:52:42 EDT
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
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):
Created attachment 90862 [details]
dmesg output from working non-smp kernel.
As reported by email@example.com, 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.
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]
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
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/