Date: Sat, 04 Oct 2008 00:54:17 +0400 From: Vladimir Grebenschikov <vova@fbsd.ru> To: Maksim Yevmenkin <maksim.yevmenkin@gmail.com> Cc: freebsd-bluetooth@freebsd.org, usb@freebsd.org Subject: Re: Bluetooth audio - crash on USB bluetooth dongle disconnect Message-ID: <1223067257.2362.6.camel@localhost> In-Reply-To: <bb4a86c70810030945g3d870a1eqacc85233d9698a66@mail.gmail.com> References: <3a386af20809261420j535680e8pf44453dbf6f84b20@mail.gmail.com> <bb4a86c70809261504v45ffe1a8oaf26670a1032e86c@mail.gmail.com> <1223034512.1842.111.camel@localhost> <bb4a86c70810030945g3d870a1eqacc85233d9698a66@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
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.
> thanks,
> max
--
Vladimir B. Grebenschikov
vova@fbsd.ru
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1223067257.2362.6.camel>