Sign in with
Sign up | Sign in
Your question
Solved

No memory remapping option

Tags:
  • Option
  • Foxconn
  • BIOS
  • Motherboards
  • Memory
  • Windows 7
  • Graphics Cards
Last response: in Motherboards
Share
June 15, 2014 3:41:08 PM

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.

More about : memory remapping option

a c 369 V Motherboard
a b } Memory
a b $ Windows 7
a c 235 U Graphics card
June 15, 2014 3:48:34 PM

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.
m
0
l
June 15, 2014 3:57:26 PM

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?
m
0
l
Related resources
a c 369 V Motherboard
a b } Memory
a b $ Windows 7
a c 235 U Graphics card
June 15, 2014 6:00:56 PM

Post your build
m
0
l
June 15, 2014 9:01:59 PM

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
m
0
l
a c 369 V Motherboard
a b } Memory
a b $ Windows 7
a c 235 U Graphics card
June 15, 2014 9:09:33 PM

"I've determined that the only way for my new graphics card to work is to truncate the memory in the bcdedit settings"

I've got no idea why you would think that. Everything looks normal and should run.

What make and model power supply?
m
0
l
June 15, 2014 9:45:15 PM

I've got a good power supply: EVGA SuperNOVA 850G2 80PLUS Gold Certified ATX12V/EPS12V 850W Power Supply 220-G2-0850-XR .

The reason I thought to truncate the memory is from this forum post: https://foldingforum.org/viewtopic.php?f=38&t=15472

m
0
l
a c 369 V Motherboard
a b } Memory
a b $ Windows 7
a c 235 U Graphics card
June 15, 2014 9:48:49 PM

Yep - that's a good psu. Only single rail 12V.

It doesn't give any particular problem. Just say new gpu is faster than old.

m
0
l
June 15, 2014 9:53:19 PM

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.
m
0
l
a c 369 V Motherboard
a b } Memory
a b $ Windows 7
a c 235 U Graphics card
June 15, 2014 10:51:13 PM

I can't see what "I have seen these kind of symptoms on my old system" means - what symptoms?
m
0
l
June 15, 2014 11:10:03 PM

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

m
0
l
a c 369 V Motherboard
a b } Memory
a b $ Windows 7
a c 235 U Graphics card
June 16, 2014 1:12:18 AM

Do you think he's playing with integrated video? It uses system ram to run.
m
0
l
June 16, 2014 5:20:31 AM

Well the Renaissance doesn't have onboard graphics...
m
0
l
a c 369 V Motherboard
a b } Memory
a b $ Windows 7
a c 235 U Graphics card
June 16, 2014 5:40:31 AM

Why would he think "it's a result of some kind of mismatch between the MTRR and the e820"?
m
0
l
June 16, 2014 6:14:58 AM

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


m
0
l
June 16, 2014 11:04:39 AM

What do you think?
m
0
l
a c 369 V Motherboard
a b } Memory
a b $ Windows 7
a c 235 U Graphics card
June 16, 2014 5:27:41 PM

I would just leave well enough alone.
m
0
l
June 17, 2014 8:54:11 AM

Should I just buy a new motherboard? This Foxconn and its BIOS are really just trash.
m
0
l

Best solution

a c 369 V Motherboard
a b } Memory
a b $ Windows 7
a c 235 U Graphics card
June 17, 2014 4:25:12 PM

Yep Foxconn and Biostar are here with problems quite often.

Try an Asus, ASRock, Gigabyte
Share
!