Re: [PATCH] IB/ipoib: Bound the net device to the ipoib_neigh structue

[Jay Vosburgh <fubar@us.ibm.com>]

Roland Dreier <rdreier@cisco.com> wrote:
[...]
>Yes, two napi_disable()s in a row without a matching napi_enable()
>will deadlock.  I guess the question is why the ipoib interface is
>being stopped twice.
>
>If you just take the net-2.6.24 tree (without bonding patches), does
>bonding for ethernet interfaces work OK, or is there a similar problem
>with double napi_disable()?  How about bonding of ethernet after this
>batch of bonding patches?

	I just checked this on an x86 box.  The bonding in stock net-2.6
pulled this morning or last night works ok (I did some basic tests,
including ifconfig down / up, with e100).  This remains true with the
IPoIB bonding patches applied.  I do not have hardware available to test
IPoIB.

	I did get a whammy from tg3, but I think this is unrelated to
bonding (as it happens when tg3 comes up, before bonding is involved):

BUG: unable to handle kernel paging request at virtual address 00004214
 printing eip:
e0828017
*pde = 00000000
Oops: 0002 [#1]
SMP
Modules linked in: thermal processor fan button loop e1000 sg evdev tg3 e100 rtb
CPU:    0
EIP:    0060:[<e0828017>]    Not tainted VLI
EFLAGS: 00010206   (2.6.23-ipv6 #1)
EIP is at tg3_ape_write32+0x7/0x10 [tg3]
eax: de9304c0   ebx: dde8fe18   ecx: 00000000   edx: 00004214
esi: de9304c0   edi: 00000000   ebp: dde8fe28   esp: dde8fdd4
ds: 007b   es: 007b   fs: 00d8  gs: 0033  ss: 0068
Process ip (pid: 2817, ti=dde8e000 task=dff4e0b0 task.ti=dde8e000)
Stack: e082fb2e 00000000 dde8fdf4 c01ece3e dde8fdf8 000003fe 00000000 00005400
       08000000 00001aa0 e083b340 08001aa0 00000060 e083ce00 08001b20 00000030
       e083ce80 00000101 de9304c0 00000001 dde56800 dde8fe38 e0830178 dff69000
Call Trace:
 [<c010536a>] show_trace_log_lvl+0x1a/0x30
 [<c0105429>] show_stack_log_lvl+0xa9/0xd0
 [<c0105639>] show_registers+0x1e9/0x2f0
 [<c0105851>] die+0x111/0x260
 [<c011c5dc>] do_page_fault+0x18c/0x6a0
 [<c0319bea>] error_code+0x72/0x78
 [<e0830178>] tg3_init_hw+0x38/0x50 [tg3]
 [<e0838886>] tg3_open+0x276/0x5d0 [tg3]
 [<c02aead8>] dev_open+0x38/0x80
 [<c02ad5cd>] dev_change_flags+0x7d/0x1a0
 [<c02f63d8>] devinet_ioctl+0x4c8/0x660
 [<c02f698b>] inet_ioctl+0x6b/0x90
 [<c02a0e5a>] sock_ioctl+0x5a/0x210
 [<c017cd98>] do_ioctl+0x28/0x80
 [<c017ce47>] vfs_ioctl+0x57/0x290
 [<c017d0b9>] sys_ioctl+0x39/0x60
 [<c01042a2>] sysenter_past_esp+0x5f/0x99
 =======================
Code: <89> 0a c3 8d b6 00 00 00 00 55 8b 48 50 89 e5 5d 01 ca 8b 02 c3 8d
EIP: [<e0828017>] tg3_ape_write32+0x7/0x10 [tg3] SS:ESP 0068:dde8fdd4
Kernel panic - not syncing: Fatal exception in interrupt

	I haven't investigated this further.  I'm using a BCM5704 card;
if this isn't a known problem and anyone is curious, I can supply
additional info.

	-J

---
	-Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com