Bluetooth audio - crash on USB bluetooth dongle disconnect

[Maksim Yevmenkin]

On 10/3/08, Vladimir Grebenschikov <vova at fbsd.ru> wrote:
> On Fri, 2008-10-03 at 09:45 -0700, Maksim Yevmenkin wrote:
>
>  > now you can connect your bluetooth device. kick tires and make sure
>  > you can do inquiry etc. then simply pull the device out _without_
>  > stopping the stack first. at least on my system it often leads to
>  > panic after a few seconds.
>
>  First of all it crashes on disconnect with big probability even without
>  btsock_sco.

yes, i know. isoc transfers seems to be triggering it

>  For me it crashes in uhci interrupt handler on NULL de-reference
>
>  trace shows something like:
>  usb_transfer_complete
>  uhci_transfer_complete
>  ...
>
>  digging a bit shows that it crashes in uhci.c:2575
>
>  usbd_status
>  uhci_device_isoc_start(usbd_xfer_handle xfer)
>  {
>         struct uhci_pipe *upipe = (struct uhci_pipe *)xfer->pipe;
>         uhci_softc_t *sc = (uhci_softc_t *)upipe->pipe.device->bus;
>
>  with upipe = NULL on interrupt
>
>  Looks like it is result of locking changes in usb stack or like.
>
>  Usb folks, can anybody give a hint what is the reason of such crash ?
>
>  PS: I have SMP system.

one thing that is different from interrupt and bulk transfers is that
ng_ubt(4) always has multiple outstanding incoming isoc transfers.
when device is simply pulled out, there is not much driver can do. if
i enable debugging i can see my transfer completion routine called
with ioerror status or something like that. so, i suspect this is a
cleanup issue. i'm not sure who supposed to do the cleanup in this
case driver or stack.

in any case,  can you verify that ubt_reset() is called when device is
pulled out? (it should be called as part of hook disconnect). if not -
then please try to call ubt_reset() from ubt_detach() just before
closing all the pipes.

thanks,
max