new inxi feature: -m for system ram

[h2]

I have managed to get this down to one corner case, let me explain the problem, which luckily a person on IRC gave me data for last night, plus my own laptop which forms the other side of the problem:

There are two cases:

case 1:
reported capacity is 4gB: right
reported max module size 4gB: right
slots: 2
max module size == capacity==4gB: right
max module size x slots == 4gB x 2 == 8gB: wrong

so in this case, 4 gB is capacity listed, and max module size is 4 gB, so with a 2 slot system, my current estimate method yields a false capacity of 8 gB

case 1 is annoying because inxi is right with no further analysis, ie, the raw data is exactly right.

case 2: my laptop
reported capacity is 1 gB: wrong
reported max module size 1gB: right
max module size == capacity==1gB: wrong
slots 2, so: 2x max module == 1gBx2 == 2gB: right

However, in case 1 I have a further data source, DMI type 5 which confirms, ie, same as, capacity in dmi type 16, which is my primary data source for array data.

case 2 is annoying because by synthesizing the data for capacity, case 1 instantly fails and is wrong, even though the dmidecode data was exactly right.

So this corner case basically means this:

1: Where max module size x slots > capacity: inxi is wrong
2: where max module size x slots == capacity: inxi right

note that to fix bad data, inxi actually records the actual real max found size per array, then uses that if it shows that:
real found size x slots > listed capacity
and

real found size > max module size, use max real found size instead of listed max module size.

this only activates if there was a max module size found, that requires data from type 5 item, otherwise inxi does not try to guess since max module can't be known, ie, a 4 gB max size filled with 1gB sticks will not have a max size of 1gB, so there's no point in showing that guess.

All calculated numbers are followed by (est) so you know inxi found bad or conflicting data.

[ReinerS]

Hi,
I have installed it om my current two boxes. On my Laptop everything seems to be fine.

On my multimedia-box however I got this:

Code: [Select]

root@VdrLX:/home/tvrec# inxi -mxxx
Memory:    Array-1 capacity: 16 GB devices: 4 EC: None max module size: 4096 MB module voltage: 2.9 V
           Device-1: DIMM_A1 size: 2048 MB speed: 400 MHz type: Other
           bus width: 64 bits manufacturer: N/A part: N/A serial: N/A
           Device-2: DIMM_B1 size: 2048 MB speed: 400 MHz type: Other
           bus width: 64 bits manufacturer: N/A part: N/A serial: N/A
           Device-3: DIMM_A2 size: No Module Installed type: N/A bus width: 64 bits
           Device-4: DIMM_B2 size: No Module Installed type: N/A bus width: 64 bits The configuration of this box is:

Code: [Select]

root@VdrLX:/home/tvrec# inxi -F
System:    Host: VdrLX Kernel: 3.16-0.towo-siduction-amd64 x86_64 (64 bit) Desktop: Xfce 4.10.2
           Distro: siduction 13.1.0 Firestarter - xfce - (201305202241)
Machine:   Mobo: ASUSTeK model: M2N32-SLI DELUXE v: 1.XX serial: 123456789000
           Bios: Phoenix v: ASUS M2N32-SLI DELUXE 5002 date: 03/18/2010
CPU:       Dual core AMD Athlon II X2 250 (-MCP-) cache: 2048 KB
           Clock Speeds: 1: 1800 MHz 2: 800 MHz
Graphics:  Card: NVIDIA G84 [GeForce 8600 GT]
           Display Server: X.org 1.16.0 driver: nvidia tty size: 130x42 Advanced Data: N/A for root
Audio:     Card NVIDIA MCP55 High Definition Audio driver: snd_hda_intel
           Sound: Advanced Linux Sound Architecture v: k3.16-0.towo-siduction-amd64
Network:   Card-1: NVIDIA MCP55 Ethernet driver: forcedeth
           IF: eth0 state: up speed: 1000 Mbps duplex: full mac: 00:17:31:70:f1:ff
           Card-2: NVIDIA MCP55 Ethernet driver: forcedeth
           IF: eth1 state: down mac: 00:18:f3:78:a1:83
           Card-3: Techsan B2C2 FlexCopII DVB chip / Technisat SkyStar2 DVB card driver: b2c2_flexcop_pci
           IF: N/A state: N/A speed: N/A duplex: N/A mac: N/A
