Re: panic: mutex Giant not owned at /usr/src/sys/kern/tty_ttydisc.c:1127

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