Ok... I finally managed to snatch my brother's pc for testing (it
already had Gentoo-Linux installed, but was outdated for a month or
so). After upgrading the kernel to 2.6.5 and rebooting and bringing
the pc here to connect it to the cable modem and blah blah blah, I got
this:

//-------------------------------------------------------
uhci_hcd 0000:00:11.2: port 1 portsc 0093
hub 1-0:1.0: port 1, status 101, change 1, 12 Mb/s
hub 1-0:1.0: debounce: port 1: delay 100ms stable 4 status 0x101
usb 1-1: new full speed USB device using address 3
usb 1-1: new device strings: Mfr=1, Product=2, SerialNumber=3
uhci_hcd 0000:00:11.2: uhci_result_control: failed with status 500000
[cf5c5240] link (0f5c51e2) element (0f7ba0c0)
 Element != First TD
  0: [cf7ba040] link (0f7ba0c0) e3 Length=7 MaxLen=7 DT0 EndPt=0
Dev=3, PID=2d(SETUP) (buf=0f29efe0)
  1: [cf7ba0c0] link (0f7ba100) e3 Stalled Babble Length=3 MaxLen=3
DT1 EndPt=0 Dev=3, PID=69(IN) (buf=0e6fac80)
  2: [cf7ba100] link (00000001) e3 IOC Active Length=0 MaxLen=7ff DT1
EndPt=0 Dev=3, PID=e1(OUT) (buf=00000000)

drivers/usb/core/message.c: error getting string descriptor 0
(error=-75)
usb 1-1: control timeout on ep0in
//-------------------------------------------------------

So it appears that afterall, the problem is in the cable modem <->
driver communication. The message still tells me the error is while
getting the string descriptor, so I suppose the problem is not
critical (well, it does works using the CDCEther on 2.4, afterall). My
brother's pc USB host controller info is:

//-------------------------------------------------------
00:11.2 USB Controller: VIA Technologies, Inc. USB (rev 23) (prog-if
00 [UHCI])
        Subsystem: VIA Technologies, Inc. (Wrong ID) USB Controller
        Flags: bus master, medium devsel, latency 32, IRQ 5
        I/O ports at dc00 [size=32]
        Capabilities: [80] Power Management version 2

00:11.3 USB Controller: VIA Technologies, Inc. USB (rev 23) (prog-if
00 [UHCI])
        Subsystem: VIA Technologies, Inc. (Wrong ID) USB Controller
        Flags: bus master, medium devsel, latency 32, IRQ 5
        I/O ports at e000 [size=32]
        Capabilities: [80] Power Management version 2
//-------------------------------------------------------

So.. now what? It looks like the communication between the uhci driver
and the modem does not goes well at all and the modem just "breaks"
down (I mean... something in the modem was changed since the next time
I load the CDCEther driver the cable-modem does not gets detected
until I re-insert the module). I am wondering if indeed some pin of my
cable modem was damaged (well if you consider it stopped working after
an accidental unplug, but I can't SEE how would that affect the pins
on the cable modem's end when the cable that was unplugged was the one
connected to the pc, and I already changed it... maybe it WAS a
coincidence afterall).
...so anything else I need to test? I don't think changing the
cable-modem would be much of an option (my cable company probably
would grumble if I ask to change it)


On Thu, 6 May 2004 11:53:28 -0400 (EDT)
Alan Stern <[EMAIL PROTECTED]> wrote:

