On 14/11/2016 11:58, Gary Jennejohn wrote: > On Sun, 13 Nov 2016 23:56:09 +0200 > Andriy Gapon <a...@freebsd.org> wrote: > >> On 11/11/2016 14:25, Andriy Gapon wrote: >>> panic: mutex sbp not owned at /usr/src/sys/dev/firewire/sbp.c:967 >>> cpuid = 2 >>> curthread: 0xfffff8000ada5000 >>> stack: 0xfffffe0504ded000 - 0xfffffe0504df1000 >>> stack pointer: 0xfffffe0504df0a00 >>> KDB: stack backtrace: >>> db_trace_self_wrapper() at 0xffffffff80420bbb = >>> db_trace_self_wrapper+0x2b/frame >>> 0xfffffe0504df0930 >>> kdb_backtrace() at 0xffffffff80670359 = kdb_backtrace+0x39/frame >>> 0xfffffe0504df09e0 >>> vpanic() at 0xffffffff8063986c = vpanic+0x14c/frame 0xfffffe0504df0a20 >>> panic() at 0xffffffff806395b3 = panic+0x43/frame 0xfffffe0504df0a80 >>> __mtx_assert() at 0xffffffff8061c40d = __mtx_assert+0xed/frame >>> 0xfffffe0504df0ac0 >>> sbp_cam_scan_lun() at 0xffffffff80474667 = sbp_cam_scan_lun+0x37/frame >>> 0xfffffe0504df0af0 >>> xpt_done_process() at 0xffffffff802aacfa = xpt_done_process+0x2da/frame >>> 0xfffffe0504df0b30 >>> xpt_done_td() at 0xffffffff802ac2e5 = xpt_done_td+0xd5/frame >>> 0xfffffe0504df0b80 >> >> So, it's pretty obvious that the sbp mutex can not be held when >> sbp_cam_scan_lun() is called. >> > > The code seems to assume that the scan_callout callout is still > holding the mutex when sbp_cam_scan_lun() is entered. > > Seems reasonable, since the man page claims that the callout routine > keeps the mutex locked until the callout function, in this case that's > sbp_cam_scan_target(), returns. Since sbp_cam_scan_target() invokes > xpt_action() with sbp_cam_scan_lun() as its callback, it seems like > the assumption should be true.
The wrong assumption in your reasoning is that the callback is executed in the same thread. > Pehaps there's some asynchronous action happening with the > firewire code which is releasing the mutex prematurely. > > Or maybe the sbp used in sbp_cam_scan_lun() is wrong? Dunno. -- Andriy Gapon _______________________________________________ email@example.com mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"