From owner-freebsd-current@FreeBSD.ORG Fri May 4 19:47:06 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 6382B16A401; Fri, 4 May 2007 19:47:06 +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 DC26513C48A; Fri, 4 May 2007 19:47:05 +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 l44Jkvpw050250; Fri, 4 May 2007 15:47:01 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: attilio@freebsd.org Date: Fri, 4 May 2007 15:46:50 -0400 User-Agent: KMail/1.9.6 References: <463B7A1D.6020602@omnisec.de> <463BF1A7.1050504@FreeBSD.org> In-Reply-To: <463BF1A7.1050504@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200705041546.50690.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 15:47:01 -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 19:47:06 -0000 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. > However I wonder, it is right to let sleepable lock to arise a WITNESS > exception if the lock is acquired in a critical section? > I can understand this is a simple way to detect if a spinlock has been > previously called, but this leads to the 'false positive' case in which > we can have something like: > > critical_enter(); > sx_xlock(&lock1); > etc.etc. This is wrong because once you do critical_enter(), you are free to assume that you won't do a context switch until you critical_exit(), and sx_xlock() would violate that if it blocked on the lock. -- John Baldwin