Bug 12148 - "EHCI: BIOS handoff failed" needs to be handled better
"EHCI: BIOS handoff failed" needs to be handled better
Status: RESOLVED INVALID
Product: Drivers
Classification: Unclassified
Component: USB
All Linux
: P1 low
Assigned To: Greg Kroah-Hartman
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-12-03 03:11 UTC by Mikko Rantalainen
Modified: 2012-02-22 20:59 UTC (History)
5 users (show)

See Also:
Kernel Version: 2.6.27.7 (latest stable version)
Tree: Mainline
Regression: No


Attachments
dmesg output (40.89 KB, text/plain)
2009-02-18 14:09 UTC, Martin Bammer
Details
lspci -vvnn (10.70 KB, text/plain)
2009-02-18 14:10 UTC, Martin Bammer
Details
dmidecode (9.71 KB, text/plain)
2009-02-18 14:11 UTC, Martin Bammer
Details
Patch for setting arbitrary ehci handoff timeout (1.05 KB, patch)
2009-03-05 11:37 UTC, Martin Bammer
Details | Diff
lspci output (2.60 KB, application/x-gzip)
2009-04-13 08:29 UTC, Bjoern T.
Details

Description Mikko Rantalainen 2008-12-03 03:11:16 UTC
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
Comment 1 Anonymous Emailer 2008-12-03 03:35:18 UTC
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
> 

Comment 2 Greg Kroah-Hartman 2008-12-03 07:45:02 UTC
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?

Comment 3 Alan Stern 2008-12-03 14:00:00 UTC
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

Comment 4 Mikko Rantalainen 2008-12-04 02:10:35 UTC
> 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?

Comment 5 Martin Bammer 2009-02-18 14:07:34 UTC
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.
Comment 6 Martin Bammer 2009-02-18 14:09:07 UTC
Created attachment 20305 [details]
dmesg output
Comment 7 Martin Bammer 2009-02-18 14:10:35 UTC
Created attachment 20306 [details]
lspci -vvnn
Comment 8 Martin Bammer 2009-02-18 14:11:08 UTC
Created attachment 20307 [details]
dmidecode
Comment 9 Martin Bammer 2009-03-05 11:36:01 UTC
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.
Comment 10 Martin Bammer 2009-03-05 11:37:03 UTC
Created attachment 20442 [details]
Patch for setting arbitrary ehci handoff timeout
Comment 11 Bjoern T. 2009-04-13 08:29:35 UTC
Created attachment 20955 [details]
lspci output

same probleme here
Comment 12 Oleksij Rempel (fishor) 2009-06-01 11:17:03 UTC
Any progress in this bug?
Comment 13 Tony Bones 2009-09-03 00:44:26 UTC
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.
Comment 14 Mikko Rantalainen 2009-09-07 10:49:31 UTC
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.
Comment 15 Yuhong Bao 2009-10-24 08:15:44 UTC
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?
Comment 16 Vedran Miletić 2009-11-08 11:55:48 UTC
Yeah, I would like to know that too. Are other manufacturers also affected?
Comment 17 Greg Kroah-Hartman 2012-02-22 20:59:20 UTC
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.

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