Bug 12148

Reply-To: akpm@linux-foundation.org


(switched to email.  Please respond via emailed reply-to-all, not via the
bugzilla web interface).

On Wed,  3 Dec 2008 03:11:17 -0800 (PST) bugme-daemon@bugzilla.kernel.org wrote:

> http://bugzilla.kernel.org/show_bug.cgi?id=12148
> 
>            Summary: "EHCI: BIOS handoff failed" needs to be handled better
>            Product: Drivers
>            Version: 2.5
>      KernelVersion: 2.6.27.7 (latest stable version)
>           Platform: All
>         OS/Version: Linux
>               Tree: Mainline
>             Status: NEW
>           Severity: low
>           Priority: P1
>          Component: USB
>         AssignedTo: greg@kroah.com
>         ReportedBy: mikko.rantalainen@peda.net
> 
> 
> Latest working kernel version: (unknown, probably never)
> Earliest failing kernel version: (unknown, probably always)
> Distribution: Ubuntu Linux 8.10 (the same code is in vanilla kernel, though)
> Hardware Environment: motherboard: Intel DG45ID (with Core 2 Duo E8400)
> Software Environment: Ubuntu Linux 8.10
> Problem Description: EHCI BIOS handoff failed 
> 
> Steps to reproduce:
> 1) Enable "USB Legacy support" in the DG45ID BIOS
> 2) boot the linux kernel
> 3) Wait for timeout (about 10 seconds)
> 4) See warning messages
> [ 0.984004] Switched to high resolution mode on CPU 0
> [ 8.976007] pci 0000:00:1a.7: EHCI: BIOS handoff failed (BIOS bug?) 01010001
> [ 16.976007] pci 0000:00:1d.7: EHCI: BIOS handoff failed (BIOS bug?) 01010001
> 5) Notice the time wasted waiting for BIOS handoff
> 
> I'm fully aware that the real problem is that the BIOS does not follow the
> EHCI
> specification[1]. As such, I already contacted Intel about the issue and
> explained that the BIOS does not follow the specification[1] as explained on
> pages 121 and 122.
> 
> [1] http://www.intel.com/technology/usb/ehcispec.htm
> 
> I got following response (I cannot attach the whole correspondence because I
> didn't got explicit permission even though I explicitly asked for such
> permission): "The link you provided does not relate specifically to this
> board
> and it is just general information for EHCI Controller." followed by "We
> cannot
> provide further information on the BIOS other than the information that is
> publicly available." when asked for a newer specification overriding the
> specification[1].
> 
> In addition, they said that this board is not officially supported and "the
> operating system you are using is not tested with this motherboard and it is
> a
> reason to function improperly."
> 
> This seems to be a common problem. Searching for "BIOS handoff failed"
> returns
> many results for many motherboards and googling for the issue suggests that
> most people only suffer from slow boot without understanding the real issue
> behind the delays (they never see the kernel warning because of the OS splash
> screen).
> 
> The specification[1] says on page 122 "The OS waits for the BIOS Owned bit to
> go to a zero before attempting to use the EHCI controller. The time that OS
> must wait for BIOS to respond to the request for ownership is beyond the
> scope
> of this specification."
> 
> As the Intel (the author of said spec) is saying that this is just "general
> information" that does not relate specifically DG45ID (and, by extension,
> probably other motherboards manufactured by Intel) I'd suggest chancing the
> value of msec from 5000 to 50 in /drivers/usb/host/pci-quirks.c on line 274.
> Doing that would still be compliant to the specification[1] (the time that OS
> must wait is not specified so why not assume the OS manufacturer can decide).
> 
> Has this ever been tested? How long does it take with a BIOS that does
> correctly implement the specification[1]? I'd *guess* that if a BIOS is not
> going to respond in 50 ms it will not respond in 5000 ms either (the current
> behavior) after which the kernel is just trying to force the handoff and
> hoping
> for the best. In most cases forcing the handoff does work and in the cases
> where it does not work, waiting longer for the BIOS handoff is not going to
> help either. I think the best fix would be to shorten then msec time as
> suggested above and still print the same warning message if the BIOS is not
> following the EHCI specification[1].
> 
> I'm *very* disappointed that Intel publishes a specification[1] and then
> decides that it does not need to follow it. And this decision is not
> documented
> anywhere public.
> 
> See also: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/275351
> 

On Wed, Dec 03, 2008 at 03:34:43AM -0800, Andrew Morton wrote:
> > Distribution: Ubuntu Linux 8.10 (the same code is in vanilla kernel,
> though)

Does the same problem happen on 2.6.28-rc releases?

> > 1) Enable "USB Legacy support" in the DG45ID BIOS

Why are you doing this?  That's not a good idea.  In fact, it's probably
the problem here.

> > 2) boot the linux kernel
> > 3) Wait for timeout (about 10 seconds)
> > 4) See warning messages
> > [ 0.984004] Switched to high resolution mode on CPU 0
> > [ 8.976007] pci 0000:00:1a.7: EHCI: BIOS handoff failed (BIOS bug?)
> 01010001
> > [ 16.976007] pci 0000:00:1d.7: EHCI: BIOS handoff failed (BIOS bug?)
> 01010001
> > 5) Notice the time wasted waiting for BIOS handoff

Yes, you told the BIOS to keep the USB controller, don't do that :)

