A Nifty Way To Access Linux Memory/RAM Information

[QwertyChouskie]

Funny, I've been working on exactly this over the past few days: https://gitlab.com/mission-center-de...e_requests/104

The issue with type detection for DDR5 is concerning though. If I can't find a consistent workaround, I may have to keep dmidecode around as a fallback...

Does anyone have any idea where the code responsible for getting the memory type resides?

Looks like a bug was already filed: https://github.com/systemd/systemd/issues/30699

And a fix merged: https://github.com/systemd/systemd/pull/30701

I also opened this issue to hopefully help avoid these situations in the future: https://github.com/systemd/systemd/issues/30857

[debrouxl]

Funny, I've been working on exactly this over the past few days: https://gitlab.com/mission-center-de...e_requests/104

The issue with type detection for DDR5 is concerning though. If I can't find a consistent workaround, I may have to keep dmidecode around as a fallback...

Does anyone have any idea where the code responsible for getting the memory type resides?

I'm curious about the amount of fuzzing work udev's DMI information parser has sustained. I know that multiple rounds of fuzzing were run on dmidecode, and that these runs yielded several fixes.

[cj.wijtmans]

maybe udev would have been better if it had not been absorbed by systemd.

[QwertyChouskie]

I'm curious about the amount of fuzzing work udev's DMI information parser has sustained. I know that multiple rounds of fuzzing were run on dmidecode, and that these runs yielded several fixes.

FWIW, the original pull request that added the feature had like 140 comments or so, so it seems some real work was put into it, but I'm not sure if fuzzing took place or not.

[debrouxl]

FWIW, the original pull request that added the feature had like 140 comments or so, so it seems some real work was put into it, but I'm not sure if fuzzing took place or not.

For users' sake, I really hope that some fuzzing work took place on systemd/udev's implementation... Serious issues in systemd's untrusted input handling were spotlit several times, e.g. in the DNS client implementation, IIRC.
IME, fuzzing dmidecode and libsmbios with AFL++ was easy, and modding memtest86+'s SMBIOS parser for libfuzzer-based fuzzing was trivial: https://github.com/memtest86plus/mem...21d24c2cda6328

[mazumoto]

So is there any reliable and easy way on Linux to determine the current speed and timings the memory runs at? I didn't get that working at all a year or so ago and it seemed impossible at that time. Only the static SPD stuff seemed to be accessible.
On Windoze it's just so easy with tools like CPU-Z ...

[QwertyChouskie]

So is there any reliable and easy way on Linux to determine the current speed and timings the memory runs at? I didn't get that working at all a year or so ago and it seemed impossible at that time. Only the static SPD stuff seemed to be accessible.
On Windoze it's just so easy with tools like CPU-Z ...

Both dmidecode and the method in this article support displaying both the default speed and the currently configured speed. Not sure about timings TBH.

EDIT: `decode-dimms` should tell you the supported timings for your modules, but I'm still not sure of a way to access currently configured timings.

[debrouxl]

So is there any reliable and easy way on Linux to determine the current speed and timings the memory runs at? I didn't get that working at all a year or so ago and it seemed impossible at that time. Only the static SPD stuff seemed to be accessible.
On Windoze it's just so easy with tools like CPU-Z ...

The likes of CPU-Z, HWiNFO and SIV implement communication with many models of SMBus controllers + I2C MUXes (for SPD), IMCs (for live data), possibly EDAC, etc. - a number of which have no or incomplete public documentation (AFAIK, that goes especially for IMCs, I2C MUXes, and probably most of all the location of the latter on a given motherboard model). Therefore, their implementation was derived from private sources: information obtained through e.g. reverse-engineering or a piece of documentation under NDA. I have no clue whether the developers of these three pieces of software share information or cooperate on their developments - they may rather have separate NDAs.

Open source software - not just Linux - developed by a handful of unpaid volunteers in their spare time will never gain the same level of functionality, especially for old processors (say, before x86-64-v2, in this day and age) and corresponding motherboards. The reasons are non-technical: 1) voluntary knowledge access limitation by manufacturers, 2) legal pressure, and 3) insufficient human developer power, time and money are the largest ones which come to my mind.
The aforementioned tools are basically not going to become open source (well, that would be a fanastic surprise, but don't daydream about it...), partially because of the non-public stuff: there would be no incentive to use the open version with crippled functionality caused by mandatory removal of non-public stuff...

Let's get down to something more concrete. memtest86+ 7.00 implements IMC support for most Intel Core i* and AMD Zen desktop processors, as GPLv2 code. Achieving this important milestone required lots of developer time for both implementation (gathering information from somewhere, turning it into code) and testing on at least one working platform of every relevant processor series.
Yet, that's presumably in the ballpark of 15-25% (*) of the work for implementing and testing support for existing x86-64-v2 platforms: nearly every generation also has mobile platforms, workstation/server platforms, and some generations have embedded platforms. That requires a linear amount of hardware for testing purposes.

As monumental it already is for past platforms, the implementation+test task is unending, needless to say. Every year brings at least 6 new platforms - (desktop + mobile + server/workstation) * 2 main x86 processor manufacturers * 1 generation per year - which must be tested one by one, after an implementation which is in the best case a matter of adding several hardware IDs to the right places, but in the worst case a matter of implementing a new set of MSR / PCI register / MMIO accesses performed with the appropriate timings. Lately, Intel and AMD have been churning new generations at a rate a bit higher than 1 per year, or tend to produce two families of server platforms (Zen 4 vs. Zen 4c, * Rapids with P-Cores vs. * Forest with E-Cores), and their roadmaps indicate that this trend should hold for a little while longer...

*: at the time of this writing, memtest86+ recognizes 51 types of x86-64-v2 IMCs (determine_imc() in https://github.com/memtest86plus/mem...stem/cpuinfo.c contains 55 occurrences of "IMC_", 4 of which are for K8, K10, K12 and K14; x86-64-v2 AMD "Heavy equipment" (Bulldozer, Piledriver, Excavator and friends) families are K15+) and implements support for 12 of them (12 occurrences of "IMC_" in memctrl_init() in https://github.com/memtest86plus/mem...stem/memctrl.c ) through 6 "drivers", 6 functions called by that same memctrl_init() function.

[LtdJorge]

Michael, should Hans maybe have a Red Hat engineer badge, similar to how AMD graphics' team members do?

[gfxdrone]

Support for the udevadm sourced ram data is in final testing phase in inxi now, I just heard about this option.

udevadm info -p /devices/virtual/dmi/id

While that path suggests this data comes from /sys/devices/virtual/dmi/id, it actually doesn't.

The comments above about the significant reliability issues of dmi data are correct, though there are two types of data, one is actual, dynamic type data, most RAM module data is of this type, and is pretty reliable, and the other are the dreaded OEM completed data, which are totally random. Since inxi already had the logic to handle the low quality dmi data from dmidecode, 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 run the existing logic on the udevamd data.

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.

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).

You can play around with this now:

https://codeberg.org/smxi/pinxi

or quick shortcut install:

wget smxi.org/pinxi && chmod +x pinxi

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: pinxi -U
and then

pinxi -ma --vs
# or for public posts
pinxi -maz --vs

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 this one did not take that long to add.

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:
udevadm info -p /devices/virtual/dmi/id > udevadm-data.txt and upload it somewhere, or here, most systems the data is not too long.

I bumped into this thread when 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.

It's not totally new, but does seem to have hit the public recently, I was told about it in an issue from someone from OpenSuse about a week ago.

I was actually just going to start posting for testers on some other forums, when I found this thread.

Sample from my system:

pinxi -maz --vs
pinxi 3.3.31-45 (2024-01-16)
Memory:
  System RAM: total: 32 GiB available: 31.27 GiB used: 11.44 GiB (36.6%)
  Message: For most reliable report, use superuser + dmidecode.
  Array-1: capacity: 128 GiB slots: 4 modules: 2 EC: None
    max-module-size: 32 GiB note: est.
  Device-1: Channel-A DIMM 0 type: no module installed
  Device-2: Channel-A DIMM 1 type: DDR4 detail: synchronous unbuffered
    (unregistered) size: 16 GiB speed: 2400 MT/s volts: note: check curr: 1
    min: 1 max: 1 width (bits): data: 64 total: 64 manufacturer: Crucial
    part-no: CT16G4DFD824A.M16FB serial: <filter>
  Device-3: Channel-B DIMM 0 type: no module installed
  Device-4: Channel-B DIMM 1 type: DDR4 detail: synchronous unbuffered
    (unregistered) size: 16 GiB speed: 2400 MT/s volts: note: check curr: 1
    min: 1 max: 1 width (bits): data: 64 total: 64 manufacturer: Crucial
    part-no: CT16G4DFD824A.M16FB serial: <filter> zz0.v2j7hyhvcfdzz