armv7 BETA3 panics when usb-disk inserted

[Warner Losh]

On Sun, Nov 4, 2018 at 12:55 AM Poul-Henning Kamp <phk at phk.freebsd.dk>
wrote:

> With the 12.0-BETA3 BEAGLEBONE image, I very often see this panic
> when I plug a USB attached SSD disk in.
>
...

>        umass0 on uhub0
>         umass0: <Seagate USB 2.0 Cable, class 0/0, rev 2.00/1.48, addr 2>
> on usbus1
>         umass0:  SCSI over Bulk-Only; quirks = 0x8100
>         umass0:0:0: Attached to scbus0
>         da0 at umass-sim0 bus 0 scbus0 target 0 lun 0
>         da0: <Seagate USB 2.0 Cable 0148> Fixed Direct Access SPC-2 SCSI
> device
>         da0: Serial Number 2HC015KJ
>         da0: 40.000MB/s transfers
>         da0: 38166MB (78165359 512 byte sectors)
>         da0: quirks=0x2<NO_6_BYTE>
>         panic: _mtx_lock_sleep: recursed on non-recursive mutex CAM device
> lock @ /usr/src/sys/cam/scsi/scsi_da.c:2123
> ...
>         db_trace_self() at db_trace_self
>
        db_trace_self_wrapper() at db_trace_self_wrapper+0x30
>         vpanic() at vpanic+0x16c
>         doadump() at doadump
>         __mtx_unlock_flags() at __mtx_unlock_flags
>         __mtx_lock_flags() at __mtx_lock_flags+0xec
>         daasync() at daasync+0x5c
>

This is line 2123


>         xpt_async_process_dev() at xpt_async_process_dev+0x220
>         xptdevicetraverse() at xptdevicetraverse+0xa4
>         xpttargettraverse() at xpttargettraverse+0x7c
>         $a.10() at $a.10+0x148
>

I love our new kang overlords. Glad I didn't vote for kodos...


>         xpt_done_process() at xpt_done_process+0x3c4
>         xpt_done_td() at xpt_done_td+0xec
>

So we're doing a walk of the scsi/sata namespace for the umass SIM and
we're calling daasync with a lock it expects to take out. The whole locking
stuff here is "a bit complicated" so I'll see why we're hitting this case
and at the same time simplify.

I'll see if I can recreate this bug here...

Warner