USB device not accepting new address

USB device not accepting new address

[Udo A. Steinberg]

Hello,

I have just come across another USB address problem, which happens sporadically
and is not easy to reproduce. It happens sometimes during bootup and is unrelated
to port overpowering, at other times everything works well. Output below.
The USB driver is the JE-driver.

Regards,
-Udo.

uhci.c: root-hub INT complete: port1: 58a port2: 49b data: 6
hub.c: port 1 connection change
hub.c: port 1, portstatus 300, change 3, 1.5 Mb/s
hub.c: port 2 connection change
hub.c: port 2, portstatus 101, change 3, 12 Mb/s
hub.c: port 2, portstatus 103, change 0, 12 Mb/s
hub.c: USB new device connect on bus1/2, assigned device number 2
uhci.c: root-hub INT complete: port1: 58a port2: 49b data: 6
usb.c: kmalloc IF c14bbe80, numif 1
usb.c: new device strings: Mfr=0, Product=0, SerialNumber=0
hub.c: USB hub found
hub.c: 5 ports detected
hub.c: standalone hub
hub.c: individual port power switching
hub.c: individual port over-current protection
hub.c: Port indicators are not supported
hub.c: power on to power good time: 100ms
hub.c: hub controller current requirement: 100mA
hub.c: port removable status: RRRRR
hub.c: local power source is good
hub.c: no over-current condition exists
hub.c: enabling power on all ports
uhci.c: root-hub INT complete: port1: 588 port2: 495 data: 2
usb.c: hub driver claimed interface c14bbe80
usb.c: kusbd: /sbin/hotplug add 2
usb.c: kusbd policy returned 0xfffffffe
hub.c: port 1 enable change, status 300
hub.c: port 1 connection change
hub.c: port 1, portstatus 101, change 1, 12 Mb/s
hub.c: port 1, portstatus 103, change 10, 12 Mb/s
hub.c: USB new device connect on bus1/2/1, assigned device number 3
uhci.c: uhci_result_control() failed with status 440000
[cfee30c0] link (0fee3062) element (0fefa240)
 Element != First TD
  0: [cfefa210] link (0fefa240) e3 Length=7 MaxLen=7 DT0 EndPt=0 Dev=0, PID=2d(SETUP) (buf=014bbf00)
  1: [cfefa240] link (00000001) e0 IOC Stalled CRC/Timeo Length=7ff MaxLen=7ff DT1 EndPt=0 Dev=0, PID=69(IN) (buf=00000000)

usb.c: USB device not accepting new address=3 (error=-84)
uhci.c: root-hub INT complete: port1: 58a port2: 49b data: 6
hub.c: port 1, portstatus 103, change 10, 12 Mb/s
hub.c: USB new device connect on bus1/2/1, assigned device number 4
usb.c: kmalloc IF c15a0140, numif 1
usb.c: skipped 1 class/vendor specific interface descriptors
usb.c: new device strings: Mfr=4, Product=14, SerialNumber=56
usb.c: USB device number 4 default language ID 0x409
uhci.c: root-hub INT complete: port1: 58a port2: 49b data: 6
Manufacturer: EIZO
Product: EIZO USB HID Monitor
SerialNumber: 23710050
uhci.c: root-hub INT complete: port1: 58a port2: 49b data: 6
uhci.c: root-hub INT complete: port1: 58a port2: 49b data: 6
uhci.c: root-hub INT complete: port1: 58a port2: 49b data: 6
uhci.c: root-hub INT complete: port1: 58a port2: 49b data: 6
uhci.c: root-hub INT complete: port1: 58a port2: 49b data: 6
uhci.c: root-hub INT complete: port1: 58a port2: 49b data: 6
uhci.c: root-hub INT complete: port1: 58a port2: 49b data: 6
uhci.c: root-hub INT complete: port1: 58a port2: 49b data: 6
uhci.c: root-hub INT complete: port1: 58a port2: 49b data: 6
uhci.c: root-hub INT complete: port1: 58a port2: 49b data: 6
uhci.c: root-hub INT complete: port1: 58a port2: 49b data: 6
hiddev0: USB HID v1.10 Device [EIZO EIZO USB HID Monitor] on usb1:4.0
usb.c: hid driver claimed interface c15a0140
usb.c: kusbd: /sbin/hotplug add 4
usb.c: kusbd policy returned 0xfffffffe
hub.c: port 1 connection change
hub.c: port 1, portstatus 300, change 3, 1.5 Mb/s
hub.c: port 2 connection change
hub.c: port 2, portstatus 101, change 3, 12 Mb/s
hub.c: port 2, portstatus 103, change 0, 12 Mb/s
hub.c: USB new device connect on bus2/2, assigned device number 2
usb.c: kmalloc IF c15a0dc0, numif 1
usb.c: new device strings: Mfr=1, Product=2, SerialNumber=0
usb.c: USB device number 2 default language ID 0x409
Manufacturer: ALCOR
Product: Generic USB Hub
hub.c: USB hub found
hub.c: 4 ports detected
hub.c: standalone hub
hub.c: ganged power switching
hub.c: global over-current protection
hub.c: Port indicators are not supported
hub.c: power on to power good time: 44ms
hub.c: hub controller current requirement: 100mA
hub.c: port removable status: RRRR
hub.c: local power source is good
hub.c: no over-current condition exists
hub.c: enabling power on all ports
usb.c: hub driver claimed interface c15a0dc0
usb.c: kusbd: /sbin/hotplug add 2
usb.c: kusbd policy returned 0xfffffffe
uhci.c: root-hub INT complete: port1: 588 port2: 495 data: 2
hub.c: port 1 enable change, status 300

