Recently my 2.0.34 reported a numerious Oops:
current->tss.cr3 = 00101000, 8r3 = 00101000
*pde = 00001067
*pte = 00000000
Oops: 0000
CPU: 0
EIP: 0010:[<0282935c>]
EFLAGS: 00010206
eax: 00000240 ebx: 00000000 ecx: 0047eac0 edx: 0282935c
esi: 01d0ccdc edi: 0047eac0 ebp: 013f9dd8 esp: 001bd4cc
ds: 0018 es: 0018 fs: 002b gs: 0018 ss: 0018
Process swapper (pid: 0, process nr: 0, stackpage=001bb640)
Stack: 0014a9c3 0047eac0 01d0ccdc 00000800 00000000 00000000 00000240 013f9c0c 00002180 00000010 001bd580 0ee613c3 00000000 00130405 0000022c 0047e860 0047e874 00e2ed18 01d0ccdc 0047eac0 0014bbce 013f9c0c 00000000 00000000
Call Trace: [tcp_do_retransmit+1267/1672] [load_elf_binary+1069/3044] [tcp_retransmit_time+22/120] [tcp_retransmit+22/116] [tcp_time_write_timeout+19/32] [tcp_retransmit_timer+142/228] [tcp_retransmit_timer+0/228]
This somehow happens when loading or autocleaning ppp module, I can't catch
the precise time. I hadn't this problems since I set up 2.0.34 kernel,
but now it started to happen regulary. This kills kerneld forever - the only
negative result I got. It's possible, that the root cause is in recieving
source quench packets - our provider installed the filter not a long time ago.
But I don't sure, since I can't map addresses back to source code, ksymoops
only returns empty output on this oops :(
So, the question is - is this a known bug and fixed in >2.0.34 ? Or there
is no reason to upgrade now ...
Thank you.
Bye.
-- A sinking ship gathers no moss. -- Donald Kaul
-- With best of best regards, Pawel S. Veselov (aka Black Angel) Web page : http://i.am/BlackAngel | ICQ UIN : 5252265 Internet e-mail : vps@druid.ml.org
- 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/