What happens if you change that BIOS option?

On Wed, 3 Dec 2008, Andrew Morton wrote:

> > http://bugzilla.kernel.org/show_bug.cgi?id=12148

> > As the Intel (the author of said spec) is saying that this is just "general
> > information" that does not relate specifically DG45ID (and, by extension,
> > probably other motherboards manufactured by Intel) I'd suggest chancing the
> > value of msec from 5000 to 50 in /drivers/usb/host/pci-quirks.c on line
> 274.
> > Doing that would still be compliant to the specification[1] (the time that
> OS
> > must wait is not specified so why not assume the OS manufacturer can
> decide).

In the current development kernel it has been reduced to 1000.

> > Has this ever been tested? How long does it take with a BIOS that does
> > correctly implement the specification[1]? I'd *guess* that if a BIOS is not
> > going to respond in 50 ms it will not respond in 5000 ms either (the
> current
> > behavior) after which the kernel is just trying to force the handoff and
> hoping
> > for the best. In most cases forcing the handoff does work and in the cases
> > where it does not work, waiting longer for the BIOS handoff is not going to
> > help either. I think the best fix would be to shorten then msec time as
> > suggested above and still print the same warning message if the BIOS is not
> > following the EHCI specification[1].

There may have been reports of systems which took at least 250 ms, 
maybe even more than 750 ms.  (It's not easy to search for such things 
in the email archives...)  Hence the maintainer is reluctant to make 
the value much lower.

> > I'm *very* disappointed that Intel publishes a specification[1] and then
> > decides that it does not need to follow it. And this decision is not
> documented
> > anywhere public.

Me too.  You'd think Intel could do a reasonable job of following its
own specifications.  And you'd think when they messed up, they would 
admit it instead of hiding behind marketing legalisms.

Alan Stern

> Does the same problem happen on 2.6.28-rc releases?

Haven't yet tested. I just checked the latest stable release.

>>> 1) Enable "USB Legacy support" in the DG45ID BIOS
> 
> Why are you doing this?  That's not a good idea.  In fact, it's probably
> the problem here.

This motherboard has no PS/2 or other legacy ports so I'm using USB
keyboard. To be able to use grub menu, I need to enable USB Legacy
support in BIOS or I cannot communicate with grub at all, because it
does not (and probably will not) include an USB/HID driver.

I thought that the BIOS handoff was designed to take care of this (yes,
I'm aware that *real* documentation for handoff is nowhere available).

>>> 2) boot the linux kernel
>>> 3) Wait for timeout (about 10 seconds)
>>> 4) See warning messages
>>> [ 0.984004] Switched to high resolution mode on CPU 0
>>> [ 8.976007] pci 0000:00:1a.7: EHCI: BIOS handoff failed (BIOS bug?)
>>> 01010001
>>> [ 16.976007] pci 0000:00:1d.7: EHCI: BIOS handoff failed (BIOS bug?)
>>> 01010001
>>> 5) Notice the time wasted waiting for BIOS handoff
> 
> Yes, you told the BIOS to keep the USB controller, don't do that :)
> 
> What happens if you change that BIOS option?

Disabling the BIOS option causes delay to go away (I'd guess that the
EHCI is not owned by BIOS in that case so there's nothing to wait for)
but then I cannot do anything with grub. Is there any boot loader that
is usable with USB keyboards without BIOS support?

Dare I suggest turning the delay as kernel option if the required
timeout is highly hardware dependant?

I have the same problem on a Datacast Jupiter 1014a. I've installed EasyPeasy 1.0 and the latest updates. Installed kernel is 2.6.27.8.12eeepc1. I've disabled the "Boot from USB"-option. Didn't help. The kernel waits 8 seconds for EHCI handoff.

Created attachment 20305 [details]
dmesg output

Created attachment 20306 [details]
lspci -vvnn

Created attachment 20307 [details]
dmidecode

And here is a patch which let's you set an arbritary handoff timeout in the kernel command line with the new parameter named ehci_ho_to. If you want 50ms timeout then just set: ehci_ho_to=50.

Created attachment 20442 [details]
Patch for setting arbitrary ehci handoff timeout

Created attachment 20955 [details]
lspci output

same probleme here

Any progress in this bug?

Can confirm this bios hand off issue with the Intel DG45FC board as well.  I got the same response from Intel, "We do not support linux."

For the time being I disabled USB Legacy Support but now I cannot use the keyboard in the pxelinux boot menu either.  Which I'm ok with I guess, I don't have a huge need to use it.

List of motherboards with this problem (according to https://bugs.launchpad.net/ubuntu/+source/linux/+bug/275351):

Intel DG45ID
Intel DG45FC
Intel DQ45CB
Intel DP45SG
Toshiba Satellite L300-1CM Notebook
ASUS P5B Deluxe

Basically a BIOS bug in Intel P965, P45, G45 and Q45 chipsets.

Has the Linux folks at Intel been notified of this issue? I see a lot of them on Linux related mailing lists, do they know of this BIOS issue with Intel's own motherboards?

Yeah, I would like to know that too. Are other manufacturers also affected?

All USB bugs should be sent to the linux-usb@vger.kernel.org mailing 
list, and not entered into bugzilla.  Please bring this issue up there,
if it is still a problem in the latest kernel release.