Message-Id: <200808062310.59360.elendil@planet.nl>
Date:	Wed, 6 Aug 2008 23:10:58 +0200
From:	Frans Pop <elendil@...net.nl>
To:	Alan Stern <stern@...land.harvard.edu>
Cc:	linux-kernel@...r.kernel.org,
	Kernel Testers List <kernel-testers@...r.kernel.org>,
	linux-usb@...r.kernel.org
Subject: Re: [regression?] usb: new errors during device detection

Hi Alan,

On Monday 04 August 2008, Alan Stern wrote:
> > +usb 3-1: device not accepting address 2, error -71
> > +hub 3-0:1.0: unable to enumerate USB device on port 1
>
> The difference is most likely meaningless; it is probably caused a
> different order of initialization of the EHCI and UHCI controllers.

Meaningless, but annoying. Especially as such "errors" get through to the 
console when you boot with the 'quiet' boot parameter and thus draw more 
attention with "regular" users than they are really worth.

> > Note that 3-1 is first assigned address 2 and then 4. With 2.6.26 3-1
> > did not have any problem accepting address 2. I assume the "unable to
> > enumerate" error is a result of the rejection of the address?
>
> No.  It is caused by the EHCI controller being initialized.
>
> When an EHCI controller is initialized, it switches all the USB
> connections from its companion controllers to itself.  Hence any device
> which _was_ connected to the UHCI controller will _now_ be connected to
> the EHCI controller.  Consequently the UHCI controller is unable to
> communicate with the device and cannot enumerate it.
>
> After a short time, the EHCI controller driver realizes that the device
> can't run at high speed and switches it back to the UHCI controller.
> At that point it gets enumerated for the second time, successfully.
>
> The difference must have been that under 2.6.26 the EHCI controller was
> initialized _before_ the 3-1 device was detected, so there was no
> aborted attempt at enumeration.

Thanks for the explanation. Attached boot messages (for -rc2) with usb 
debug enabled as suggested by Felipe Balbi. Messages have been extracted 
from kern.log (dmesg had already overflowed).

If I filter out messages related to bus 3 (PCI 1d.2) what I see is:
[...]
! usb 3-1: new low speed USB device using uhci_hcd and address 2
[ EHCI Host Controller gets initialized here for bus 5 ]
! usb 3-1: uhci_result_common: failed with status 440000
! usb 3-1: device not accepting address 2, error -71
! hub 3-0:1.0: unable to enumerate USB device on port 1
! hub 3-0:1.0: state 7 ports 2 chg 0000 evt 0002
! hub 3-0:1.0: state 7 ports 2 chg 0000 evt 0002
! uhci_hcd 0000:00:1d.2: port 1 portsc 01a3,00
! hub 3-0:1.0: port 1, status 0301, change 0001, 1.5 Mb/s
! hub 3-0:1.0: debounce: port 1: total 100ms stable 100ms status 0x301
! usb 3-1: new low speed USB device using uhci_hcd and address 4
[...]

I guess that does match your description.

I do find it a bit strange though that EHCI is allowed to grab bus 3 when 
UHCI has already identified a low speed device on that bus.

> If you want to prevent all errors of this sort, all you have to do is
> insure that ehci-hcd is loaded before either uhci-hcd or ohci-hcd
> during system startup.

Hmmm. Also not sure that I'm ready to agree with this conclusion.

Shouldn't the kernel itself be smart enough to prevent error messages in 
apparently predictable and probably fairly common scenarios?

To me this seems a lot like an issue discussed during the .25 cycle in
   http://lkml.org/lkml/2008/5/2/256
which was eventually fixed by you with
   3a31155c Alan Stern, "USB: EHCI: suppress unwanted error messages"

Cheers,
FJP


View attachment "usb-debug_2.6.27-rc2" of type "text/x-log" (82900 bytes)

Powered by blists - more mailing lists