Re: [dmidecode] Determining Current and Maximum RAM

[Jean Delvare]

Hi Anthony, 

On Wed, 19 Sep 2007 13:43:48 +0100, Anthony Wright wrote:
> I'm trying to use dmidecode to work out what the current amount of ram 
> available is and what is the maximum amount the motherboard will support 
> for any given PC. I've tested on a few PCs and I seem to be doing ok, 
> but I'm not sure if this will work on all systems, and I'm a little 
> confused by what appears to be two types of recording memory.
>
> There appears to be Physical Memory Arrays (type 16) and Memory Devices 
> (type 17) which is what I'm using at the moment. However there also 
> seems to be Memory Controllers (type 5) and Memory Modules (type 6) 
> which I ignore. Of the limited number of motherboards I've tested most 
> only report type 16 & 17 handles, but one reports the same memory under 
> handles of both sets of types, and the two sets disagree - under the 
> Physical Memory Arrays it reports a maximum capacity of 256 MB, while 
> under Memory Controller it reports a maximum capacity of 512 MB.
> 
> Could anybody explain the difference between Memory Controllers and 
> Physical Memory Arrays as seen by dmidecode, how I should interpret them 
> and how reliable the numbers are likely to be?

Types 5 and 6 were used up to SMBIOS 2.0. In SMBIOS 2.1, types 16 and
17 were added, and types 5 and 6 were declared obsolete. Newer systems
should implement types 16 and 17, but some might still additionally
implement types 5 and 6 for compatibility purposes.

I'm now taking a look at the various sample DMI tables I have at hand
that implement both sets, and indeed many of them have contradicting
information. In particular, a number of these systems store the maximum
size per memory module, instead of the maximum total memory size, in
type 16.

My overall impression is that, when both new types 5 and 6 and types 16
and 17 are present, types 5 and 6 are more likely to be correct. But I
wouldn't recommend relying on such a heuristic, as hopefully types 16
and 17 should become more reliable over time, while types 5 and 6 might
become less reliable.

Such bugs in the DMI table should be reported to the system
manufacturers, after checking that there's no BIOS updates already
available fixing them.

> Alternatively could you tell me whether there's a better way of getting 
> this information out of the motherboard? Ideally I'd like a little 
> program that analyses the motherboard, works out the specification of 
> the memory that's already there and tells me the specification of the 
> memory it will support e.g. 2 x 256MB modules PC-133 non-ecc.

For the maximum supported memory, I know of no other way, sorry. For the
installed memory, under Linux, you can use the "eeprom" kernel driver
in conjunction with whatever SMBus master driver is suitable for your
system (i2c-i801, i2c-viapro, i2c-nforce2...) then run the
decode-dimms.pl script that comes with lm-sensors.

Using the DMI data is definitely the easiest way to achieve what you
want to do, but of course it will only work on systems those DMI table
holds reliable information.

-- 
Jean Delvare
http://khali.linux-fr.org/wishlist.html