From owner-freebsd-current@FreeBSD.ORG Fri May 4 21:49:20 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 948BB16A400; Fri, 4 May 2007 21:49:20 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.freebsd.org (Postfix) with ESMTP id 23D8913C43E; Fri, 4 May 2007 21:49:20 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.8/8.13.8) with ESMTP id l44LnGHu050957; Fri, 4 May 2007 17:49:16 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: Scott Long Date: Fri, 4 May 2007 17:48:56 -0400 User-Agent: KMail/1.9.6 References: <463B7A1D.6020602@omnisec.de> <200705041637.38955.jhb@freebsd.org> <463B9C7E.2080901@samsco.org> In-Reply-To: <463B9C7E.2080901@samsco.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200705041748.56842.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Fri, 04 May 2007 17:49:17 -0400 (EDT) X-Virus-Scanned: ClamAV 0.88.3/3206/Fri May 4 15:42:28 2007 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx 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 21:49:20 -0000 On Friday 04 May 2007 04:50:06 pm Scott Long wrote: > 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. Do you really expect bus_alloc_resource()-type things to fail to attach a driver instead of waiting for the system to free up some memory? Most of that sort of thing is quite resilient right now, and I'm hesitant to make the system start breaking things instead of waiting when memory runs low. -- John Baldwin