lkml.org 
[lkml]   [1996]   [Aug]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectOopses in 2.0.9
The machine was up and running 2.0.9 for several days before spewing these
oopses, then locking _hard_ about 30 minutes later.

The machine is a P100 with 32 megs RAM. The drives are a 4GB and a 1GB
SCSI hanging off an Adaptec 1542. The machine is generally under moderate
load (6-10 or so loadavg) and serves as the server for our ISP. I'll
probably try 2.0.10 later today.

The kernel was compiled with GCC 2.7.2, libc 5.2.18 and binutils 2.6.0.14.

In the first one, the code dump is obviously messed. This appears to
have been caused by the exception handler managing to strangle itself.

Unable to handle kernel paging request at virtual address d191ae8c
current->tss.cr3 = 01dd6000,
*pde = 00000000
Oops: 0000
CPU: 0
EIP: 0010:[<1191ae8c>]
EFLAGS: 00010246
eax: 0000002b ebx: 01dd7e6c ecx: 001d7b60 edx: 1191ae8c
esi: 0000002b edi: 01ff15b8 ebp: 00000080 esp: 01dd7c0c
ds: 0018 es: 0018 fs: 0018 gs: 002b ss: 0018
Process sh (pid: 27731, process nr: 42, stackpage=01dd7000)
Stack: 00128a69 01ff15b8 01dd7c38 01dd7e6c 00000080 00000000 01ff15b8 0009ef18
01811914 0000002b fffffff8 00a70001 00000000 00000000 00010000 00000000
01811914 00000217 00129c24 01e97000 00000000 0012a13c 01e97000 01ff15b8
Call Trace: [<00128a69>] [<00129c24>] [<0012a13c>] [<0012e179>] [<00123ba4>] [<00123ad6>] [<0015d2f6>]
[<00128a69>] [<00128ac6>] [<00150016>] [<00128f0b>] [<001306c8>] [<001306eb>] [<00128f0b>] [<00129161>]
[<00129186>] [<00150016>] [<00109bce>] [<0010a442>]
Code: <1>
Using `../System.map' to map addresses to symbols.

Trace: 128a69 <read_exec+f9/168>
Trace: 129c24 <putname+c/10>
Trace: 12a13c <namei+3c/48>
Trace: 12e179 <load_elf_binary+31d/b28>
Trace: 123ba4 <bread+18/7c>
Trace: 123ad6 <__brelse+22/44>
Trace: 15d2f6 <ext2_update_inode+2ae/2c0>
Trace: 128a69 <read_exec+f9/168>
Trace: 128ac6 <read_exec+156/168>
Trace: 150016 <igmp_rcv+6e/ec>
Trace: 128f0b <search_binary_handler+3f/150>
Trace: 1306c8 <do_load_script+1ec/200>
Trace: 1306eb <load_script+f/14>
Trace: 128f0b <search_binary_handler+3f/150>
Trace: 129161 <do_execve+145/1b8>
Trace: 129186 <do_execve+16a/1b8>
Trace: 150016 <igmp_rcv+6e/ec>
Trace: 109bce <sys_execve+32/50>
Trace: 10a442 <system_call+52/80>

Manual disassembly from gdb (transcribed by hand):
0x128a69 <read_exec+249>: movl %eax,0x24(%esp,1)
0x128a6d <read_exec+253>: addl $0x10,%esp
0x128a70 <read_exec+256>: movl 0x10(%esp,1),%esi
0x128a74 <read_exec+260>: movw %si,%fs
0x128a77 <read_exec+263>: jmp 0x128ab3 <read_exec+323>
0x128a79 <read_exec+265>: leal 0x0(%esi),%esi
0x128a7c <read_exec+268>: pushl %ebp

Unable to handle kernel paging request at virtual address d191ae8c
current->tss.cr3 = 01dd6000,
*pde = 00000000
Oops: 0000
CPU: 0
EIP: 0010:[<0010a99b>]
EFLAGS: 00010202
eax: 00000010 ebx: 0000002b ecx: 1191ae8c edx: 01de1c0c
esi: 00000000 edi: 01dd8000 ebp: 01dd7bd0 esp: 01dd7b78
ds: 0018 es: 0018 fs: 0010 gs: 002b ss: 0018
Process sh (pid: 27731, process nr: 42, stackpage=01dd7000)
Stack: 0000002b 00000000 d191ae8c 01dd7bd0 00000000 02800000 03000000 02800000
001b0018 0010fcff 001b981b 01dd7bd0 00000000 0010fa6c 0000002b 01ff15b8
00000080 005fd5b8 00000000 0010a5cd 01dd7bd0 00000000 01dd7e6c 001d7b60
Call Trace: [<02800000>] [<03000000>] [<02800000>] [<001b0018>] [<0010fcff>] [<0010fa6c>] [<0010a5cd>]
[<00128a69>] [<00129c24>] [<0012a13c>] [<0012e179>] [<00123ba4>] [<00123ad6>] [<0015d2f6>] [<00128a69>]
[<00128ac6>] [<00150016>] [<00128f0b>] [<001306c8>] [<001306eb>] [<00128f0b>] [<00129161>] [<00129186>]
[<00150016>] [<00109bce>] [<0010a442>]
Code: 64 8a 04 0e 0f a1 88 c2 81 e2 ff 00 00 00 89 54 24 10 52 68
Using `../System.map' to map addresses to symbols.

>>EIP: 10a99b <die_if_kernel+27f/2c0>
Trace: 2800000
Trace: 3000000
Trace: 2800000
Trace: 1b0018 <scsi_ioctl+8/22c>
Trace: 10fcff <do_page_fault+293/29c>
Trace: 10fcff <do_page_fault+293/29c>
Trace: 10a5cd <error_code+3d/50>
Trace: 128a69 <read_exec+f9/168>
Trace: 129c24 <putname+c/10>
Trace: 12a13c <namei+3c/48>
Trace: 12e179 <load_elf_binary+31d/b28>
Trace: 123ba4 <bread+18/7c>
Trace: 123ad6 <__brelse+22/44>
Trace: 15d2f6 <ext2_update_inode+2ae/2c0>
Trace: 128a69 <read_exec+f9/168>
Trace: 128ac6 <read_exec+156/168>
Trace: 150016 <igmp_rcv+6e/ec>
Trace: 128f0b <search_binary_handler+3f/150>
Trace: 1306c8 <do_load_script+1ec/200>
Trace: 1306eb <load_script+f/14>
Trace: 128f0b <search_binary_handler+3f/150>
Trace: 129161 <do_execve+145/1b8>
Trace: 129186 <do_execve+16a/1b8>
Trace: 150016 <igmp_rcv+6e/ec>
Trace: 109bce <sys_execve+32/50>
Trace: 10a442 <system_call+52/80>

Code: 10a99b <die_if_kernel+27f/2c0> movb %fs:(%esi,%ecx,1),%al
Code: 10a99f <die_if_kernel+283/2c0> popl %fs
Code: 10a9a1 <die_if_kernel+285/2c0> movb %al,%dl
Code: 10a9a3 <die_if_kernel+287/2c0> andl $0xff,%edx
Code: 10a9a9 <die_if_kernel+28d/2c0> movl %edx,0x10(%esp,1)
Code: 10a9ad <die_if_kernel+291/2c0> pushl %edx
Code: 10a9ae <die_if_kernel+292/2c0> pushl $0x90909000


You will be surprised by a loud noise.



\
 
 \ /
  Last update: 2005-03-22 13:37    [W:0.032 / U:2.500 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site