From owner-freebsd-usb@FreeBSD.ORG Sun Nov 26 10:18:14 2006 Return-Path: X-Original-To: usb@freebsd.org Delivered-To: freebsd-usb@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E38BD16A4B3 for ; Sun, 26 Nov 2006 10:18:14 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe11.swip.net [212.247.155.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 91EA643D67 for ; Sun, 26 Nov 2006 10:17:20 +0000 (GMT) (envelope-from hselasky@c2i.net) X-T2-Posting-ID: 1yoZIIrJifi9k2x23EpYZw== X-Cloudmark-Score: 0.000000 [] Received: from [193.217.132.116] (account mc467741@c2i.net HELO [10.0.0.249]) by mailfe11.swip.net (CommuniGate Pro SMTP 5.0.12) with ESMTPA id 168943398; Sun, 26 Nov 2006 11:18:11 +0100 From: Hans Petter Selasky To: Peter Carah Date: Sun, 26 Nov 2006 11:17:50 +0100 User-Agent: KMail/1.7 References: <4568CFDD.9030004@altadena.net> In-Reply-To: <4568CFDD.9030004@altadena.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200611261117.51441.hselasky@c2i.net> Cc: usb@freebsd.org Subject: Re: Test (belated) of new umass driver X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Nov 2006 10:18:15 -0000 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