On Fri, 29 Aug 2008, Yinghai Lu wrote:
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
So this didn't work _originally_ either?
> solutions will be
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
which you said came from another BAR. That isn't the HPET.
> 2. or the one you are reverted... check_bar_with_valid. (hpet, ioapic,
Yeah, no, that's horrid. I'm happy it's reverted.
> 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
Yes. And I do think this is a workable model.
Linus
--
| Greg KH | [GIT PATCH] driver core patches against 2.6.24 |
| Linus Torvalds | Linux 2.6.27-rc8 |
| Christoph Lameter | Re: Major regression on hackbench with SLUB (more numbers) |
| Mike Travis | Re: [RFC 00/15] x86_64: Optimize percpu accesses |
git: | |
| Gerrit Renker | [PATCH 15/37] dccp: Set per-connection CCIDs via socket options |
| Jarek Poplawski | Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| David Miller | [GIT]: Networking |
| Hugh Dickins | Re: [bug?] tg3: Failed to load firmware "tigon/tg3_tso.bin" |
