From owner-freebsd-usb@FreeBSD.ORG Wed Jan 21 02:59:16 2009 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 26279106566C for ; Wed, 21 Jan 2009 02:59:16 +0000 (UTC) (envelope-from freebsdusb@bindone.de) Received: from mail.bindone.de (mail.bindone.de [80.190.134.51]) by mx1.freebsd.org (Postfix) with SMTP id 93D4A8FC17 for ; Wed, 21 Jan 2009 02:59:15 +0000 (UTC) (envelope-from freebsdusb@bindone.de) Received: (qmail 63356 invoked by uid 89); 21 Jan 2009 02:59:14 -0000 Received: from unknown (HELO ufo.bindone.de) (mg@bindone.de@87.152.191.126) by mail.bindone.de with ESMTPA; 21 Jan 2009 02:59:14 -0000 Message-ID: <49768F47.7090204@bindone.de> Date: Wed, 21 Jan 2009 03:58:15 +0100 From: Michael User-Agent: Thunderbird 2.0.0.18 (X11/20081129) MIME-Version: 1.0 To: Hans Petter Selasky References: <492D6E0D.7020500@bindone.de> <200812031631.59515.hselasky@c2i.net> <49379FFF.6000007@bindone.de> <200812041544.57108.hselasky@c2i.net> In-Reply-To: <200812041544.57108.hselasky@c2i.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-usb@freebsd.org Subject: Re: Device IDs for HP hs2300 HSDPA modem 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: Wed, 21 Jan 2009 02:59:16 -0000 Hans Petter Selasky wrote: > On Thursday 04 December 2008, Michael wrote: > >> Hans Petter Selasky wrote: >> >>> On Wednesday 03 December 2008, Michael wrote: >>> >>>> Hans Petter Selasky wrote: >>>> >>>>> On Tuesday 02 December 2008, Michael wrote: >>>>> >>>>>> 3. I tried using a current checkout of usb2 (and added all the device >>>>>> IDs necessary), but serial_3g is missing (and therefore >>>>>> commented out in sys/modules/usb2/Makefile), so I'm stuck there as >>>>>> well. Is there actual hope that the problem >>>>>> might not appear when using usb2? (all I know about usb2 is that >>>>>> it's supposed to be giant-free, no idea if it can >>>>>> handle these issues any better - seems like at least 50% of USB >>>>>> devices are violating the standard in one way or >>>>>> another anyway). >>>>>> >>>>> Alfred forgot to add the Makefile. The 3g id's are now in >>>>> core/usb2_msctest.c . I've sent him a patch to fix this, but have not >>>>> heard from him yet, assuming he is very busy. >>>>> >>>>> Just copy one of the other serial driver Makefiles and add "u3g2.c". >>>>> >>>>> --HPS >>>>> >>>> Ok, essentially this seems to work, even so there are some caveats: >>>> 1. usb2_serial_3g has to be loaded before of usb2_controller_ehci >>>> 2. When I disable the device (button or bios command) it is detached >>>> correctly, >>>> but reattaching it fails 9 out of 10 times with the following error: >>>> kernel: usb2_alloc_device:1421: set address 2 failed (ignored) >>>> kernel: usb2_alloc_device:1456: getting device descriptor at addr 2 >>>> failed! kernel: uhub_reattach_port:402: could not allocate new device! >>>> If I kldunload usb2_controller_ehci and reload it, its detected ok. >>>> usb1 has no issues performing the same operation. >>>> 3. The machine crashed once after reenabling the device. No crashdumps >>>> here, mostly because I'm stupid :( >>>> 4. There is only one serial device created (/dev/cuaU0), which >>>> represents the data interface. The control interface is not detected. >>>> (usb1 creates two interfaces /dev/cuaU0.0 for data and /dev/cuaU0.2 for >>>> control). This is essential, because even so the data interface supports >>>> most commands, it doesn't accept the PIN code entry cmomand (or other >>>> maintenance commands). For testing purposes I disabled the PIN entry >>>> requirement on the SIM and was able to get reasonable stable service (up >>>> to 250kb/s). >>>> >>>> Let me know if there is anything I can do to help debugging the issues >>>> above. I attached the patches for the HS2300 device. >>>> >>>> br >>>> michael >>>> >>> Hi, >>> >>> Try tuning the following knobs, one at a time. >>> >>> sysctl hw.usb2.ehci.no_hs=1 >>> >>> This will disable hooking on devices to high speed. >>> >>> I think there is a problem with your device! >>> >>> Another thing you can try before re-plugging: >>> >>> sysctl hw.usb2.ss_delay=2 >>> >>> Also try: >>> >>> sysctl hw.usb2.pr_recovery_delay=500 >>> >>> --HPS >>> >> None of these knobs have a lasting effect. Sometimes it works, sometimes >> it doesn't. Disconnecting/reconnecting at a fast pace confuses it >> completely (missing the event completely). That's intersting because >> usb1 seems to be able to keep track of that ok, so it should be >> possible. Do you think this relates to caveat 1 (because I think >> normally loading 3g after ehci should work)? Are there any debugging >> knobs I should use to get more useful traces? >> > > See "sysctl hw.usb2" > > >> What about 4, is there anything I can do or anybody to contact to figure >> why the control device doesn't show up at all? (or is more a missing >> feature than a bug?) >> > > Send me a dump of the usb-descriptors using: > > usbconfig -u xxx -a yyy dump_curr_config_desc > > And I will have a look at it. I suspect that the device is there, but has > another unit ID than you expect. > > --HPS > It actually only works 1 out of 100 times now :( In general what I find interesting is that ugen0 - ugen4 come in when loading controller_uhci, while ugen5 and ugen6 are controlled by controller_ehci, BUT if the device is actually found, it will end up on ugen1.2, but only if uhci AND ehci are loaded.