summaryrefslogtreecommitdiffstats
path: root/drivers/net/wireless/rt2x00/rt2x00queue.h
diff options
context:
space:
mode:
authorYinghai Lu <yhlu.kernel@gmail.com>2008-08-25 00:56:08 -0700
committerIngo Molnar <mingo@elte.hu>2008-08-25 10:02:03 +0200
commita2bd7274b47124d2fc4dfdb8c0591f545ba749dd (patch)
tree06be7ab89e371f6fe803075bdcc2f0902cba105a /drivers/net/wireless/rt2x00/rt2x00queue.h
parent060700b571717c997a2ea5e2049b848fa248ee13 (diff)
downloadop-kernel-dev-a2bd7274b47124d2fc4dfdb8c0591f545ba749dd.zip
op-kernel-dev-a2bd7274b47124d2fc4dfdb8c0591f545ba749dd.tar.gz
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>
Diffstat (limited to 'drivers/net/wireless/rt2x00/rt2x00queue.h')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud