I have now seen three oopsen in __release_sock() all with one thing in
common, and a fourth now in tcp_v4_unhash() with the same common item.
The common item being that registers are ending up with HTML data in them.
The last two oopsen (__release_sock) both had eax=3e696c3c which is
'<li>', and the latest (tcp_v4_unhash) had eax=672e7261 and edx=6d3e227a
which matches up nicely with...
<li><a href="metahtml-5.01.tar.gz">metahtml-5.01.tar.gz (2046430 bytes)</a>
^^^^^^^^
...from the page being requested.
The stack trace looks 'highly improbable' but also looks remarkably similar
to the last oops I posted. It looks like the trace belongs to at least
two different contexts. load_elf_binary certainly has NO buisness being
there. The System.map is guaranteed the correct one :) I went back and
double (aaand triple) checked to be absolutely certain.
general protection: 0000
CPU: 0
EIP: 0010:[<0014ddc8>]
EFLAGS: 00010202
eax: 672e7261 ebx: 009b0414 ecx: 009b0414 edx: 6d3e227a
esi: 009b04d4 edi: 00b8ff44 ebp: 00000000 esp: 00b8fd0c
ds: 0018 es: 0018 fs: 002b gs: 002b ss: 0018
Process webtest (pid: 214, process nr: 37, stackpage=00b8f000)
Stack: 0014fa39 009b0414 009b0414 00b7b190 00b7b190 00000003 00b00018 008a3018
00000000 00000000 00000000 00000003 fbd06425 fbd06425 5493664e 5493664e
fbd06425 00000001 fbd0e19d 5493664e 00000000 00000000 00000000 00000000
Call Trace: [<0014fa39>] [<001347cc>] [<00153360>] [<00133c49>] [<00133caa>] [<00133cbe>] [<00155140>]
[<00133c44>] [<00154dc0>] [<00133cba>] [<00147e40>] [<0015ab40>] [<0015ab60>] [<0015ab90>] [<0015ab40>]
[<0015b017>] [<0013d09c>] [<0013d315>] [<0012571c>] [<00125798>] [<001257f4>] [<0010aa69>]
Code: 89 50 68 8b 51 68 8b 41 64 89 02 c7 41 68 00 00 00 00 8b 51
Aiee, killing interrupt handler
Using `/boot/2.0.35/System.map' to map addresses to symbols.
>>EIP: 14ddc8 <tcp_v4_unhash+18/50>
Trace: 14fa39 <tcp_close+289/2a0>
Trace: 1347cc <load_elf_library+cc/300>
Trace: 153360 <tcp_send_partial>
Trace: 133c49 <load_elf_binary+159/c10>
Trace: 133caa <load_elf_binary+1ba/c10>
Trace: 133cbe <load_elf_binary+1ce/c10>
Trace: 155140 <tcp_retransmit_timer>
Trace: 133c44 <load_elf_binary+154/c10>
Trace: 154dc0 <tcp_delack_timer>
Trace: 133cba <load_elf_binary+1ca/c10>
Trace: 147e40 <net_timer>
Trace: 15ab40 <def_callback1>
Trace: 15ab60 <def_callback2>
Trace: 15ab90 <def_callback3>
Trace: 15ab40 <def_callback1>
Trace: 15b017 <inet_release+67/70>
Trace: 13d09c <sock_release+5c/a0>
Trace: 13d315 <sock_close+25/30>
Trace: 12571c <__fput+1c/40>
Trace: 125798 <close_fp+58/70>
Trace: 1257f4 <sys_close+44/50>
Trace: 10aa69 <system_call+55/7c>
Code: 14ddc8 <tcp_v4_unhash+18/50>
Code: 14ddc8 <tcp_v4_unhash+18/50> 89 50 68 movl %edx,0x68(%eax)
Code: 14ddcb <tcp_v4_unhash+1b/50> 8b 51 68 movl 0x68(%ecx),%edx
Code: 14ddce <tcp_v4_unhash+1e/50> 8b 41 64 movl 0x64(%ecx),%eax
Code: 14ddd1 <tcp_v4_unhash+21/50> 89 02 movl %eax,(%edx)
Code: 14ddd9 <tcp_v4_unhash+29/50> c7 41 68 00 00 movl $0x0,0x68(%ecx)
Code: 14dde0 <tcp_v4_unhash+30/50> 8b 51 00 movl 0x0(%ecx),%edx
Code: 14dde9 <tcp_v4_unhash+39/50> 90 nop
Code: 14ddea <tcp_v4_unhash+3a/50> 90 nop
Code: 14ddeb <tcp_v4_unhash+3b/50> 90 nop
-
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/