> 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... Best regards MichaelReceived on Sun Nov 06 2016 - 12:17:51 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:08 UTC