From owner-freebsd-current@FreeBSD.ORG Tue Aug 17 19:57:38 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EDD7A16A4CE for ; Tue, 17 Aug 2004 19:57:37 +0000 (GMT) Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id D0F5143D1F for ; Tue, 17 Aug 2004 19:57:37 +0000 (GMT) (envelope-from eta@lclark.edu) Received: from [192.168.0.103] (c-24-21-18-195.client.comcast.net[24.21.18.195]) by comcast.net (rwcrmhc13) with SMTP id <2004081719573601500s817ie>; Tue, 17 Aug 2004 19:57:37 +0000 From: Eric Anholt To: "M. Warner Losh" In-Reply-To: <20040817.134957.35663556.imp@bsdimp.com> References: <20040817014828.GA12921@tadpole.intranet> <20040817.134957.35663556.imp@bsdimp.com> Content-Type: text/plain Message-Id: <1092772654.928.12.camel@leguin> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 17 Aug 2004 12:57:35 -0700 Content-Transfer-Encoding: 7bit cc: current@freebsd.org cc: nate@root.org Subject: Re: LOR (drm,acpi) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2004 19:57:38 -0000 On Tue, 2004-08-17 at 12:49, M. Warner Losh wrote: > 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. I had a hard time getting any review when adding locking to the DRM. I suspect that I made the mistake of holding the lock while calling into other subsystems in some cases. I could probably get things fixed up now (having learned more, and having more examples available), but unfortunately I'm consumed with critical bugfixes for the next X.Org release and moving to a new house. -- Eric Anholt eta@lclark.edu http://people.freebsd.org/~anholt/ anholt@FreeBSD.org