OSDev.org

Hey everybody. I have a very specific problem.
GRUB is not returning enough memory. Instead of 4 GB it only returns 3145215 KB (3.14 GB) of usable RAM. Also I tested it on my PC which has 8 GB of DDR4, same story applies.
It seems to be locked at 3.14 GB max. Why could this be happening. It has nothing to do with my OS, tried booting it bare bones (no OS specific code) - same story.
Did anyone encounter this before? Does it matter if I am using GRUB 2 with an old 0.6.96 specification header?

Hi,



My first guess is that you've got some kind of bug that causes any RAM where the physical address doesn't fit in 32 bits (RAM above 4 GiB) to be ignored.

Typically there's a "PCI hole" (plus space for a few other things, like the firmware ROM, local APICs, etc) that ends at 0xFFFFFFFF and is often relatively large (e.g. 512 MiB, 1 GiB, ...). When a computer has more than about 3 GiB of RAM (depending on size of the "PCI hole") a good chipset will relocate any RAM where the hole is to a higher address (0x0000000100000000). For example, with 4 GiB of RAM and a 512 MiB hole you'd probably have 3.5 GiB (minus any RAM firmware reserved for things like ACPI) below 4 GiB and then an extra 512 GiB of RAM above 4 GiB.

Note that there are some (older) "cheap and nasty" motherboards/chipsets that don't do this relocation; where if 4 GiB or more RAM is installed anything that would be at the "PCI hole" disappears. Also don't forget that computers with integrated video normally take some of the RAM too (e.g. with 8 GiB of RAM you might have about 3 GiB below 4 GiB, 4 GiB above 4 GiB, and 1 GiB used for video). Of course neither of these things are likely for emulators.


Cheers,

Brendan

No commas, many numbers - took me around 30 reads before I could understand this. 512 GiB doe?
I have a very good motherboard. I don't think it should cause any problems.
Almost every computer (better said motherboard) has an integrated graphics card/processor these days.
As you stated it is very unusual for emulators to behave like this.
What could be the cause? GRUB? Myself (not likely)?
I can't really do anything about these holes, can't I?

Some video cards are dedicated, some are just generic onboard ones.

Dedicated video cards, no matter how simple, free main RAM from being accessed constantly just to display video. They have their own RAM and complex stand-alone display circuitry. That causes the full main RAM bus speed to be available to running programs, not shared between refreshing the video and running code.

Even a single-core machine feels noticeably faster. VESA modes look practically like native ones (depending on the quality of graphics implementation too), almost as if it was a dual-core machine.

Hi,



