Mon 13 Jan 2014 04:44:22 PM UTC, comment #5:
You're welcome.
\x04 -> \x0c is fixing the structure count (4 -> 12).
\x23 -> \x1b is adjusting the checksum accordingly, otherwise the SMBIOS entry is no longer considered valid and is thus skipped.
Needless to say this exact fix is very specific to your issue and wouldn't apply as is to any other case, even if looking similar.
|
Mon 13 Jan 2014 04:23:17 PM UTC, comment #4:
wow ! This hex' change you did in fixed.bin wasn't trivial after all, but the result is amazing.
If I understood the point, this substitution could (more or less) do the trick in the future:
\x04\x00\x23\x00 => \x0c\x00\x1b\x00
around the 29th byte.
thank you !
|
Mon 13 Jan 2014 04:21:07 PM UTC, comment #3:
I have attached your DMI table, fixed :-)
My guess was wrong, the problem wasn't with the length, it was with the structure count. It was encoded as 4 while there are 12 structures. I would blame it on an accidental bit flip (12 - 4 is 8 which is a single bit), however the checksum is correct so a single bit flip can't explain it.
I agree that we could add a command line parameter to ignore the structure count and walk until the end-of-table marker or the declared length has been reached, whichever comes first. OTOH I don't want to encourage broken DMI tables, plus I doubt the kernel would ever implement such a workaround anyway.
BIOS bugs are better fixed in the BIOS.
|
Mon 13 Jan 2014 03:10:11 PM UTC, comment #1:
There is no easy way, no. If the DMI data is incorrect, it can be wrong in so many ways that there is no way dmidecode can figure it out automatically in a safe way.
The right thing to do here would be to look for a BIOS update for your system. If there is none or if it doesn't help, the next step would be to complain to the manufacturer. But I understand that for a system of that age, it's not going to be very helpful.
Note that it is entirely possible that there is nothing else to decode anyway, i.e. this is only a warning, the table itself is good and only its announced length is not. If the table properly ends with a type 127 record, you're most probably wasting your time trying to get more.
Still, if you really want to get to the end of this, you could dump the DMI table to a binary file (using the --dump-bin option), then edit the file with a binary editor. In the binary dump, look for the end-of-table marker: 0x00 0x00 0x7f 0x04 <two bytes for the handle> 0x00 0x00, and replace the 0x7f by 0x7e to let dmidecode go past it. Lastly, point dmidecode to the modified dump (using the --from-dump option.) This might lead to dmidecode printing total crap after this point though, you've been warned. It might even stop again or crash (though it really shouldn't.)
|
Fri 29 Nov 2013 12:43:21 PM UTC, original submission:
dmidecode fails to dump some information (probably memory related) on my hardware.
(installed memory is a set of 3 Samsung 1Go DDR 400Mhz sticks)
IS there any way to get the dump to go further ?
Please note that dmidecode -u fails in a same way.
> Wrong DMI structures length: 501 bytes announced, structures occupy 335 bytes.
|