I upgraded my old Linux system to glibc / kernel 2.2.1.
Now I constantly obtain Ooops messages.
So I compiled ksymoops and run it with the Ooops log message
as input. Please find its output at the end of this mail.
Hardware:
****************************************************************************************************************
Gigbyte GA 586HX Rev 1.3 with additional tag ram
P 166
96 MB Edo Ram
SB 16
Matrox Mystique 4MB
Zip Drive parallel
Printer at separate IO card
IDE Hard disk and CdRom
serial Modem
Software:
****************************************************************************************************************
p133:/root # uname -r
2.2.1
p133:/root # insmod -V
insmod version 2.1.121
p133:/root # gcc --version
2.7.2.3
p133:/root # ld -v
GNU ld version 2.9.1 (with BFD 2.9.1.0.19)
p133:/root # ls -l /lib/libc.so.*
lrwxrwxrwx 1 root root 13 Dec 15 1997 /lib/libc.so.4 -> libc.so.4.7.6
-rwxr-xr-x 1 root root 634880 Apr 29 1996 /lib/libc.so.4.7.6
lrwxrwxrwx 1 root root 14 Jan 31 21:12 /lib/libc.so.5 -> libc.so.5.4.46
-rwxr-xr-x 1 root root 1803483 Nov 14 1997 /lib/libc.so.5.4.33
-rwxr-xr-x 1 bin bin 1427975 Jun 20 1998 /lib/libc.so.5.4.46
-rwxr-xr-x 1 root root 1787712 Nov 16 1997 /lib/libc.so.5.4.7
lrwxrwxrwx 1 root root 13 Feb 26 16:45 /lib/libc.so.6 -> libc-2.0.6.so
p133:/root # ldd -v
ldd: version 1.9.9
p133:/root # ls -l /usr/lib/libg++.so.*
lrwxrwxrwx 1 root root 17 Feb 28 02:14 /usr/lib/libg++.so.2.7.2 -> libg++.so.2.7.2.8
-rwxr-xr-x 1 root root 952961 Aug 22 1997 /usr/lib/libg++.so.2.7.2.
p133:/root # ps --version
procps version 1.2.7
That is not true. It is version 1.2.9
p133:/root # procinfo -v
This is procinfo version 16 (1998-12-31)
p133:/root # pstree -V
pstree from psmisc version 18
p133:/root # pppd --version
pppd version 2.3 patch level 4
****************************************************************************************************************
Remarks:
- It's always the same EIP: c01243ba
- It always takes a while until the opps occurs. Sometimes I get no oops for
several days.
- kernel 2.0.36 runs perfectly.
- I tried also kernel 2.2.2, with the same results. But unfortunately xosview
1.7.0 doesn't work anymore with 2.2.2, so I still run 2.2.1. Is this problem
already known?
- The Ooops always takes place when processes with large memory requirements
or hard disc activity are running. In the example below the corresponding
process is cdda2wav but I found also tar, cp, rm producing oops messages with
the same EIP.
- When the first oops occurs, many more follow soon.
- Repeating the command that produced the oops gives me another oops. After a
reboot the same command works fine.
****************************************************************************************************************
If there is some more information I should tell you, feel free to contact me.
These oopses are very nasty for me since the system doesn't shut down correcly
when an oops occurs. The filesystems involved with the corresponding process can
not be unmounted anymore.
So I would be glad if you drop me a note if there is something I can do apart
from using 2.0.36 again.
Greetings from Germany
Andre
****************************************************************************************************************
Output of ./ksymoops -m /usr/src/linux/System.map < the_oops_3.txt
Options used: -V (default)
-o /lib/modules/2.2.1/ (default)
-k /proc/ksyms (default)
-l /proc/modules (default)
-m /usr/src/linux/System.map (specified)
-c 1 (default)
Mar 9 21:52:19 p133 kernel: Unable to handle kernel paging request at virtual address 08000000
Mar 9 21:52:19 p133 kernel: current->tss.cr3 = 02fa3000, Xr3 = 02fa3000
Mar 9 21:52:19 p133 kernel: *pde = 02fa2067
Mar 9 21:52:19 p133 kernel: Oops: 0000
Mar 9 21:52:19 p133 kernel: CPU: 0
Mar 9 21:52:19 p133 kernel: EIP: 0010:[<>]
Mar 9 21:52:19 p133 kernel: EFLAGS: 00010206
Mar 9 21:52:19 p133 kernel: eax: 08000000 ebx: 00007ca9 ecx: c4520304 edx: 08000000
Mar 9 21:52:19 p133 kernel: esi: 00000400 edi: 00007ca9 ebp: 00000304 esp: c4529e10
Mar 9 21:52:19 p133 kernel: ds: 0018 es: 0018 ss: 0018
Mar 9 21:52:19 p133 kernel: Process cdda2wav (pid: 25858, process nr: 55, stackpage=c4529000)
Mar 9 21:52:19 p133 kernel: Stack: c01243e9 00000304 00007ca9 00000400 c0124647 00000304 00007ca9 00000400
Mar 9 21:52:19 p133 kernel: 00007ca9 c51a2470 c4529f14 00007ca9 c57b0420 c0139049 00000304 00007ca9
Mar 9 21:52:19 p133 kernel: 00000400 00000000 00007ca9 00000001 c51a2470 00000008 c01396a9 c51a2470
Mar 9 21:52:19 p133 kernel: Call Trace: [<c01243e9>] [<c0124647>] [<c0139049>] [<c01396a9>] [<c0139951>] [<c0137d26>] [<c0137b3c>]
Mar 9 21:52:19 p133 kernel: [<c017a760>] [<c01099a1>] [<c010fcdf>] [<c0129072>] [<c0122f66>] [<c0123052>] [<c0108918>]
Mar 9 21:52:19 p133 kernel: Code: 8b 12 39 58 04 75 f3 39 70 08 75 ee 66 39 48 0c 75 e8 89 c2
>>EIP: c01243ba <find_buffer+2a/44>
Trace: c01243e9 <get_hash_table+15/20>
Trace: c0124647 <getblk+1f/21c>
Trace: c0139049 <ext2_alloc_block+65/144>
Trace: c01396a9 <block_getblk+161/288>
Trace: c0139951 <ext2_getblk+181/22c>
Trace: c0137d26 <ext2_file_write+1ea/4b0>
Trace: c0137b3c <ext2_file_write+0/4b0>
Trace: c017a760 <cdrom_pc_intr+0/208>
Code: c01243ba <find_buffer+2a/44> 00000000 <_EIP>:
Code: c01243ba <find_buffer+2a/44> 0: 8b 12 movl (%edx),%edx
Code: c01243bc <find_buffer+2c/44> 2: 39 58 04 cmpl %ebx,0x4(%eax)
Code: c01243bf <find_buffer+2f/44> 5: 75 f3 jne fffffffa <_EIP+0xfffffffa> c01243b4 <find_buffer+24/44>
Code: c01243c1 <find_buffer+31/44> 7: 39 70 08 cmpl %esi,0x8(%eax)
Code: c01243c4 <find_buffer+34/44> a: 75 ee jne fffffffa <_EIP+0xfffffffa> c01243b4 <find_buffer+24/44>
Code: c01243c6 <find_buffer+36/44> c: 66 39 48 0c cmpw %cx,0xc(%eax)
Code: c01243ca <find_buffer+3a/44> 10: 75 e8 jne fffffffa <_EIP+0xfffffffa> c01243b4 <find_buffer+24/44>
Code: c01243cc <find_buffer+3c/44> 12: 89 c2 movl %eax,%edx
--If NT is the answer the question must have been rather stupid...
- 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/