SMBIOS type 17 table doesn't show reliable data

[krystian-hebel]

Component

Dasharo firmware

Device

MSI Pro Z790-P, NovaCustom NV4x 12th Gen, other

Dasharo version

No response

Dasharo Tools Suite version

No response

Test case ID

No response

Brief summary

SMBIOS Memory Device table doesn't show correct data. Device and Bank Locator is constant between all DIMMs, which makes it impossible to differentiate between them, at least without comparing serial numbers (which usually are encoded in a way that doesn't match what is on a sticker). On top of that, SMBIOS specification clearly states that type 17 entry must be produced also for non-populated slots. Currently such entries are skipped for most Intel SoCs, probably due to the code being copied for each new family from an existing one. Example for Alderlake, but others are similar - entry is saved only if DIMM is present.

How reproducible

No response

How to reproduce

sudo dmidecode -t 17

Expected behavior

Proper locators should be reported. Empty DIMM slots should also be reported.

Actual behavior

ubuntu@3mdeb:~$ sudo dmidecode -t 17
# dmidecode 3.3
Getting SMBIOS data from sysfs.
SMBIOS 3.3.0 present.

Handle 0x000B, DMI type 17, 40 bytes
Memory Device
	Array Handle: 0x000A
	Error Information Handle: Not Provided
	Total Width: 64 bits
	Data Width: 64 bits
	Size: 8 GB
	Form Factor: SODIMM
	Set: None
	Locator: Channel-0-DIMM-0
	Bank Locator: BANK 0
	Type: DDR4
	Type Detail: Unknown Synchronous
	Speed: 3200 MT/s
	Manufacturer: Kingston
	Serial Number: ff9ace91
	Asset Tag: Channel-0-DIMM-0-AssetTag
	Part Number: 9905700-118.A00G
	Rank: 1
	Configured Memory Speed: 3200 MT/s
	Minimum Voltage: 1.2 V
	Maximum Voltage: 1.2 V
	Configured Voltage: 1.2 V

Handle 0x000C, DMI type 17, 40 bytes
Memory Device
	Array Handle: 0x000A
	Error Information Handle: Not Provided
	Total Width: 64 bits
	Data Width: 64 bits
	Size: 8 GB
	Form Factor: SODIMM
	Set: None
	Locator: Channel-0-DIMM-0
	Bank Locator: BANK 0
	Type: DDR4
	Type Detail: Unknown Synchronous
	Speed: 3200 MT/s
	Manufacturer: Kingston
	Serial Number: ff9aee4a
	Asset Tag: Channel-0-DIMM-0-AssetTag
	Part Number: 9905700-118.A00G
	Rank: 1
	Configured Memory Speed: 3200 MT/s
	Minimum Voltage: 1.2 V
	Maximum Voltage: 1.2 V
	Configured Voltage: 1.2 V

Screenshots

No response

Additional context

No response

Solutions you've tried

No response

[Firminator]

Question: is this about RAM slots and their numbering? If not, let me know and file a seperate issue.

From a end-user perspective this results for example on an OptiPlex 9010 w/ Dasharo v0.2 RC 3 (released 2021-09-24) in that Memtest has the slots all wrong:

Mainboard | Memtest
Slot      | Slot
-------------------
3         |0
1         |1
4         |2
2         |3

[krystian-hebel]

@Firminator AFAICT Memtest iterates over I2C addresses, which aren't necessarily lined up with how the slots are laid out on the board. I2C addresses are hardwired and can't be changed. It may be possible to modify Memtest to use locators from SMBIOS instead, but I2C addresses are much more predictable and by design they are unique. Another reason why Memtest had chosen to use those indices may be that they are short, while SMBIOS locators are strings with unbounded length, which could easily overflow the screen width.

I'm afraid this isn't something that can be fixed by changes to Dasharo. It would be possible to make SMBIOS numbering the same as Memtest, but then it wouldn't match labels on the board, which would be even worse.

[Firminator]

Thanks for the reply Krystian. So this is actually an 'issue' with Memtest and not Dasharo firmware. Interesting. I wonder if I should just ignore this... or if there are chances this can be addressed by Memtest. Sounds like a long stretch and lots of core code changes if they have to change the way how to identify memory slots. It's definitely confusing for users being pointed to an incorrect RAM slot given that's the whole purpose of Memtest. Maybe it's only affecting certain mainboards? I think I give opening an issue with Memtest a try and see what happens.
Thanks.

[krystian-hebel]

Maybe it's only affecting certain mainboards?

Maybe. How vendor wants to label slots on the mainboard is entirely up to them. It seems that in case of OptiPlex they decided to number them according to suggested order of population, which is one of the reasonable possibilities. There are users which are technical enough to install new module, but not enough to understand channels (or worse, those who misunderstand how channels work), and this approach of labeling the slots is perfect for them.

In any case, at least for some platforms Dasharo reports that each DIMM is in Channel-0-DIMM-0. I haven't checked if OptiPlex is also impacted by this issue.

[Firminator]

When I populate slot 1 and 2 (both white), and leave slots 3 and 4 (both black) unpopulated, then DTS reports:

RAM Channel-0-DIMM-1
RAM Channel-1-DIMM-1

But that's with v0.2 RC 3 (released 2021-09-24) ... one of the first releases when Michal Z. initially reverse-engineered the platform ('cursed EC'!; https://blog.3mdeb.com/2021/2021-06-01-optiplex_part2/ ) and adopted it to coreboot. Not sure yet what v0.1.1 from December 2024 will look like. I'm in the process of updating currently.

[mkopec]

I think the DIMM locator issue can be handled by properly implementing smbios_fill_dimm_locator in mainboard code

[miczyg1]

I think the DIMM locator issue can be handled by properly implementing smbios_fill_dimm_locator in mainboard code

Usually, the soc code parses the FSP HOB to produce this data. I have been fixing the parsing for a couple of platforms already in the past. Otherwise it is just ordered per I2C address.

[Firminator]

Is the 9010 one of those platforms that hasn't been fixed (or cannot be fixed) and that's why it's using the I2C address? Or in other words will implementing the smbios_fill_dimm_locator method fix the RAM slot order presented to other OS (like Memtest)?