From owner-freebsd-acpi@FreeBSD.ORG Tue Aug 17 18:08:18 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 5CA4C16A4CE; Tue, 17 Aug 2004 18:08:18 +0000 (GMT) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 26EA143D2F; Tue, 17 Aug 2004 18:08:18 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.0.34] (adsl-67-127-84-57.dsl.snfc21.pacbell.net [67.127.84.57]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id i7HI8H8U015333; Tue, 17 Aug 2004 11:08:17 -0700 Message-ID: <41224990.9050008@root.org> Date: Tue, 17 Aug 2004 11:08:16 -0700 From: Nate Lawson User-Agent: Mozilla Thunderbird 0.7 (X11/20040702) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alex Vasylenko References: <20040817014828.GA12921@tadpole.intranet> In-Reply-To: <20040817014828.GA12921@tadpole.intranet> Content-Type: text/plain; charset=us-ascii; format=flowed 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 18:08:18 -0000 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); -Nate