MTRR fixup?

Scott Long scottl at
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.


More information about the freebsd-current mailing list