Device IDs for HP hs2300 HSDPA modem

Michael freebsdusb at bindone.de
Thu Dec 4 01:16:52 PST 2008


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?
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?)

thanks
michael


More information about the freebsd-usb mailing list