New inxi / pinxi features: user RAM reports! And much more! Testers?
SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
New inxi / pinxi features: user RAM reports! And much more! Testers?
Support for the udevadm sourced ram data is in final testing phase in inxi now, I just heard about this option from someone posting an inxi codeberg feature request. This is the source of the data:
Code:
udevadm info -p /devices/virtual/dmi/id
While that path suggests this data comes from /sys/devices/virtual/dmi/id, it actually doesn't, or I would have used it years ago. That's where the board/chassis/bios data lives, and oddly, udevadm barely shows any of that.
Slackware appears to be using the eudev package to provide udevadm, not sure if that's a standard install item, it was in my test, but I used Slax to verify. eudev is what inxi shows for slackware in --recommends anyway, correct please if wrong.
Since inxi already had the logic to handle the low quality dmi data from dmidecode, which needs a lot of filters, and some core logic to make sure the results are not logically impossible, implementing the udevadm sourced version was pretty straightforward since all I had to do was tweak the existing logic for the udevamd data. I was kind of lucky because all the hard fixes, logic corrections, tests, etc, were done a long time ago for dmidecode sourced ram data, so udevadm as data source did not take that long to add.
There are so far two significant issues with udevadm data I've found, first, and most likely to be visible to average users, is the RAM voltages appear to be broken, in all my tests, systems that returned voltages return 1 for all, min, max, configured, which is clearly wrong. The other is that while dmidecode correctly assigns the main RAM Array to a handle, then links the RAM Device module reports to that handle, in udevadm it appears they assume that there will never be more than one RAM system board array. That's very corner case, but it is an odd oversight.
If anyone has, which I know is a stretch, a box with 2 system board memory arrays (which would show as 2 separate type 16 memory devices, those are the Arrays), I'm particularly interested in those. Or remote access to one, that's going to be a big server for sure.
A few other differences, which are actually improvements, is the speeds are all MT/s, and the sizes are in Bytes. dmidecode changes sizes to human readable, which takes more processing to deal with.
But given for most users, most of the time, this data will be largely correct (assuming the logic tests run to correct obviously impossible situations), and also, will for the first time let you get data without dmidecode (I think, not sure where udevadm is getting it's dmi data from, will test to verify it still works without dmidecode).
I put pinxi in /usr/local/bin so it's in path, but it doesn't matter where it is.
If you already have pinxi installed, just use its self updater:
Code:
pinxi -U
and then
Code:
pinxi -SIGma --vs
# or for public posts
pinxi -SIGmaz --vs
Note that -S, -I, and -G have seen the most upgrades, refactors, and enhancements, but the non root/sudo -ma showing data was not an expected feature for this upcoming release until last week, when I got an issue saying it was possible, which I'd never known.
I still have some fine tunings, but I'm shooting to release this as next inxi, 3.3.32 within a week, unless some testers can find failure cases that need handling, which is often the case with RAM data sources.
Note that if you get what you believe are wrong or misleading results, and want to help improve it, supply:
Code:
udevadm info -p /devices/virtual/dmi/id > udevadm-data.txt
and upload it somewhere, or here, most systems the data is not too long. Feel free to slightly alter the serial numbers if you don't want those to show, I'm doing that on all the test files I'm adding to the pinxi/data/ram/udevadm/ as I go along, I just XXXX out half the serial nummber, but leave enough unique so I can tell it's working.
I was checking some last minute details and testing some stuff, for example, udevadm version 174 does not appear to have this feature, at least not in TinyCore, though I know the dmi data is there, so I was wondering when it was added.
Sample from my system [sorry, forum gets rid of indentation]:
Any tests, feedback, etc appreciated, and in particular, any data samples that show it not working when dmidecode did.
Note that if you have dmidecode installed, pinxi will use that automatically for sudo/root start of inxi, though you can force udevadm with --force udevadm, so it's easy to compare the two sources for variations.
Note that dmidecode has more data than udevadm, which offers up a sort of basic summary per array and module, but the data is pretty close and inxi didn't use all the dmidecode values anyway, so it's quite similar.
Thanks for looking, and testing, if you feel so inclined.
drumz, quite the contrary, I was hoping to find where this method fails, and it didn't take long, lol.
Can you confirm version: udevadm --version
On Slax 15, it shows: 243, I assume your's is the same?
I don't know when this feature was added, it may be quite recent because there was some buzz about this week, one on phoronix, and I got an issue / feature request for it about a week ago, and I'd never heard of this before.
I should have booted slax in usb live mode on physical hardware, but your output looks the same as what I got, roughly, no ram array/devices.
What's that board/system? This is I think one of the first samples I've seen of > 1 arrays being there, and more than 2 as well.
This confirms a lot of things for me, first, that the inxi ram handler for > 1 array actually works, but has a bug, the total capacity is failing to add to the total, that's because I never noticed since never had a sample of that, so that's a bug found and hopefully soon fixed, thanks.
It's a Thelio Massive from System76. Motherboard is a WS C621E SAGE from ASUS.
Portion of dmidecode:
Code:
# dmidecode
# dmidecode 3.3
Getting SMBIOS data from sysfs.
SMBIOS 3.2.1 present.
Table at 0x6EC26000.
<snip>
Handle 0x0001, DMI type 1, 27 bytes
System Information
Manufacturer: System76
Product Name: Thelio Massive
Version: thelio-massive-b1
Serial Number: System Serial Number
UUID: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
Wake-up Type: Power Switch
SKU Number: Not Specified
Family: Server
Handle 0x0002, DMI type 2, 15 bytes
Base Board Information
Manufacturer: System76
Product Name: Thelio Massive
Version: thelio-massive-b1
Serial Number: xxxxxxxxxxxxxxx
Asset Tag: To Be Filled By O.E.M.
Features:
Board is a hosting board
Board is replaceable
Location In Chassis: To Be Filled By O.E.M.
Chassis Handle: 0x0003
Type: Motherboard
Contained Object Handles: 0
Handle 0x0003, DMI type 3, 22 bytes
Chassis Information
Manufacturer: System76
Type: Desktop
Lock: Not Present
Version: thelio-massive-b1
Serial Number: To Be Filled By O.E.M.
Asset Tag: To Be Filled By O.E.M.
Boot-up State: Safe
Power Supply State: Safe
Thermal State: Safe
Security Status: None
OEM Information: 0x00000000
Height: Unspecified
Number Of Power Cords: 1
Contained Elements: 0
SKU Number: To Be Filled By O.E.M.
<snip>
This confirms a lot of things for me, first, that the inxi ram handler for > 1 array actually works, but has a bug, the total capacity is failing to add to the total, that's because I never noticed since never had a sample of that, so that's a bug found and hopefully soon fixed, thanks.
The capacity and installed memory amounts are correct.
Arrays 1 and 3 have capacity 384 GiB and installed 192 GiB, which is correct.
Arrays 2 and 4 have capacity 384 GiB and installed 64 GiB, which is correct. (Each array has 2 empty slots, which is correct.)
(I have 8 64 GiB sticks installed in total.)
Total installed memory is 512 GiB, which is correct.
Total capacity is I guess 1536 GiB, which pinxi does not display. Maybe that's what you're talking about?
Yes, sorry, I just realized I was getting confused, this often happens to me when I've been hacking a while.
But I realized that in fact, inxi does not display the total capacity anywhere, that's something that didn't come up since I hadn't seen any > 1 array samples, or if I had, it was a long time ago. I'll think on that one, maybe a new line, a summary if > 1 array:
I think that's how I will handle it. Note that I am failing to reset the modules iterator per array? That's a bug. These things are easy to miss.
I wonder if I could talk you into booting a usb device on that, with more current udevadm (antix is nice for testing) and if I could get the udevadm report from it? That might be significant in terms of releasing without this issue, I want to see how udevadm handles > 1 array in the output, that would determine how I loop the data and build it up.
So that data is all correct, good.
However, your setup confirms my fear that, assuming this is a relatively recent feature of udevadm (did not work in 174, does not seem to work, though I will confirm on a live slackware usb boot), on 243, does work on 255, and I think 252, have to check the versions of successful.
Checking [all boards with dmi ram]:
Supermicro board, ubuntu 22.04, kernel 5.15: version 249, works
Gigabyte board, Debian testing, current, 6.6 kernel: version 255, works
Supermicro amd board, frugalware current, 6.2 kernel: version 253, works
Thinkpad x220, antix current, 5.10 kernel: version 251, works
another supermicro, 5.15 kernel, ubuntu 22.04: version 249, works
Thinkpad x220, tinycore 14: version 174, doesn't work
Supermicro, 5.4 kernel, ubuntu 20.04: version 245, doesn't work
That suggests that the feature may have been added between 245 and 249?
pinxi 3.3.31-47 should handle > 1 RAM arrays, I merged the already existing --memory-short/--ms short form report with > 1 arrays, and added some counters and data stores internally.
This seems like a decent solution, and less hackish than the old way that was used to generate the Report: arrays: line.
That also includes the bug fix for the per array modules used counters.
chrisretusn, thanks, however in this case, we want this to run as user, not root, since that's the new availability of this data, first time ever for user.
Your sample is very good, I'm going to add it to the pinxi/data/ram/udevadm set because that is less data per stick than I'd seen so far. Sometimes samples with very barebones data are useful to make sure all the error and null data and filter protections are working. That's about as lean a sample as I've seen.
Null ram module type is concerning, but your root with dmidecode shows the dmi data is just not there, though a very stripped down version.
Is there anything unusual about the board that comes from?
The really great thing about posting here is someone always has some awesome hardware, like drumz had, that let me test some of my assumptions, and find and fix some bugs related to the uncommon cases. I always really appreciate the help because, well, it tends to be so helpful.
I had confirmed just now on the original codeberg.org/smxi/pinxi issue request for udevadm that they are getting valid RAM data back to v249, which is so far the earliest version I've seen data from as well, and those were different OS (OpenSuse/Leap etc), so it's looking possible the feature is quite new. And you're confirming for v251, so that seems to start locking down around when the feature was released.
[except for the System RAM:... available/used, those come from somewhere else.]
As an aside, I seem to be getting a good habit, after my big docs/data opening/release/reorganization, of releasing my test data files used to develop concurrently with the feature as it's developed. I'm trying to be reasonably good about this since going back and redoing a bunch of stuff I've already forgotten most of is very time consuming, far easier to just do it as I develop it. Speaking of which, I'd better update the inxi-ram.txt doc file.
So far the only broken thing appears to be RAM module voltages, they seem to always show as 1, not a real value, not sure where that comes from, never matches what dmidecode lists when it has voltages so it's not from dmi, to me it looks like it might be a placeholder or something that was left in place by accident. Or maybe that data is not available.
Also, just added module firmware version number, that is a very rare value to get, they have the field names for it, but they are almost never populated, so it only shows up with -ma, and if it exists.
chrisretusn, thanks, however in this case, we want this to run as user, not root, since that's the new availability of this data, first time ever for user.
chrisretusn: Oops, sorry, that one slipped by. Now corrected in 3.3.31-49
The per array active modules fix works, that's good, though it looks like something is getting trimmed from Error Correction Type.
[another bug, sorry, error correction type passed the field name, not the value, to the cleaner]
I'd still like to know what the udevadm output for > 1 array setups looks like, to me it looks like they made a mistake, and assumed only 1 array, so did not number the MEMORY_ARRAY_[field] items like they do with: MEMORY_DEVICE_(\d+)_[field name]
I'm leaning towards guessing that first, MEMORY_ARRAY_LOCATION is always first, and that the ordered sequence is per array, then adding in a check for a possible array number, along with the known no number case which is so far standard. But there's no way to know this since the way they did it appears to be a mistake, a subtle one, that I can see why would not have gotten caught so far, but I have to assume it will get caught.
I may have to redo that logic to actually build the structure that is missing.
This is a similar issue I'm having with a current active bug report where with amd threadripper 2950x, 16 core, I assume 2 die, each die is counting its cores independently, which no other amd zen does that I have seen, leading to a reported core count of 1/2, but impossible to debug without the debugger data required to emulate it, I can't actually guess what the data looks like.
The good side is, very few users will have > 1 array systems, so any potential issues will be limited to a small set of people, and I'll only need probably one udevadm data sample from that system to fix it, as logic goes, this is pretty easy overall.
Thanks for confirming the fix, and sorry for the typo, I should have run some data through it with EC active, but I forgot.
Note that another actually important difference, which I don't like, between dmidecode output and udevadm output is that in many cases, udevadm does not output values if they are not active, whereas dmidecode has the same values for modules whether they are occupied or not, or for arrays, EC whether active or not.
===============================
rizitis, you found a bug with the new logic, when it says the array capacity is an 'estimate', that's wrong, it had the capacity. I'll run that data through and fix it, thanks.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