Drives:    HDD Total Size: 5001.0GB (85.2% used) ID-1: /dev/sda model: WDC_WD10EARS size: 1000.2GB
           ID-2: /dev/sdc model: WDC_WD20EARS size: 2000.4GB ID-3: /dev/sdb model: WDC_WD20EARX size: 2000.4GB
Partition: ID-1: / size: 50G used: 17G (37%) fs: ext4 dev: /dev/sda1
           ID-2: swap-1 size: 4.29GB used: 0.00GB (0%) fs: swap dev: /dev/sda2
RAID:      No RAID devices: /proc/mdstat, md_mod kernel module present
Sensors:   System Temperatures: cpu: 57.0C mobo: 43.0C
           Fan Speeds (in rpm): cpu: 1595 psu: 2549 sys-1: 2710 sys-2: 1834 sys-3: 1528 sys-4: 0
Info:      Processes: 252 Uptime: 1:07 Memory: 895.0/3958.6MB Client: Shell (bash) inxi: 2.1.94

regards

Reiner

[h2]

 Maximum memory: 8192MB
Slots: 4 (2 banks of 2)
*Not to exceed manufacturer supported memory.

http://www.crucial.com/usa/en/compatible-upgrade-for/ASUS/m2n32-sli-deluxe

http://www.newegg.com/Product/Product.aspx?Item=N82E16813131011

However you aren't using the newest inxi so I can't say if inxi is still wrong, make sure to update each and every time you run it for these tests since new fixes may have just been put live. 2.1.94 did not have any dynamic correction of the data, that came in 2.1.95 I think.

I'm checking data to see how many fringe cases can be handled without breaking correct data and already handled cases.

If you get data that is wrong, first, update inxi to latest, then if it's still wrong, do: inxi -xx@ 14 as root so I can see what is happening and add that data to my test data file.

In this case dmidecode data is important because this may be yet another fringe case, where:

max module size x slots < capacity, ie, capacity is wrong by being too high. This problem may not be fixable though, since there is no real way to check that it is wrong.

[melmarker]

This problem may not be fixable though, since there is no real way to check that it is wrong.

hmm -- from ReinerS datas --- Array-1 capacity: 16 GB --- Info: Memory: 895.0/3958.6MB
imho the magnitude of the two values ​​should be approximately equal

[h2]

ah, an excellent point, I had forgotten to look at better sources, I'll pass into the function that source of memory as well for checking, as a final or first fix.

Right now I've only been working on dmidecode data itself, so I forgot we have other sources available to us.

Howver, note that number is just what is installed, and I was actually just now working on assembling via dmidecode the actually installed amount of ram.

that patch version should be ready in an hour or so, but this type of logic is VERY hard because almost anythign you do at this point will break something that was working for someone else.

[ReinerS]

Ahh, I did miss the new update

I will try again tomorrow (Later in the day)

regards

Reiner

[melmarker]

new version upped: inxi_2.1.95.4.r2376_all.deb

[h2]

inxi 2.1.96 now released, this has modified many hacks to get right max capacity.

If your system shows wrong wrap data, then please run: inxi -xx@14
so I can get the debugger data, run as root.

Or, show output of: inxi -bmxxx

so I can check the system board specs myself, or post the specs, but I can't debug the system ram without the full debugger data set, run as root.

What I'm doing is taking the datasets that I have and running them as huge memory sets of data and then debugging them one by one until the stuff I have works as expected, but it's purely emprical, ie, Iam making specific systems work, which can break other systems that were working.

My conclusion is that it is impossible to get this data right untili the actual linux kernel can give the true ram data via /sys, otherwise it's subject to the same failures all data of this type is, totally random entries into various fields, mostly in the capacity/max module size, the other stuff seems to be mostly right as far as I can tell.

I'll do a few more patches on 2.1.96 but then I think I will call it good enough, otherwise this can take forever.

The more data sets I get, the better, however.

