1 |
sean posted on Tue, 01 Dec 2009 15:54:36 -0500 as excerpted: |
2 |
|
3 |
> If I am reading this correctly my system here is not seeing all 8GB of |
4 |
> memory, though the system bios does. |
5 |
> |
6 |
> cat /proc/meminfo |
7 |
> |
8 |
> MemTotal: 5581372 kB |
9 |
> |
10 |
> MemFree: 4051424 kB |
11 |
> |
12 |
> Buffers: 240436 kB |
13 |
> |
14 |
> Cached: 645496 kB |
15 |
> |
16 |
> SwapCached: 0 kB |
17 |
> |
18 |
> |
19 |
> |
20 |
> Any reason where to check why all the memory? |
21 |
|
22 |
No time to detail ATM, but at least some of it may have to do with the |
23 |
legacy 32-bit PCI device I/O area at the top of 32-bit memory -- that is, |
24 |
at the top of the 4 gig address space. That takes a chunk of memory |
25 |
address space, typically a half gig tho it may be a gig or so (but you |
26 |
seem to have even more missing than that??) for device io use. If your |
27 |
bios and the kernel aren't setup properly to leave a hole in the physical |
28 |
memory address space there, the real memory addresses behind the io |
29 |
addresses will be masked and that memory not available. |
30 |
|
31 |
Some BIOSs actually count more memory than one has when this hole is |
32 |
active, counting "thru" the hole, but displacing the real physical memory |
33 |
up above 4 gig, so 8 gig may appear as 9 or 10 gig. Others do that, but |
34 |
then subtract the memory hole, so the total returns to normal. Others |
35 |
may simply skip that area when detecting memory and not show it at all, |
36 |
so the memory count appears normal, even tho the hole is there. |
37 |
|
38 |
But if you don't have that hole configured properly, you WILL lose access |
39 |
to the real memory behind it. |
40 |
|
41 |
Gotta run... |
42 |
|
43 |
|
44 |
|
45 |
|
46 |
-- |
47 |
Duncan - List replies preferred. No HTML msgs. |
48 |
"Every nonfree program has a lord, a master -- |
49 |
and if you use the program, he is your master." Richard Stallman |