Bug 169525 - Random unable to handle kernel paging request resulting in kernel oops
Random unable to handle kernel paging request resulting in kernel oops
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
4
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Dave Jones
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-09-29 07:54 EDT by Fred van Lieshout
Modified: 2015-01-04 17:22 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-09-29 19:30:27 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)

  None (edit)
Description Fred van Lieshout 2005-09-29 07:54:49 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.7) Gecko/20050414 Firefox/1.0.3

Description of problem:
During nightly builds of our source code on a dual CPU machine, in several chroot environments on ext3 as well as reiserfs partitions, the system randomly (i.e. not during execution of a particular program or access to a particular mounted partition) hangs in a kernel oops once a week.


Version-Release number of selected component (if applicable):
kernel-2.6.12-1.1398_FC4.rootsmp

How reproducible:
Sometimes

Steps to Reproduce:
Difficult to reproduce. We build our software every night for various platforms using chroot environments. The system hangs every once a week.

Actual Results:  System ends up in a kernel oops.

Expected Results:  System should have kept running.

Additional info:

The following messages were shown on the console:
Unable to handle kernel paging request at virtual address 00b83488
Printing eip:
c03057a2
*pde=21d37001
Oops: 000[#1]
SMP
CPU:1
EIP: 0060:[<c03057a2>]
EIFLAGS: 000126d6
EIP is at schedule+0x412/0xc5e

Call trace:
load_elf_binary+0x0/0xd95
search_binary_handler+0x94/0x22f
do_execve+0x20b/0x23c
sys_execve+030/0x73
syscall_call+0x7/0xb
___________________________

/proc/cpuinfo 
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 15
model           : 2
model name      : Intel(R) Xeon(TM) CPU 3.06GHz
stepping        : 5
cpu MHz         : 3066.383
cache size      : 512 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 2
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse
2 ss ht tm pbe cid xtpr
bogomips        : 6078.46

processor       : 1
vendor_id       : GenuineIntel
cpu family      : 15
model           : 2
model name      : Intel(R) Xeon(TM) CPU 3.06GHz
stepping        : 5
cpu MHz         : 3066.383
cache size      : 512 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 2
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse
2 ss ht tm pbe cid xtpr
bogomips        : 6127.61
Comment 1 Dave Jones 2005-09-29 19:30:27 EDT
this kernel is quite old now, please retry with a newer update.
(There's actually one in progress of being pushed right now, which you can get
early at http://people.redhat.com/davej/kernels/Fedora/FC4/)
Comment 2 Fred van Lieshout 2005-09-30 02:02:34 EDT
Ok, we'll give it a try and let you know the results. Thanks.

Comment 3 Fred van Lieshout 2005-10-06 07:33:04 EDT
Things are looking good, but we have to test longer to be sure the problem has 
gone. A nice side effect is that we don't see the "unknown error 525" messages 
anymore when performing NFS file operations (but that's another issue).

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