From owner-freebsd-current@FreeBSD.ORG Fri May 4 20:37:49 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 856BA16A400; Fri, 4 May 2007 20:37:49 +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 0D11C13C458; Fri, 4 May 2007 20:37:48 +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 l44KbkZp050571; Fri, 4 May 2007 16:37:47 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: attilio@freebsd.org Date: Fri, 4 May 2007 16:37:38 -0400 User-Agent: KMail/1.9.6 References: <463B7A1D.6020602@omnisec.de> <200705041546.50690.jhb@freebsd.org> <463C01B4.9050802@FreeBSD.org> In-Reply-To: <463C01B4.9050802@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200705041637.38955.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 16:37:47 -0400 (EDT) X-Virus-Scanned: ClamAV 0.88.3/3205/Fri May 4 06:50:21 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: 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:37:49 -0000 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. -- John Baldwin