Sorry - that is a silly typo (should've been 512 MiB).



It's extremely unlikely that it's a problem with GRUB and extremely unlikely that multiple different (real and virtual) computers all happen to have the same bug; which means that it's extremely likely that the problem is somewhere in your code (accidentally trashing or truncating the memory map, not handling 64-bit physical addresses properly, not printing 64-bit integers properly, assuming physical RAM is contiguous, ...).



In practice, there's nothing you can really do. In theory you might be able to write your own firmware to pre-configure the chipset as "hole-less", but I wouldn't consider that sane and wouldn't assume that all computers support being configured that way.

Also note that in practice (assuming you use paging) there shouldn't be any reason to care if there's holes everywhere or not.


Cheers,

Brendan

I am glad it is (likely) my fault, that means it can be fixed. I am not touching 64-bit integers at all. The way I am getting the total amount of memory is - (multiboot_info->memory_lower + multiboot_info->memory_upper).
An unsigned integer can handle (2,147,483,647 / 1024) KB of RAM returned by GRUB, aka ~2048 GB of detectable memory (for uint32_t).
I use paging so then there is no need to care for those holes. That is good.
The question is, what is being overwritten? How is that possible considering bare bones code? I should try to compile someone's else kernel to see if they've got the same issue.

You seem to be missing the crucial point, namely that on most x86 systems the physical memory is not mapped continuously. There are typically holes just before the 1MB mark, and some section of addresses before the 4G mark is usually also used for hardware. Because you use the simple memory map format from grub (instead of the more complicated but flexible one given by the mmap fields), it can only tell you about the amount before the 1M hole, and the amount from 1M to wherever the next hole is. On most systems with larger amounts of memory, this will not show you all the memory, simply because there are holes in the way.

Just to be sure, you are trying to get the memory info from the Multiboot memory map, right? Not from BIOS and not from mem_lower and _upper? I've never even read what's in the mem_lower and _upper.. I only ever use the memory map since it's the only sane solution.

And with the memory map you are iterating thru all of the entries? Does this happen with emulators?

If nothing else, can you just print the memory map and copy it here?

Is this all just your opinion or is it also based on facts?

For instance, if you don't use 3D acceleration, then where is the actual "picture" to be displayed composited? In a RAM based framebuffer? How does that end up on the discrete display adapter's VRAM? By copying it from RAM to VRAM? How does it avoid RAM access?

Integrated GPU solutions also have "complex stand-alone display circuitry"...

That makes sense... So it is likely that GRUB doesn't care about that at all. Good peace of information. +1

Not really. It is basically:


How would you use the memory map, it does not make any sense to me. Care to explain a bit?

Here is how it looks like:


Yes it does happen with emulators too.
How can I get the total amount of memory from this data? Since it returns 4 GB no matter if it is 2 GB or 1000 GB. To do like length_1 + length_2 + length_3 + length_4?

GPU also counts as more than one core and dedicated video system/bus.

I have a K8MM-V for development with onboard video, 2GB, 2GHz, shared video RAM.

Once I installed a 512MB nVidia in dedicated AGP, I could even watch and record TV the whole day, using a generic Windows 98 VBE 2 driver, because there is no native driver for that card.

It feels as if at the very least I'm finally using the whole speed of the system.

Emulation of Windows XP under Bochs 2.6 is also faster.

If I go back to use the onboard shared video, the system is not so outstanding in performance or speed. It is visible when recording from a LifeView FlyTV FlyVideo 2000.

Basic DirectX functionality seems available in this setup.

Dedicated video doesn't need to use bandwidth from main system RAM because it has its own RAM to read that in a dedicated way instead.

I managed to solve it. Thanks for letting me know that memory_upper and memory_lower fields are not reliable.
So basically I tried to sum up all the memory map lengths, and it matched perfectly with what I was expecting.
What a stupid little misinterpretation. I didn't know it was that easy.
Now emulators return ~4 GB as expected, except Bochs. (which is always special, it also has a shorter memory map emulation so this behavior is expected)
There is one more thing doe - when I run this thing on my PC it only returns 4.3 GB instead of 8 GB. Is this supposed to happen?

With regards to the lower/upper, if I were to tell you the system has 8 GiB RAM, but I don't tell you at what _physical_ address it is, how would you ever be able to use it? By assuming it starts at zero and goes up to 8GiB? That's a relatively fair assumption, but in reality there are holes in it that are used for other purposes and are not RAM. As a consequence even if the lower/upper reported everything you still wouldn't be able to reliable use it.

So you need to look at the memory map which tells you exactly where is available RAM, that you can use as physical memory. You should look the detecting memory wiki page as well as the other related memory pages and maybe the threads where Brendan has in lengths explained how to do this stuff properly. For instance the memory map is not "sanitized" for you, which means you need to sort it, remove overlaps and in cases of overlap decide what's safe (err on the side of caution), combine adjacent areas if they are of same type, etc.. Most stuff I've seen give a nice clean memory map that is sorted, but not all devices.

As for the 4,3GiB vs 8GiB, as far as I know that shouldn't happen. So I'd still look at your code to find the reason, are you fully printing the entire memory map? Have you used some other OS (Windows, Linux, etc) on that same PC? If so, do they report all of the RAM? If you think they do, check and verify. Can you copy that memory map here? You didn't mention where you got the previous memory map from, so I don't know what that is..

Tilde, since you are talking about AGP which was deprecated around 2004 according to Wikipedia (superseded by PCI-E), you are talking about "antiquated" piece of tech. I was talking about something a bit more recent.

I think it's a fair assumption that if not explicitly stated everyone is talking about something modern which means at most 5 years old hardware. So if you want to talk about 80386 you should say that explicitly, I certainly won't assume anyone is talking about 10+ years old hardware by default.

First integrated graphics were pretty bad, modern are actually pretty decent and it's possible that discrete GPU will become extinct. AFAIK integrated is already be far more common, though PC gamers according to Steam (IIRC) do still use more discrete than integrated.

Also, I haven't touched (thankfully) Win98 in close to two decades and I have no wish to ever even hear about Win98.

It's entirely possible that the performance difference you see is not caused by memory bandwidth, but rather by other things that change when using a discrete graphics card. Such as less swapping (if swapping is enabled), in general less memory usage, etc..