Date: Fri, 23 Jan 2009 20:29:09 +0100 From: Hans Petter Selasky <hselasky@c2i.net> To: Maksim Yevmenkin <maksim.yevmenkin@gmail.com> Cc: Lars Engels <lme@freebsd.org>, current@freebsd.org Subject: Re: panic: mutex Giant not owned at /usr/src/sys/kern/tty_ttydisc.c:1127 Message-ID: <200901232029.10538.hselasky@c2i.net> In-Reply-To: <bb4a86c70901230947kca3036bycb88caefd5414b2b@mail.gmail.com> References: <20090123154336.GJ60948@e.0x20.net> <200901231714.39873.hselasky@c2i.net> <bb4a86c70901230947kca3036bycb88caefd5414b2b@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200901232029.10538.hselasky>