On Thu, 13 Mar 2025 10:13:58 +0100,
Martin Pieuchot <mpi@grenadille.net> wrote:
> 
> On 13/03/25(Thu) 09:59, Kirill A. Korinsky wrote:
> > tech@,
> > 
> > I had discovered one more crash which can be triggered by an application
> > when it sends ioctl(VIDIOC_STREAMOFF) into streaming isco webcam, or
> > when the device is detached.
> > 
> > To avoid such crash I'd like to add requirements that pipe is still
> > open, before parse header, or schedule a new isoc transfer.
> 
> All these checks look like workarounds to me.  Could you describe what
> is happening?  Would you mind sharing the panic trace?  What race is
> this diff working around?
> 

This is addresses this issue (text is OCRed but looks without too many typos):

        ~ $ pkill ffplay
        ~ $ video0 detached
        uvideo0 detached
        panic: uvm_fault failed: ffffff00003a9cd0 esr 96000004 far dead007fdead0f3?
        Stopped at      panic+0x140:     cmp     w21, #0x0
             TID     PID     UID   PRFLAGS    PFLAGS  CPU COMMAND
          326064   47722      35      0x12         0    1 Xorg
          522716   17327       0    0x14000     0x200    4 softclockhp
        db_enter() at panic+0x13c
        panic() at kdata_abort+0x170
        kdata_abort() at handle_el1h_sync+0x68
        handle_el1h_sync() at usbd_free_xfer+0x58
        usbd_free_xfer() at uvideo_vs_free_isoc+0x48
        uvideo_vs_free_isoc() at uvideo_close+0xc4
        uvideo_close() at videoclose+0x64

I had run ffplay which stream from a webcam in X11, switched to console,
deattached cam and tries to kill ffplay.

And system crash or frozen.

I do have a few similar workarounds which allows me to suceffuly deatach
this webcam when it streams without crash or freeze system.

I had dig into wtf is going on, and seems that xhci controller starts to
send really a lot of xfer packets when device is detached.

And when I had tried to kill ffplay... well, it leads to crashed.

It has a few places which I had, locally, workedaroud, and one of the
notable example is https://marc.info/?l=openbsd-tech&m=174180759929893&w=2
Without this, it calls video_stop after device is detached and it is blocked
on mutex. I had logged an owner of the mutex a few times before it
completley frozen, and it was 0x10000001e, 0x10000001d or similar values.

-- 
wbr, Kirill