Date: Sun, 26 Nov 2006 11:17:50 +0100 From: Hans Petter Selasky <hselasky@c2i.net> To: Peter Carah <pete@altadena.net> Cc: usb@freebsd.org Subject: Re: Test (belated) of new umass driver Message-ID: <200611261117.51441.hselasky@c2i.net> In-Reply-To: <4568CFDD.9030004@altadena.net> References: <4568CFDD.9030004@altadena.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200611261117.51441.hselasky>