New version, tarball, man page. Maintainers, this is the official release of -m feature.

I have collected enough datasamples to allow for reasonably fine grained corrections, estimates,
warnings about unreliable capacity now, and have fixed all major failures. 

Also, because this stuff is filled out by people somewhere, or not, some fields often are just
empty, or contain the default values, ie, they are worthless. inxi shows N/A for those situations,
it means there is really no actual data to show you.

This feature, sadly, well never be totally reliable, because dmi data is frankly junk, especially
dmi type 5 and 16, which is what is supposed to tell you total capacity of memory array, and the
maximum module size (type 5). However, this data is totally random, often it is right, sometimes
it is wrong. Sometimes type 5 is right and type 16 is wrong, sometimes the other way. And since
type 5 is only present in some systems, it's not reliable anyway.

What is reliable and always right is the actually installed memory per device, ie, sticks. I have
not seen any errors in that, so that seems to be actually coming from the system itself. type 5 / 16
sadly are clearly entered in manually by some poorly paid engineers out there in the world, and are
often total fictions, either far too small, or far too big, or whatever.

inxi will attempt to correct all clear logic errors, and whenever it changes the listed data from 
type 5/16, it notes either (est) or (check). (est) means it is a good guess, one I am comfortable making,
(check) means it is either an unreliable guess, or that what the system is reporting is so unlikely that
even though inxi is showing it, it doubts it could actually be true, or at least, it thinks you
should check this yourself. 

-m has 3 extra data options, -x prints the part number, if found, and the max module size, if type 5
is present. inxi does NOT attempt to guess at max module size based on what is installed, it only will
correct a listed max module size if installed modules are > than listed max size. Usually part numbers,
if present, are all you need to order a new stick.

