Mon 08 May 2006 09:22:19 AM UTC, comment #1:
The SMBIOS specification says that the part number is stored as a string, and dmidecode properly displays that string. The SMBIOS specification doesn't mention any additional processing for that string.
Now, it indeed looks like your implementation uses Jedec hexadecimal codes for this string and the "Manufacturer" string, as read from the memory module SPD EEPROM. Other implementations have it differently though.
For the manufacturer, I have seen some Compaq systems with strings like this one: "JEDEC ID:C1 00 00 00 00 00 00 00". So it's a JEDEC manufacturer code, like your system has, but it's encoded differently. And I have seen some HP systems where the string would simply be "HP", so it's already decoded.
For the part number, I've only seen them set on some Compaq systems, and they were already decoded (e.g. "8LSDT1664AG-133E1" or "64D32300GU6C").
So, as you can see, the decoding of these strings, where needed, is manufacturer-specific. We may add some heuristics to dmidecode so that it tries to decode them, but it's not trivial. A look-up table would also be required for manufacturers. And it's definitely a feature request and not a bug.
Could you please provide a dump of your SMBIOS table?
dd if=/dev/mem of=/tmp/macintel bs=4k seek=130760 count=2
I'd like to add it to my non-regression test suite.
|