From owner-freebsd-current@FreeBSD.ORG Fri May 4 20:50:13 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C619316A401; Fri, 4 May 2007 20:50:13 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 71A3213C4AD; Fri, 4 May 2007 20:50:12 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from phobos.samsco.home (phobos.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.8/8.13.8) with ESMTP id l44Ko9oK074260; Fri, 4 May 2007 14:50:10 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <463B9C7E.2080901@samsco.org> Date: Fri, 04 May 2007 14:50:06 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.2pre) Gecko/20070111 SeaMonkey/1.1 MIME-Version: 1.0 To: John Baldwin References: <463B7A1D.6020602@omnisec.de> <200705041546.50690.jhb@freebsd.org> <463C01B4.9050802@FreeBSD.org> <200705041637.38955.jhb@freebsd.org> In-Reply-To: <200705041637.38955.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (pooker.samsco.org [168.103.85.57]); Fri, 04 May 2007 14:50:10 -0600 (MDT) X-Spam-Status: No, score=-1.4 required=5.5 tests=ALL_TRUSTED autolearn=failed version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: attilio@freebsd.org, freebsd-current@freebsd.org, Harald Schmalzbauer Subject: Re: PANIC: blockable slep lock (sx) msi @ ....msi.c:374 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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: Fri, 04 May 2007 20:50:14 -0000 John Baldwin wrote: > On Saturday 05 May 2007 12:01:56 am Attilio Rao wrote: >> John Baldwin wrote: >>> On Friday 04 May 2007 10:53:27 pm Attilio Rao wrote: >>>> Harald Schmalzbauer wrote: >>>>> Hello, >>>>> >>>>> recent changes (during the last 2 days,I guess tha acpi stuff) broke >>>>> -current for me: >>>>> >>>>> ad6: 476940MB at ata3-master SATA300 >>>>> SMP: AP CPU #1 Launched! >>>>> panic: blockable sleep lock (sx) msi @ >>>>> /FlashBSD/src/sys/i386/i386/msi.c:374 >>>>> cpuid = 0 >>>>> KDB: enter: panic >>>>> [thread pid 0 tid 0 ] >>>>> Stopped at kdb_enter+0x30: leave >>>>> db> bt >>>>> Tracing pid 0 tid 0 td 0xc07c2d60 >>>>> kdb_enter(c07422df,0,c0746e47,c1420bdc,c07c2d60,...) at kdb_enter+0x30 >>>>> panic(c0746e47,c073180d,c0732bb2,c0764c8e,176,...) at panic+0x135 >>>>> witness_checkorder(c082f0fc,1,c0764c8e,176,c55c0980,...) at >>>>> witness_checkorder+0xd6 >>>>> _sx_slock(c082f0fc,c0764c8e,176,c1420c64,c06f7e65,...) at _sx_slock+0x5f >>>>> msi_map(100,c1420d08,c1420d04,c1420c94,c04b5cc5,...) at msi_map+0x22 >>>>> nexus_map_msi(c5552000,c55e4000,100,c1420d08,c1420d04,...) at >>>>> nexus_map_msi+0x1f >>>>> pcib_map_msi(c55d9080,c55e4000,100,c1420d08,c1420d04,...) at >>>>> pcib_map_msi+0x86 >>>>> pcib_map_msi(c55e4200,c55e4000,100,c1420d08,c1420d04,...) at >>>>> pcib_map_msi+0x86 >>>>> pci_remap_msi_irq(c55e4000,100,c06ecb73,c54fff78,100,...) at >>>>> pci_remap_msi_irq+0xeb >>>>> msi_assign_cpu(c55e6240,0,100,c079d170,c1420d70,...) at >>> msi_assign_cpu+0x68 >>>>> intr_assign_next_cpu(c55e6240,0,c07631d3,1c7,c54f3a44,...) at >>>>> intr_assign_next_cpu+0x23 >>>>> intr_shuffle_irqs(0,141e000,141ec00,141e000,0,...) at >>>>> intr_shuffle_irqs+0x5e >>>>> mi_startup() at mi_startup+0xa0 >>>>> begin() at begin+0x2c >>>> In this case the culprit is intr_table_lock spinlock I think. >>>> This can be fixed switching the msi lock to be a spinlock instead than a >>>> sx lock. >>> Actually, I think the real fix is I need to better handle the locking for >>> assigning interrupts to CPUs. >> I have a question. >> Why you currently use a sx lock? There are places where msi functions >> can sleep? > > malloc M_WAITOK, and considering how rarely this stuff is called (just during > attach routines for drivers during boot) I didn't consider it important > enough to do something more complicated. > Well, you were just using it as a hack around a WITNESS warning ;-) I think it's OK for memory allocations to fail in this kind of code, so long as the failure is propagated to the caller. Scott