question on sky2 driver panic
Hi, We're using Yukon-XL (0xb3) rev 3 hardware with a vendor-supplied 2.6.14. BAsed on suggestions here, I backported the sky2 driver (v1.10 from 2.6.20.6) to 2.6.14. Unfortunately, when I booted this I got the following: skb_over_panic: text:d00d4e14 len:60 put:60 head:c00264920770 data:c00264920720 tail:c00264920720 end:c002649207a0 dev: kernel BUG in skb_over_panic at /usr/local/src/2.6.14/gd/linux/net/core/skbuff.c:94! Oops: Exception in kernel mode, sig: 5 [#1] SMP NR_CPUS=2 Modules linked in: tipc bond1 bond0 ipmi_devintf ipmi_msghandler NIP: C020D7E8 XER: LR: C020D7E4 CTR: C01C210C REGS: c0025c2aefe0 TRAP: 0700 Not tainted (2.6.14-pne) MSR: 90029032 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11 CR: 28008022 DAR: DSISR: c0025c2af1c0 TASK: cfec2940[2107] 'insmod' THREAD: c0025c2ac000 CPU: 0 GPR00: C020D7E4 C0025C2AF300 C041DA08 009C GPR04: 90009032 0030 C037C428 GPR08: C037EEF0 C043AD68 C043AC88 GPR12: 0010 C0374000 100D47E8 GPR16: 100D55A0 GPR20: 0001 GPR24: B6AA7FFF GPR28: 003C CFEF5B10 C03BB778 003C NIP [c020d7e8] .skb_over_panic+0x50/0x68 LR [c020d7e4] .skb_over_panic+0x4c/0x68 Call Trace: [c0025c2af300] [c020d7e4] .skb_over_panic+0x4c/0x68 (unreliable) [c0025c2af390] [d00d4e20] .named_prepare_buf+0x298/0x2a8 [tipc] [c0025c2af450] [d00d4e90] .named_publish+0x60/0xe4 [tipc] [c0025c2af4e0] [d00d80a8] .nametbl_publish+0x128/0x198 [tipc] [c0025c2af590] [d00de7dc] .tipc_publish+0xe8/0x188 [tipc] [c0025c2af650] [d00d7f4c] .nametbl_publish_rsv+0x30/0x64 [tipc] [c0025c2af6e0] [d00d2600] .cfg_init+0x120/0x150 [tipc] [c0025c2af7a0] [d00e31ac] .process_signal_queue+0xa4/0x100 [tipc] [c0025c2af8/0x1ec [tipc] [c0025c2afcf0] [c00685ec] .sys_init_module+0x28c/0x510 [c0025c2afd90] [c0009b9c] syscall_exit+0x0/0x18 Now granted it looks like this was triggered by tipc, but is there anything that you can think of in the sky2 driver that may have been related? Maybe due to the fragmented buffer handling? The link would have been using an mtu of 9KB. Thanks, Chris - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: question on sky2 driver panic
On Mon, 15 Oct 2007 14:17:50 -0600 "Chris Friesen" <[EMAIL PROTECTED]> wrote: > > Hi, > > We're using Yukon-XL (0xb3) rev 3 hardware with a vendor-supplied > 2.6.14. BAsed on suggestions here, I backported the sky2 driver (v1.10 > from 2.6.20.6) to 2.6.14. > > Unfortunately, when I booted this I got the following: > > > skb_over_panic: text:d00d4e14 len:60 put:60 > head:c00264920770 data:c00264920720 tail:c00264920720 > end:c002649207a0 dev: > kernel BUG in skb_over_panic at > /usr/local/src/2.6.14/gd/linux/net/core/skbuff.c:94! > Oops: Exception in kernel mode, sig: 5 [#1] > SMP NR_CPUS=2 > Modules linked in: tipc bond1 bond0 ipmi_devintf ipmi_msghandler > NIP: C020D7E8 XER: LR: C020D7E4 CTR: > C01C210C > REGS: c0025c2aefe0 TRAP: 0700 Not tainted (2.6.14-pne) > MSR: 90029032 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11 CR: 28008022 > DAR: DSISR: c0025c2af1c0 > TASK: cfec2940[2107] 'insmod' THREAD: c0025c2ac000 CPU: 0 > GPR00: C020D7E4 C0025C2AF300 C041DA08 009C > GPR04: 90009032 0030 C037C428 > GPR08: C037EEF0 C043AD68 C043AC88 > GPR12: 0010 C0374000 100D47E8 > GPR16: 100D55A0 > GPR20: 0001 > GPR24: B6AA7FFF > GPR28: 003C CFEF5B10 C03BB778 003C > NIP [c020d7e8] .skb_over_panic+0x50/0x68 > LR [c020d7e4] .skb_over_panic+0x4c/0x68 > Call Trace: > [c0025c2af300] [c020d7e4] .skb_over_panic+0x4c/0x68 (unreliable) > [c0025c2af390] [d00d4e20] .named_prepare_buf+0x298/0x2a8 [tipc] > [c0025c2af450] [d00d4e90] .named_publish+0x60/0xe4 [tipc] > [c0025c2af4e0] [d00d80a8] .nametbl_publish+0x128/0x198 [tipc] > [c0025c2af590] [d00de7dc] .tipc_publish+0xe8/0x188 [tipc] > [c0025c2af650] [d00d7f4c] .nametbl_publish_rsv+0x30/0x64 [tipc] > [c0025c2af6e0] [d00d2600] .cfg_init+0x120/0x150 [tipc] > [c0025c2af7a0] [d00e31ac] .process_signal_queue+0xa4/0x100 > [tipc] > [c0025c2af8/0x1ec [tipc] > [c0025c2afcf0] [c00685ec] .sys_init_module+0x28c/0x510 > [c0025c2afd90] [c0009b9c] syscall_exit+0x0/0x18 > > > > Now granted it looks like this was triggered by tipc, but is there > anything that you can think of in the sky2 driver that may have been > related? Maybe due to the fragmented buffer handling? The link would > have been using an mtu of 9KB. > > Thanks, > > Chris Maybe TIPC can't handle fragmented receive buffers. The sky2 driver generates skb's with header and multiple pages if MTU is big enough. For 9K MTU that would be 1K of data + 2 4K pages. The protocols are supposed to be smart enough to handle this, but TIPC is rarely used. -- Stephen Hemminger <[EMAIL PROTECTED]> -- Stephen Hemminger <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: question on sky2 driver panic
Stephen Hemminger wrote: Maybe TIPC can't handle fragmented receive buffers. The sky2 driver generates skb's with header and multiple pages if MTU is big enough. For 9K MTU that would be 1K of data + 2 4K pages. The protocols are supposed to be smart enough to handle this, but TIPC is rarely used. We already had to modify tipc to handle fragmented receive buffers when we had memory allocation errors on the e1000 and moved to fragmented skbs in that driver. Our version of the e1000 passes 200 bytes in the initial chunk, and the rest in fragments. tipc currently handles that without any difficulty. I was just checking more to see if there were any known issues in this area that have been fixed in more recent driver versions. Chris - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: question on sky2 driver panic
From: "Chris Friesen" <[EMAIL PROTECTED]> Date: Mon, 15 Oct 2007 23:16:16 -0600 > Our version of the e1000 passes 200 bytes in the initial chunk, and the > rest in fragments. tipc currently handles that without any difficulty. There is no requirement for any bytes to be in the initial skb->data chunk, in fact the Neptune NIU driver only pulls the ethernet header into there for example. net/tipc/eth_media.c:recv_msg() seems to dereference buf->data directly without making any pskb_may_pull() checks, and that is a bug. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
