[1.] One line summary of the problem:
Unable to handle kernel paging request at virtual address c61d63e8
[2.] Full description of the problem/report:
I was testing IBM DB2 with one of our databases (~500M). When running a
program against it I got the oops below. The machine in question has only
32M RAM, but 392244 kB swap. I was not trying to push the memory usage to
any extreme levels, the oops came on one of the simpler sql statements,
but there was some swapping going on.
DB2 uses "a lot of" shared memory (ipc). Don't know if that might be
helpful.
[3.] Keywords (i.e., modules, networking, kernel):
kernel mm?
[4.] Kernel version (from /proc/version):
Linux version 2.2.2 (root@cola.svenskatest.se) (gcc version 2.8.1) #1 Tue
Feb 23 13:23:23 CET 1999
[5.] Output of Oops.. message (if applicable) with symbolic information
resolved (see Documentation/oops-tracing.txt)
Options used: -V (default)
-o /lib/modules/2.2.2/ (default)
-k /proc/ksyms (default)
-l /proc/modules (default)
-m /boot/System.map-2.2.2 (specified)
-c 1 (default)
Unable to handle kernel paging request at virtual address c61d63e8
current->tss.cr3 = 00101000, %cr3 = 00101000
*pde = 00000000
Oops: 0000
CPU: 0
EIP: 0010:[<c0123b90>]
EFLAGS: 00010282
eax: c61d63c4 ebx: c119b540 ecx: c1e9296c edx: 00000001
esi: c1e9296c edi: c1eed5c0 ebp: 00001000 esp: c1845f54
ds: 0018 es: 0018 ss: 0018
Process db2sysc (pid: 8084, process nr: 64, stackpage=c1845000)
Stack: c1393160 c0124b7c c119b540 c119b540 c17680c0 41599000 c011ba06 c119b540
c1393160 c1844000 40239a00 bfffc4a8 c1768080 c0112413 c1393160 c1393160
c1393160 c01169bf c1393160 c1844000 080505a0 40239a00 bfffc4a8 41450620
Call Trace: [<c0124b7c>] [<c011ba06>] [<c0112413>] [<c01169bf>] [<c0116b2f>]
[<c01095a4>]
Code: 8b 40 24 85 c0 74 07 53 56 ff d0 83 c4 08 c7 43 08 00 00 00
>>EIP: c0123b90 <__fput+14/48>
Trace: c0124b7c <fput+18/44>
Trace: c011ba06 <exit_mmap+be/10c>
Trace: c0112413 <mmput+1b/34>
Trace: c01169bf <do_exit+d7/238>
Trace: c0116b2f <sys_exit+f/10>
Trace: c01095a4 <system_call+34/40>
Code: c0123b90 <__fput+14/48> 00000000 <_EIP>:
Code: c0123b90 <__fput+14/48> 0: 8b 40 24
movl 0x24(%eax),%eax
Code: c0123b93 <__fput+17/48> 3: 85 c0
testl %eax,%eax
Code: c0123b95 <__fput+19/48> 5: 74 07
je e <_EIP+0xe> c0123b9e <__fput+22/48>
Code: c0123b97 <__fput+1b/48> 7: 53
pushl %ebx
Code: c0123b98 <__fput+1c/48> 8: 56
pushl %esi
Code: c0123b99 <__fput+1d/48> 9: ff d0
call *%eax
Code: c0123b9b <__fput+1f/48> b: 83 c4 08
addl $0x8,%esp
Code: c0123b9e <__fput+22/48> e: c7 43 08 00 00
movl $0x0,0x8(%ebx)
Code: c0123ba3 <__fput+27/48> 13: 00 00
(Grmbl, who ever made the ksymoops output wider than 80 chars? ;)
[6.] A small shell script or example program which triggers the
problem (if possible)
[7.] Environment
[7.1.] Software (add the output of the ver_linux script here)
-- Versions installed: (if some fields are empty or looks
-- unusual then possibly you have very old versions)
Linux tux.svenskatest.se 2.2.2 #1 Tue Feb 23 13:23:23 CET 1999 i586 unknown
Kernel modules 2.1.55
Gnu C 2.7.2.3
Binutils 2.9.1.0.19
Linux C Library ..
ldd: unrecognized option `-v'
Try `ldd --help' for more information.
Linux C++ Library 2.7.2
Procps 1.2.4
Mount 2.7f
Net-tools (1998-12-05)
Kbd 0.94
Sh-utils 1.16
Worth noting is that no modules are used, that the ldd error is strange (?)
db2inst1@tux:~>rpm -qf `which ldd`
glibc-2.0.7-19
[7.2.] Processor information (from /proc/cpuinfo):
processor : 0
vendor_id : GenuineIntel
cpu family : 5
model : 2
model name : Pentium 75 - 200
stepping : 12
cpu MHz : 132.956963
fdiv_bug : no
hlt_bug : no
sep_bug : no
f00f_bug : yes
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr mce cx8
bogomips : 53.04
[7.3.] Module information (from /proc/modules):
db2inst1@tux:~>cat /proc/modules
db2inst1@tux:~>
[7.4.] SCSI information (from /proc/scsi/scsi)
N/A
[7.5.] Other information that might be relevant to the problem
(please look in /proc and include all information that you
think to be relevant):
[X.] Other notes, patches, fixes, workarounds:
I have repeated the problem, so I'm going to try it with 2.2.3-pre1.
Maybe the machine is cursed? or allergic to databases? :)
I got an OOM (which killed init amongst other things ...) when sending a
"tricky" sql statement to postgresql. I didn't get any info on it, and as
I understand it the oom problems have been pushed to 2.3 (?), so I never
reported it.
/Urban
--- Urban Widmark urban@svenskatest.se Svenska Test AB +46 90 71 71 23
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/