It misreports on some DDR4 systems and I haven't found conclusive clarification. I have one system for example which reports TotalWidth 72 and DataWidth 72. But it doesn't influence the amount of…
one:
Handle 0x0001, DMI type 1, 27 bytes
System Information
Manufacturer: To Be Filled By O.E.M.
Product Name: X570D4U
Version: To Be Filled By O.E.M.
Serial Number: To Be Filled By…
I need to verify how it works if there are multiple processors. I have a couple of dual-socket systems, but they always have the same processor model.
I was looking at some systems, and sometimes both TotalWidth and DataWidth is 72. I'm not really sure what it means. I vaguely remember reading that that's a bug in some DDR4 modules or motherboards. For now I would only check for TotalWidth and ignore DataWidth.
There are actually two speeds reported, one is the specification of the module and the other is configured speed. What you could do, is to report them both separated with "@". E.g. "1866@1333MHz".
We should also report "baseboard", and "system", if present. Traditional servers seem to report "system" and/or "chassis" whereas custom build machines report only "baseboard" (i.e. motherboard), as there is no way for the motherboard to find out what kind of chassis it is mounted into.
I'll merge it because the comments I have can be done in next iteration.
We also need to check for /sys/block/*/device as I explained in the chat. The logic is supposed to be like this.
Well, this logging.info we could keep but I would prefer if we got rid of f-strings due to #9
We shouldn't use /proc/diskstats at all because it doesn't contain the information we need. We could use /proc/partitions if /sys/block isn't available. But I don't think I have such a…
Good approach. There is a good chance the parser functionality is sufficient for what we need. You can now continue extracting more and more data from it.
We shouldn't log it, just skip it, or we should first test if the file exists or is readable to filter the obvious exceptions.