> 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, JoshReceived on Wed Sep 03 2008 - 20:08:04 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:34 UTC