Sat 29 Jan 2011 03:59:07 PM UTC, comment #3:
The real bug in your DMI table is that the last string in handle 0x0002 isn't properly 0-terminated. Instead it ends with a new line character (0x0a). Replacing the byte at offset 0xD4 by 0x00 using an hexadecimal editor fixes the table and dmidecode 2.11 then decodes it properly.
Without this fix, the strings area of handle 0x0002 is not double-0-terminated as the specification requires. This is the reason why dmidecode gets confused: it looks for a double-0, and the first one it finds is in the middle of the next handle.
Dmidecode 2.8 did eventually recover, but it was by luck, not by design. And it still missed one record (in addition to printing 2 bogus reports.)
The problem is that the SMBIOS specification is such that there is no way to skip a broken record. You have to fully decode one record before you can access the next. It is thus impossible to properly handle broken tables: as soon as one record is broken, you have no reliable way to continue.
So, I don't want to add code to dmidecode to handle such cases. It is pointless, because it shouldn't be needed and can't be implemented reliably.
In your case, I see that there are many BIOS updates available for your board, so if you are really worried about the broken DMI table, you should give them a try - maybe they include a fixed DMI table.
|