From owner-freebsd-current@FreeBSD.ORG Fri May 4 18:49:57 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 7899016A401 for ; Fri, 4 May 2007 18:49:57 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.168]) by mx1.freebsd.org (Postfix) with ESMTP id 0B10D13C45D for ; Fri, 4 May 2007 18:49:56 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by ug-out-1314.google.com with SMTP id 71so589564ugh for ; Fri, 04 May 2007 11:49:55 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:reply-to:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding:sender; b=iaHbrbY/ln+SciJ4mkXSdJbNS4OawfBCnfv7z0CIHR//wAoVcgP2A8p0Pa067RRB8VU7Ohpec+D5KDc/3GnY5z+D/iWvwZR3eZKO41SA97r9/WY3vMwqgkRHJ2Jhg3nDnM1raHo+DlUJzmp41kt0Ql6Ju9rppLGvxg5uMIp8Jmc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:reply-to:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding:sender; b=EwPnNNlK6XG8YUhf7WZfziUVG0nyyn4KKc+xa/w7UHvGURltIexx7sGnuaLopaqHZ2uf1Y3ijG8ZbhsOMaDAnyiDF0B26kkZSy2mvxbXHonYAEtv3tqg3cZvMQr6Rgkr7KIvLAI9vSmRPH3S/g8wqU5jb6T12epTniGfATjpEpg= Received: by 10.67.27.15 with SMTP id e15mr507437ugj.1178304595863; Fri, 04 May 2007 11:49:55 -0700 (PDT) Received: from ?151.75.229.145? ( [151.75.229.145]) by mx.google.com with ESMTP id l40sm4757429ugc.2007.05.04.11.49.54; Fri, 04 May 2007 11:49:54 -0700 (PDT) Message-ID: <463BF1A7.1050504@FreeBSD.org> Date: Sat, 05 May 2007 04:53:27 +0200 From: Attilio Rao User-Agent: Thunderbird 1.5 (X11/20060526) MIME-Version: 1.0 To: Harald Schmalzbauer References: <463B7A1D.6020602@omnisec.de> In-Reply-To: <463B7A1D.6020602@omnisec.de> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Sender: Attilio Rao Cc: freebsd-current@freebsd.org 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 Reply-To: attilio@FreeBSD.org 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 18:49:57 -0000 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. Thanks, Attilio