> On Wed, 5 May 2004, Randy.Dunlap wrote:
> 
> > On Wed, 5 May 2004 23:11:10 -0500 Zariel Skotlex
> > <[EMAIL PROTECTED]> wrote:
> > 
> > | Hi...
> > |  I asked this a long time ago when I just got subscribed, but
> > got no answer... I guess I'll have to ask again and try to be
> > specific/simpler this time.| 
> > | When my kernel 2.6.5 tries to detect the modem, it goes on like
> > this:|
> > //---------------------------------------------------------------
> > ------------| usb 2-2: new full speed USB device using address 3
> > | usb 2-2: new device strings: Mfr=1, Product=2, SerialNumber=3
> > | ohci_hcd 0000:00:02.0: urb df530240 path 2 ep0in 82d60000 cc 8
> > --> status -75| drivers/usb/core/message.c: error getting string
> > descriptor 0 (error=-75)| drivers/usb/core/message.c: USB device
> > number 3 default language ID 0x409| ohci_hcd 0000:00:02.0: urb
> > df530240 path 2 ep0in 82d60000 cc 8 --> status -75|
> > drivers/usb/core/usb.c: usb_hotplug| usb 2-2: registering 2-2:1.0
> > (config #1, interface 0)| drivers/usb/core/usb.c: usb_hotplug
> > | usb 2-2: registering 2-2:1.1 (config #1, interface 1)
> > | drivers/usb/core/usb.c: usb_hotplug
> > | usbnet 2-2:1.0: usb_probe_interface
> > | usbnet 2-2:1.0: usb_probe_interface - got id
> > | ohci_hcd 0000:00:02.0: urb df530240 path 2 ep0in 82d60000 cc 8
> > --> status -75| usbnet: probe of 2-2:1.0 failed with error -75
> > | drivers/usb/core/usb.c: registered new driver usbnet
> > | ohci_hcd 0000:00:02.0: urb df5a2c40 path 2 ep0in 82d60000 cc 8
> > --> status -75| ohci_hcd 0000:00:02.0: urb df5a2c40 path 2 ep0in
> > 82d60000 cc 8 --> status -75| ohci_hcd 0000:00:02.0: urb df5a2c40
> > path 2 ep0in 82d60000 cc 8 --> status -75| ohci_hcd 0000:00:02.0:
> > urb df5a2c40 path 2 ep0in 82d60000 cc 8 --> status -75| ohci_hcd
> > 0000:00:02.0: urb df5a2c40 path 2 ep0in 82d60000 cc 8 --> status
> > -75| ohci_hcd 0000:00:02.0: urb df5a2c40 path 2 ep0in 82d60000 cc
> > 8 --> status -75|
> > //---------------------------------------------------------------
> > ------------| 
> > | Pretty much says that my ohci_hcd driver couldn't probe the
> > hardware.. and the error code is -75 (what does -75 means
> > anyway?). I've been having this problem since 2.6.1, I think (it
> > was working before... but strangely enough, my cable modem stopped
> > working the day I accidentally unplugged it... ever since then it
> > won't work. I tried connecting to other usb ports, I even got a
> > new usb cable to no avail).
> > 
> > To look up USB error codes, first look at
> > linux/include/asm-generic/errno*.h to find the value.  75 is
> > EOVERFLOW in Linux. Now read linux/Documentation
> > usb/error-codes.txt to see how linux-usb uses error codes. 
> > EOVERFLOW means:
> > 
> > -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.  "Babble".
> > 
> > and the (*) footnote says:
> > 
> > (*) Error codes like -EPROTO, -EILSEQ and -EOVERFLOW normally
> > indicate hardware problems such as bad devices (including
> > firmware) or cables.
> > 
> > This has been our experience most of the time, so first guess is a
> > suspect device.  It doesn't reply as expected, and possibly it's
> > sending more data than was requested by linux-usb.
> > This happens sometimes when linux-usb is trying to read
> > descriptors from the device.  linux-usb often tries to read
> > partial descriptors and some devices don't like that, even though
> > it's allowed by the USB spec.
> > 
> > 
> > | 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!
> > 
> > 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.
> 
> 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.
> 
> A good test, if Zariel can do it, would be to try using a different 
> computer, maybe even one with a UHCI controller.
> 
> Alan Stern
> 

Attachment: pgp00000.pgp
Description: PGP signature

Reply via email to