Re: MTRR fixup?

From: Josh Carroll <josh.carroll_at_gmail.com>
Date: Wed, 3 Sep 2008 23:43:08 -0400
> The SMAP table, printed early during boot when bootverbose is set, will
> tell you what is mapped where.

Ok, here is my SMAP (I had to transcribe it by hand from a picture, it
doesn't appear in dmesg or get written to /var/run/dmesg.boot):

SMAP type=01 base=0000000000000000 len=000000000009ec00
SMAP type=02 base=000000000009ec00 len=0000000000001400
SMAP type=02 base=00000000000e4000 len=000000000001c000
SMAP type=01 base=0000000000100000 len=00000000cfe80000
SMAP type=03 base=00000000cff80000 len=000000000000e000
SMAP type=04 base=00000000cff8e000 len=0000000000052000
SMAP type=02 base=00000000cffe0000 len=0000000000020000
SMAP type=02 base=00000000fee00000 len=0000000000001000
SMAP type=02 base=00000000ffe00000 len=0000000000200000
SMAP type=01 base=0000000100000000 len=0000000030000000

Comparing that to the memcontrol list output for uncacheable address
ranges (the large high-order ones):

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

It looks like there is only overlap for type 02 (which is "reserved"
from sys/amd64/include/pc/bios.h) and of just 4K and 2M respectively:

SMAP type=02 base=00000000fee00000 len=0000000000001000 (4 KB) resides
inside uncacheable range [e0000000,100000000]
SMAP type=02 base=00000000ffe00000 len=0000000000200000 (2048 KB)
resides inside uncacheable range [e0000000,100000000]

So I guess for this particular board/BIOS it is not an issue.

>>> At best, nothing will happen.  But more likely, your box won't boot.

Yes, it caused a deadlock after some increased memory usage. Lesson learned.

Josh
Received on Thu Sep 04 2008 - 01:43:09 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:34 UTC