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