sslug-teknik team mailing list archive

[Jørgen Heesche <heesche@xxxxxxxxxxx>]

Kabelmodem til Webspeed fungerer ikke under Suse 9.1, kernel 2.6.4.
I dmesg ses flg.:
...
usb 3-1: new full speed USB device using address 2
usb 3-1: Product: USB Cable Modem
....
usb 3-1: USB disconnect, address 2
...
drivers/usb/core/usb.c: registered new driver usbnet
usb 3-1: new full speed USB device using address 3
drivers/usb/core/message.c: error getting string descriptor 0 (error=-75)
usbnet: probe of 3-1:1.0 failed with error -75
....

Modemet fungerer fint ved USB-tilslutning under Mdk9.1, kernel 2.4, men
efter forsøg med kernel 2.6 er der lidt problemer: USB-kablet skal lige
kobles fra og til et par gange før modemet virker igen. Kernel 2.6
initialiserer sikkert galt, hvorefter kernel 2.4 får problemer med at
detektere modemet.

I linux-usb-users mail archive fandt jeg et indlæg, som beskriver netop
det jeg oplever.
http://www.mail-archive.com/linux-usb-users@xxxxxxxxxxxxxxxxxxxxx/msg10388.html
Derefter følger en længere diskussion, som jeg her bringer nogle uddrag af.

Vedr. error -75:
To look up USB error codes, first look at
linux/include/asm-generic/errno*.h to find the value.  75 is EOVERFLOW
in Linux.
-EOVERFLOW (*)          The amount of data returned by the endpoint was
                        greater than either the max packet size of the
                        endpoint or the remaining buffer size.

Vedr. skift til boot med kernel2.4:
Strange thing is that the kernel 2.4.25 has no problems loading my cable
modem,
EXCEPT after rebooting from a 2.6 kernel, when I do a 2.6-> 2.4 change,
my cable modem also fails to be detected!

SVAR:
Oh.  So this represents some kind of regression in linux-usb, eh?
Could you try Linux-2.6.6-rc3?  (hopefully 2.6.6 will be out soon
and you can test it)

Alan, any thoughts about this one?
It seems that Zariel thinks it is OHCI-related, so you wouldn't be
the right person for that, but it seems more related to
descriptor parsing to me.  Of course, that is just a guess.
 Randy.Dunlap

SVAR:
It might not be related to OHCI; it might have more to do with the way
the modem is initialized by usbcore.  Clearly this is more than just a
descriptor-parsing problem, because -EOVERFLOW shouldn't ever happen
unless something is wrong with either the host hardware or the device.
Alan Stern

Vedr. error -75:
error getting string descriptor 0 (error=-75)
usb 1-1: control timeout on ep0in

SVAR:

This means that when the PC asked for the first 4 bytes of string
descriptor 0, the cable modem sent back more than 4 bytes.  That's a
definite error, and the device probably would not pass USB certification.

Trying to read string descriptors from devices is a problem.  The length
of a string descriptor is stored in its first 2 bytes, so a natural
approach is to read just that much (to learn the length) and then read the
whole thing.  Some devices, like your cable modem, won't cooperate with
this scheme.  Since the maximum possible descriptor length is 255 bytes,
another approach is to try asking for that much and let the device send as
much as it's got -- but other devices won't cooperate with that scheme.
There's no universal solution.

Alan Stern

Nu følger en diskussion om kernel-patches, kernel releases, udskiftning
af modem, opgradering  af modem-firmware osv., uden at det fører til
nogen løsning.
Det anføres også at det kunne være nyttigt at prøve en 'lsusb -v'. Her
er det åbenlyst, at den helt gal med Motorola i kernel 2.6:
.
.
.
  iManufacturer           1
  iProduct                2 Broadcom Corporation
  iSerial                 3 USB Cable Modem
.
.
.
altså noget værre rod.

I kernel 2.4 med CDCEther ser man med 'lsusb -v':
.
.
.
  iManufacturer           1 Broadcom Corporation
  iProduct                2 USB Cable Modem
  iSerial                 3 000CE53D2E1B
.
.
.

Det kommenterer Alan Stern med flg.:

I can't imagine why it should behave like this.  Firmware bug,
obviously, but a very strange one.

However, I can tell you that the code responsible for retrieving string
descriptors changed between 2.4 and 2.6.  Under 2.4 the code simply asks
for 255 bytes of data and accepts as much as the device will send.
Under 2.6 the code first asks just for 2 bytes (which contain the actual
length) and then asks for just that much data.  But I can't see how this
would cause the modem to misbehave in the way you're seeing.
Alan Stern

Det synes jeg engentlig godt jeg kan se. Hvis disse descriptorer findes
i records med variable længder skal man selvfølgelig læse dem på
2.6-måden, men hvis nu Motorola ikke har variable recordlængder går det
jo helt galt.

Nu afslutter spørgeren, Zariel Skotlex, med:

Ah well... looks like I hit the end of the road for now
.
.
.
I'll have to wait for a usbnet upgrade that automagically fixes it or
until I can convince my isp that my modem is buggy, whichever miracle
happens first.

Der vil jeg mene, at da modemet virker i MSwindows og altså også i Linux
kernel 2.4, vil isp-udbyderen helt sikkert ikke kunne overbevises om
fejl, så det mirakel er en utopi. Derimod finder jeg at en opgradering
af usbnet burde være realistisk. Når CDCEther kan håndtere Motorola
USB-modem, bør udviklerne af usbnet kunne fikse problemet.

Med venlig hilsen
Jørgen Heesche