A Nifty Way To Access Linux Memory/RAM Information

[phoronix]

Phoronix: A Nifty Way To Access Linux Memory/RAM Information

Making use of dmidecode is the go-to way of being able to read various DIMM memory information on Linux systems like the model number, speed, and other attributes. But sadly using dmidecode is restricted to root due to needing to access /dev/mem. But it turns out there is another less reported way to receive much the same information...

https://www.phoronix.com/news/Linux-DIMM-Details-As-Root

[debrouxl]

While it's a good idea to expose the DMI/SMBIOS information through the udev database, let's just say that this information is not always correct in practice, be it for memory or various other things... There's a reason why software aiming at gathering memory information attempts to use the SMBus controller to read SPD data on the I2C bus
I have already seen laptop models whose DMI data reports wrong (placeholder) serial number information, or worse, 4 memory slots whereas only 2 are physically present on the motherboard, there are no memory slots hidden on the other side... Or an old Intel motherboard whose self-indicated system type (in record type 2 or 1, whichever is filled in and picked up by memtest86+ first) is flat out garbage: dozens of non-printable characters.

Reliable information is a whole can of worms of its own:
* on the SPD data side: a new format for every memory generation since RDRAM and SDRAM, as well as turbo / vendor extensions (e.g. EPP, XMP / DOCP, EXPO), but that's manageable;
* on the hardware access side: many SMBus controller models (though fortunately, only about two matter on modern platforms), SMBus controllers which are hidden or disabled, SMBus controllers which require extra setup (e.g. most Xeons since over a decade ago), I2C bus MUX chips which need to be fiddled with in order to handle more than 8 memory slots - that's quite frequent on even not so modern servers or workstations - and of course usually have undocumented access methods (otherwise, where's the fun ?), etc.
That's why i2c-tools' `decode-dimms` often retrieves only partial memory SPD information, when it can retrieve anything at all, even after loading all of the appropriate Linux kernel modules.

[ayumu]

lsmem needs to be upgraded. It'd be this much more useful if it was able to present this data.

[rene]

despite being inaccurate or plain bogus (hardcoded default values, or base clock, or w/o manual overclock) as already outlined above. You could also quickly patched teh missing DDR5 value into the kernel driver, in like 5 minutes and sent it upstream, ... ;-)

[Weasel]

Accessing hardware information without being root is something to be praised, but Crapland refusing to query window positions is a godsend of """security""" or """privacy"""?

[Old Grouch]

Accessing hardware information without being root is something to be praised, but Crapland refusing to query window positions is a godsend of """security""" or """privacy"""?

Hmm. Does the graphics hardware keep track of window positions, and could the hardware be interrogated to give the required information?

[Fifteen]

Couldn't you just run something like `udevadm info /sys/devices/virtual/dmi/id` instead of grepping through a full dump?

[briceburg]

Couldn't you just run something like `udevadm info /sys/devices/virtual/dmi/id` instead of grepping through a full dump?

^^^ this =)

[Weasel]

Hmm. Does the graphics hardware keep track of window positions, and could the hardware be interrogated to give the required information?

Not sure, my point was that window positions are treated as more confidential than your freaking hardware identification. Which is a joke just like the Wayland devs.

Let's praise when apps can query everything about my hardware because using root is a pain in the ass right? I say down to the unique ID and serial number!!!

But god forbid they know of my window positions... HUGE privacy leak I tell you!!!

[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?