> > During my tests I found that when running > > 1. modprobe -r ib_mthca (to delete IPoIB interfaces) > 2. ping somewhere on the subnet of bond0 > > I get this stack dump (which ends with kernel death) > [<ffffffff8037ff32>] skb_under_panic+0x5c/0x60 > [<ffffffff882e00c2>] :ib_ipoib:ipoib_hard_header+0xa6/0xc0 > [<ffffffff803c3c98>] arp_create+0x120/0x226 > [<ffffffff803c3dc3>] arp_send+0x25/0x3b > [<ffffffff803c466a>] arp_solicit+0x186/0x195 > [<ffffffff8038c0ac>] neigh_timer_handler+0x2b5/0x309 > [<ffffffff8038bdf7>] neigh_timer_handler+0x0/0x309 > [<ffffffff80239599>] run_timer_softirq+0x130/0x19e > [<ffffffff80235fcc>] __do_softirq+0x55/0xc3 > [<ffffffff8020acac>] call_softirq+0x1c/0x28 > [<ffffffff8020c02b>] do_softirq+0x2c/0x7d > [<ffffffff8021864a>] smp_apic_timer_interrupt+0x57/0x6a > [<ffffffff80208e19>] mwait_idle+0x0/0x45 > [<ffffffff8020a756>] apic_timer_interrupt+0x66/0x70 > <EOI> [<ffffffff80208e5b>] mwait_idle+0x42/0x45 > [<ffffffff80208db1>] cpu_idle+0x8b/0xae > [<ffffffff80217d60>] start_secondary+0x47f/0x48f > > The only way I found to avoid this (for now) is to check skb headroom in > ipoib_hard_header. I guess that this safety check doesn't harm regular IPoIB > operation and it seems to solve my problem. However, I would be happy to hear > what > others think of this last issue.
This seems to mean that hard_header_len is not copied from slave to master device. Right? Maybe that's what needs to be fixed. -- MST _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
