Test (belated) of new umass driver

[Hans Petter Selasky]

On Sunday 26 November 2006 00:21, Peter Carah wrote:
> I just noticed today your call from a couple of months ago to try the new
> umass driver; just did so and noticed only a 2-3% improvement.  the sys and
> int times were all over the map so couldn't tell what to say about them. 
> (likely from running X doing all this :-)

If you have a faster memory stick, you should see more improvement.

>
> The problem removing active umass devices applies to *all* usb that have
> secondary drivers, though I presume you all know about that...

Yes. I have asked Scott Long to come up with a solution for it. So far no 
solution.

> umodem, 
> uftdi, uplcom all panic on removal if the secondary device is open.

Have you tried this with the new USB stack? I tried to fix these issues with 
all the drivers in the "UCOM" layer. Maybe you could send me a backtrace, if 
it still panics.

> I 
> presume this is due to a lack of callbacks into the secondary driver to
> cause it to clean up before the lower-level driver does.  Unfortunately I
> don't know what the inter-layer linkages look like and don't at the moment
> have much time to look into it.

The problem is simply that many abstraction layers in the kernel where not 
designed to allow device detach.

> (the worst one of these is my verizon card 
> which adds yet another extra layer - the usb ohci is a cardbus device...) 
> (and it used to panic whether or not the tty layer was open; something
> (probably newbus and the bus-dma stuff) fixed that).  Also I haven't seen
> anything about this on the mailing list for the last month or so.  At least
> the new driver works.
>
> I also have problems with data transfers on libusb+ugen, on every device I
> have that needs libusb; this includes two cameras, a scanner, and a
> tripp-lite ups. The device opens properly but transfers either time out or
> fail.  I don't know if the new structure is likely to help there...  (btw
> this happens on 3 different computers with totally different I/O
> structures; this laptop, whose dmesg appears below, one with an Intel 865
> board, and a soekris (on which I've only tried the ups...)
> UMASS works fine with one of the cameras, so I think this is a fbsd-side
> problem.

Did you have the same problems before with libusb+ugen ?

Thanks for testing,
--HPS