Bug 151210 - kswapd kernel oopses with multithreaded applications
Summary: kswapd kernel oopses with multithreaded applications
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
(Show other bugs)
Version: 2
Hardware: All Linux
Target Milestone: ---
Assignee: Dave Jones
QA Contact: Brian Brock
: 151211 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2005-03-16 00:48 UTC by Bevan Bennett
Modified: 2015-01-04 22:17 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-04-16 04:26:25 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Combined syslog grepped for oopsing process (12.96 KB, text/plain)
2005-03-16 00:53 UTC, Bevan Bennett
no flags Details
Oops syslog details for one system "vanadium" (10.41 KB, text/plain)
2005-03-16 01:01 UTC, Bevan Bennett
no flags Details
Combined syslog grepped for kernel versions (10.19 KB, text/plain)
2005-03-16 01:08 UTC, Bevan Bennett
no flags Details

Description Bevan Bennett 2005-03-16 00:48:14 UTC
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:

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

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-16 00:52:29 UTC
*** Bug 151211 has been marked as a duplicate of this bug. ***

Comment 2 Bevan Bennett 2005-03-16 00:53:29 UTC
Created attachment 112040 [details]
Combined syslog grepped for oopsing process

Comment 3 Bevan Bennett 2005-03-16 01:01:13 UTC
Created attachment 112041 [details]
Oops syslog details for one system "vanadium"

Comment 4 Bevan Bennett 2005-03-16 01:08:21 UTC
Created attachment 112042 [details]
Combined syslog grepped for kernel versions

Comment 5 Dave Jones 2005-04-16 04:26:25 UTC
Fedora Core 2 has now reached end of life, and no further updates will be
provided by Red Hat.  The Fedora legacy project will be producing further kernel
updates for security problems only.

If this bug has not been fixed in the latest Fedora Core 2 update kernel, please
try to reproduce it under Fedora Core 3, and reopen if necessary, changing the
product version accordingly.

Thank you.

Comment 6 Bevan Bennett 2005-04-19 00:17:11 UTC
Congratulations Kernel! It turns out that, in a roundabout way, there was a
hardware problem effecting my entire machine room. It seems our power out here
is not very good and that, combined with a few too many servers on the same
circut, caused hardware flutter and kernel Oopsing under load.  The
multi-threaded corrolation came in because those apps were more likely to
generate near maximum CPU utilization. Not the easiest problem to diagnose...

I recently got in a huge shipment of UPSs, moved all the servers to them, and
we've been crash free for a week now. (*knocks on wood*)

Closing the bug with appropriate commentary.

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