This 2+2GB RAM however shows up only as 3.3GB. Wow. Only 0.4GB increase. So I started to look around for the WHY?!?
Probably useful links:
- There is actually a post about TC4400 here: http://forum.notebookreview.com/threads/tc4400-only-recognizes-3447mb-in-windows.225619/ It concludes that it was Windows' fault, and it needed an upgrade.
- More useful info for linux: http://superuser.com/questions/453201/only-3-2gb-of-4gb-ram-detected-on-64-bit-debian
- Here they suggest to reinstall the 64-bit system: http://askubuntu.com/questions/32272/why-does-ubuntu-only-show-3gb-of-ram
Another important note is that the BIOS is already the latest (Version: 68YHV Ver. F.0C; Release Date: 07/09/2008); It does not have an option for Memory Hole Remapping; The processor is Intel Pentium M Core2 CPU T5600 @ 1.83GHz and it does have a PAE (Physical address extension) flag (according to dmidecode).
I definitely have a 64-bit operating system, so the limitation cannot be due to a 32-bit OS.
~$ uname -a
Linux 3.13.0-74-generic #118~precise1-Ubuntu SMP Fri Dec 18 10:38:55 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
The maximum capacity is 4GB:
~$ sudo dmidecode --type 16
# dmidecode 2.11
SMBIOS 2.4 present.
Handle 0x000A, DMI type 16, 15 bytes
Physical Memory Array
Location: System Board Or Motherboard
Use: System Memory
Error Correction Type: None
Maximum Capacity: 4 GB
Error Information Handle: No Error
Number Of Devices: 2
I do have 4GB installed:
~$ sudo dmidecode --type 19
# dmidecode 2.11
SMBIOS 2.4 present.
Handle 0x000D, DMI type 19, 15 bytes
Memory Array Mapped Address
Starting Address: 0x00000000000
Ending Address: 0x000FFFFFFFF
Range Size: 4 GB
Physical Array Handle: 0x000A
Partition Width: 2
However, there is only ~3.3GB available:
~$ cat /proc/meminfo | grep "MemTotal"
MemTotal: 3460508 kB
Free shows the same:
~$ free -m
total used free shared buffers cached
Mem: 3379 2673 705 0 346 1109
-/+ buffers/cache: 1217 2161
Swap: 4881 0 4881
DMSG log has more detailed info:
~$ cat /var/log/dmesg | grep "Memory"
[ 0.000000] Memory: 3439500K/3530168K available (7639K kernel code, 1140K rwdata, 3512K rodata, 1360K init, 1448K bss, 90668K reserved)
[ 15.528520] [drm] Memory usable by graphics device = 256M
There is something else interesting in /var/log/dmesg (opened it with gedit)
[ 0.000000] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
[ 0.000000] original variable MTRRs
[ 0.000000] reg 0, base: 0GB, range: 2GB, type WB
[ 0.000000] reg 1, base: 2GB, range: 1GB, type WB
[ 0.000000] reg 2, base: 3GB, range: 256MB, type WB
[ 0.000000] reg 3, base: 3328MB, range: 128MB, type WB
[ 0.000000] reg 4, base: 64888MB, range: 8MB, type UC
[ 0.000000] reg 5, base: 4175488KB, range: 128KB, type UC
[ 0.000000] total RAM covered: 3456M
[ 0.000000] Found optimal setting for mtrr clean up
[ 0.000000] gran_size: 64K chunk_size: 1G num_reg: 3 lose cover RAM: 0G
[ 0.000000] New variable MTRRs
[ 0.000000] reg 0, base: 0GB, range: 4GB, type WB
[ 0.000000] reg 1, base: 3456MB, range: 128MB, type UC
[ 0.000000] reg 2, base: 3584MB, range: 512MB, type UC
The same information can be found here:
~$ cat /proc/mtrr
reg00: base=0x000000000 ( 0MB), size= 4096MB, count=1: write-back
reg01: base=0x0d8000000 ( 3456MB), size= 128MB, count=1: uncachable
reg02: base=0x0e0000000 ( 3584MB), size= 512MB, count=1: uncachable
And then, 'smem' shows that there is ~700K reserved for the firmware/hardware... but WHY? (the "Used" amount sums up to 4194304 below)
~$ smem -R 4G -w
Area Used Cache Noncache
firmware/hardware 733796 0 733796
kernel image 0 0 0
kernel dynamic memory 1827468 1718276 109192
userspace memory 1180160 207332 972828
free memory 452880 452880 0
In comparison, when 3GB memory is in the machine, the numbers are like this:
~$ smem -R 3G -w
Area Used Cache Noncache
firmware/hardware 72292 0 72292
kernel image 0 0 0
kernel dynamic memory 2324328 2228148 96180
userspace memory 648196 164924 483272
free memory 100912 100912 0
~$ free -m
total used free shared buffers cached
Mem: 3001 2919 81 0 26 2164
-/+ buffers/cache: 727 2273
Swap: 4881 0 4881
[ 0.000000] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
[ 0.000000] original variable MTRRs
[ 0.000000] reg 0, base: 0GB, range: 2GB, type WB
[ 0.000000] reg 1, base: 2GB, range: 1GB, type WB
[ 0.000000] reg 2, base: 64504MB, range: 8MB, type UC
[ 0.000000] reg 3, base: 4175488KB, range: 128KB, type UC
[ 0.000000] total RAM covered: 3072M
[ 0.000000] Found optimal setting for mtrr clean up
[ 0.000000] gran_size: 64K chunk_size: 64K num_reg: 2 lose cover RAM: 0G
[ 0.000000] New variable MTRRs
[ 0.000000] reg 0, base: 0GB, range: 2GB, type WB
[ 0.000000] reg 1, base: 2GB, range: 1GB, type WB
I also tried running Ubuntu from an USB pendrive, but it shows the same amount of memory. And I tried running Windows 7, and this also shows only 3,3GB.
According to this article (http://duartes.org/gustavo/blog/post/getting-physical-with-memory/), "some of the physical memory range in an Intel computer is mapped to devices like hard drives and network cards instead of actual RAM memory. This allows drivers to communicate with their devices by writing to and reading from memory. The kernel marks these memory regions as uncacheable in the page tables." Then in the article about the Memory Map (http://duartes.org/gustavo/blog/post/motherboard-chipsets-memory-map/) it is said that "this mapping of memory addresses away from RAM modules causes the classic hole in PC memory between 640KB and 1MB. A bigger hole arises when memory addresses are reserved for video cards and PCI devices." "The diagram below shows a typical memory map for the first 4 gigs of physical memory addresses in an Intel PC:"
Then it is said that "the CPU mode determines how much physical memory can be accessed. For example, if the CPU is running in 32-bit mode, then it is only capable of physically addressing 4 GB (well, there is an exception called physical address extension, but ignore it for now). Since the top 1 GB or so of physical addresses are mapped to motherboard devices the CPU can effectively use only ~3 GB of RAM. [...] On the other hand, a CPU running in 64-bit mode can physically access 64GB (few chipsets support that much RAM though). In 64-bit mode it is possible to use physical addresses above the total RAM in the system to access the RAM regions that correspond to physical addresses stolen by motherboard devices. This is called reclaiming memory and it’s done with help from the chipset."
My conclusion is that there is no way to access all the 4GB of memory as RAM.
Nincsenek megjegyzések:
Megjegyzés küldése