Messages in this thread | | | Date | Tue, 9 Mar 1999 22:07:22 +0000 | From | Andre <> | Subject | Oops: 0000 |
| |
Hi
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/
| |