On Fri, Aug 29, 2008 at 7:33 PM, Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > > > On Fri, 29 Aug 2008, Yinghai Lu wrote: >> >> 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 problem there was that traditionally, e820_reserve_resource() > expected to be the first one to populate any resources. That's changed, > and that's why it now needs to use "insert_resource()" rather than > "request_resource()". > >> 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. > > So this didn't work _originally_ either? orginally it works, because lapic address entry open the big hole for near address. > >> solutions will be >> 1. use quirk to protect hpet in BAR, Ingo said it is not generic. > > Yeah, I don't like it. The quirk I was talking about was the one about > apparetly bogus MMIO address: > >>> pci 0000:00:00.0: BAR has MMCONFIG at e0000000-ffffffff >> PCI: Using MMCONFIG at e0000000 - efffffff >> >> Where did it get that bogus "ffffffff" end address? > > which you said came from another BAR. That isn't the HPET. that is from Rafael's system mmconfig BAR in 00:00.0. that chipset is broken ... > > >> 2. or the one you are reverted... check_bar_with_valid. (hpet, ioapic, >> mmconfig) --> happenly reveal another problem with Rafael's >> system/chipset. > > Yeah, no, that's horrid. I'm happy it's reverted. if update res->end according mmconfig end, before insert it forcibly, then could fix the chipset BAR problem too. > >> 3. or sticky resource... , but could have particallly overlapping > > And no, this doesn't work. > >> 4. or don't register reserved entries in e820.. Eric, Nacked. > > Yeah, no, we do want reserved entries from e820 to show up to at least > stop late _dynamic_ allocations from taking over. > >> 5. or you sugges, regiser some reserved entries later...., and have >> insert_resource_expand_to_fit... > > Yes. And I do think this is a workable model. BTW, insert_resource_expand_to_fit need to be replaced with insert_resource_split_to_fit.... test stub reveal expand will make __request_region not working for some devices...because reserved_entries from e820 take IORESOUCE_BUSY... YH -- To unsubscribe from this list: send the line "unsubscribe kernel-testers" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