-xx shows serial number, manufacturer (often empty, or just random alphanumeric identifiers, but sometimes
they list the actual company name, which is helpful. It also shows, if type 5 data is present, single/double
bank.

-xxx as usual shows largely useless data that may be of interest to soemone, like if ram type is synchronous, 
memory bus width data, and module voltage (type 5 data).

This feature will never be reliable I am sad to say because the source data itself is random and much
has been filled out, or not filled out, by engineering drones somewhere out there in the underpaid
world. The ranges of errors are so wide that inxi just has to check what is possible, reasonable, unlikely,
etc, to generate its numbers. In other words, this is NOT just parsing dmidecode output, that is the raw
material only, sad to say.

So this is it, for better or worse. All bug / issue reports with this MUST come with a full:
inxi -xx@14 
hardware data upload, run as root. 

Also, much to my annoyance, this feature requires root, since /dev/mem needs root to be read, and I assume
the dmi table, so that is a departure from normal inxi standards, as is the low quality input, and thus,
output, data, though I can guarantee that what inxi tells you is in most cases on average more accurate than
what dmidecode tells you, since dmidecode simply prints out what it finds in the dmi table, and nothing else,
in whatever order it finds it, from what I can see, ie, you also cannot trust the order of dmidecode output.

I had been hoping that /sys would start to contain memory data like it does mobo/system data, but it never
happened so I finally decided to just do the ram thing, require dmidecode, require root/sudo, and that's
that.

There will be issue reports, you can help them by looking up the mobo stats/specs yourself and listing them
in the issue, so I don't have to do it. I use the tool at crucial.com which is very accurate and also very 
complete in terms of all possible hardware out there. 

I would trust that tool before trusting the companies that have the least reliable data, like ASUS.

Much thanks to everyone who is contributing datasets, and the distros, particularly siduction, that really 
were very helpful in this process, by finding more and more failure cases that helped me start to tighten
the logic, and make it more and more robust. Special thanks to Mikaela, of #smxi irc.oftc.net, who came up
with two systems that both required a full redo of the logic, and thus who helped a lot in this process.
This commit is contained in:
inxi-svn 2014-08-18 22:26:25 +00:00
parent 33966eb988
commit f7117db9ac
2 changed files with 99 additions and 6 deletions

26
inxi
View file

@ -1,9 +1,9 @@
#!/usr/bin/env bash
########################################################################
#### Script Name: inxi
#### Version: 2.1.98
#### Date: 2014-08-17
#### Patch Number: 01
#### Version: 2.2.00
#### Date: 2014-08-18
#### Patch Number: 00
########################################################################
#### SPECIAL THANKS
########################################################################
@ -4901,7 +4901,7 @@ get_dmidecode_data()
# strip out all the stuff we don't want to see in the results. We want the error data in
# stdout for error handling
if [[ $b_debugger == 'true' && $HOSTNAME == 'yawn' ]];then
dmiData="$( cat ~/bin/scripts/inxi/data/dmidecode/dmidecode-memory-variants-2.txt )"
dmiData="$( cat ~/bin/scripts/inxi/svn/misc/data/dmidecode/dmidecode-memory-variants-2.txt )"
else
dmiData="$( $dmidecodePath 2>&1 )"
fi
@ -8216,6 +8216,9 @@ get_ram_data()
/^Handle .* DMI[[:space:]]+type[[:space:]]+6(,|[[:space:]])/ {
while ( getline && !/^$/ ) {
if ( $1 == "Installed Size" ) {
# get module size
aMemory[k,j,18]=calculateSize($2,0)
# get data after module size
sub(/ Connection/,"",$2)
sub(/^[0-9]+[[:space:]]*[MGTP]B[[:space:]]*/,"",$2)
aMemory[k,j,16]=$2
@ -8534,9 +8537,20 @@ get_ram_data()
aArrayData[m,"maxModuleSize"] = 0
# print "yes"
}
if ( bDebugger1 == "true" ){
print "5: dms: " aArrayData[m,"derivedModuleSize"] " :dc: " aArrayData[m,"deviceCount16"] " :wmc: " workingMaxCap
}
## prep for output ##
if (aArrayData[m,"maxModuleSize"] == 0 ){
aArrayData[m,"maxModuleSize"]=""
# ie: 2x4gB
if ( estCap == "" && int(aArrayData[m,"derivedModuleSize"]) > 0 &&
workingMaxCap > ( int(aArrayData[m,"derivedModuleSize"]) * int(aArrayData[m,"deviceCount16"]) * 4 ) ) {
estCap=" (check)"
if ( bDebugger1 == "true" ){
print "G"
}
}
}
else {
# case where listed max cap is too big for actual slots x max cap, eg:
@ -8544,8 +8558,8 @@ get_ram_data()
if ( estCap == "" && aArrayData[m,"maxModuleSize"] > 0 ) {
if ( int(workingMaxCap) > int(aArrayData[m,"maxModuleSize"]) * aArrayData[m,"deviceCount16"] ) {
estCap=" (check)"
if ( deBugger1 == "true" ){
print "G"
if ( bDebugger1 == "true" ){
print "H"
}
}
}

View file

@ -1,3 +1,82 @@
=====================================================================================
Version: 2.2.00
Patch Version: 00
Script Date: 2014-08-18
-----------------------------------
Changes:
-----------------------------------
New version, tarball, man page. Maintainers, this is the official release of -m feature.
I have collected enough datasamples to allow for reasonably fine grained corrections, estimates,
warnings about unreliable capacity now, and have fixed all major failures.
Also, because this stuff is filled out by people somewhere, or not, some fields often are just
empty, or contain the default values, ie, they are worthless. inxi shows N/A for those situations,
it means there is really no actual data to show you.
This feature, sadly, well never be totally reliable, because dmi data is frankly junk, especially
dmi type 5 and 16, which is what is supposed to tell you total capacity of memory array, and the
maximum module size (type 5). However, this data is totally random, often it is right, sometimes
it is wrong. Sometimes type 5 is right and type 16 is wrong, sometimes the other way. And since
type 5 is only present in some systems, it's not reliable anyway.
What is reliable and always right is the actually installed memory per device, ie, sticks. I have
not seen any errors in that, so that seems to be actually coming from the system itself. type 5 / 16
sadly are clearly entered in manually by some poorly paid engineers out there in the world, and are
often total fictions, either far too small, or far too big, or whatever.
inxi will attempt to correct all clear logic errors, and whenever it changes the listed data from
type 5/16, it notes either (est) or (check). (est) means it is a good guess, one I am comfortable making,
(check) means it is either an unreliable guess, or that what the system is reporting is so unlikely that
even though inxi is showing it, it doubts it could actually be true, or at least, it thinks you
should check this yourself.
-m has 3 extra data options, -x prints the part number, if found, and the max module size, if type 5
is present. inxi does NOT attempt to guess at max module size based on what is installed, it only will
correct a listed max module size if installed modules are > than listed max size. Usually part numbers,
if present, are all you need to order a new stick.
-xx shows serial number, manufacturer (often empty, or just random alphanumeric identifiers, but sometimes
they list the actual company name, which is helpful. It also shows, if type 5 data is present, single/double
bank.
-xxx as usual shows largely useless data that may be of interest to soemone, like if ram type is synchronous,
memory bus width data, and module voltage (type 5 data).
This feature will never be reliable I am sad to say because the source data itself is random and much
has been filled out, or not filled out, by engineering drones somewhere out there in the underpaid
world. The ranges of errors are so wide that inxi just has to check what is possible, reasonable, unlikely,
etc, to generate its numbers. In other words, this is NOT just parsing dmidecode output, that is the raw
material only, sad to say.
So this is it, for better or worse. All bug / issue reports with this MUST come with a full:
inxi -xx@14
hardware data upload, run as root.
Also, much to my annoyance, this feature requires root, since /dev/mem needs root to be read, and I assume
the dmi table, so that is a departure from normal inxi standards, as is the low quality input, and thus,
output, data, though I can guarantee that what inxi tells you is in most cases on average more accurate than
what dmidecode tells you, since dmidecode simply prints out what it finds in the dmi table, and nothing else,
in whatever order it finds it, from what I can see, ie, you also cannot trust the order of dmidecode output.
I had been hoping that /sys would start to contain memory data like it does mobo/system data, but it never
happened so I finally decided to just do the ram thing, require dmidecode, require root/sudo, and that's
that.
There will be issue reports, you can help them by looking up the mobo stats/specs yourself and listing them
in the issue, so I don't have to do it. I use the tool at crucial.com which is very accurate and also very
complete in terms of all possible hardware out there.
I would trust that tool before trusting the companies that have the least reliable data, like ASUS.
Much thanks to everyone who is contributing datasets, and the distros, particularly siduction, that really
were very helpful in this process, by finding more and more failure cases that helped me start to tighten
the logic, and make it more and more robust. Special thanks to Mikaela, of #smxi irc.oftc.net, who came up
with two systems that both required a full redo of the logic, and thus who helped a lot in this process.
-----------------------------------
-- Harald Hope - Mon, 18 Aug 2014 15:07:36 -0700
=====================================================================================
Version: 2.1.98
Patch Version: 01