This service will be undergoing maintenance at 00:00 UTC, 2016-09-28. It is expected to last about 1 hours
Bug 250545 - Early boot - usb device descriptor errors
Early boot - usb device descriptor errors
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
7
All Linux
low Severity low
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-08-02 02:11 EDT by David Campbell
Modified: 2007-11-30 17:12 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-09-25 07:26:02 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
image of boot screen (120.20 KB, image/jpeg)
2007-08-02 02:11 EDT, David Campbell
no flags Details

  None (edit)
Description David Campbell 2007-08-02 02:11:17 EDT
Description of problem:

    Early in the boot process, I find that this error is ALWAYS reported,
    and has been on every F7 version since the install DVD:

    usb 1-1: device descriptor read/all, error -71

    My hardware:  Clevo D870P notebook.

And sometimes during the boot process additionally these:

    usb-5-1.4: device descriptor read/64, error -32
    usb-5-1.4: device descriptor read/64, error -32
    usb-5-1.4: device descriptor read/64, error -32
    usb-5-1.4: device descriptor read/64, error -32
    usb=5=1/4: device not accepting address 10, error -32
    usb=5=1/4: device not accepting address 11, error -32

    I will attach a photo of the screen.

    And sometimes during the boot process, errors about mknod which prevent
    a successful boot.

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

    2.6.22.1-27.fc7
    2.6.22.1-41.fc7
    in fact all Fedora 7 releases I've seen, since the DVD original

How reproducible:

    I've described what happens every time above, and what doesn't happen
    every time.

Steps to Reproduce:

    1. Boot
    2. Watch early boot messages.
  
Actual results:

    See attached image

Expected results:

    No errors

Additional information:

    Kernel is booted with irqpoll and pci=assign-busses options
    Without the irqpoll option, my audio doesn't work and there are "Nobody
cared" exceptions from the audio IRQ.
    Without the pci=assign-busses option, the kernel logs messages about a pci
bus being hidden behind a transparent bridge and if I remember correctly one of
the devices doesn't get seen as a result.
Comment 1 David Campbell 2007-08-02 02:11:17 EDT
Created attachment 160497 [details]
image of boot screen
Comment 2 Pete Zaitcev 2007-08-02 02:22:48 EDT
The -71 seems like a transient happening when a device is being passed
between EHCI and its companion controller. Sometimes we can make it go
away by changing the order in which ehci_hcd and uhci_hcd/ohci_hcd are
loaded. I would not pay it any attention unless other specific malfunction
existed.

The -32 is a so-called "stall", and it's bad. If a defice stalls enumeration
it means that it does not work. It may be broken, or it may dislike how we
enumerate.

So, what is that 5-1.4 device? A fingerprint reader, memory stick slot,
or what? Unfortunately, F-7 can't tell you. If FC-6 worked, and you have
a CD with boot.iso on it, you can boot, go to Alt-F2, cat
/proc/bus/usb/devices, look at anything with Bus=05.
Comment 3 David Campbell 2007-08-02 03:10:57 EDT
I would think that F-7 can only not tell me when it comes up with those errors
about 5-1.4, but it doesn't come up with those errors every time, so I believe
F-7 can provide the details from a boot when it doesn't fail, which is what I've
done below.

Detail below.  I never have had any trouble with it when hot-plugging it in
rather than booting with it already plugged in.

lsusb says:
Bus 005 Device 004: ID 0dda:2026 Integrated Circuit Solution, Inc. 

cat /proc/bus/usb/devices says:
T:  Bus=05 Lev=01 Prnt=01 Port=01 Cnt=02 Dev#=  4 Spd=480 MxCh= 0
D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=0dda ProdID=2026 Rev= 1.6e
S:  Manufacturer=ICSI
S:  Product=USB2.0 Card Reader
S:  SerialNumber=0000001
C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=500mA
I:* If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage
E:  Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms

