iManufacturer 3 Linux 2.6.5 ohci_hcd iProduct 2 nVidia Corporation nForce2 USB Controller (#2) iSerial 1 0000:00:02.1
Does the 2.6.6-rc3 code behave differently?
There's a patch in that release which should help with device firmware that mis-handles descriptor fetches in certain ways. One that I don't think was in the stock 2.6.5 kernels, and was essential to making Linux reliably enumerate certain devices ... failure modes resembled what you're reporting. The fix was just retrying after certain errors.
Bus 002 Device 002: ID 07b2:5100 Motorola BCS, Inc. Device Descriptor:
...
idVendor 0x07b2 Motorola BCS, Inc.
idProduct 0x5100 bcdDevice 1.01
iManufacturer 1 iProduct 2 Broadcom Corporation
iSerial 3 USB Cable Modem
For example, here somehow iManufacturer got turned into iProduct, and iProduct turned into iSerial ...
bNumConfigurations 1
Configuration Descriptor:
...
unknown descriptor type: 05 24 00 10 01
unknown descriptor type: 05 24 06 00 01
unknown descriptor type: 0d 24 0f 03 00 00 00 00 ea 05 00 00 00
That's not actually where these descriptors belong ... but Broadcom's firmware seems to put them there, so Linux copes. Also, more current versions of "lsusb -v" should actually tell you most of what they say.
Interface Descriptor:
..
bInterfaceClass 2 Communications
bInterfaceSubClass 6 Ethernet Networking
bInterfaceProtocol 0 iInterface 5 000CE53D2E1B
In this case, fetching string 5 seemed to return what should have come out for string 3 ...
...
Language IDs: (length=42)
0044 Tatar(Tatar)
0061 Nepali(Nepali)
0074 (null)((null))
0061 Nepali(Nepali)
0020 Urdu(Urdu)
0049 Tamil(Tamil)
006e (null)((null))
0074 (null)((null))
0065 (null)((null))
0072 (null)((null))
0066 (null)((null))
0061 Nepali(Nepali)
0063 (null)((null))
0065 (null)((null))
0020 Urdu(Urdu)
0043 Uzbek(Uzbek)
006c (null)((null))
0061 Nepali(Nepali)
0073 (null)((null))
0073 (null)((null))
And the language IDs ("string 0") look pretty much like garbage, though it'd make sense as an ASCII string: "Data Interface Class".
Again, this looks like the firmware is sending part of a previous string request ... as if the firmware didn't clear out previous EP0-IN buffers when getting a SETUP packet, so Linux got the wrong string.
modem. The problem persists so I think it does not has to do with drivers (I have mostly everything done as modules except for the core stuff like hd, filesystems and keyboard drivers), looks like the problem lies within usbnet (or ehci_hcd) themselves (of course, unless my modem is to be blamed for being an utter piece of non-usb-specs-conforming crap).
The HCDs are only reporting what the device told them, but I think some firmware developers are pretty slack about actually doing the right thing for descriptor fetches. Unfortunately, the firmware doesn't all misbehave in the same way ... requests that work with some firmware will break for other firmware, and vice versa. I'm not sure Linux works around all the common firmware bug modes yet.
- Dave
-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
