From owner-freebsd-current@freebsd.org Sun Nov 6 13:17:51 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 570E3C335BA for ; Sun, 6 Nov 2016 13:17:51 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.franken.de", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1FC253BF for ; Sun, 6 Nov 2016 13:17:50 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from [192.168.1.101] (p508F1FA4.dip0.t-ipconnect.de [80.143.31.164]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id 83B8E721E281A; Sun, 6 Nov 2016 14:17:47 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Subject: Re: New warnings from WITNESS From: Michael Tuexen In-Reply-To: <20161106122802.GA54029@kib.kiev.ua> Date: Sun, 6 Nov 2016 14:17:45 +0100 Cc: FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: References: <20161106122802.GA54029@kib.kiev.ua> To: Konstantin Belousov X-Mailer: Apple Mail (2.3251) X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=disabled version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail-n.franken.de X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 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: Sun, 06 Nov 2016 13:17:51 -0000 > On 6 Nov 2016, at 13:28, Konstantin Belousov = wrote: >=20 > On Sun, Nov 06, 2016 at 12:50:12PM +0100, Michael Tuexen wrote: >> bus_dmamap_create with the following non-sleepable locks held: >> exclusive sleep mutex mpt (mpt) r =3D 0 (0xfffffe0000e2f008) locked @ = dev/mpt/mpt.c:2287 >> stack backtrace: >> #0 0xffffffff80ac0300 at witness_debugger+0x70 >> #1 0xffffffff80ac15e7 at witness_warn+0x3d7 >> #2 0xffffffff81055fef at bus_dmamap_create+0x2f >> #3 0xffffffff80678a25 at mpt_configure_ioc+0x3a5 >> #4 0xffffffff80677476 at mpt_attach+0x226 >> #5 0xffffffff80683299 at mpt_pci_attach+0x9c9 >> #6 0xffffffff80a9478d at device_attach+0x41d >> #7 0xffffffff80a9595a at bus_generic_attach+0x4a >> #8 0xffffffff806ebe75 at pci_attach+0xd5 >> #9 0xffffffff80a9478d at device_attach+0x41d >> #10 0xffffffff80a9595a at bus_generic_attach+0x4a >> #11 0xffffffff803c11a2 at acpi_pcib_acpi_attach+0x402 >> #12 0xffffffff80a9478d at device_attach+0x41d >> #13 0xffffffff80a9595a at bus_generic_attach+0x4a >> #14 0xffffffff803b4c8f at acpi_attach+0xdbf >> #15 0xffffffff80a9478d at device_attach+0x41d >> #16 0xffffffff80a9595a at bus_generic_attach+0x4a >> #17 0xffffffff80ee03e3 at nexus_acpi_attach+0x73 >>=20 >> ... and so on. Not sure which revision introduced it... > r308268 >=20 > I believe that this is an mpt(4) driver issue, which calls > bus_dmamap_create(9) with the mpt mutex held. OK. Whom to contact? Or are you willing to look into it? I haven't worked in that area... Best regards Michael