A lot of these LORs were fixed in cxgb in FreeBSD 8. You can look at
cxgb_main.c in 8 for details. I'll also try and figure out if those
changes are easily MFC'able.
Regards,
Navdeep
On Mon, Sep 14, 2009 at 2:29 PM, Matthew Fleming
matthew.flem...@isilon.com wrote:
We got a cxgb LOR report of:
1st 0xff8001e37be0 vlan_global (vlan_global) @
/build/mnt/src/sys/modules/if_vlan/../../net/if_vlan.c:1310
2nd 0xff80010892f0 cxgb port lock (cxgb port lock) @
/build/mnt/src/sys/modules/cxgb/../../dev/cxgb/cxgb_main.c:1956
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2a
witness_checkorder() at witness_checkorder+0x9e2
_sx_xlock() at _sx_xlock+0x55
cxgb_ioctl() at cxgb_ioctl+0x1e8
vlan_ioctl() at vlan_ioctl+0x359
ifhwioctl() at ifhwioctl+0xb1
ifioctl() at ifioctl+0xb1
kern_ioctl() at kern_ioctl+0xa3
ioctl() at ioctl+0xf1
freebsd32_ioctl() at freebsd32_ioctl+0x13e
isi_syscall() at isi_syscall+0x94
ia32_syscall() at ia32_syscall+0x1a3
Xint0x80_syscall() at Xint0x80_syscall+0x60
--- syscall (54, FreeBSD ELF32, freebsd32_ioctl), rip = 0x2868db1b, rsp
= 0xd4bc, rbp = 0xda38 ---
So we tried changing cxgb to not USE_SX. This resulted in a different
LOR:
lock order reversal: (sleepable after non-sleepable)
1st 0xff8000f9d508 cxgb controller lock 0 (cxgb controller lock 0)
@
/build/mnt/src/sys/modules/cxgb/cxgb/../../../dev/cxgb/cxgb_main.c:1889
2nd 0x806064e0 ACPI root bus (ACPI root bus) @
/build/mnt/src/sys/dev/acpica/acpi.c:1040
KDB: stack backtrace:
[8018e9fa] db_trace_self_wrapper+0x2a
[80298e89] witness_checkorder+0x719
[8025bf75] _sx_xlock+0x55
[8019678a] acpi_alloc_resource+0x9a
[80281714] resource_list_alloc+0x184
[801d9f98] pci_alloc_resource+0x158
[802814b9] bus_alloc_resource+0x89
[81804201] cxgb_setup_interrupts+0x51
[81807f33] cxgb_up+0xa3
[818083c0] cxgb_init_locked+0x1b0
[81808539] cxgb_init+0x39
[81808758] cxgb_ioctl+0x1f8
[8031e9e1] ifhwioctl+0xb1
[8031f720] ifioctl+0xb0
[8029a873] kern_ioctl+0xa3
[8029aad1] ioctl+0xf1
[8041eb93] freebsd32_ioctl+0xb3
[8025d963] isi_syscall+0x83
[8041de63] ia32_syscall+0x1a3
[803efc60] Xint0x80_syscall+0x60
--- syscall (54, FreeBSD ELF32, freebsd32_ioctl), rip = 0x2826ea67, rsp
= 0xd8ac, rbp = 0xd928 ---
(we modified cxgb_ioctl to call cxgb_init because otherwise the cxgb
interface would require an ifconfig up before it detected a link, which
was different behaviour from the em driver. Since the locks in question
are acquired inside cxgb_init() I don't think the rest of the stack is
relevant, but network stack isn't my area of expertise).
So it seems that with cxgb we're damned if we do, damned if we don't.
Any advice on which LOR is worse or if one is harmless, or how to make
it go away?
Note also that if cxgb uses a mtx then it will do malloc while holding
the mtx in this stack:
[803cc58a] uma_zalloc_arg+0x2da
[80241ef9] malloc+0x89
[8023115f] intr_event_add_handler+0x5f
[803f26d2] intr_add_handler+0x72
[801dc171] pci_setup_intr+0x41
[801dc171] pci_setup_intr+0x41
[802807e6] bus_setup_intr+0x96
[8180423c] cxgb_setup_interrupts+0x8c
[81807f33] cxgb_up+0xa3
[818083c0] cxgb_init_locked+0x1b0
[81808539] cxgb_init+0x39
Thanks,
matthew
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
