Re: USB problems

John Birrell wrote:

>[ I'm not sure who the maintainer for FreeBSD's code is these days. ]
>

It's a consortium of time strapped people who have lots of other stuff 
to do :-)

>
>I've been encountering a number of problems with the USB implementation
>in current. Although this message refers to current, I think the problems
>are in RELENG_5 too.
>
>1. The USB sub-system doesn't handle loading and unloading drivers properly.
>   If a driver is unloaded when a USB device is still attached, the next
>   time the driver is loaded, the kernel panics. This might not be such
>   a problem to normal users because they don't have a need to do that, but
>   during driver development when you want to load and unload repeatedly,
>   it's a pain.
>
One would think it would refuse to unload if it was still in use..
possibly one for imp.. he's doing stuff in that part at the moment I think.

>
>2. I have two devices that are based on Philips' ISP1581 USB 2.0 controller.
>   Both are MPEG encoders and one has a TV tuner. The one without the
>   tuner is Philips' USB-MPEG2 evaluation board which has example firmware
>   on-board as a reference design. It isn't possible to use either of these
>   boards with FreeBSD's USB implementation because of the over-zealous
>   firmware code which stalls the control endpoint at every opportunity.
>

can you be a bi tmore explicit abuot what you mena by "stalls the 
control endpoint at
every opportunity".

The linux libusb has code in its' timeout code that "unstalls"
endpoints if they timeout. I p[resume becasue they have seen this as 
a common reason for timeouts. FreeBSD issues teh same command on 
endpoint open.. try closing and reopenning the endpoint.


>   The Windows driver that Philips' supply without source code appears to
>   have no problems talking to the device. When I do the same things with
>   FreeBSD, the continual control endpoint stalls result in not being
>   able to even get the string descriptors for manufacturer and product
>   (the firmware code stalls those requests).
>
>
>   I think what is happening is that the uhci (and ehci etc) drivers are
>   detecting the stall and not processing the data that is actually
>   returned with the stall status. When I move the code:

hmm I'll have to look at the spec to see if a stall status can 
come back with data?
There are two 'stalls'.. the endpoint stalls, and the local status 
word reflects that. (at least in EHCI), so you'd need to clear both.. 
one with a write and teh other with a memory write..

>   if (nstatus & UHCI_TD_ACTIVE)
>      break;
>
>>   in uhci_idone() to the bottom of the loop, it returns the actlen
>   properly (I think). At least I can get the data from the device despite
>   the stall.

can it then proceed?


>3. The usbd_bulk_transfer function calls tsleep() to wait for streaming
>   data to become available. On current, this bumps into a KASSERT in
>   msleep because Giant is not locked and no mutex has been supplied.
>   In my driver, I need to run an 'encoder' thread which calls
>   usbd_bulk_transfer() to gobble the incoming MPEG data stream. While
>   this is going on, there is no syscall in progress because the
>   application is off doing other things. It might be looking at the
>   mmaped buffer or it may not.
>
>   For FreeBSD, usbd_bulk_transfer() needs to change to allow the driver
>   to specify it's mutex. I don't know what the implications are for
>   uhci given that it hasn't been converted to use mutexes. Can anyone
>   comment on that?

> Where do we stand making architectural changes to the USB code given the
> efforts to stay in sync with NetBSD/OpenBSD?

I'm trying to address that issue right now..
If we can't bring netBSD withus in some architectural changes than at 
some stage we'll have to go it ourselves. Which I'd rather not do.. 
but they are hard to contact.. (probably also short of time)

> 
> I'd love to get rid of the attach_args structure and just pass a
> usbd_device_handle into the drivers, with struct usbd_device containing
> a couple of extra variables for use during matching.

sure.. there are a number of architectural changes "in the wings"
that I'd like ot thrash out with the NetBSD guys but I have found
it hard to find a forum to communicate with tehm on..
the suggestion "send a NetBSD PR" is the best I've got back so far..
Though they have seemed friendly enough.

> 
> I'd like to remove the subdevs array from struct usbd_device under
> FreeBSD because the parent/child device tree should only be managed by
> bus routines. The relationship between a USB device and it's device_t
> should just be a field in struct usbd_device and it should be cleared
> when there is no device_t. Leaving a device_t hanging around when a
> driver had been unloaded is what is causing the panics I am seeing.

talk to imp_at_

> 
> I think that the uhub driver should have a uhub_driver_added routine rather
> than using the generic one. I'd really like to see the uhub code re-match
> vendor/product codes when a new driver is added, and if the new driver
> matches, then uhub should detach ugen and use the new driver. Similarly,
> when a driver is unloaded, if a USB device is still present, it should go
> back to ugen.

yes yes yes etc.

>