Bug 270081 - Inconsistent USB device recognition
Summary: Inconsistent USB device recognition
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 7
Hardware: All
OS: All
Target Milestone: ---
Assignee: Pete Zaitcev
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2007-08-31 03:02 UTC by David Campbell
Modified: 2007-11-30 22:12 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2007-10-02 14:39:49 UTC
Type: ---

Attachments (Terms of Use)
behaviour seen in (4.62 KB, text/plain)
2007-10-01 22:34 UTC, David Campbell
no flags Details

Description David Campbell 2007-08-31 03:02:53 UTC
Description of problem:

I've previously raised a report about USB errors on booting...

This case reports similar problems but as applied to a USB device hot-plugged in
after the system is already booted.

My USB mouse looks like this when it has properly configured (from

T:  Bus=02 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  8 Spd=1.5 MxCh= 0
D:  Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
P:  Vendor=1267 ProdID=0210 Rev= 0.01
S:  Product=PS/2+USB Mouse
C:* #Ifs= 1 Cfg#= 1 Atr=a0 MxPwr=100mA
I:* If#= 1 Alt= 0 #EPs= 1 Cls=03(HID  ) Sub=01 Prot=02 Driver=usbhid
E:  Ad=81(I) Atr=03(Int.) MxPS=   8 Ivl=10ms

Notice that the first interface number is 1, which isn't strictly compliant with
the USB spec, but is compatible with the loosening up of the interpretation made
by a certain popular operating system vendor, see
http://www.microsoft.com/whdc/system/bus/USB/USBFAQ_intermed.mspx where it says:

Windows XP Service Pack 2 (SP2) relaxed the requirement that interface numbers
be consecutive by making changes to the driver Usbccgp.sys. Beginning with SP2,
interface numbers need only be increasing.

So I guess now we're likely to see a new army of USB devices that are compatible
with windows but not strictly with the USB spec.  Groan.  Anyway, linux usually
seems to understand the device, but does give a warning.

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.  Plug in USB mouse
2.  Observe behaviour....if it works then problem is not reproducable this time,
but if it doesn't work continue with subsequent steps
3.  Unplug mouse and retry again and again...consistent behaviour each time
4.  Plug in USB pen...works
5.  Plug in USB mouse...now works
Actual results:

USB device sometimes doesn't work

Expected results:

Works every time

Additional info:

When the USB mouse fails to be recognised, dmesg reports this:

usb 2-1: new low speed USB device using uhci_hcd and address 4
usb 2-1: device descriptor read/64, error -71
usb 2-1: device descriptor read/64, error -71
usb 2-1: new low speed USB device using uhci_hcd and address 5
usb 2-1: device descriptor read/64, error -71
usb 2-1: device descriptor read/64, error -71
usb 2-1: new low speed USB device using uhci_hcd and address 6
usb 2-1: device not accepting address 6, error -71
usb 2-1: new low speed USB device using uhci_hcd and address 7
usb 2-1: device not accepting address 7, error -71

When it does work, dmesg reports this:

usb 2-1: new low speed USB device using uhci_hcd and address 8
usb 2-1: config 1 has an invalid interface number: 1 but max is 0
usb 2-1: config 1 has no interface number 0
usb 2-1: configuration #1 chosen from 1 choice
input: PS/2+USB Mouse as /class/input/input8
input: USB HID v1.00 Mouse [PS/2+USB Mouse] on usb-0000:00:1d.1-1

Comment 1 Pete Zaitcev 2007-08-31 03:17:15 UTC

I'll poke Alan Stern about the strange maximum number.

Comment 2 Pete Zaitcev 2007-09-13 16:29:27 UTC
I suppose that interface number message will remain:
The summary is, as long as the device ultimately works, there's nothing to
be concerned about.

The -71 part is bad, if it means the failure of enumeration. But this usually
means that something is broken, often a cable.

Comment 3 David Campbell 2007-09-27 00:03:51 UTC
I haven't seen this issue for a while.  It may have been fixed in newer kernel
releases.  If I notice anything I'll add it here.

Comment 4 Christopher Brown 2007-10-01 14:42:02 UTC
Hello David,

(As you know by now) I'm reviewing this bug as part of the kernel bug triage
project, an attempt to
isolate current bugs in the fedora kernel.


If you're not seeing this issue any longer could you please close CURRENTRELEASE
indicating what you think may have fixed the problem for you.


Comment 5 David Campbell 2007-10-01 22:34:25 UTC
Created attachment 212951 [details]
behaviour seen in 

I did further testing and I was able to reproduce the problem, in I see errors as attached, now saying "Maybe the USB cable is
bad?" which is a more friendly message from last time.

However I believe the root of this problem to be a faulty mouse, as I have also
been able to reproduce similar problems on my wife's WinXP computer. 
Connecting the mouse seems to be intermittently bad and good.

So I am happy to close this case.

Comment 6 David Campbell 2007-10-01 22:50:15 UTC
I can resolve this case to closed, but given that there seem to have been useful
recent changes (perhaps made due to this case??) in the log reporting,
indicating the possibility of a faulty cable, how should this case be resolved?

Comment 7 Christopher Brown 2007-10-02 14:39:49 UTC
Since you suspect it is bad hardware (and Pete Zaitcev's comment backs this up),
I'm closing NOTABUG as it isn't something the kernel can really do anything about. 


Note You need to log in before you can comment on or make changes to this bug.