If the system has a wrong max capacity, without (est) or (check), then that's coming from the system itself not inxi, so make sure to give me the: inxi -xx@ 14 for that system, as root. In most cases this will be a capacity that is too high, not too low, the too low is easier to handle by tests, but too high is basically impossible to handle in most cases. Items that are like this: 32 gB (est OR check) however that are wrong can probably be fixed, or at least improved once I have the data.

I thought about 20 data sets would be enough, but it looks like about 50 may be needed to really get the stuff consistent, though with each release I believe a higher percentage of systems will be right, and those that are wrong, will be less wrong, though some will be way off.

[ghstryder]

@ghstryder - you really own a 64G array? interesting ...
maybe you should retest it with the new version, i see only 12G - same as in the info

Sorry, that was with the new version.
The capacity is 64G if all the risers are full - I have 12G installed, it picked it up correctly.

I thought that was correct, that it was supposed to show max/actual. Am I misinterpreting that?

[h2]

I believe I got the asus 16 gB reported, but 8gB actual, dataset, thanks for that.

In this case, inxi can't fix it or figure out the data is wrong, both max mod size and capacity are wrong in dmidecode, but inxi cannot logically deduce that fact since it could be 16 gB cap with max mod size 4 gB (what dmidecode lists), that's lgical, 4x 4 = 16, and no installed ram can be greater than that, so that's a corner case that can't be fixed, but thanks for the sample, it confirmed it couldn't be fixed. Blame the people who fill out the dmi data that dmidecode then inxi get, not dmidecode or inxi. ie, in this case, Asus.

My suspicion is that lazy mobo companies just use the same dmi data sets for different mobos, that's what it looks like to me, sometimes, other times it looks like they list max single slot capacity as max array capacity. Dirty data.

[h2]

2.1.97 is now out, yet another rewrite triggered by ever more arcane bad data in dmidecode output, anyone who wants to test and post success, failure, feel free.

If I get no more issue reports of clearly wrong data, 2.1.97 is going to be it, I'll wait til monday, then release 2.2.0, after that I won't have any more time to do this stuff at this rate.

2.1..96 was going to be the real prerrelease test, but now 2.1.97 is. Here's hoping this is it. Now I know why I put this off so long, dealing with randomly junk data is no fun.

[h2]

2.1.98 fixes an assumption I'd made about dmi type ordering, which I'd used to trigger array counters, that assumption was proved wrong. Basically you cannot count at all on dmidecode types being in any order at all it turns out. So I'm using a more reliable trigger in the output.

Also changed output to show module sizes in MB or GB or TB depending on how big they are, like capacity and max mod size do already.

Whoever is tracking this and supplying new datasets, thanks.

[melmarker]

uploaded ...

[h2]

Another siduction dataset, this one two slots, listed 8gB cap, 1 gB max cap, actual max mod, 2 gB, so actual max cap is 4 gB. In this case I'm leaving the higher number, but adding (check), which is the message gives you when it has least faith in the outcome of the tests and checks it has run, ie, it means, here's what I got, but honestly, I don't believe this has a high chance of being correct. the (est) means it's an estimate, and could well be right, or more right than dmidecode says anyway. Neither means its using the data from dmidecode without changing it, since it doesn't seem to contradict itself too badly.

This is in 2.1.98-1, just a patch fix. I'll save 99 for any real changes I do to either logic or output. Once I get no more datasets that suggest fine tuning of logic, I'll put this at 2.2.0, then of courses I'll get a bunch of new datasets right off, that show how output needs further tweaks, but one step  at a time.

[h2]

2.2.0 is now released, with some last fixes of datasets I got last night, in this case, where inxi sees that the listed total capacity just seems to be too big for max module size found x slots, in this case, I made it conservative so it should usually not trip this case.

thanks for all the datasets, sadly capacity can NEVER be fully trusted, but the information on each Device, slot, is basically right, and reliable, so inxi says you have an 8 gB stick installed in slot A1, or whatever, then you do.

The max module size generally will not be too low, although it can be, and if it says (est) after, it means that what the system listed was actually less than the max module actually found, so it corrects it to the max actually found.

this logic is convoluted and very hard to do, dealing with basically junk data is always very hard, sadly.

But I can say that thanks to all the datasets, where the dmi data is wrong, inxi will be more right more of the time than dmidecode, lol, but that's all I can say.