Here are some more things below from dmesg that might interest you.  The
situation is that this notebook computer has built-in card readers (4 port) that
is internally USB, but the built-in card-reader doesn't work with my SanDisk
Extreme SD card, so I plug in another USB card reader as per below (4 port) to
be able to read the card.  It is the external USB card reader that is bus 5
device 4.

Initializing USB Mass Storage driver...
usb 5-2: device descriptor read/64, error -110
usb 5-2: new high speed USB device using ehci_hcd and address 4
usb 5-2: configuration #1 chosen from 1 choice
usb 5-4: new high speed USB device using ehci_hcd and address 5
usb 5-4: configuration #1 chosen from 1 choice
usb 5-5: new high speed USB device using ehci_hcd and address 6
usb 5-5: configuration #1 chosen from 1 choice
usb 5-6: new high speed USB device using ehci_hcd and address 7
usb 5-6: configuration #1 chosen from 1 choice
usb 5-1.3: new high speed USB device using ehci_hcd and address 9
usb 5-1.3: configuration #1 chosen from 1 choice
usb 5-1.4: new low speed USB device using ehci_hcd and address 10
usb 5-1.4: config 1 has an invalid interface number: 1 but max is 0
usb 5-1.4: config 1 has no interface number 0
usb 5-1.4: configuration #1 chosen from 1 choice
input: PS/2+USB Mouse as /class/input/input4
input: USB HID v1.00 Mouse [PS/2+USB Mouse] on usb-0000:00:1d.7-1.4
scsi4 : SCSI emulation for USB Mass Storage devices
usb-storage: device found at 4
usb-storage: waiting for device to settle before scanning
scsi5 : SCSI emulation for USB Mass Storage devices
usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.
usb-storage: device found at 5
usb-storage: waiting for device to settle before scanning
usb 4-1: new full speed USB device using uhci_hcd and address 2
usb 4-1: configuration #1 chosen from 1 choice
usb-storage: device scan complete
usb-storage: device scan complete
scsi 5:0:0:0: Direct-Access     GENERIC  USB Storage-SMC  014D PQ: 0 ANSI: 0 CCS
scsi 4:0:0:0: Direct-Access     ICSI     IC1210        CF 1.6E PQ: 0 ANSI: 0 CCS
scsi 5:0:0:1: Direct-Access     GENERIC  USB Storage-CFC  014D PQ: 0 ANSI: 0 CCS
scsi 4:0:0:1: Direct-Access     ICSI     IC1210        MS 1.6E PQ: 0 ANSI: 0 CCS
scsi 5:0:0:2: Direct-Access     GENERIC  USB Storage-MMC  014D PQ: 0 ANSI: 0 CCS
scsi 4:0:0:2: Direct-Access     ICSI     IC1210    MMC/SD 1.6E PQ: 0 ANSI: 0 CCS
scsi 5:0:0:3: Direct-Access     GENERIC  USB Storage-MSC  014D PQ: 0 ANSI: 0 CCS
scsi 4:0:0:3: Direct-Access     ICSI     IC1210        SM 1.6E PQ: 0 ANSI: 0 CCS
sd 4:0:0:0: [sdc] Attached SCSI removable disk
sd 4:0:0:1: [sdd] Attached SCSI removable disk
sd 4:0:0:2: [sde] Attached SCSI removable disk
sd 4:0:0:3: [sdf] Attached SCSI removable disk
sd 5:0:0:0: [sdg] Attached SCSI removable disk
sd 5:0:0:1: [sdh] Attached SCSI removable disk
sd 5:0:0:2: [sdi] Attached SCSI removable disk
sd 5:0:0:3: [sdj] Attached SCSI removable disk
Comment 4 David Campbell 2007-08-02 03:22:29 EDT
So what's this on about:

usb 5-1.4: config 1 has an invalid interface number: 1 but max is 0
usb 5-1.4: config 1 has no interface number 0
usb 5-1.4: configuration #1 chosen from 1 choice

I would think that the relevant usb detail would be:

C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=500mA

