Bug 151211 - kswapd kernel oopses with multithreaded applications
kswapd kernel oopses with multithreaded applications
Status: CLOSED DUPLICATE of bug 151210
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
2
All Linux
medium Severity high
: ---
: ---
Assigned To: Dave Jones
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-03-15 19:50 EST by Bevan Bennett
Modified: 2015-01-04 17:17 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-02-21 14:08:18 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Bevan Bennett 2005-03-15 19:50:45 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20041020

Description of problem:
Across a variety of server hardware (IBM eServer 330, Dell PE1750, Dell PE2650, Dell PE2550, AMD64 dual opteron system) I've been seeing a large number of kernel Oopses over the past several weeks.  The systems will keep running at first, but usually end up locking up once Oopsing has started.  Looking over my logs, I have 134 logged oopses since Feb 28th spread over 28 different systems.

Of those 134, 49 appear to be initiating with kswapd; the others are reported from somewhat random other processes (often multithreaded java-based applications) after a kswapd oops has occurred on the running kernel.

I've read through the current list of 'kernel oops' bugs (I really have) and haven't found anything substantially similar, but I've missed dups before, and I apologize if that's the case. If nothing else, I have a large quantity of data available on these oopses.

Version-Release number of selected component (if applicable):
kernel-2.6.10-1.9_FC2smp  kernel-2.6.10-1.14_FC2smp  2.6.10-1.770_FC2smp

How reproducible:
Sometimes

Steps to Reproduce:
1. Run memory intensive, multithreaded applications
2. Wait
3.
  

Actual Results:  Kernel Oopses and eventual hang.

Expected Results:  User app can crash if neccessary, but the kernel should go on.

Additional info:

I'll attach one set of representative log messages, plus a combined syslog listing grepped for 'Process: ' in case someone would like to request others.
Comment 1 Bevan Bennett 2005-03-15 19:52:12 EST

*** This bug has been marked as a duplicate of 151210 ***
Comment 2 Red Hat Bugzilla 2006-02-21 14:08:18 EST
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.

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