Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 3 Sep 2008 17:46:35 -0400
From:      "Josh Carroll" <josh.carroll@gmail.com>
To:        "David Malone" <dwmalone@maths.tcd.ie>
Cc:        Bernd Walter <ticso@cicely7.cicely.de>, ticso@cicely.de, freebsd-current@freebsd.org
Subject:   Re: MTRR fixup?
Message-ID:  <8cb6106e0809031446i3e2a47dar385125ecfb0275dc@mail.gmail.com>
In-Reply-To: <20080903204759.GA4898@walton.maths.tcd.ie>
References:  <20080903034943.GD11548@cicely7.cicely.de> <20080903204759.GA4898@walton.maths.tcd.ie>

next in thread | previous in thread | raw e-mail | index | archive | help
> 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).

I'm guessing this means I am affected:

0xd0000000/0x10000000 BIOS uncacheable set-by-firmware active
0xe0000000/0x20000000 BIOS uncacheable set-by-firmware active

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?

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

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.

Can someone confirm whether the above assumptions are correct?

Thanks,
Josh



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8cb6106e0809031446i3e2a47dar385125ecfb0275dc>