Why is it expecting a config number zero?  None of the other usb devices on my
system have a config number of zero.

Comment 5 Pete Zaitcev 2007-08-20 18:34:07 EDT
BTW, Peter Jones has addressed the spurious -71 on boot by rearranging EHCI
coming first at all times in mkinitrd. The fix is available in rawhide now.

The rest of it seems like a duff device to me. The wrong number of configs
might be caused by a descriptor not being read due to the stall (-32), but
perhaps it's just zero in ROM itself.
Comment 6 David Campbell 2007-08-20 19:28:14 EDT
But isn't the below a decoding of the content of the rom, showing the number of
configs as 1 and the config number as 1?  Could the invalid interface number
issue be caused by a loop of the type  for(i = 0; i < max; i++) instead of for(i
= 1; i <= max; i++) seeing that the config numbers start at 1 and in this case
finishes at 1 as well?

T:  Bus=05 Lev=01 Prnt=01 Port=01 Cnt=02 Dev#=  4 Spd=480 MxCh= 0
D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=0dda ProdID=2026 Rev= 1.6e
S:  Manufacturer=ICSI
S:  Product=USB2.0 Card Reader
S:  SerialNumber=0000001
C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=500mA

The behaviour with fedora 7 is inconsistent...often it works fine...but other
times you get these errors I've reported above... if the rom were wrong, then
surely you'd expect the behaviour to be consistent?
Comment 7 David Campbell 2007-08-30 23:06:33 EDT
hmmm....

I sorted out the business about "config 1 has an invalid interface number: 1 but
max is 0"

It turns out that my USB mouse has been made compatible with Windows....see
below, but not strictly with the USB spec.

From http://www.microsoft.com/whdc/system/bus/USB/USBFAQ_intermed.mspx

Windows XP (prior to Service Pack 2) mandates that interface numbers follow
these rules:
  Interface numbers must be zero-based.
  Interface numbers must be consecutive and increasing.

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.

From the USB 2 spec:
bInterfaceNumber 1 Number Number of this interface. Zero-based
                          value identifying the index in the array of
                          concurrent interfaces supported by this
                          configuration.

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.
Comment 8 Christopher Brown 2007-09-21 11:14:59 EDT
Hello David,

I'm reviewing this bug as part of the kernel bug triage project, an attempt to
isolate current bugs in the fedora kernel.

http://fedoraproject.org/wiki/KernelBugTriage

I am CC'ing myself to this bug and will try and assist you in resolving it if I can.

There hasn't been much activity on this bug for a while. Could you tell me if
you are still having problems with the latest kernel as I'm struggling to see
whether this has been resolved for you.

If the problem no longer exists then please close this bug or I'll do so in a
few days if there is no additional information lodged.

Cheers
Chris
Comment 9 David Campbell 2007-09-24 23:50:31 EDT
I've done some further testing with the 2.6.22.5-76.fc7 kernel, and:

1.  I haven't seen any of the error messages with -32 error-code I've previously
seen.

2.  The following error messages appears whenever I have an external USB 2.0 hub
plugged in at time of boot.  I have tried two different usb 2.0 hubs and
whenever I have either or both of them plugged in, I see this message appear
once.  The message appears whether or not there are any devices plugged into the
hub(s), and none of the ports or devices are USB 1.x so I don't know why it is
giving me the error about usb 1-1 as below.

  usb 1-1: device descriptor read/all, error -71
Comment 10 Christopher Brown 2007-09-25 04:35:43 EDT
Are these error messages preventing the device(s) from working correctly? At the
moment I'm unable to tell whether these are spurious errors or are actually
causing problems for you. Pete indicated a fixed mkinitrd was available, however
this is just for F8 and upwards.  My thinking would therefore be to close this
as NEXTRELEASE.
Comment 11 David Campbell 2007-09-25 07:26:02 EDT
The -71 error is not causing a problem and I haven't seen the others, so
NEXTRELEASE seems fine.

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