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

hello,

> Maksim has made a lot of changes to the Bluetooth driver. Maybe he can look
> into it?

yes, i will take a look at it.
>
> This looks like a NULL-pointer access to me.
>
> Maksim:
>
> In the ubt_detach routine, make sure that:
>
> 0) No further commands are accepted from the Netgraph stack.

yes, we do that.

> 1) You drain the task queue!

that should not be needed (in theory) but i will add it.

> 2) You drain all USB transfers: "usb2_transfer_drain()" called unlocked.

yes, usb2_transfer_unsetup() does that, does it not?

> 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 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.

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?

the completely different question here is why stall happens in the first place.

also as others pointed out, panic in ttydisc_getc is something else.

thanks,
max