No memory remapping option

ryandward

Honorable
Jun 6, 2014
36
0
10,530
I've got a Foxconn Renaissance motherboard, and I'm using the newest supportable version of BIOS, 6GB memory, 2GB memory on my GTX760 graphics card, and WIndows 7 x64,

Unfortunately, there's no option to enable memory remapping, which is causing me a really strange problem. After about a week of fiddling with the settings, I've determined that the only way for my new graphics card to work is to truncate the memory in the bcdedit settings.

After trial and error I determined that truncating at in the memory address 0x12c9003ee (4.7GB) gives me exactly 4GB of memory available to Windows, and reserves exactly 2GB in the resource monitor under "Hardware Reserved". If I reserve any less the graphics card doesn't work well, and the whole system sputters and lags.

I assume this has something to do with poor memory mapping, because the graphics card works flawlessly but I'm not able to use those last 2GB of RAM.

Is there anything I can do given my BIOS does not support memory remapping? The motherboard can support upto 24GB or RAM.
 
First off there is no need for memory remapping.

All you can do there is change the allocation for integrated graphics, not a discrete card like the gtx760.

The gtx760 vram has nothing to do with system memory (ram).

If you think you've got ram problems, try MemTest on it.
 

ryandward

Honorable
Jun 6, 2014
36
0
10,530
I've got no problems with the RAM, memtest comes back with no errors. But the only thing that helps is truncating the memory, otherwise the system is unusable. It takes ~15 minutes to boot up, as opposed to 10 seconds with truncation. If it's not remapping what else could it be?
 

ryandward

Honorable
Jun 6, 2014
36
0
10,530
Foxconn Renaissance LGA 1366 Intel X58 ATX Intel Motherboard

Intel Core i7-950 Bloomfield Quad-Core 3.06GHz LGA 1366 130W Processor

(3 x 2GB) OCZ Platinum 6GB 240-Pin DDR3 SDRAM DDR3 1600

EVGA GeForce GTX760 SuperClocked w/EVGA ACX Cooler 2GB

Intel 320 Series SSDSA2CW120G3K5 2.5" 120GB SATA II MLC Internal (SSD) - Windows is installed on this drive

Western Digital WD Black WD1001FALS 1TB - Has some other programs installed on this larger drive

Windows 7 Home Premium
 

ryandward

Honorable
Jun 6, 2014
36
0
10,530
So are you saying there's not really much merit to this guy's advice?



I have seen these kind of symptoms on my old system, so here is a good guess as to the issue at hand. The BIOS fails to mark the last several (hundred?) megabytes of RAM as "cacheable". The OS "randomly" uses those un-cached memory pages, and gets really slow as a result.

The likely reason you don't see this when using the old card is that the BIOS algorithm works "okay" when it sees a 1024MB card. It probably gets confused when it sees a 1280MB card.

When running with less RAM installed, the inputs to the algorithm change, and it could successfully mark all RAM as cacheable. When running with a 32-bit OS, the top of the RAM is chopped off, which is where the problem resides, so the issue no longer occurs.

Suggested workaround: Use the Windows boot loader configuration to "chop off" some RAM from the TOP of the address space. Either by guess-and-check (start with 256MB for example), or use the actual data from the system.



I don't get it though, because I've got a 64 bit system, but so far this has been the only thing that works. I was on the brink of sending my new graphics card back before I truncated it, and it works like it should, but just at the expense of sacrificing 2GB memory for a 2GB card.
 

ryandward

Honorable
Jun 6, 2014
36
0
10,530
He's referring to installing a new graphics card and having the computer behave like it has almost no RAM, and the CPU jumping up and down wildly. He thinks it's a result of some kind of mismatch between the MTRR and the e820 (memory map).

 

ryandward

Honorable
Jun 6, 2014
36
0
10,530
His idea was that truncating the memory before the first uncachable entry in MTRR would make the system work the best.

It also might be worth noting that Ubuntu works perfectly without having to do any workarounds, although it reduces the memory to 5.6GB. But Windows only lets you truncate the memory above a certain point, and won't mark certain address ranges as "not memory" the way Ubuntu does.

ubuntu@ubuntu:~$ cat /proc/mtrr
reg00: base=0x000000000 ( 0MB), size= 2048MB, count=1: write-back
reg01: base=0x080000000 ( 2048MB), size= 1024MB, count=1: write-back
reg02: base=0x0c0000000 ( 3072MB), size= 256MB, count=1: write-back
reg03: base=0x0d0000000 ( 3328MB), size= 64MB, count=1: write-back
reg04: base=0x0d3800000 ( 3384MB), size= 8MB, count=1: uncachable
reg05: base=0x100000000 ( 4096MB), size= 2048MB, count=1: write-back
reg06: base=0x180000000 ( 6144MB), size= 512MB, count=1: write-back

ubuntu@ubuntu:~$ dmesg | grep e820
[ 0.000000] e820: BIOS-provided physical RAM map:
[ 0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009fbff] usable
[ 0.000000] BIOS-e820: [mem 0x000000000009fc00-0x000000000009ffff] reserved
[ 0.000000] BIOS-e820: [mem 0x00000000000e4000-0x00000000000fffff] reserved
[ 0.000000] BIOS-e820: [mem 0x0000000000100000-0x00000000d378ffff] usable
[ 0.000000] BIOS-e820: [mem 0x00000000d3790000-0x00000000d379dfff] ACPI data
[ 0.000000] BIOS-e820: [mem 0x00000000d379e000-0x00000000d37cffff] ACPI NVS
[ 0.000000] BIOS-e820: [mem 0x00000000d37d0000-0x00000000d37dffff] reserved
[ 0.000000] BIOS-e820: [mem 0x00000000d37ec800-0x00000000d3ffffff] reserved
[ 0.000000] BIOS-e820: [mem 0x00000000fee00000-0x00000000fee00fff] reserved
[ 0.000000] BIOS-e820: [mem 0x00000000ffb00000-0x00000000ffffffff] reserved
[ 0.000000] BIOS-e820: [mem 0x0000000100000000-0x00000001abffffff] usable