From owner-freebsd-acpi@FreeBSD.ORG Tue Aug 17 19:50:51 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 713C816A4CF; Tue, 17 Aug 2004 19:50:51 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id EED3443D1F; Tue, 17 Aug 2004 19:50:50 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.11/8.12.11) with ESMTP id i7HJnutS079283; Tue, 17 Aug 2004 13:49:56 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Tue, 17 Aug 2004 13:49:57 -0600 (MDT) Message-Id: <20040817.134957.35663556.imp@bsdimp.com> To: nate@root.org From: "M. Warner Losh" In-Reply-To: <41224990.9050008@root.org> References: <20040817014828.GA12921@tadpole.intranet> <41224990.9050008@root.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: acpi@freebsd.org cc: current@freebsd.org Subject: Re: LOR (drm,acpi) X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2004 19:50:51 -0000 In message: <41224990.9050008@root.org> Nate Lawson 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) @ @/dev/drm/drm_irq.h:192 : > 2nd 0xc0872060 ACPI root bus (ACPI root bus) @ /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