x86: fix HPET regression in 2.6.26 versus 2.6.25, check hpet against BAR, v3
authorYinghai Lu <yhlu.kernel@gmail.com>
Mon, 25 Aug 2008 07:56:08 +0000 (00:56 -0700)
committerIngo Molnar <mingo@elte.hu>
Mon, 25 Aug 2008 08:02:03 +0000 (10:02 +0200)
commita2bd7274b47124d2fc4dfdb8c0591f545ba749dd
tree06be7ab89e371f6fe803075bdcc2f0902cba105a
parent060700b571717c997a2ea5e2049b848fa248ee13
x86: fix HPET regression in 2.6.26 versus 2.6.25, check hpet against BAR, v3

David Witbrodt tracked down (and bisected) a hpet bootup hang on his
system to the following problem: a BIOS bug made the hpet device
visible as a generic PCI device. If e820 reserved entries happen to
be registered first in the resource tree [which v2.6.26 started doing],
then the PCI code will reallocate that device's BAR to some other
address - breaking timer IRQs and hanging the system.

( Normally hpet devices are hidden by the BIOS from the OS's PCI
  discovery via chipset magic. Sometimes the hpet is not a PCI device
  at all. )

Solve this fundamental fragility by making non-PCI platform drivers
insert resources into the resource tree even if it overlaps the e820
reserved entry, to keep the resource manager from updating the BAR.

Also do these checks for the ioapic and mmconfig addresses, and emit
a warning if this happens.

Bisected-by: David Witbrodt <dawitbro@sbcglobal.net>
Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com>
Tested-by: David Witbrodt <dawitbro@sbcglobal.net>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
arch/x86/pci/i386.c