Re: LOR in Jan16 -CUR, ACPI related possibly

From: John Baldwin <jhb_at_FreeBSD.org>
Date: Tue, 18 Jan 2005 11:12:55 -0500
On Sunday 16 January 2005 04:37 pm, Ketrien I. Saihr-Kenchedra wrote:
> Yes yes, bad form to reply to myself, I know. Managed to salvage the LOR
> from logs. (Filesystems were an unholy mess.)
>
> ukphy0: detached
> miibus0: detached
> lock order reversal
> 1st 0xc1f3a790 pcn0 (network driver) _at_
> /usr/src/sys/modules/pcn/../../pci/if_pcn.c:1385 2nd 0xc08b02c0 ACPI root
> bus (ACPI root bus) _at_
> /usr/src/sys/modules/acpi/acpi/../../../dev/acpica/acpi.c:1050 KDB: stack
> backtrace:
> witness_checkorder(c08b02c0,9,c08aa6b7,41a,c0700795) at
> witness_checkorder+0x5c6 _sx_xlock(c08b02c0,c08aa6b7,41a,1,c1c59380) at
> _sx_xlock+0x5d
> acpi_release_resource(c1c58600,c1c59380,1,0,c1d13a00) at
> acpi_release_resource+0x30
> resource_list_release(c1c59a84,c1ccf100,c1c59380,1,0,c1d13a00) at
> resource_list_release+0x125
> bus_generic_rl_release_resource(c1ccf100,c1c59380,1,0,c1d13a00) at
> bus_generic_rl_release_resource+0x7b
> bus_release_resource(c1c59380,1,0,c1d13a00,c1c59380) at
> bus_release_resource+0x6b
> pcn_detach(c1c59380,c1cb2850,c073606c,933,c3e5b9f0) at pcn_detach+0x17b
> device_detach(c1c59380,c3e5a759,c1e79540,1,c1c1fa00) at device_detach+0x99
> devclass_delete_driver(c1c1fa00,c3e5b9f0,1f2,0,c212db80) at
> devclass_delete_driver+0xd1 driver_module_handler(c212db80,1,c3e5b9dc) at
> driver_module_handler+0xe2 module_unload(c212db80,0,1f2,c21a5400,c07001e5)
> at module_unload+0x68 linker_file_unload(c21a5400,0,c07001ee,31e,bfbfe8a0)
> at linker_file_unload+0x29d kern_kldunload(0,db2f7d14,8,3ff,2) at
> kern_kldunload+0x8c
> syscall(2f,2f,2f,3,bfbfee16) at syscall+0x137
> Xint0x80_syscall() at Xint0x80_syscall+0x1f
> --- syscall (444, FreeBSD ELF32, kldunloadf), eip = 0x280c459f, esp =
> 0xbfbfe89c, ebp = 0xbfbfed10 --- pcn0: detached

This is because the driver (pcn) in this case is holding a lock across 
bus_release_resoruce() when it probably should not be.  I get the same LOR 
with radeondrm because it holds the lock across bus_teardown_intr() (which is 
definitely wrong since that can sleep).

-- 
John Baldwin <jhb_at_FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve"  =  http://www.FreeBSD.org
Received on Tue Jan 18 2005 - 17:08:43 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:26 UTC