MTRR fixup?
Scott Long
scottl at samsco.org
Wed Sep 3 23:03:56 UTC 2008
Josh Carroll wrote:
>> Actually, it likely doesn't.
>
> Ok, something else then. My second guess (and what I thought prior to
> seeing this mail thread) was that it was perhaps address space
> reserved for the kernel? Off topic for this thread I suppose, I can
> ask elsewhere.
>
>> All systems reserve the top 256MB of the address space for PCI
>> memory and chipset registers. Modern systems have started
>> reserving even more than that for other new PCI functionality.
>> Note that this is address space, not RAM. The RAM is likely
>> being remapped to some place above the 4GB barrier.
>
> That makes sense. But is there a way to correlate where the physical
> memory is mapped with the memory ranges listed in memcontrol list
> output then? Or how would someone check if they are, in fact, affected
> by this sort of BIOS bug?
>
The SMAP table, printed early during boot when bootverbose is set, will
tell you what is mapped where.
>>> I'll have to play with memcontrol to see if I can set those two large
>>> ranges as cacheable. So this is a BIOS bug? The board in question is
>>> an Asus P5K-E with BIOS revision 1102, which uses an Intel P35
>>> chipset.
>> At best, nothing will happen. But more likely, your box won't boot.
>
> So I'd be stepping on/trashing memory ranges used for PCI device
> mappings? I guess I probably just started a ticking time bomb then,
> huh? :)
No, you'd made PCI registers be cachable, making any reads from them
unreliable and useless.
Scott
More information about the freebsd-current
mailing list