Roland Dreier <[EMAIL PROTECTED]> 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, [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
