[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1254804819.14541.101.camel@macbook.infradead.org>
Date: Tue, 06 Oct 2009 05:53:39 +0100
From: David Woodhouse <dwmw2@...radead.org>
To: Nick Piggin <npiggin@...e.de>, hpa@...or.com, greg@...ah.com
Cc: Mikael Pettersson <mikpe@...uu.se>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Patch "USB: Work around BIOS bugs by quiescing USB controllers
earlier" causes MCEs
On Tue, 2009-10-06 at 06:44 +0200, Nick Piggin wrote:
> > Changing this quirk back to a FIXUP_FINAL allows the platform's PCI
> > init to complete. Later on the generic pci_init() calls the quirk,
> > which now gets the correct I/O base address, and the outw()s in
> > uhci_reset_hc() don't fail.
>
> Thanks for this, I guess we await David's response.
The problem is that FIXUP_FINAL is too late. If the USB controllers are
still active at the time the IOMMU is initialised, then DMA for their
'legacy keyboard/mouse emulation' will go AWOL -- because the BIOS
authors are too incompetent to tell the OS about it correctly.
And then the whole system goes down, locked up in SMM mode because the
BIOS authors are too incompetent to write code which can _cope_ with the
DMA going AWOL. Or do any testing.
One option is to add a new quirk somewhere in the middle, or to invoke
the USB fixups manually rather than by the quirk mechanism.
Another might be to move the initialisation of the IOMMU to later in the
boot, so it happens just after the final PCI fixups.
But I distinctly remember a conversation, probably with hpa, in which he
(or whoever) said that he wants to kill the USB controllers even
_earlier_ in the boot process, because of other problems. So I was kind
of hoping that whoever it was would pipe up. And then we'd take that
option.
--
David Woodhouse Open Source Technology Centre
David.Woodhouse@...el.com Intel Corporation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists