Siduction Forum

Siduction Forum => Scripting & Kernelhacking => Scripting & Kernelhacking (EN) => Topic started by: h2 on 2014/08/13, 22:00:12

Title: new inxi feature: -m for system ram
Post by: h2 on 2014/08/13, 22:00:12
The latest version of inxi, 2.1.93 is now ready for testing. This features the -m option, for ram report. dmidecode is required, but inxi has improved error handling for dmidecode issues so any failures should be obvious now.

This version is close to the 2.2.0 final release but I thought I'd post for bugs/issues before switching to the 2.2 final.

Sample outputs:
Code: [Select]
inxi -mxxx
Memory:  Array-1 capacity: 16 GB devices: 2 EC: No
           Device-1: ChannelA-DIMM0 size: 4096 MB speed: 1067 MHz type: DDR3 (Synchronous)
           bus width: 64 bits manufacturer: ELPIDA part: EBJ41UF8BCS0-DJ-F serial: 522C70BA
           Device-2: ChannelA-DIMM1 size: No Module Installed type: N/A
           Device-3: ChannelB-DIMM0 size: 2048 MB speed: 1067 MHz type: DDR3 (Synchronous)
           bus width: 64 bits manufacturer: ELPIDA part: EBJ20UF8BCS0-DJ-F serial: 55922ADE
           Device-4: ChannelB-DIMM1 size: No Module Installed type: N/A

Memory:  Array-1 capacity: 3 GB devices: 2 EC: No
           Device-1: SO DIMM 0 size: 256 MB speed: N/A type: DDR (Synchronous)
           bus width: 64 bits manufacturer: N/A part: N/A serial: N/A
           Device-2: SO DIMM 1 size: 1024 MB speed: N/A type: DDR (Synchronous)
           bus width: 64 bits manufacturer: N/A part: N/A serial: N/A


Memory:  Array-1 capacity: 8 GB devices: 4 EC: Single-bit ECC
           Device-1: DIMM0 size: 2048 MB speed: 1333 MHz type: DDR3 (Synchronous)
           bus width: 64 bits manufacturer: Samsung part: M378B5673FH0-CH9 serial: 65F1C07D
           Device-2: DIMM1 size: 2048 MB speed: 1333 MHz type: DDR3 (Synchronous)
           bus width: 64 bits manufacturer: Toshiba part: 9905471-001.A01LF serial: 2A1BA548
           Device-3: DIMM2 size: 1024 MB speed: 1333 MHz type: DDR3 (Synchronous)
           bus width: 64 bits manufacturer: Samsung part: M378B2873FHS-CH9 serial: 76046756
           Device-4: DIMM3 size: 2048 MB speed: 1333 MHz type: DDR3 (Synchronous)
           bus width: 64 bits manufacturer: Toshiba part: 9905471-001.A01LF serial: 2C1BA548

-x shows part number, -xx shows serial number/manufactorer, and -xxx shows largely useless info like memory bus width and extra data for type.

This seems to be to about all the useful data you can grab from dmidecode, the array is Type 16, and the device is type 17. I looked into useing other types but they are very inconsistent and often not present so I stuck with 16 and 17. type 5 has a lot more information on the controller, for example, but you can't count on it being there. Type 6 gives current speed in nano seconds, as well as notes if double banked connection, maybe I will do more searches for that now that I think about it, and use that data if present, though it's good enough for now.
Title: Re: new inxi feature: -m for system ram
Post by: ReinerS on 2014/08/13, 22:53:40
Thank you h2 for the support and improvements! :)

I will test it asap and report if there are any problems.

regards

Reiner

Edit: hmm seems not yet available for me. Will try later again
Title: Re: new inxi feature: -m for system ram
Post by: h2 on 2014/08/13, 23:18:11
I couldn't resist, now -x shows maximum module size, if the system has that data, most do not, and -xxx shows module voltage, again, most systems will probably not have it, some do, like my test system.

this is the svn inxi, the latest, not the repo, you have to chnage /etc/inxi.conf and set B_ALLOW_UPDATES=true to use -U for testing/debugging of new features.
Title: Re: new inxi feature: -m for system ram
Post by: melmarker on 2014/08/13, 23:19:14
@h2 - i uploaded the .94 instead of the totaly outdated .93 :P

hmm - dunno if i misinterpret the memory output, but it seems to be wrong
i have 4x8G - thats right, but i don't understand the first mem line

inxi -S -I -mxxxx                                                                                                                                             
System:    Host: razorbox Kernel: 3.16-0.towo-siduction-amd64 x86_64 (64 bit gcc: 4.9.1) Desktop: N/A dm: lightdm
           Distro: siduction 13.1.0 Firestarter - rqt - (201306021344)                                                                                                                                                   
Memory:    Array-1 capacity: 2 GB devices: 4 EC: No max module size: 1024 MB module voltage: 3.3 V                                                                                                                       
           Device-1: A0 size: 8192 MB speed: 1333 MHz type: N/A                                                                                                                                                         
           bus width: 64 bits manufacturer: N/A part: N/A serial: N/A                                                                                                                                                   
           Device-2: A1 size: 8192 MB speed: 1333 MHz type: N/A                                                                                                                                                         
           bus width: 64 bits manufacturer: N/A part: N/A serial: N/A                                                                                                                                                   
           Device-3: A2 size: 8192 MB speed: 1333 MHz type: N/A                                                                                                                                                         
           bus width: 64 bits manufacturer: N/A part: N/A serial: N/A                                                                                                                                                   
           Device-4: A3 size: 8192 MB speed: 1333 MHz type: N/A                                                                                                                                                         
           bus width: 64 bits manufacturer: N/A part: N/A serial: N/A                                                                                                                                                   
Info:      Processes: 240 Uptime: 1 day Memory: 2108.0/32180.1MB                                                                                                                                                         
           Init: systemd v: 210 runlevel: 5 default: 5 Gcc sys: 4.9.1 alt: 4.2/4.3/4.4/4.5/4.6/4.7/4.8                                                                                                                   
           Client: Shell (bash 4.3.221 running in bash) inxi: 2.1.94   
Title: Re: new inxi feature: -m for system ram
Post by: h2 on 2014/08/13, 23:39:03
it's probably dmidecode being wrong.

If you run as root: dmidecode > dmidata.txt then attach that file, or run:

sudo inxi -xx@ 14
to upload it automatically I can tell you, but it's probably dmidecode being wrong, I have a laptop where it's wrong too, it says capacity of array is 1 gB, but there are 2 1 gB memory sticks installed.

Data from dmi depends on the vendors doing it right, and they very often do not. But your actual data can tell me that.

It uses DMI type 16 for the array, and DMI type 17 for the device data, and if present, DMI type 5 for the extra array data, like max module size and voltage.

If that data is wrong in dmiedecode, it will be wrong in inxi, that's the reason I don't like using stuff like dmidecode, I was hoping ram data would be available in /sys but it never appeared so I had to give up and rely on dmidecode.
Title: Re: new inxi feature: -m for system ram
Post by: h2 on 2014/08/13, 23:50:29
I'll get some more data samples, but I may have to get rid of the -x/-xx items for the array, I have new sample where they do not match, and type 5 appears to be wrong.

This is always a very empircal process since nobody who makes hardware follows rules consistently enough to let us simply know when things are usable or not.
Title: Re: new inxi feature: -m for system ram
Post by: melmarker on 2014/08/13, 23:55:25
file: inxi-razorbox-20140813-235447-all-root.tar.gz
/incoming
SUCCESS: file uploaded
Title: Re: new inxi feature: -m for system ram
Post by: h2 on 2014/08/14, 00:06:37
Ok, I have more datasets, they show clearly that: type 5 can be wrong, and sometimes is.

They also show that type 16 can be, and sometimes is, wrong.

The only things that always seem to be right are type 17, the individual memory device item.

the data in Array-X can't be synthesized reliably from the type 17 data unfortunately, and it's often right.

So maybe the best thing to do is to somehow indicate not to trust the data in Array-X line. I believe the number of devices is almost always right, ie, how many slots etc exist, so probbly the voltage is right usually, so it's just the capacity/max module size that are in question. Hmmm, I can add up the installed memory as inxi calculates the data, and if it's greater than the listed capacity, / and or if the individual module sizes are greater than the listed max size, dump that and show an error message, maybe? like: 32 gB (est.)

While annoying, this is the exact type of issue I was hoping to find.
Title: Re: new inxi feature: -m for system ram
Post by: h2 on 2014/08/14, 06:13:41
inxi 2.1.95 solves most of these failures with capacity/max size.

Doing this required a big rewrite of the core logic, now it does actual comparisons of the capacity data with number of devices times largest detected device size, plus some other logic.

Code: [Select]
# corrects bad max size reading, where max size is > than capacity, by removing max size
Memory:    Array-1 capacity: 2 GB devices: 2 EC: None module voltage: 2.9 V
           Device-1: DIMM 1 size: 1024 MB speed: 667 MHz type: DDR2 (Synchronous)
           bus width: 64 bits manufacturer: N/A part: N/A serial: N/A
           Device-2: DIMM 2 size: No Module Installed type: DDR2 (Synchronous)

# corrects wrong capacity and wrong max size, using max actual module size detected
# to generate a synthetic capacity.
Memory:    Array-1 capacity: 32 GB (est) devices: 4 EC: None
           max module size: 8192 MB (est.) module voltage: 3.3 V
           Device-1: A0 size: 8192 MB speed: 1333 MHz type: N/A
           bus width: 64 bits manufacturer: N/A part: N/A serial: N/A
           Device-2: A1 size: 8192 MB speed: 1333 MHz type: N/A
           bus width: 64 bits manufacturer: N/A part: N/A serial: N/A
           Device-3: A2 size: 8192 MB speed: 1333 MHz type: N/A
           bus width: 64 bits manufacturer: N/A part: N/A serial: N/A
           Device-4: A3 size: 8192 MB speed: 1333 MHz type: N/A
           bus width: 64 bits manufacturer: N/A part: N/A serial: N/A

# dev system, no corrections since it was right
Memory:    Array-1 capacity: 8 GB devices: 4 EC: None max module size: 2048 MB module voltage: 3.3 V
           Device-1: DIMM0 size: 2048 MB speed: 400 MHz type: DDR2 (Synchronous)
           bus width: 64 bits (total: 72 bits) manufacturer: N/A part: N/A serial: N/A
           Device-2: DIMM1 size: 2048 MB speed: 400 MHz type: DDR2 (Synchronous)
           bus width: 64 bits (total: 72 bits) manufacturer: N/A part: N/A serial: N/A
           Device-3: DIMM2 size: 1024 MB speed: 400 MHz type: DDR2 (Synchronous)
           bus width: 64 bits (total: 72 bits) manufacturer: N/A part: N/A serial: N/A
           Device-4: DIMM3 size: 1024 MB speed: 400 MHz type: DDR2 (Synchronous)
           bus width: 64 bits (total: 72 bits) manufacturer: N/A part: N/A serial: N/A

when inxi now tries to generate its guesses, either it simply removes the item, or it says (est.) after it to let you know it's a synthesized number, deduced from various dmidecode values.

Also, keep in mind, if you use -m then certain other features inxi will not work since it's root, like most desktop id, and advanced graphics card data.
Title: Re: new inxi feature: -m for system ram
Post by: ghstryder on 2014/08/14, 07:36:22
Thanks, h2
It appears to be working fine here.
Code: [Select]
# inxi -S -I -mxxx
System:    Host: P690 Kernel: 3.16-0.towo-siduction-amd64 x86_64 (64 bit gcc: 4.9.1)
           Desktop: KDE 4.13.3 (Qt 4.8.6) info: plasma-desktop dm: lightdm                                           
           Distro: siduction 12.1 Desperado - kde - (201205212202)                                                   
Memory:    Array-1 capacity: 64 GB devices: 16 EC: Single-bit ECC                                                   
           Device-1: RISER 1 DIMM 1 size: 1024 MB speed: 667 MHz type: DDR2 FB-DIMM (Synchronous)                   
           bus width: 64 bits (total: 72 bits)                                                                       
           manufacturer: 80CE808980CE part: M395T2953EZ4-CE65 serial: 5116F501                                       
           Device-2: RISER 2 DIMM 1 size: 1024 MB speed: 667 MHz type: DDR2 FB-DIMM (Synchronous)                   
           bus width: 64 bits (total: 72 bits)                                                                       
           manufacturer: 80CE808980CE part: M395T2953CZ4-CE65 serial: 0327A4E8                                       
           Device-3: RISER 3 DIMM 1 size: 1024 MB speed: 667 MHz type: DDR2 FB-DIMM (Synchronous)                   
           bus width: 64 bits (total: 72 bits)                                                                       
           manufacturer: 80CE808980CE part: M395T2953CZ4-CE65 serial: 0327A5F9                                       
           Device-4: RISER 4 DIMM 1 size: 1024 MB speed: 667 MHz type: DDR2 FB-DIMM (Synchronous)                   
           bus width: 64 bits (total: 72 bits)                                                                       
           manufacturer: 80CE808980CE part: M395T2953CZ4-CE65 serial: 0327A458
           Device-5: RISER 1 DIMM 2 size: 2048 MB speed: 667 MHz type: DDR2 FB-DIMM (Synchronous)
           bus width: 64 bits (total: 72 bits)
           manufacturer: 80CE7FB380CE part: M395T5750EZ4-CE66 serial: 10115059
           Device-6: RISER 2 DIMM 2 size: 2048 MB speed: 667 MHz type: DDR2 FB-DIMM (Synchronous)
           bus width: 64 bits (total: 72 bits)
           manufacturer: 80CE7FB380CE part: M395T5750EZ4-CE66 serial: 1011505F
           Device-7: RISER 3 DIMM 2 size: 2048 MB speed: 667 MHz type: DDR2 FB-DIMM (Synchronous)
           bus width: 64 bits (total: 72 bits)
           manufacturer: 80CE7FB380CE part: M395T5750EZ4-CE66 serial: 1011508B
           Device-8: RISER 4 DIMM 2 size: 2048 MB speed: 667 MHz type: DDR2 FB-DIMM (Synchronous)
           bus width: 64 bits (total: 72 bits)
           manufacturer: 80CE7FB380CE part: M395T5750EZ4-CE66 serial: 10114FFE
           Device-9: RISER 1 DIMM 3 size: No Module Installed type: DDR2 FB-DIMM (Synchronous)
           bus width: 64 bits (total: 72 bits)
           Device-10: RISER 2 DIMM 3 size: No Module Installed type: DDR2 FB-DIMM (Synchronous)
           bus width: 64 bits (total: 72 bits)
           Device-11: RISER 3 DIMM 3 size: No Module Installed type: DDR2 FB-DIMM (Synchronous)
           bus width: 64 bits (total: 72 bits)
           Device-12: RISER 4 DIMM 3 size: No Module Installed type: DDR2 FB-DIMM (Synchronous)
           bus width: 64 bits (total: 72 bits)
           Device-13: RISER 1 DIMM 4 size: No Module Installed type: DDR2 FB-DIMM (Synchronous)
           bus width: 64 bits (total: 72 bits)
           Device-14: RISER 2 DIMM 4 size: No Module Installed type: DDR2 FB-DIMM (Synchronous)
           bus width: 64 bits (total: 72 bits)
           Device-15: RISER 3 DIMM 4 size: No Module Installed type: DDR2 FB-DIMM (Synchronous)
           bus width: 64 bits (total: 72 bits)
           Device-16: RISER 4 DIMM 4 size: No Module Installed type: DDR2 FB-DIMM (Synchronous)
           bus width: 64 bits (total: 72 bits)
Info:      Processes: 227 Uptime: 34 min Memory: 762.8/12020.9MB
           Init: systemd v: 208 runlevel: 5 default: 5 Gcc sys: 4.9.1 alt: 4.7/4.8
           Client: Shell (bash 4.3.221 running in yakuake) inxi: 2.1.94
Title: Re: new inxi feature: -m for system ram
Post by: melmarker on 2014/08/14, 17:20:54
@h2 - new version uploaded, looks good to me:

Memory:    Array-1 capacity: 32 GB (est) devices: 4 EC: None
           max module size: 8192 MB (est.) module voltage: 3.3 V
           Device-1: A0 size: 8192 MB speed: 1333 MHz type: N/A
           bus width: 64 bits manufacturer: N/A part: N/A serial: N/A
           Device-2: A1 size: 8192 MB speed: 1333 MHz type: N/A
           bus width: 64 bits manufacturer: N/A part: N/A serial: N/A
           Device-3: A2 size: 8192 MB speed: 1333 MHz type: N/A
           bus width: 64 bits manufacturer: N/A part: N/A serial: N/A
           Device-4: A3 size: 8192 MB speed: 1333 MHz type: N/A
           bus width: 64 bits manufacturer: N/A part: N/A serial: N/A
Info:      Processes: 247 Uptime: 2 days Memory: 2292.5/32180.1MB
           Init: systemd v: 210 runlevel: 5 default: 5 Gcc sys: 4.9.1 alt: 4.2/4.3/4.4/4.5/4.6/4.7/4.8
           Client: Shell (sudo running in bash) inxi: 2.1.95-3
Title: Re: new inxi feature: -m for system ram
Post by: dibl on 2014/08/14, 17:44:42
New version looks fine here:


Code: [Select]
root@imerabox:/# inxi -S -I -mxxxx
System:    Host: imerabox Kernel: 3.16-1.towo-siduction-amd64 x86_64 (64 bit gcc: 4.9.1)
           Desktop: KDE 4.13.3 (Qt 4.8.6) info: plasma-desktop dm: lightdm
           Distro: aptosid 2011-02 Ἡμέρα - kde-lite - (201107131633)
Memory:    Array-1 capacity: 24 GB devices: 6 EC: Multi-bit ECC
           max module size: 4096 MB module voltage: 3.3 V
           Device-1: DIMM0 size: 2048 MB speed: N/A type: Other
           bus width: 64 bits (total: 72 bits) manufacturer: N/A part: N/A serial: N/A
           Device-2: DIMM1 size: No Module Installed type: Other bus width: 64 bits (total: 72 bits)
           Device-3: DIMM2 size: 2048 MB speed: N/A type: Other
           bus width: 64 bits (total: 72 bits) manufacturer: N/A part: N/A serial: N/A
           Device-4: DIMM3 size: No Module Installed type: Other bus width: 64 bits (total: 72 bits)
           Device-5: DIMM4 size: 2048 MB speed: N/A type: Other
           bus width: 64 bits (total: 72 bits) manufacturer: N/A part: N/A serial: N/A
           Device-6: DIMM5 size: No Module Installed type: Other bus width: 64 bits (total: 72 bits)
Info:      Processes: 317 Uptime: 4:27 Memory: 2308.5/5965.5MB
           Init: systemd v: 208 runlevel: 5 default: 5 Gcc sys: 4.9.1 alt: 4.6/4.7/4.8
           Client: Shell (bash 4.3.221 running in konsole) inxi: 2.1.95-3


Thanks h2!
Title: Re: new inxi feature: -m for system ram
Post by: melmarker on 2014/08/14, 19:09:00
@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

@dibl - looks interesting describe it far better

- array 24 G with 6 devices - aka 4G per device
- 3 modules a 2 G  dev-1, dev-3, dev-5
- info shows approx. 6G - that would match the modules
Title: Re: new inxi feature: -m for system ram
Post by: bluelupo on 2014/08/14, 19:43:35
New version looks fine here, too.

Code: [Select]
# inxi -S -I -mxxxx
System:    Host: polarfox Kernel: 3.16-0.towo-siduction-amd64 x86_64 (64 bit gcc: 4.9.1)
           Desktop: N/A info: plasma-desktop dm: kdm
           Distro: siduction 12.1.1 Desperado Reloaded - kde - (201206241901)
Memory:    Array-1 capacity: 16 GB devices: 2 EC: None
           Device-1: CHANNEL A DIMM0 size: 8192 MB speed: 1333 MHz type: DDR3 (Synchronous)
           bus width: 64 bits manufacturer: Kingston part: 9905403-502.A00LF serial: 030C39BE
           Device-2: CHANNEL B DIMM0 size: 8192 MB speed: 1333 MHz type: DDR3 (Synchronous)
           bus width: 64 bits manufacturer: Kingston part: 9905458-031.A00LF serial: 911E64AD
Info:      Processes: 317 Uptime: 2:47 Memory: 2383.2/15954.8MB
           Init: systemd v: 208 runlevel: 5 default: 5 Gcc sys: 4.9.1 alt: 4.7/4.8
           Client: Shell (bash 4.3.221 running in systemd) inxi: 2.1.94
