panic: mutex Giant not owned at
/usr/src/sys/kern/tty_ttydisc.c:1127
Hans Petter Selasky
hselasky at c2i.net
Fri Jan 23 11:26:48 PST 2009
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
More information about the freebsd-current
mailing list