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. 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. -- Gary Jennejohn _______________________________________________ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
