The bottom line is that the BIOS isn't giving Linux access to the chunk of ram that you reported missing in your other thread.
http://www.linuxquestions.org/questi...31#post3387331
There is nothing in that dmesg output regarding any memory given to the onboard video. But more memory is missing than the amount that might be given to onboard video, so changing the amount given to onboard video (if you could) wouldn't help.
In other threads, there is discussion of certain motherboard chipsets that can't remap memory, so a big chunk of 4GB is necessarily unusable (even if the dmidecode info lets the BIOS and/or Linux know that ram is present).
Some BIOSs have options for whether they set up the remapping. I think some have options for how they report memory to the OS. So if your chipset supports the remapping, there is some BIOS feature that needs to be enabled to make it work.
Regarding your direct question in this thread, the missing ram problem does not mean RAM was allocated by the BIOS or Linux to some purpose. (So you are asking the wrong question for the problem as well as the wrong question for the data posted).
Of course, you still could use some program to translate the hex number to decimal if you want to better follow the significant data from that quote, which is the location and size of the usable chunks of ram.
The key thing I see in that quoted data is the final number 100000000 hex, which represents exactly the 4GB boundary in the address space.
Part of the address space in the first 4GB must be used for things other than ram. So if you have 4GB of ram, part of that ram must use address space above the 4GB boundary. The data you quoted says there is nothing above the 4GB boundary, meaning either the motherboard can't support addresses above the 4GB boundary or the BIOS hasn't or can't turn on that support.
