Bug 87857 - Kernel Panic: Attempted to kill the idle task! - 2.4.20-8smp
Kernel Panic: Attempted to kill the idle task! - 2.4.20-8smp
Status: CLOSED WONTFIX
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
9
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Arjan van de Ven
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-04-03 02:54 EST by Chris Hubick
Modified: 2007-04-18 12:52 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-09-30 11:40:44 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
dmesg output from working non-smp kernel. (10.49 KB, text/plain)
2003-04-03 02:55 EST, Chris Hubick
no flags Details
dmesg from working 2.4.21-pre3-ac5 smp kernel (11.19 KB, text/plain)
2003-04-05 23:35 EST, Chris Hubick
no flags Details
The oops (902 bytes, text/plain)
2003-05-06 06:37 EDT, Anders Carlsson
no flags Details

  None (edit)
Description Chris Hubick 2003-04-03 02:54:50 EST
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
Comment 1 Chris Hubick 2003-04-03 02:55:57 EST
Created attachment 90862 [details]
dmesg output from working non-smp kernel.
Comment 2 Michael Wolfinger 2003-04-05 04:01:41 EST
As reported by chris@hubick.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.

Michael
Comment 3 Chris Hubick 2003-04-05 22:18:41 EST
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.
Comment 4 Chris Hubick 2003-04-05 23:35:43 EST
Created attachment 90930 [details]
dmesg from working 2.4.21-pre3-ac5 smp kernel
Comment 5 Michael Wolfinger 2003-04-09 03:18:25 EDT
Unfortunately, the kernel panic does also occur with the new 2.4.20-9smp kernel 
Comment 6 Anders Carlsson 2003-05-06 06:37:45 EDT
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
Comment 7 Anders Carlsson 2003-05-06 06:54:09 EDT
(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.
Comment 8 Arjan van de Ven 2003-05-06 07:04:08 EDT
what modules are in use ?
it looks like something installed an idle handler and then unloaded it, incorrectly.
Comment 9 Anders Carlsson 2003-05-06 13:03:34 EDT
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)
Comment 10 Peter van Egdom 2003-05-29 10:50:22 EDT
You can get a list of the loaded modules with the command "/sbin/lsmod".
Comment 11 Alan Cox 2003-06-05 12:50:20 EDT
Does "apm=off" help as an option here ?
Comment 12 Ivo 2003-06-16 04:42:16 EDT
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!
Comment 13 Yi Chu 2004-05-10 12:27:09 EDT
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.
Comment 14 Bugzilla owner 2004-09-30 11:40:44 EDT
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/

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