Re: USB device not accepting new address

[Greg KH]

On Wed, Sep 05, 2001 at 06:44:43AM +0200, Udo A. Steinberg wrote:
> 
> Hello,
> 
> I have just come across another USB address problem, which happens sporadically
> and is not easy to reproduce. It happens sometimes during bootup and is unrelated
> to port overpowering, at other times everything works well. Output below.
> The USB driver is the JE-driver.

What kernel is this?
What happens when you use the usb-uhci.o driver?

greg k-h

Re: USB device not accepting new address

[Udo A. Steinberg]

> Greg KH wrote:

> > What happens when you use the usb-uhci.o driver?

With the usb-uhci driver from 2.4.9-ac7 everything works well and
the problem never occurs.

-Udo.

Re: USB device not accepting new address

[Pete Zaitcev]

> I have just come across another USB address problem, which happens
> sporadically and is not easy to reproduce.

>   1: [cfefa240] link (00000001) e0 IOC Stalled CRC/Timeo Length=7ff MaxLen=7ff
>   DT1 EndPt=0 Dev=0, PID=69(IN) (buf=00000000)

If usb_set_address() ends in timeouts, something is bad with the
hadrware, most likely. Microcode crash in the device, perhaps.
Someone, I think it was Oliver, posted a patch that retries
usb_set_address(). It may help you, look in linux-usb-devel
archives.

-- Pete

Re: USB device not accepting new address

[Udo A. Steinberg]

Pete Zaitcev wrote:
> 
> > I have just come across another USB address problem, which happens
> > sporadically and is not easy to reproduce.
> 
> >   1: [cfefa240] link (00000001) e0 IOC Stalled CRC/Timeo Length=7ff MaxLen=7ff
> >   DT1 EndPt=0 Dev=0, PID=69(IN) (buf=00000000)
> 
> If usb_set_address() ends in timeouts, something is bad with the
> hadrware, most likely. Microcode crash in the device, perhaps.
> Someone, I think it was Oliver, posted a patch that retries
> usb_set_address(). It may help you, look in linux-usb-devel
> archives.

Maybe it's a hardware problem, but this problem has never occured before Alan
started merging bits of 2.4.9 into his tree.

-Udo.

Re: USB device not accepting new address

[Udo A. Steinberg]

Pete Zaitcev wrote:

> Interesting. I just dealt with a bug which is most definitely
> a hardware problem, and the owner swore that "it worked with
> 2.4.3-12 perfectly" (it was the last errata that we shipped).
> The thing (a Kaweth compatible Ethernet) was found NOT to work
> on earlier kernels reliably either. Such things do happen:
> something stops working just in time.
> What regressions did you do? Did you run 2.4.7-ac _after_
> it broke?

I've just tried all -ac1 kernels from 2.4.5-ac1 to 2.4.9-ac1
and the problem exists with all of them. So it would appear that
it didn't work reliably with earlier kernels either. I find it
interesting however, that it is much harder to trigger in
earlier kernels and that it doesn't happen every time.

-Udo.

Re: USB device not accepting new address

[Len Sorensen]

On Thu, Sep 06, 2001 at 02:38:50AM +0200, Udo A. Steinberg wrote:
> I've just tried all -ac1 kernels from 2.4.5-ac1 to 2.4.9-ac1
> and the problem exists with all of them. So it would appear that
> it didn't work reliably with earlier kernels either. I find it
> interesting however, that it is much harder to trigger in
> earlier kernels and that it doesn't happen every time.

I have seen a similar problem when I plugged in a creative nomad jukebox
(which was misbehaving with windows as well).  It had been behaving
properly in the past, but was of course an unrecognized usb device.
However this time it failed to get a device id assigned.  The solution:
replace the usb cable.  Turns out one of the wires had a break in it,
and would loose the connection in one direction if you didn't bend it
"just right".  if you have usb problems, treat it like scsi: blame the
cable first.  With a different usb cable all the problems went away
instantly and it accepted it's usb device id.

Len Sorensen