usb0 no longer comes up if booting with usb plugged in

[mickey@…]

This is a kernel regression, it worked a couple of revisions ago.

The log says:

usb 2-1: new full speed USB device using uhci_hcd and address 50
usb 2-1: unable to read config index 0 descriptor/start: -110
usb 2-1: chopping to 0 config(s)
usb 2-1: no configuration chosen from 0 choices

[me@…]

Could you describe more ?
Did you change your kernel version (on your host machine i mean) recently?
Which kernel version is your host machine running ?

This error can only occur if the urb can't be submitted to the device in case it
couldn't get and endpoint for that. Then urb.c:usb_submit_urb() will return
-ENOENT and up in message.c:usb_start_wait_urb() this value is changed to
-ETIMEDOUT in the line:

57 retval = (ctx.status == -ENOENT ? -ETIMEDOUT : ctx.status);

and retval is return from that function to message.c:usb_internal_control_msg()
and to message.c:usb_control_msg() and finally to message.c:usb_get_descriptor().

So, most likely this is a bug coming from host machine. If you tell me which
kernel version is your host machine running I could prepare a diagnostic patch
to get more info.

BTW, enable CONFIG_USB_DEBUG for you kernel and also try to get some usbmon
traces. This would help a lot understanding the problem ;-)

[werner@…]

I've noticed EoUSB occasionally not coming up (unplugging and replugging
always fixed this), but haven't been able to establish a pattern so far.
If anyone sees this on a regular basis, the following information would
be useful:

• does this affect ttyACM (u-boot) as well ?
• what sequence(s) of events lead(s) to this failure ?
• are there small alterations of the above sequence(s) that makes the problem go away ?

Items that are relevant parts of these sequences would include:

• how did we reset ? Power on, USB insertion, JTAG reset, ...
• NOR or NAND boot ?
• bootmenu activation ?
• is a splash image loaded ?
• from where is the kernel loaded ?

• Werner

[mickey@…]

More information: It only occurs very sporadic and I have seen it almost always
after having DFU-uploaded something and then booted right without resetting or
replugging.

[andy]

I believe this was resolved by a backport of then new mainline git patch to solve Ethernet over USB issue in mainline. I use it all the time like that and do not see this issue. So closing as fixed, re-open if it still makes trouble.

[mickeyl]

With recent andy kernels I cansee this behaviour again. dmesg shows:

usb 3-1: new low speed USB device using uhci_hcd and address 2
usb 3-1: new low speed USB device using uhci_hcd and address 3
usb 3-1: new low speed USB device using uhci_hcd and address 4
usb 3-1: device not accepting address 4, error -71
usb 3-1: new low speed USB device using uhci_hcd and address 5
usb 3-1: device not accepting address 5, error -71
usb 3-1: new low speed USB device using uhci_hcd and address 6
usb 3-1: new low speed USB device using uhci_hcd and address 7
usb 3-1: new low speed USB device using uhci_hcd and address 8
usb 3-1: device not accepting address 8, error -71
usb 3-1: new low speed USB device using uhci_hcd and address 9
usb 3-1: device not accepting address 9, error -71
usb 3-1: new full speed USB device using uhci_hcd and address 10
usb 3-1: new full speed USB device using uhci_hcd and address 11
usb 3-1: new full speed USB device using uhci_hcd and address 12
usb 3-1: device not accepting address 12, error -71
usb 3-1: new full speed USB device using uhci_hcd and address 13
usb 3-1: device not accepting address 13, error -71

[andy]

This is different from your original report: it was a timeout then and this is something else, for example your host is misunderstanding the device as "low speed" USB half the time. Can the device be in host mode, is the cable definitely good?

[mickeyl]

• cables ok (tried multiple cables and multiple ports on multiple machines)
• no host mode
• needs one or more reboots to work again

[andy]

I use the USB port all day to send new kernel images to SD Card, I would notice this immediately if it was happening here. "one or more reboots" does not make it sound like a software issue. Can you reproduce it on a second physical device with the same software patchlevel?

[andy]

Hum started looking for this behaviour and there it is in my logs too.

What it is doing is spamming D+ and D- with differential 6MHz square wave the whole time, AIUI this is same as transmitting 00110011... from the GTA02. Host gets very confused trying to understand it after that and sees it as low speed, etc.

If you force it to host mode, it shuts up, but as soon as you send it back to device mode it spews again. Normally the bus should be quiet except for short 1ms frame signals when idle.

Did not see any test bits in s3c2442 datasheet.

[andy]

Probing it with USBMON, there is no logical activity at the USB Host controller. So this is happening at a low level in the S3C24xx rather than some storm coming from the gadget.

[andy]

I spotted this starting up during a reboot -if action, it goes nuts early in U-Boot and stays that way the whole session.

Mickey, do you tend to use reboot / shutdown or the hard reset button on the debug board?

[andy]

Never mind, resetting either way going through current U-Boot you have a 50:50 chance to get "insane USB device" mode for the whole of the session.

Just stick a scope probe on say D+ and keep resetting a couple of seconds after the red light flashes briefly, you will see 1ms period spikes on a good boot and spamming 6MHz madness on a bad one, with ~50% probability per-boot seen here tonight.

It's a U-Boot issue.

[werner]

Nitpicking: a 6MHz wave would be a 01010101 sequence. Since USB is using a
NRZI encoding, this would be a stream of 0 bits at the layer above encoding.
(See also USB 2.0 spec, section 7.1.8, page 157.)

Unfortunately, there's no bit stuffing when sending a stream of zeroes, so
you can't tell by looking at the bit stream whether this is originally a
square wave or a lot of zeroes. Presumably the latter.

[andy]

Yeah. I made a patchset last night that reduces the probability of this down to 10% rather than 50%.

There's a big fat warning in the USB device code that it is really time critical and not to printf() there... we added some I2C transaction for current limit on that code path in a recent patch...

Why shifting that out didn't fix it 100% I dunno, but 90% is better than what we got. I guess this might always have been there at 10% probability.

[andy]

Closing this because it's not reported any more and Qi won't trigger it as it doesn't bring up USB.