Re: firewire panic

On Sun, 13 Nov 2016 23:56:09 +0200
Andriy Gapon <avg_at_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