General Protection oops in 2.0.35

Chris Adams (cadams@ro.com)
Wed, 21 Oct 1998 10:49:50 -0500

I got this on a SMP dual Pentium 200 server with 128 MB parity RAM (in ECC
mode), an Adaptec 2940 SCSI controller (AIC-7881U), and a 3Com 3C905
ethernet card (in 10BaseT mode). It is running Red Hat 5.1. The kernel
was compiled with gcc from Red Hat's package gcc-2.7.2.3-11.

The httpsd process is Stronghold 2.4 (compiled by me also with the same
gcc). At that point, Stronghold stopped answering HTTP requests (they
weren't refused - they just hung). I was able to stop and restart
Stronghold and everything is running okay since.

general protection: 0000
CPU: 0
EIP: 0010:[<00116768>]
EFLAGS: 00010216
eax: 0704e3a2 ebx: 0704e38a ecx: 07a4b0d8 edx: 056dd597
esi: 6b357433 edi: 0704e39e ebp: 01ec7f30 esp: 01ec7f1c
ds: 0018 es: 0018 fs: 002b gs: 002b ss: 0018
Process httpsd (pid: 16837, process nr: 36, stackpage=01ec7000)
Stack: 0704e38a 056dd598 00000000 00000246 0704e39e 00000001 00135af1 0704e3a2
056dd598 00000000 00000000 00136a00 056dd598 00000000 056dd598 001364dd
027c2a50 00000000 07ff6fac 00000008 08101a14 bffff380 00135ba6 07ff6fac
Call Trace: [<00135af1>] [<00136a00>] [<001364dd>] [<00135ba6>] [<0010acee>]
Code: 8b 0e 8b 76 04 85 c9 0f 84 50 01 00 00 8b 01 83 f8 02 74 0b

Using `/System.map' to map addresses to symbols.

>>EIP: 116768 <wake_up+30/1d0>
Trace: 135af1 <locks_wake_up_blocks+19/40>
Trace: 136a00 <locks_delete_lock+34/7c>
Trace: 1364dd <flock_lock_file+9d/1a8>
Trace: 135ba6 <sys_flock+8e/98>
Trace: 10acee <system_call+102/138>

Code: 116768 <wake_up+30/1d0>
Code: 116768 <wake_up+30/1d0> 8b 0e movl (%esi),%ecx
Code: 11676a <wake_up+32/1d0> 8b 76 04 movl 0x4(%esi),%esi
Code: 11676d <wake_up+35/1d0> 85 c9 testl %ecx,%ecx
Code: 11676f <wake_up+37/1d0> 0f 84 50 01 00 je 1168c5 <wake_up+18d/1d0>
Code: 11677a <wake_up+42/1d0> 00
Code: 11677b <wake_up+43/1d0> 8b 01 movl (%ecx),%eax
Code: 11677d <wake_up+45/1d0> 83 f8 02 cmpl $0x2,%eax
Code: 116780 <wake_up+48/1d0> 74 0b je 116787 <wake_up+4f/1d0>
Code: 116788 <wake_up+50/1d0> 

-- 
Chris Adams - cadams@ro.com
System Administrator - Renaissance Internet Services
I don't speak for anybody but myself - that's enough trouble.


-
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/