From owner-freebsd-current@FreeBSD.ORG Fri May 4 20:07:12 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 4FDC616A400 for ; Fri, 4 May 2007 20:07:12 +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 D115513C44C for ; Fri, 4 May 2007 20:07:11 +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 l44K78RU074090; Fri, 4 May 2007 14:07:08 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <463B9268.1040305@samsco.org> Date: Fri, 04 May 2007 14:07:04 -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: attilio@freebsd.org References: <463B7A1D.6020602@omnisec.de> <463BF1A7.1050504@FreeBSD.org> In-Reply-To: <463BF1A7.1050504@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:07:08 -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: 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:07:12 -0000 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. > > 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. > When a CPU enters a critical section, it basically won't be allowed to run a different thread than the current one, the only exception being for bottom half interrupt handlers (note that an ithread is not a bottom half interrupt handler). So it simply doesn't make sense to do an action that is meant to reschedule you to another thread when you've just signaled that you don't want to reschedule. The real problem is that infrastructure code like MSI should not hold locks across calls to consumer code. That's what needs to be fixed, not hacks to WITNESS. Scott