From owner-freebsd-usb@FreeBSD.ORG Wed Jan 21 03:09:58 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 43CF4106564A for ; Wed, 21 Jan 2009 03:09:58 +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 6BD858FC12 for ; Wed, 21 Jan 2009 03:09:57 +0000 (UTC) (envelope-from freebsdusb@bindone.de) Received: (qmail 63736 invoked by uid 89); 21 Jan 2009 03:09:56 -0000 Received: from unknown (HELO ufo.bindone.de) (mg@bindone.de@87.152.191.126) by mail.bindone.de with ESMTPA; 21 Jan 2009 03:09:56 -0000 Message-ID: <497691CC.1030603@bindone.de> Date: Wed, 21 Jan 2009 04:09:00 +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> <49768F47.7090204@bindone.de> In-Reply-To: <49768F47.7090204@bindone.de> 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 03:09:58 -0000 Michael wrote: > 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. > _______________________________________________ > freebsd-usb@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-usb > To unsubscribe, send any mail to "freebsd-usb-unsubscribe@freebsd.org" > Sorry about the ongoing bombardment... I figured the best way to almost reliably getting the device detected after booting. 1. sysctl dev.acpi_hp.0.wwan_enabled = 0 (Disable the wwan device - I do this through the acpi_hp kernel module I wrote and ment to release weeks ago) 2. kldload usb2_controller_uhci 3. kldload usb2_serial_3g 4. kldload usb2_controller_ehci 5. sysctl dev.acpi_hp.0.wwan_enabled=1 Without using my acpi module and disabling the device first, chances of getting it detected properly are almost zero. The control device is still missing though... usbconfig with the modem detected (this time I loaded drivers in reverse order, so don't get confused by the numbering) ugen2.1: at usbus2, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON ugen3.1: at usbus3, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON ugen4.1: at usbus4, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON ugen5.1: at usbus5, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON ugen6.1: at usbus6, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON ugen0.1: at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON ugen1.1: at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON ugen3.2: at usbus3, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON usbconfig -u 3 -a 2 dump_curr_config_desc ugen3.2: at usbus3, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON Configuration index 0 bLength = 0x0009 bDescriptorType = 0x0002 wTotalLength = 0x0043 bNumInterfaces = 0x0001 bConfigurationValue = 0x0001 iConfiguration = 0x0000 bmAttributes = 0x00e0 bMaxPower = 0x0000 Interface 0 bLength = 0x0009 bDescriptorType = 0x0004 bInterfaceNumber = 0x0000 bAlternateSetting = 0x0000 bNumEndpoints = 0x0007 bInterfaceClass = 0x00ff bInterfaceSubClass = 0x00ff bInterfaceProtocol = 0x00ff iInterface = 0x0003 Endpoint 0 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0081 bmAttributes = 0x0003 wMaxPacketSize = 0x0010 bInterval = 0x0080 bRefresh = 0x0000 bSynchAddress = 0x0000 Endpoint 1 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0082 bmAttributes = 0x0002 wMaxPacketSize = 0x0040 bInterval = 0x0000 bRefresh = 0x0000 bSynchAddress = 0x0000 Endpoint 2 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0002 bmAttributes = 0x0002 wMaxPacketSize = 0x0040 bInterval = 0x0000 bRefresh = 0x0000 bSynchAddress = 0x0000 Endpoint 3 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0084 bmAttributes = 0x0002 wMaxPacketSize = 0x0040 bInterval = 0x0000 bRefresh = 0x0000 bSynchAddress = 0x0000 Endpoint 4 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0004 bmAttributes = 0x0002 wMaxPacketSize = 0x0040 bInterval = 0x0000 bRefresh = 0x0000 bSynchAddress = 0x0000 Endpoint 5 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0085 bmAttributes = 0x0002 wMaxPacketSize = 0x0040 bInterval = 0x0000 bRefresh = 0x0000 bSynchAddress = 0x0000 Endpoint 6 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0005 bmAttributes = 0x0002 wMaxPacketSize = 0x0040 bInterval = 0x0000 bRefresh = 0x0000 bSynchAddress = 0x0000 Let me know if it would actually help you to see any debugging output from the legacy usb1 stack with both devices (data + control) deteced. michael