Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 87857 - Kernel Panic: Attempted to kill the idle task! - 2.4.20-8smp
Summary: Kernel Panic: Attempted to kill the idle task! - 2.4.20-8smp
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kernel
Version: 9
Hardware: i686
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Arjan van de Ven
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2003-04-03 07:54 UTC by Chris Hubick
Modified: 2007-04-18 16:52 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2004-09-30 15:40:44 UTC


Attachments (Terms of Use)
dmesg output from working non-smp kernel. (deleted)
2003-04-03 07:55 UTC, Chris Hubick
no flags Details
dmesg from working 2.4.21-pre3-ac5 smp kernel (deleted)
2003-04-06 04:35 UTC, Chris Hubick
no flags Details
The oops (deleted)
2003-05-06 10:37 UTC, Anders Carlsson
no flags Details

Description Chris Hubick 2003-04-03 07:54:50 UTC
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 07:55:57 UTC
Created attachment 90862 [details]
dmesg output from working non-smp kernel.

Comment 2 Michael Wolfinger 2003-04-05 09:01:41 UTC
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-06 03:18:41 UTC
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-06 04:35:43 UTC
Created attachment 90930 [details]
dmesg from working 2.4.21-pre3-ac5 smp kernel

Comment 5 Michael Wolfinger 2003-04-09 07:18:25 UTC
Unfortunately, the kernel panic does also occur with the new 2.4.20-9smp kernel 

Comment 6 Anders Carlsson 2003-05-06 10:37:45 UTC
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 10:54:09 UTC
(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 11:04:08 UTC
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 17:03:34 UTC
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 14:50:22 UTC
You can get a list of the loaded modules with the command "/sbin/lsmod".

Comment 11 Alan Cox 2003-06-05 16:50:20 UTC
Does "apm=off" help as an option here ?


Comment 12 Ivo 2003-06-16 08:42:16 UTC
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 16:27:09 UTC
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 15:40:44 UTC
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.