Date: Fri, 3 Oct 2008 14:18:26 -0700 From: "Maksim Yevmenkin" <maksim.yevmenkin@gmail.com> To: vova@fbsd.ru Cc: freebsd-bluetooth@freebsd.org, usb@freebsd.org Subject: Re: Bluetooth audio - crash on USB bluetooth dongle disconnect Message-ID: <bb4a86c70810031418t5b9eef45p4d57b55f22c05715@mail.gmail.com> In-Reply-To: <1223067257.2362.6.camel@localhost> References: <3a386af20809261420j535680e8pf44453dbf6f84b20@mail.gmail.com> <bb4a86c70809261504v45ffe1a8oaf26670a1032e86c@mail.gmail.com> <1223034512.1842.111.camel@localhost> <bb4a86c70810030945g3d870a1eqacc85233d9698a66@mail.gmail.com> <1223067257.2362.6.camel@localhost>
next in thread | previous in thread | raw e-mail | index | archive | help
On 10/3/08, Vladimir Grebenschikov <vova@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bb4a86c70810031418t5b9eef45p4d57b55f22c05715>