Well, my kernel is still 2.6.5, so I had to manually apply the patch's chunks #2 and #3 (after 2.6.6 goes out, I'll try it on that). And this is what now happens when I plugin the modem:
//-------------------------------------------------------
ehci_hcd 0000:00:02.2: GetStatus port 2 status 001803 POWER sig=j CSC
CONNECT
hub 1-0:1.0: port 2, status 501, change 1, 480 Mb/s
hub 1-0:1.0: debounce: port 2: delay 100ms stable 4 status 0x501
ehci_hcd 0000:00:02.2: port 2 full speed --> companion
ehci_hcd 0000:00:02.2: GetStatus port 2 status 003001 POWER OWNER
sig=se0 CONNE
CT
ohci_hcd 0000:00:02.0: GetStatus roothub.portstatus [2] = 0x00010101
CSC PPS CCS
hub 2-0:1.0: port 2, status 101, change 1, 12 Mb/s
hub 2-0:1.0: debounce: port 2: delay 100ms stable 4 status 0x101
ohci_hcd 0000:00:02.0: GetStatus roothub.portstatus [2] = 0x00100103
PRSC PPS PE
S CCS
usb 2-2: new full speed USB device using address 2
usb 2-2: new device strings: Mfr=1, Product=2, SerialNumber=3
usb_control_msg2: result = 4
drivers/usb/core/message.c: USB device number 2 default language ID
0x409
usb_control_msg2: result = 2
usb 2-2: Product: USB Cable Modem
usb_control_msg2: result = 0
usb_control_msg2: result = 2
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
//-------------------------------------------------------
I find it odd that it didn't even try to load the usbnet driver... so
I loaded it manually:
//-------------------------------------------------------
usbnet 2-2:1.0: usb_probe_interface
usbnet 2-2:1.0: usb_probe_interface - got id
usb_control_msg2: result = 26
usbnet: probe of 2-2:1.0 failed with error -22
drivers/usb/core/usb.c: registered new driver usbnet
//-------------------------------------------------------
Which is an invalid argument... so.. basicly, the data my modem is
sending is just plain garbage. What was mentioned on a buggy firmware
upgrade made me think about it... does the cable-modem performs
firmware upgrades automatically? (or my isp forces them on my modem?)
That would explain why it just suddenly stopped working next time I
tried to start it up. I'll look around to see if I can upgrade the
firmware myself (altough I don't have much hope in that). For the sake
of completeness here goes what happens on my brother's uhci-based host
controller:
//-------------------------------------------------------
uhci_hcd 0000:00:11.2: wakeup_hc
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 2
usb 1-1: new device strings: Mfr=1, Product=2, SerialNumber=3
usb_control_msg2: result = 26
drivers/usb/core/message.c: USB device number 2 default language ID
0x30
usb_control_msg2: result = 4
usb_control_msg2: result = 4
usb_control_msg2: result = 32
drivers/usb/core/usb.c: usb_hotplug
usb 1-1: registering 1-1:1.0 (config #1, interface 0)
drivers/usb/core/usb.c: usb_hotplug
usb 1-1: registering 1-1:1.1 (config #1, interface 1)
drivers/usb/core/usb.c: usb_hotplug
uhci_hcd 0000:00:11.2: port 1 portsc 008a
hub 1-0:1.0: port 1, status 100, change 3, 12 Mb/s
//-------------------------------------------------------
The logs don't look at ALL between both computers... but I just "know"
they are the ones that belong to the modem (since my brother's pc
didn't have any other usb's items attached, and neither did mine).
Well.. I dunno if this is the end of the road for now, I'll go look
into firmware upgrading for my cable modem.
On Fri, 7 May 2004 14:51:30 -0400 (EDT)
Alan Stern <[EMAIL PROTECTED]> wrote:
> On Fri, 7 May 2004, Zariel Skotlex wrote:
>
> > 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
>
> 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.
>
>
> > 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
>
> Critical is as critical does. While failure to retrieve string
> descriptor 0 won't hurt very much, the particular mode of failure
> might be important. For example, in the log above there was a
> "babble" error -- the device tried to send more data than it had
> been asked for. As it happens, VIA's UHCI controllers have a bug
> that causes them to stop functioning when they receive a packet
> longer than expected! Although you didn't show any more of the log,
> if you had persisted you would have found that _nothing_ you plugged
> into that USB port thereafter would work until you either reloaded
> the UHCI driver or rebooted.
>
> > 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).
>
> If it was a damaged pin you probably wouldn't be able to communicate
> at all. This sounds more like a firmware change (if it ever used to
> work with 2.6) or a firmware bug (if it never worked with 2.6).
>
> > ...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)
>
> Just for kicks, try applying this patch on both computers and send
> the relevant debugging logs. My hope is that this will avoid the
> "babble" errors and allow things to proceed, even if reading the
> descriptors fails. Of course, if something else is also wrong with
> the cable modem, this won't help.
>
> Alan Stern
>
>
>
> ===== drivers/usb/core/message.c 1.82 vs edited =====
> --- 1.82/drivers/usb/core/message.c Thu Apr 15 08:28:25 2004
> +++ edited/drivers/usb/core/message.c Fri May 7 14:45:56 2004
> @@ -1241,6 +1241,68 @@
> return ret;
> }
>
> +static int usb_control_msg2(struct usb_device *dev, unsigned int
> pipe,+ int request, int requesttype, int value, int index,
> + void *data, int size, int timeout)
> +{
> + struct usb_ctrlrequest *dr = kmalloc(sizeof(struct
> usb_ctrlrequest),+ GFP_NOIO);
> + int maxpacket, i;
> + int ret;
> +
> + if (!dr)
> + return -ENOMEM;
> +
> + dr->bRequestType= requesttype;
> + dr->bRequest = request;
> + dr->wValue = cpu_to_le16p(&value);
> + dr->wIndex = cpu_to_le16p(&index);
> + dr->wLength = cpu_to_le16p(&size);
> +
> + maxpacket = min((int) dev->epmaxpacketin[0], 64);
> + i = size % maxpacket;
> + if (i > 0)
> + size += maxpacket - i;
> +
> + ret = usb_internal_control_msg(dev, pipe, dr, data, size,
> timeout);+ printk(KERN_DEBUG "%s: result = %d\n", __FUNCTION__, ret);
> +
> + kfree(dr);
> + return ret;
> +}
> +
> +static int usb_get_descriptor2(struct usb_device *dev, int type,
> int index,+ void *buf, int size)
> +{
> + int i = 5;
> + int result;
> +
> + memset(buf,0,size); // Make sure we parse really received data
> +
> + while (i--) {
> + /* retry on length 0 or stall; some devices are flakey */
> + if ((result = usb_control_msg2(dev, usb_rcvctrlpipe(dev, 0),
> + USB_REQ_GET_DESCRIPTOR, USB_DIR_IN,
> + (type << 8) + index, 0, buf, size,
> + HZ * USB_CTRL_GET_TIMEOUT)) > 0
> + || result != -EPIPE)
> + break;
> +
> + dev_dbg (&dev->dev, "RETRY descriptor, result %d\n", result);
> + result = -ENOMSG;
> + }
> + return result;
> +}
> +
> +static int usb_get_string2(struct usb_device *dev, int langid, int
> index,+ void *buf, int size)
> +{
> + return usb_control_msg2(dev, usb_rcvctrlpipe(dev, 0),
> + USB_REQ_GET_DESCRIPTOR, USB_DIR_IN,
> + (USB_DT_STRING << 8) + index, langid, buf, size,
> + HZ * USB_CTRL_GET_TIMEOUT);
> +}
> +
> /**
> * usb_string - returns ISO 8859-1 version of a string descriptor
> * @dev: the device whose string descriptor is being retrieved
> @@ -1280,7 +1342,7 @@
>
> /* get langid for strings if it's not yet known */
> if (!dev->have_langid) {
> - err = usb_get_descriptor(dev, USB_DT_STRING, 0, tbuf, 4);
> + err = usb_get_descriptor2(dev, USB_DT_STRING, 0, tbuf, 4);
> if (err < 0) {
> dev_err (&dev->dev,
> "string descriptor 0 read error: %d\n",
> @@ -1303,7 +1365,7 @@
> * ask for the length of the string
> */
>
> - err = usb_get_string(dev, dev->string_langid, index, tbuf, 2);
> + err = usb_get_string2(dev, dev->string_langid, index, tbuf,
> 2);
> if (err == -EPIPE) {
> dev_dbg(&dev->dev, "RETRY string %d read/%d\n", index, 2);
> err = usb_get_string(dev, dev->string_langid, index, tbuf,
> 2);
>
pgp00000.pgp
Description: PGP signature
