From owner-freebsd-current@FreeBSD.ORG Fri Jan 23 19:26:48 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 444AB106566C for ; Fri, 23 Jan 2009 19:26:48 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe11.tele2.se [212.247.155.65]) by mx1.freebsd.org (Postfix) with ESMTP id A2A5D8FC22 for ; Fri, 23 Jan 2009 19:26:47 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=nTib0wbUE7AA:10 a=J2nnhgZB8JEA:10 a=6I5d2MoRAAAA:8 a=BgLTMzI9XPk8trZRc9gA:9 a=hZqmzLOkog5fejotXWAA:7 a=41F6Q73lrYk4a1dNx3WkeRwJGlgA:4 a=50e4U0PicR4A:10 Received: from [85.19.218.115] (account mc467741@c2i.net HELO [10.37.1.92]) by mailfe11.swip.net (CommuniGate Pro SMTP 5.2.6) with ESMTPA id 1012633704; Fri, 23 Jan 2009 20:26:45 +0100 From: Hans Petter Selasky To: Maksim Yevmenkin Date: Fri, 23 Jan 2009 20:29:09 +0100 User-Agent: KMail/1.9.7 References: <20090123154336.GJ60948@e.0x20.net> <200901231714.39873.hselasky@c2i.net> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200901232029.10538.hselasky@c2i.net> Cc: Lars Engels , current@freebsd.org Subject: Re: panic: mutex Giant not owned at /usr/src/sys/kern/tty_ttydisc.c:1127 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2009 19:26:48 -0000 Hi Maksim, First of all I've made some patches which try to tidy up the USB blutooth driver. Please see: http://perforce.freebsd.org/chv.cgi?CH=156577 http://perforce.freebsd.org/chv.cgi?CH=156579 Maybe you can review this and consider it for commit to -current. My problem is that I do not fully understand Netgraph. > > that should not be needed (in theory) but i will add it. Yes! We are multithreaded! > > 2) You drain all USB transfers: "usb2_transfer_drain()" called unlocked. > > yes, usb2_transfer_unsetup() does that, does it not? That is correct, but sometimes you need to stop the transfers at an earlier point. It depends on your design. I see in your code that you try to do things Asynchronously. This complicates stuff quite a lot. In my patches I've tried to do some things synchronously. > > 3) Set the "sc_node" to NULL. > > yes, we do that too. > > i have lots of questions about stalled transfers. in any case, it > appears that my code is wrong when it comes to stalled transfers. in > particular, usb2_clear_stall_callback() returns 0 The return value of this function should not an error code. > in both USB_ST_SETUP > and default/error cases, so the code incorrectly clears node reference > in USB_ST_SETUP case. that needs to be fixed. Yes, I noticed that. > > i'm also deeply confused about error handling in transfers. in > particular, any error that is not USB_ERR_CANCELLED makes code to > assume that it was a stall and queue clear stall transfer. that is > clearly not the case when hardware is yanked while transfer is active. > in this case transfer callback seems to be called with USB_ERR_IOERROR > (or something like that). so, shouldn't we be safe and only queue > stall transfer if callback was in fact called with USB_ERR_STALLED? > 1) Any non-cancelled error goes through the standard clear-stall procedure. The clear stall transfers are niced for 50ms interval, see the "interval" field in the "usb2_config" structure! We do the clear stall, because it puts some delay between the error and the re-start of the transfers. We don't want to end up in a case where the transfer simply stops because of a silly CRC error. Or that we go into fast race with the hardware on errors. 2) "xfer->error" is never set at the same time you are in the transferred state. > the completely different question here is why stall happens in the first > place. 1) Cable signal error 2) Device sent a STALL PID. > > also as others pointed out, panic in ttydisc_getc is something else. Yepp. Maybe my P4 patches will help you? --HPS