From owner-freebsd-usb@FreeBSD.ORG Fri Oct 3 21:47:35 2008 Return-Path: Delivered-To: usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A0C7B1065686 for ; Fri, 3 Oct 2008 21:47:35 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.187]) by mx1.freebsd.org (Postfix) with ESMTP id 2CE068FC15 for ; Fri, 3 Oct 2008 21:47:34 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: by nf-out-0910.google.com with SMTP id h3so746878nfh.33 for ; Fri, 03 Oct 2008 14:47:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=/6x2r+sCwqZPvBzccd/CqFJck+ZtF/7FwupKS60LBvI=; b=MWVUIjvFea3TaasNCshvI9irFjEDLse/6ItC8gm8e9JfcJYQQdmZmybFKjcZirp+cX l2P1JtqTGckFZTX/p4YAKJGTmIiQMiSsteuM9D5GeHQFUArLBoeCPzna/cc6CYUvGBmN KyuRfnb8hBbIdA5lwN3Ac1eKLfrL93Chf1J9o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=Nh004ieSDEuS7XKylM/Scv1OwgNXIxR1+Sr4TGuxDh53Loo+0OvD5CD6AFBPrgo+Zw EXgy7qE1aO5otmqXWexTcFqtiTcuCHOMD7vIAQq+PC9V3qCI3dsoeerhkO33bG3pijMf w+dXuq5XWnHoJMwE0JJ1rhb8+Bhur5zMUeJF4= Received: by 10.86.62.3 with SMTP id k3mr1739424fga.1.1223068706237; Fri, 03 Oct 2008 14:18:26 -0700 (PDT) Received: by 10.86.62.1 with HTTP; Fri, 3 Oct 2008 14:18:26 -0700 (PDT) Message-ID: Date: Fri, 3 Oct 2008 14:18:26 -0700 From: "Maksim Yevmenkin" To: vova@fbsd.ru In-Reply-To: <1223067257.2362.6.camel@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <3a386af20809261420j535680e8pf44453dbf6f84b20@mail.gmail.com> <1223034512.1842.111.camel@localhost> <1223067257.2362.6.camel@localhost> Cc: freebsd-bluetooth@freebsd.org, usb@freebsd.org, Federico Lorenzi Subject: Re: Bluetooth audio - crash on USB bluetooth dongle disconnect X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2008 21:47:35 -0000 On 10/3/08, Vladimir Grebenschikov 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