Re: MTRR fixup?

Josh Carroll wrote:
>> You may be able to fix this by just using the memcontrol command -
>> it already lets you program the MTRRs.
> 
> Hmm, I think this explains why the amount of ACTIVE memory never
> exceeds 3G on this box with 4G (with very little WIRED when it "stops"
> at 3G).

Actually, it likely doesn't.

> 
> I'm guessing this means I am affected:
> 
> 0xd0000000/0x10000000 BIOS uncacheable set-by-firmware active
> 0xe0000000/0x20000000 BIOS uncacheable set-by-firmware active

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.

> 
> I wrote a little script to parse the memcontrol output to make it a
> little easier to digest at a glance.
> 
> Memory range [a0000 - a4000] : (640 - 656) is uncacheable {16 KB}
> Memory range [a4000 - a8000] : (656 - 672) is uncacheable {16 KB}
> Memory range [a8000 - ac000] : (672 - 688) is uncacheable {16 KB}
> Memory range [ac000 - b0000] : (688 - 704) is uncacheable {16 KB}
> Memory range [b0000 - b4000] : (704 - 720) is uncacheable {16 KB}
> Memory range [b4000 - b8000] : (720 - 736) is uncacheable {16 KB}
> Memory range [b8000 - bc000] : (736 - 752) is uncacheable {16 KB}
> Memory range [bc000 - c0000] : (752 - 768) is uncacheable {16 KB}
> Memory range [d0000000 - e0000000] : (3407872 - 3670016) is
> uncacheable {262144 KB}
> Memory range [e0000000 - 100000000] : (3670016 - 4194304) is
> uncacheable {524288 KB}
> 
> So if I'm understanding this correctly, the top 768 MB of physical
> memory on this box is uncacheable, but usable for other purposes?

Used for PCI, yes.

> 
> I guess I haven't noticed this since FreeBSD does not (apparently?)
> start caching from the top of memory like Linux does?

Irrelevant observation =-)

> 
> 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.


Scott