Cc: Rafael J. Wysocki <rjw@...>, Linux Kernel Mailing List <linux-kernel@...>, Jeff Garzik <jeff@...>, Tejun Heo <htejun@...>, Ingo Molnar <mingo@...>, David Witbrodt <dawitbro@...>, Andrew Morton <akpm@...>, Kernel Testers <kernel-testers@...>
On Fri, Aug 29, 2008 at 6:11 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
we reverted the commit , David's problem still happen.
the root cause is:
before 2.6.26, call init_apic_mapping and will insert_resource for
lapic address.
and then call e820_resource_resouce (with request_resource) to
register e820 entries.
so the lapic entry in the resource tree will prevent some entry in
e820 to be registered.
later request_resource for BAR res (==hpet) will succeed.
from 2.6.26. we move lapic address registering to late_initcall, so
the entry is reserved in e820 getting into resource tree at first.
and later pci_resource_survey::request_resource for BAR res (==hpet,
0xfed00000) will fail. so pci_assign_unsigned... will get new
res for the BAR, so it messed up hpet setting.
solutions will be
1. use quirk to protect hpet in BAR, Ingo said it is not generic.
2. or the one you are reverted... check_bar_with_valid. (hpet, ioapic,
mmconfig) --> happenly reveal another problem with Rafael's
system/chipset.
3. or sticky resource... , but could have particallly overlapping
4. or don't register reserved entries in e820.. Eric, Nacked.
5. or you sugges, regiser some reserved entries later...., and have
insert_resource_expand_to_fit...
YH
--
