On Sun, Nov 06, 2016 at 02:17:45PM +0100, Michael Tuexen wrote: > > On 6 Nov 2016, at 13:28, Konstantin Belousov <kostikbel_at_gmail.com> wrote: > > > > 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 = 0 (0xfffffe0000e2f008) locked _at_ 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 > >> > >> ... and so on. Not sure which revision introduced it... > > r308268 > > > > 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... I am really not sure. Looking at the svn history is not very encouraging. Might be try freebsd-scsi_at_ as well.Received on Sun Nov 06 2016 - 13:39:18 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:08 UTC