Re: LOR (drm,acpi)

In message: <41224990.9050008_at_root.org>
            Nate Lawson <nate_at_root.org> writes:
: Alex Vasylenko wrote:
: > The following was reported when leaving X on FreeBSD 5.2-CURRENT #6: Sat Aug 14 09:23:46 EDT 2004:
: > 
: > lock order reversal
: > 1st 0xc18ae064 drm device (drm device) _at_ _at_/dev/drm/drm_irq.h:192
: > 2nd 0xc0872060 ACPI root bus (ACPI root bus) _at_ /usr/src/sys/modules/acpi/acpi/../../../dev/acpica/acpi.c:841
: > KDB: stack backtrace:
: > kdb_backtrace(c06c0eb4,c0872060,c086c28e,c086c28e,c086c693) at kdb_backtrace+0x2e
: > witness_checkorder(c0872060,9,c086c693,349,c06f0bc4) at witness_checkorder+0x6a6
: > _sx_xlock(c0872060,c086c693,349,c06f0ba0,40) at _sx_xlock+0x7e
: > acpi_release_resource(c1794680,c1742a00,1,0,c18046c0) at acpi_release_resource+0x2b
: > bus_generic_release_resource(c1742e00,c1742a00,1,0,c18046c0) at bus_generic_release_resource+0x82
: > resource_list_release(c1794084,c1801d00,c1742a00,1,0) at resource_list_release+0x84
: > bus_generic_rl_release_resource(c1801d00,c1742a00,1,0,c18046c0) at bus_generic_rl_release_resource+0x86
: > bus_generic_release_resource(c1802080,c1742a00,1,0,c18046c0) at bus_generic_release_resource+0x82
: > resource_list_release(c1794084,c1742e80,c1742a00,1,0) at resource_list_release+0x13b
: > bus_generic_rl_release_resource(c1742e80,c1742a00,1,0,c18046c0) at bus_generic_rl_release_resource+0x86
: > bus_release_resource(c1742a00,1,0,c18046c0,c18ae064) at bus_release_resource+0x7f
: > radeon_irq_uninstall(c18ae000,0,c1d85640,c0,c1d88130) at radeon_irq_uninstall+0x7b
: > radeon_control(c1ce8b00,80086414,d5de0c58,43,c19a22c0) at radeon_control+0x8d
: > radeon_ioctl(c1ce8b00,80086414,d5de0c58,43,c19a22c0) at radeon_ioctl+0x1f6
: > spec_ioctl(d5de0b80,d5de0c2c,c0590fc1,d5de0b80,1) at spec_ioctl+0x1ce
: > spec_vnoperate(d5de0b80,1,c06c6266,30e,c070f8a0) at spec_vnoperate+0x18
: > vn_ioctl(c19acd48,80086414,d5de0c58,c1d91480,c19a22c0) at vn_ioctl+0x1c1
: > ioctl(c19a22c0,d5de0d14,c,437,3) at ioctl+0x4f2
: > syscall(2840002f,bfbf002f,bfbf002f,8945400,8734000) at syscall+0x2a0
: > Xint0x80_syscall() at Xint0x80_syscall+0x1f
: > --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x2827000f, esp = 0xbfbfeadc, ebp = 0xbfbfeaf8 ---
: 
: I can't see how the radeon and acpi locks are interrelated.  Anyone else 
: have an idea?  The radeon call is just a simple:
: 
: bus_release_resource(dev->device, SYS_RES_IRQ, irqrid, dev->irqr);
: 
: Perhaps it's not ok to hold a sx lock while calling into the parent 
: (from acpi.c):
: 
: ret = BUS_RELEASE_RESOURCE(device_get_parent(bus), child, type, rid, r);

The lock is the ACPI root lock vs the drm lock. It appears that there
are two different code paths, one of which takes the drm lock first,
the other of which takes the acpi lock first.  My guess is that the
former is taken in the probe routine, while the latter is taken when
reconfiguring itself via ioctl at runtime.  One should look there for
the problems.

Warner