Title: Re: new inxi feature: -m for system ram
Post by: dibl on 2014/08/14, 20:12:57

@dibl - looks interesting describe it far better

- array 24 G with 6 devices - aka 4G per device
- 3 modules a 2 G  dev-1, dev-3, dev-5
- info shows approx. 6G - that would match the modules


Yes, the mobo is an Asus P6X58D-E, which uses DDR3 DIMMs. The maximum memory capacity is 6 DIMMs, 4GB each. I installed 3 DIMMS, 2GB each. So the 24GB number is the maximum capacity, and the 6GB figure is the installed memory.
Title: Re: new inxi feature: -m for system ram
Post by: h2 on 2014/08/14, 20:15:17
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.

Title: Re: new inxi feature: -m for system ram
Post by: ReinerS on 2014/08/14, 21:01:01
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
Title: Re: new inxi feature: -m for system ram
Post by: h2 on 2014/08/14, 21:20:37
 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.
Title: Re: new inxi feature: -m for system ram
Post by: melmarker on 2014/08/14, 22:25:36
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 :)
Title: Re: new inxi feature: -m for system ram
Post by: h2 on 2014/08/14, 23:15:18
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.
Title: Re: new inxi feature: -m for system ram
Post by: ReinerS on 2014/08/14, 23:36:06
Ahh, I did miss the new update 8)

I will try again tomorrow (Later in the day)

regards

Reiner
Title: Re: new inxi feature: -m for system ram
Post by: melmarker on 2014/08/15, 02:16:13
new version upped: inxi_2.1.95.4.r2376_all.deb
Title: Re: new inxi feature: -m for system ram
Post by: h2 on 2014/08/15, 02:55:47
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.
Title: Re: new inxi feature: -m for system ram
Post by: ghstryder on 2014/08/15, 04:06:34
@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?
Title: Re: new inxi feature: -m for system ram
Post by: h2 on 2014/08/16, 02:47:06
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.
Title: Re: new inxi feature: -m for system ram
Post by: h2 on 2014/08/17, 02:36:30
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.
Title: Re: new inxi feature: -m for system ram
Post by: h2 on 2014/08/17, 21:09:33
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.
Title: Re: new inxi feature: -m for system ram
Post by: melmarker on 2014/08/17, 23:31:56
uploaded ...
Title: Re: new inxi feature: -m for system ram
Post by: h2 on 2014/08/18, 04:48:36
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.
Title: Re: new inxi feature: -m for system ram
Post by: h2 on 2014/08/19, 01:03:36
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.
Title: Re: new inxi feature: -m for system ram
Post by: bluelupo on 2014/08/27, 21:42:37
hi h2,
I would request concerning the implementation of a features for your tool "inxi". For me would be interesting if inxi the last system update (date and time of an "apt-get dist-upgrade") could be determined?

Would that be feasible? It would be very pleased if you could implement the proposal.
Title: Re: new inxi feature: -m for system ram
Post by: h2 on 2014/08/28, 01:47:27
smxi does that but can only do it if you always use smxi, otherwise there's no actual way to know when a full upgrade has been run.

Remember that all upgrade/dist-upgrade means as far as I know (and correct me if I am wrong) is that you tell the system to install latest version of all the packages.

I have some understanding of the issues from making the smxi last upgrade thing, but that one only works if

a: you always use smxi to upgrade

b: the system has been upgraded by smxi before

the hack I did there was to simply add a 'last-upgrade=' item to the smxi.conf file, which smxi reads.

However, in the context of inxi, I do not know of any way to know the system has been upgraded or when, and such a feature should include at least rpm/deb, maybe pacman, though I doubt pacman has a way to know such things.

With this said, if you can find a way to actually determine when the system last was upgraded, let me know, I am failrly familiar with debian upgrade stuff and I could not find a way that a script could read from the system state itself.

Remember that to actually be a real upgrade, the system must not exit the upgrade before it's done, that's why smxi for example only sets the last upgrade time after du/upgrade exits/completes without error or user initiated exit.

as good as apt is, it's missing a few things, meaningful error return numbers for example, a flag set each fully completed upgrade, and some other basic stuff that would not be that hard to do in apt, but I don't believe they are done.