Bjarni R. Einarsson wrote:
>
> Call me stubborn, but I still think the crashes might be attack related.
> I just found more 'evidence' when I typed 'dmesg'.
>
> Unfortunately dmesg does not include timestamps.. somebody please add
> timestamps to the kernel messages!! :-) If anyone has a patch to do this
> I'd love to apply it. Anyway. It is possible that the fact that the
> following oopses are followed IMMEDIATELY by teardrop warnings, may not be
> a coincidence.
>
> I have this machine tcpdumping on the same network as my crashing proxy
> server.. which hasn't crashed since I changed kernels to 2.0.32 w/ 2.0.29
> networking.
>
> The machine that recorded this stuff is running 2.0.31 w/ 2.0.29 networking,
> because after 24 hours of heavy stress testing on it barfed out a stream of
> oops-es and rebooted. This implies to me that either my problems are
> probably NOT the 2.0.30 network codes fault.
>
> I'm still tcpdumping and stresstesting.
>
> I'm just a lowly sysadmin, so I don't know what to do with these oopses
> other than send them to you.. dmesg said:
>
> nable to handle kernel NULL pointer dereference at virtual address c0000014
> current->tss.cr3 = 02d13000, %cr3 = 02d13000
> *pde = 00102067
> *pte = 00000000
> Oops: 0000
> CPU: 0
> EIP: 0010:[<0014011a>]
> EFLAGS: 00010202
> eax: 00000000 ebx: 00d6d598 ecx: 00000018 edx: 00d6d658
> esi: 030e38d8 edi: 00000000 ebp: 00000009 esp: 014cdf10
> ds: 0018 es: 0018 fs: 002b gs: 002b ss: 0018
> Process make (pid: 21833, process nr: 45, stackpage=014cd000)
> Stack: 00095d44 00095d04 0000002e 014cdf80 00d6d598 00000000 00000018 00000014
> 00002000 00095d19 036de7d8 030e38d8 0013f5b8 00095d04 00095d44 001eaef8
> 00000000 00095d44 001e10c4 0014d1de 01c04578 00000003 00000000 00000001
> Call Trace: [<0013f5b8>] [<0014d1de>] [<0013ee00>] [<00138a54>] [<00117937>] [<0010a57b>]
> Code: 83 7f 14 00 74 09 8b 53 14 8b 43 18 89 42 18 8b 54 24 14 8b
> Aiee, killing interrupt handler
> Unable to handle kernel NULL pointer dereference at virtual address c0000014
> current->tss.cr3 = 01619000, %cr3 = 01619000
> *pde = 00102067
> *pte = 00000000
> Oops: 0000
> CPU: 0
> EIP: 0010:[<0014011a>]
> EFLAGS: 00010206
> eax: 00000000 ebx: 00ed3618 ecx: 00000018 edx: 00ed30d8
> esi: 00ed36d8 edi: 00000000 ebp: 00000009 esp: 00477f10
> ds: 0018 es: 0018 fs: 002b gs: 002b ss: 0018
> Process cc1 (pid: 22100, process nr: 53, stackpage=00477000)
> Stack: 00095a50 00095a10 0000002e 00477f80 00ed3618 00000000 00000018 00000014
> 00002000 00095a25 00ed3e98 00ed36d8 0013f5b8 00095a10 00095a50 001eaef8
> 00000000 00095a50 001e10c4 0014d1de 01c04578 00000003 00000000 00000001
> Call Trace: [<0013f5b8>] [<0014d1de>] [<0013ee00>] [<00138a54>] [<00117937>] [<0010a57b>]
> Code: 83 7f 14 00 74 09 8b 53 14 8b 43 18 89 42 18 8b 54 24 14 8b
> Aiee, killing interrupt handler
> Unable to handle kernel NULL pointer dereference at virtual address c0000014
> current->tss.cr3 = 01288000, %cr3 = 01288000
> *pde = 00102067
> *pte = 00000000
> Oops: 0000
> CPU: 0
> EIP: 0010:[<0014011a>]
> EFLAGS: 00010202
> eax: 00000000 ebx: 030e3598 ecx: 00000018 edx: 030e3958
> esi: 030e3a18 edi: 00000000 ebp: 00000009 esp: 02ec5f10
> ds: 0018 es: 0018 fs: 002b gs: 002b ss: 0018
> Process cc1 (pid: 22615, process nr: 51, stackpage=02ec5000)
> Stack: 00095c48 00095c08 0000002e 02ec5f80 030e3598 00000000 00000018 00000014
> 00002000 00095c1d 030e32d8 030e3a18 0013f5b8 00095c08 00095c48 001eaef8
> 00000000 00095c48 001e10c4 0014d1de 01c04578 00000003 00000000 00000001
> Call Trace: [<0013f5b8>] [<0014d1de>] [<0013ee00>] [<00138a54>] [<00117937>] [<0010a57b>]
> Code: 83 7f 14 00 74 09 8b 53 14 8b 43 18 89 42 18 8b 54 24 14 8b
> Aiee, killing interrupt handler
> Unable to handle kernel NULL pointer dereference at virtual address c0000014
> current->tss.cr3 = 00901000, %cr3 = 00901000
> *pde = 00102067
> *pte = 00000000
> Oops: 0000
> CPU: 0
> EIP: 0010:[<0014011a>]
> EFLAGS: 00010202
> eax: 00000000 ebx: 033fd918 ecx: 00000018 edx: 033fd998
> esi: 033fdb58 edi: 00000000 ebp: 00000009 esp: 0386af10
> ds: 0018 es: 0018 fs: 002b gs: 002b ss: 0018
> Process as (pid: 23000, process nr: 56, stackpage=0386a000)
> Stack: 00095f3c 00095efc 0000002e 0386af80 033fd918 00000000 00000018 00000014
> 00002000 00095f11 00d6d458 033fdb58 0013f5b8 00095efc 00095f3c 001eaef8
> 00000000 00095f3c 001e10c4 0014d1de 01c04578 00000003 00000000 00000001
> Call Trace: [<0013f5b8>] [<0014d1de>] [<0013ee00>] [<00138a54>] [<00117937>] [<0010a57b>]
> Code: 83 7f 14 00 74 09 8b 53 14 8b 43 18 89 42 18 8b 54 24 14 8b
> Aiee, killing interrupt handler
> IP: Invalid IP fragment (offset > end) found from 198.137.241.30
> IP: Invalid IP fragment (offset > end) found from 198.137.241.30
> IP: Invalid IP fragment (offset > end) found from 198.137.241.30
> IP: Invalid IP fragment (offset > end) found from 198.137.241.30
> IP: Invalid IP fragment (offset > end) found from 198.137.241.30
>
> --
> Bjarni R. Einarsson
> bre@margmidlun.is [ THIS SPACE INTENTIONALLY LEFT BLANK ]
> http://www.mmedia.is/~bre
> Juggler@IRC Hail Eris! All Hail Discordia!
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
-- Did you read the documentation AND the FAQ? If not, I'll probably still answer your question, but my patience will be limited, and you take the risk of sarcasm and ridicule.- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu