"Identifies the position of the referenced Memory Device in a row of the address partition. For example, if two 8-bit devices form a 16-bit row, this field’s value is either 1 or 2.
The value 0 is reserved. If the position is unknown, the field contains FFh."
So, the firmware is using a reserved value of 0. We should expect unknown (0xff) or a value > 0.
This probably won't cause any issues with Linux, but it should be fed back to the BIOS vendor as a query or something to fix
on the next BIOS release
fwts is flagging up a DMI table field that is not strictly conforming to the DMI specification,
http:// dmtf.org/ sites/default/ files/standards /documents/ DSP0134_ 2.7.1.pdf
Section 7.21, page 93, offsect 10h, "Partition Row Postion" states:
"Identifies the position of the referenced Memory Device in a row of the address partition. For example, if two 8-bit devices form a 16-bit row, this field’s value is either 1 or 2.
The value 0 is reserved. If the position is unknown, the field contains FFh."
So, the firmware is using a reserved value of 0. We should expect unknown (0xff) or a value > 0.
This probably won't cause any issues with Linux, but it should be fed back to the BIOS vendor as a query or something to fix
on the next BIOS release