Bug 84889 - machine hesitating, giving oops, and ksoftirqds overactive after upgrade from 2.4.9-12
Summary: machine hesitating, giving oops, and ksoftirqds overactive after upgrade from...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kernel
Version: 7.1
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-02-23 02:46 UTC by bil kleb
Modified: 2007-04-18 16:51 UTC (History)
0 users

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

Attachments (Terms of Use)
an unclean ksymoops (5.99 KB, text/plain)
2003-02-23 02:48 UTC, bil kleb 		no flags Details
dmesg w/o an oops (14.90 KB, text/plain)
2003-02-23 15:19 UTC, bil kleb 		no flags Details
A dmesg after a longer period of uptime (15.05 KB, text/plain)
2003-02-26 14:25 UTC, bil kleb 		no flags Details
ksymoops output of recent oops (5.90 KB, text/plain)
2003-04-10 15:29 UTC, bil kleb 		no flags Details
View All

Description bil kleb 2003-02-23 02:46:15 UTC 
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003

Description of problem:
After upgrading to the 2.4.18 series kernels from 2.4.9-12
our http://supermicro.com/PRODUCT/MotherBoards/RCC_LE/370dl3.htm
dual Pentium 3 machine has been leaving 'wait_on_irq' oops in the
logs for both processors, the ksoftirqd_CPU[0-1] processes have
been racking up abnormal quantities of time, and the machine will go
unresponsive to the keyboard for tens of seconds at a time.

We've swapped out the CPUs, memory, broken an IDE software raid,
and tried various kernels in the 2.4.18 series (currently running
2.4.18-24.7.xsmp) all to no avail.


How reproducible:
Always

Steps to Reproduce:
1. shutdown machine
2. reboot

Actual Results:  If one waits for about a hour, things start going south in terms of
keyboard responsiveness. Then every few days it'll drop an oops
in the log and the keyboard responsiveness will progressively
get worse.

Expected Results:  No hesitations or oops
Comment 1 bil kleb 2003-02-23 02:48:43 UTC 
Created attachment 90284 [details]
an unclean ksymoops
Comment 2 Arjan van de Ven 2003-02-23 10:13:45 UTC 
can you post a dmesg of the machine ?
Comment 3 bil kleb 2003-02-23 15:19:20 UTC 
Created attachment 90293 [details]
dmesg w/o an oops

The machine's only been up 12 hours and hasn't lobbed an oops yet.
Comment 4 Arjan van de Ven 2003-02-23 15:28:41 UTC 
one interesting test would be to use aic7xxx_old instead of aic7xxx
2.4.9 used the old driver by default
Comment 5 bil kleb 2003-02-26 14:25:07 UTC 
Created attachment 90375 [details]
A dmesg after a longer period of uptime

Here's a dmesg after 3 days worth of uptime
and we now have

 54:13 ksoftirqd_CPU0
 66:58 ksoftirqd_CPU1
Comment 6 bil kleb 2003-03-24 03:14:13 UTC 
Is there a "step by step" somewhere for trying the aic7xxx swap?
Comment 7 bil kleb 2003-04-04 21:35:16 UTC 
Replaced the last piece of hardware: the motherboard, and still
the same "wait_on_irq" oops.  <sigh>
Comment 8 bil kleb 2003-04-10 15:29:05 UTC 
Created attachment 91059 [details]
ksymoops output of recent oops
Comment 9 Bugzilla owner 2004-09-30 15:40:33 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.