Hello all,
I sometimes get this message when I boot kernel 2.6.19. Could this be
related to the BIOS option "USB keyboard support"? When I turn it off I
never get the "handoff failed" message afaik. But I need it to access
lilo. Now I use an USB->PS2 adapter and turn "USB keyboard support" off.
If "handoff failed" and "USB keyboard support" are related wouldn't it
make sense to change the USB error handling?
Regards
Sebastian
On Fri, Dec 01, 2006 at 02:03:59PM +0100, Sebastian Kemper wrote:
> Hello all,
>
> I sometimes get this message when I boot kernel 2.6.19. Could this be
> related to the BIOS option "USB keyboard support"? When I turn it off I
> never get the "handoff failed" message afaik. But I need it to access
> lilo. Now I use an USB->PS2 adapter and turn "USB keyboard support" off.
>
> If "handoff failed" and "USB keyboard support" are related wouldn't it
> make sense to change the USB error handling?
>
> Regards
> Sebastian
I digged deeper:
* the same happens with older kernels (I tried 2.6.17.13 for instance)
* the handoff works every time when "USB Keyboard Support" is disabled
in my BIOS
* the handoff doesn't work when I enable "USB Keyboard Support" and use
the keyboard at the lilo prompt (up, down, enter ...). It does work,
though, when I keep my hands afk.
I also increased the wait time from 5 seconds to 20 in
drivers/usb/host/pci-quirks.c but that didn't change anything. I guess
the bios won't release OHCI in order to be able to serve keyboard input
without usb hid drivers once I hit a key when bios is still in charge.
But I looked around and couldn't see any ill effects so I'll stop
bothering you with this ;-)
Regards
Sebastian
Hardware:
* 32bit Sempron
* Shutte AN35N NForce2 mainboard
...
IP route cache hash table entries: 4096 (order: 2, 16384 bytes)
TCP established hash table entries: 16384 (order: 4, 65536 bytes)
TCP bind hash table entries: 8192 (order: 3, 32768 bytes)
TCP: Hash tables configured (established 16384 bind 8192)
TCP reno registered
Machine check exception polling timer started.
io scheduler noop registered
io scheduler cfq registered (default)
0000:00:02.0 OHCI: BIOS handoff failed (BIOS bug ?) 00000784
############################################################
ACPI: PCI Interrupt Link [LNK4] enabled at IRQ 11
PCI: setting IRQ 11 as level-triggered
ACPI: PCI Interrupt 0000:02:00.0[A] -> Link [LNK4] -> GSI 11 (level,
low) -> IRQ 11
radeonfb: Found Intel x86 BIOS ROM Image
radeonfb: Retrieved PLL infos from BIOS
...
/usr/src/linux/scripts/ver_linux
If some fields are empty or look unusual you may have an old version.
Compare to the current minimal requirements in Documentation/Changes.
Linux section_eight 2.6.19 #3 Fri Dec 1 19:04:08 CET 2006 i686 AMD
Sempron(tm) 2400+ AuthenticAMD GNU/Linux
Gnu C 4.1.1
Gnu make 3.81
binutils 2.16.1
util-linux 2.12r
mount 2.12r
module-init-tools 3.2.2
e2fsprogs 1.39
Linux C Library > libc.2.4
Dynamic linker (ldd) 2.4
Procps 3.2.6
Net-tools 1.60
Kbd 1.12
Sh-utils 6.4
udev 103
Modules Loaded rt61 lirc_serial lirc_dev
On Fri, 1 Dec 2006 19:28:55 +0100, Sebastian Kemper <[email protected]> wrote:
> I also increased the wait time from 5 seconds to 20 in
> drivers/usb/host/pci-quirks.c but that didn't change anything.
That was a good try, but I thought maybe it needs doing something
twice, or having some extra bits set... There's always a possibility
that the BIOS refuses the handoff on purpose though. If it does not
cause any misbehaviour, it may be safe to ignore.
-- Pete
On Fri, 1 Dec 2006 15:23:39 -0800, [email protected] wrote:
> BIOS handoff assumes an SMI, right? Could SMI be masked?
That might be a bad idea, because things like fans may be controlled
by SMM BIOS. The best thing we can do is to follow the published
procedure, and maybe insert a workaround if Sebastian can identify it.
-- Pete
On Fri, Dec 01, 2006 at 03:02:01PM -0800, Pete Zaitcev wrote:
> On Fri, 1 Dec 2006 19:28:55 +0100, Sebastian Kemper <[email protected]> wrote:
>
> > I also increased the wait time from 5 seconds to 20 in
> > drivers/usb/host/pci-quirks.c but that didn't change anything.
>
> That was a good try, but I thought maybe it needs doing something
> twice, or having some extra bits set... There's always a possibility
> that the BIOS refuses the handoff on purpose though. If it does not
> cause any misbehaviour, it may be safe to ignore.
BIOS handoff assumes an SMI, right? Could SMI be masked?
On Fri, Dec 01, 2006 at 03:29:22PM -0800, Pete Zaitcev wrote:
> On Fri, 1 Dec 2006 15:23:39 -0800, [email protected] wrote:
>
> > BIOS handoff assumes an SMI, right? Could SMI be masked?
>
> That might be a bad idea, because things like fans may be controlled
> by SMM BIOS. The best thing we can do is to follow the published
> procedure, and maybe insert a workaround if Sebastian can identify it.
Sorry, I don't mean "could we mask it" but rather "is it possible that it
is already masked"?
Tim
On Fri, Dec 01, 2006 at 03:32:47PM -0800, [email protected] wrote:
> On Fri, Dec 01, 2006 at 03:29:22PM -0800, Pete Zaitcev wrote:
> > On Fri, 1 Dec 2006 15:23:39 -0800, [email protected] wrote:
> >
> > > BIOS handoff assumes an SMI, right? Could SMI be masked?
> >
> > That might be a bad idea, because things like fans may be controlled
> > by SMM BIOS. The best thing we can do is to follow the published
> > procedure, and maybe insert a workaround if Sebastian can identify it.
>
> Sorry, I don't mean "could we mask it" but rather "is it possible that it
> is already masked"?
>
> Tim
Hi,
I can't see any negative effects when the handoff fails. But if any of
you think it's worth to get to the bottom of this I'm more than willing
to help the best I can. But I don't know what SMI nor SMM BIOS is, just
so you know that I can't figure out these things on my own.
I extracted my BIOS' dsdt and disassembled it (on a hunch). I grepped
it for strings like "Microsoft" and "Windows" and found three:
Method (_INI, 0, NotSerialized)
{
If (STRC (_OS, "Microsoft Windows"))
{
Store (0x56, SMIP)
}
Else
{
If (STRC (_OS, "Microsoft Windows NT"))
{
If (CondRefOf (_OSI, Local0))
{
If (_OSI ("Windows 2001"))
{
Store (0x59, SMIP)
Store (Zero, OSFL)
Store (0x03, OSFX)
}
}
Else
{
Store (0x58, SMIP)
Store (Zero, OSFL)
}
}
Else
{
Store (0x57, SMIP)
Store (0x02, OSFL)
}
}
}
So I tried all possible combinations of acpi_os_name and acpi_osi
(allthough the latter seemed to be ignored by the ACPI system). But this
didn't change the OHCI handoff behaviour. At least we can rule this one
out. But probably disassembling the dsdt was a waste of time :-)
Regards
Sebastian