Thanks for the report.
> ddb{0}>
> memcpy(ffff800000165000,fffffd804da1f728,8d8,ffff800000165000,b5bd47118
> ed5c95a,ffff800000165000) at memcpy+0x15
> uvideo_vs_cb(fffffd80778f2870,ffff8000001667d8,0) at uvideo_vs_cb+0x8b
> usb_transfer_complete(fffffd80778f2870) at usb_transfer_complete+0x20f
> xhci_event_dequeue(ffff8000000af000) at xhci_event_dequeue+0x103
> xhci_softintr(ffff8000000af000) at xhci_softintr+0x2d
> softintr_dispatch(1) at softintr_dispatch+0xf2
> Xsoftnet(0,ffffffff819c05e0,0,18041969,80,a) at Xsoftnet+0x1f
> Xspllower(0,0,c7ef80837208d4cc,ffff80000159c000,ffffffff81983ee1,708000) at
> Xsp
> llower+0x19
> free(ffff80000159c000,2,708000) at free+0x160
> uvideo_detach(ffff800000165000,1) at uvideo_detach+0x71
> config_detach(ffff800000165000,1) at config_detach+0x152
> usbd_detach(ffff800000137500,ffff800000086d00) at usbd_detach+0x5a
> uhub_port_connect(ffff800000086d00,4,2a0,286) at uhub_port_connect+0x68
> uhub_explore(ffff8000000a9500) at uhub_explore+0x23d
> usb_explore(ffff8000000a9400) at usb_explore+0x12b
> usb_task_thread(ffff80001f8efb30) at usb_task_thread+0x10b
> end trace frame: 0x0, count: -16
> ddb{0}>
> memcpy(ffff800000165000,fffffd804da1f728,8d8,ffff800000165000,b5bd47118
It seems that the pipe aren't close when uvideo_detach() is called.
This is similar to the recent race fixed in uhidev(4). It would be
great to find a generic way of handling this situation.
uhidev_detach() calls vdevgone() for example...
