Device IDs for HP hs2300 HSDPA modem
Michael
freebsdusb at bindone.de
Fri Jan 23 00:26:01 PST 2009
Just for the records and anybody using this device (and googling around
for a solution):
Hans Petter took the time and investigated the issue and could actually
solve all the problems I had with this device. New versions are
available in perforce:
http://perforce.freebsd.org/chv.cgi?CH=156521
http://perforce.freebsd.org/chv.cgi?CH=156522
Now everything works perfectly smooth (can switch the wwan on/off
kldload/kldunload whatever any time and it's absolutely stable - normal
ppp configuration works as expected, getting up to 230kb/s FTP transfer
rate with no load).
kldload usb2_serial_3g
kldload usb2_controller_uhci
=> /dev/cuaU0 (data port)
=> /dev/cuaU2 (control port)
Thanks to Hans Petter for his really fast and competent support and the
immediate fix, never experienced this in an open source project before.
cheers
Michael
Michael wrote:
> Michael wrote:
>
>> 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 at freebsd.org mailing list
>>> http://lists.freebsd.org/mailman/listinfo/freebsd-usb
>>> To unsubscribe, send any mail to "freebsd-usb-unsubscribe at 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: <UHCI root HUB Intel> at usbus2, cfg=0 md=HOST spd=FULL
>> (12Mbps) pwr=ON
>> ugen3.1: <UHCI root HUB Intel> at usbus3, cfg=0 md=HOST spd=FULL
>> (12Mbps) pwr=ON
>> ugen4.1: <UHCI root HUB Intel> at usbus4, cfg=0 md=HOST spd=FULL
>> (12Mbps) pwr=ON
>> ugen5.1: <UHCI root HUB Intel> at usbus5, cfg=0 md=HOST spd=FULL
>> (12Mbps) pwr=ON
>> ugen6.1: <UHCI root HUB Intel> at usbus6, cfg=0 md=HOST spd=FULL
>> (12Mbps) pwr=ON
>> ugen0.1: <EHCI root HUB Intel> at usbus0, cfg=0 md=HOST spd=HIGH
>> (480Mbps) pwr=ON
>> ugen1.1: <EHCI root HUB Intel> at usbus1, cfg=0 md=HOST spd=HIGH
>> (480Mbps) pwr=ON
>> ugen3.2: <HP hs2300 HSDPA Broadband Wireless Module HP> at usbus3, cfg=0
>> md=HOST spd=FULL (12Mbps) pwr=ON
>>
>> usbconfig -u 3 -a 2 dump_curr_config_desc
>>
>> ugen3.2: <HP hs2300 HSDPA Broadband Wireless Module HP> 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 <no string>
>> bmAttributes = 0x00e0
>> bMaxPower = 0x0000
>>
>> Interface 0
>> bLength = 0x0009
>> bDescriptorType = 0x0004
>> bInterfaceNumber = 0x0000
>> bAlternateSetting = 0x0000
>> bNumEndpoints = 0x0007
>> bInterfaceClass = 0x00ff
>> bInterfaceSubClass = 0x00ff
>> bInterfaceProtocol = 0x00ff
>> iInterface = 0x0003 <Data Interface>
>>
>> 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
>> _______________________________________________
>> freebsd-usb at freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-usb
>> To unsubscribe, send any mail to "freebsd-usb-unsubscribe at freebsd.org"
>>
>>
> One more... I tried upgrading to the latest usb2 version (as merged by
> alfred earlier this month). Using this things get better and worse at
> the same time.
> Now the 3g serial device is detected everytime reliably whenever
> usb2_controller_uhci is loaded. When loading usb2_controller_ehci, it
> gets disconnected and reconnect again. /dev/cuU0 is there in both cases.
> It still complains about not being able assigning an address (this time
> on ushub4). So maybe that's where the "missing" interface is. The
> biggest complaint I have right now is, that the device is not working
> anymore (whatever I send to the modem like a plain "AT" does not return
> anything), so I reverted back to the source tree of mid december
> (sometimes ZFS is really useful :). To be it seems like the machine is
> doing something really strange to get both serial devices registered,
> maybe that's why it sometimes works and sometimes not (especially
> considering how uhci and ehci somehow interfere on ushub1). "Hands on"
> (IM) help would really be appreciated, I'm pretty stuck at this point :/
>
> /(michael
>
> _______________________________________________
> freebsd-usb at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-usb
> To unsubscribe, send any mail to "freebsd-usb-unsubscribe at freebsd.org"
>
More information about the freebsd-usb
mailing list