Sorry for the crosspost, but I think this is of interest on both lists.
I'm reliably panicing the kernel when sending tcp over a bridge that
includes a netgear GA620 (acenic driver) card.
Setup:
Dual PIII 1Ghz, serverworks chipset, vanilla linux 2.4.17. Network
cards: 1 eepro100, 1 Netgear GA620 gigE card, 1 4-port linksys tulip
card.
Driver versions from dmesg:
acenic.c: v0.85 11/08/2001 Jes Sorensen, [EMAIL PROTECTED]
Linux Tulip driver version 0.9.15-pre9 (Nov 6, 2001)
NET4: Ethernet Bridge 008 for NET4.0
I'm trying to make an ethernet bridge between all 4 ports of the tulip
card and the netgear gigabit card. Because of the kernel crashes, I
narrowed it down to 1 port of the tulip card and the Netgear.
Bridges without the netgear card are rock solid.
Once I bring up this bridge, I can ping across it. The instant I try to
open an ssh session or use ttcp across the bridge, though, the kernel
goes down in flames. I took down the oops output by hand and ran it
through ksymoops (it took a couple tries before I could get the call
trace properly decoded, but i think this is right. The "Stack" section
is probably wrong; I was mostly trying to get a good call trace.)
I know enough about kernel networking internals to help debug this, but
do any of you know where I should start? Does anyone have any experience
using gigibit cards in linux bridges?
thanks, Jason
ksymoops 2.4.3 on i686 2.4.17-jl9. Options used
-V (default)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o /lib/modules/2.4.17-jl9/ (default)
-m /boot/System.map-2.4.17-jl9 (default)
Invalid operand: 0000
CPU: 1
EIP: 0000:[<c018dfc3>] Not tainted
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010206
eax: 00007e7d ebx: df87a6e0 ecx: b80dc66d edx: 0000003c
esi: 00007e7b edi: df54f780 ebp: ded67800 esp: c181de8c
ds: 0018 es: 0018 ss: 0018
Stack: dfac9800 df87a6e0 df664c00 c018e0a1 df87a6e0 df87a6e0 deccffc0 df664800
e08c8d54 df87a6e0 df87a6e0 e08c8d66 df87a6e0 e08c8d98 df87a6e0 e08c8dfd
def2a140 df87a6e0 e08c8f54 def2a140 df87a6e0 ded67800 df87a6e0 dfb64c00
Call Trace: [<c018e0a1>] [<e08c2d54>] [<e08c2d66>] [<e08c2d98>] [<e08c2dfd>]
[<e08c37e2>] [<e08c3858>] [<e08c386e>] [<c018e7c0>] [<c011a35f>]
[<c010863b>]
[<c01051b0>] [<c01051b0>] [<c010a6d8>] [<c01051b0>] [<c01051b0>]
[<c01051dc>]
[<c0105242>] [<c0116438>] [<c011634e>]
Code: 0f 0b 89 c8 25 00 00 ff ff c1 e1 10 01 c8 15 ff ff 00 00 f7
>>EIP; c018dfc2 <skb_checksum_help+46/70> <=====
Trace; c018e0a0 <dev_queue_xmit+b4/2ec>
Trace; e08c2d54 <[bridge]__dev_queue_push_xmit+34/3c>
Trace; e08c2d66 <[bridge]__br_forward_finish+a/10>
Trace; e08c2d98 <[bridge]__br_forward+14/18>
Trace; e08c2dfc <[bridge]br_forward+1c/40>
Trace; e08c37e2 <[bridge]__br_handle_frame+19e/1f0>
Trace; e08c3858 <[bridge]br_handle_frame_finish+24/30>
Trace; e08c386e <[bridge]br_handle_frame+a/1c>
Trace; c018e7c0 <net_rx_action+16c/318>
Trace; c011a35e <do_softirq+6e/cc>
Trace; c010863a <do_IRQ+da/ec>
Trace; c01051b0 <default_idle+0/34>
Trace; c01051b0 <default_idle+0/34>
Trace; c010a6d8 <call_do_IRQ+6/e>
Trace; c01051b0 <default_idle+0/34>
Trace; c01051b0 <default_idle+0/34>
Trace; c01051dc <default_idle+2c/34>
Trace; c0105242 <cpu_idle+3e/54>
Trace; c0116438 <release_console_sem+94/98>
Trace; c011634e <printk+11e/138>
Code; c018dfc2 <skb_checksum_help+46/70>
00000000 <_EIP>:
Code; c018dfc2 <skb_checksum_help+46/70> <=====
0: 0f 0b ud2a <=====
Code; c018dfc4 <skb_checksum_help+48/70>
2: 89 c8 mov %ecx,%eax
Code; c018dfc6 <skb_checksum_help+4a/70>
4: 25 00 00 ff ff and $0xffff0000,%eax
Code; c018dfca <skb_checksum_help+4e/70>
9: c1 e1 10 shl $0x10,%ecx
Code; c018dfce <skb_checksum_help+52/70>
c: 01 c8 add %ecx,%eax
Code; c018dfd0 <skb_checksum_help+54/70>
e: 15 ff ff 00 00 adc $0xffff,%eax
Code; c018dfd4 <skb_checksum_help+58/70>
13: f7 00 00 00 00 00 testl $0x0,(%eax)
<0>Kernel panic: Aiee, killing interrupt handler!
_______________________________________________
Bridge mailing list
[EMAIL PROTECTED]
http://www.math.leidenuniv.nl/mailman/listinfo/bridge
