Re: [dmidecode] dmidecode not return type 2 (baseboard)

[Jean Delvare]

Hi Talmai,

[Jean Delvare]
> > Please provide the output of:
> > dmidecode -t 2
> > dmidecode -u -t 2

[Talmai Oliveira]
> Its the same output for both commands:
> 
> # dmidecode 2.8
> SMBIOS 2.3 present.

I see. The table is broken so dmidecode fails to locate this entry
(type 2). From the copy you sent me off-list, this can be explained.
Here is a dump of the first 64 bytes, which almost covers the first 4
entries of the table.

 offset    0  1  2  3   4  5  6  7   8  9  a  b   c  d  e  f  0123456789abcdef

Record of type 0 (handle 0x0000)
000f0100  00 14 00 00  01 02 00 e0  03 03 80 9e  cb 7f 00 00  .......à....Ë...
000f0110  00 00 37 00  41 77 61 72  64 20 53 6f  66 74 77 61  ..7.Award Softwa
000f0120  72 65 20 49  6e 74 65 72  6e 61 74 69  6f 6e 61 6c  re International
000f0130  2c 20 49 6e  63 2e 00 46  31 30 00 30  31 2f 30 35  , Inc..F10.01/05
000f0140  2f 32 30 30  35 00 00                               /2005..

Record of type 1 (handle 0x0001)
000f0140                        01  19 01 00 01  02 03 04 ff         ........ÿ
000f0150  ff ff ff ff  ff ff ff ff  ff ff ff ff  ff ff ff 06  ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ.
000f0160  53 65 6d 70  20 54 6f 73  68 69 62 61  20 49 6e 66  Semp Toshiba Inf
000f0170  6f 72 6d 61  74 69 63 61  20 4c 74 64  61 00 53 54  ormatica Ltda.ST
000f0180  49 00 52 65  76 2e 20 31  30 2f 30 30  00 35 30 33  I.Rev. 10/00.503
000f0190  30 37 33 38  39 20 00 00  00                        07389 ...

Record of type 2 (handle 0x0002)
000f0190                               02 08 02  00 01 02 03           .......
000f01a0  04 20 00 50  34 4d 32 36  36 41 2d 38  32 33 35 00  . .P4M266A-8235.
000f01b0  20 00 20 00  00                                      . ..

Record of type 3 (handle 0x0003, incomplete)
000f01b0                  03 11 03  00 01 03 02  03 04 02 02       ...........
000f01c0  02 02 00 00  00 00 20 00  20 00 20 00  20 00 00 04  ...... . . . ...
000f01d0  23 04 00 01  03 b2 02 34  0f 00 00 ff  fb eb bf 03  #....².4...ÿûë¿.
000f01e0  8d 85 00 10  0e f0 0a 41  04 09 00 0a  00 ff ff 04  .....ð.A.....ÿÿ.
000f01f0  05 06 53 6f  63 6b 65 74  20 34 37 38  00 49 6e 74  ..Socket 478.Int

I've split the records the way the encoder wants us to. However, if you
look at the end of the second record (type 1), you'll notice that it
ends up with three 00. According to the SMBIOS specification, a record
must be terminated with two 00. As a consequence, dmidecode does not
include the last 00 in this record, and thinks this is the first byte
of the next record. So this is how dmidecode sees the beginning of the
table:

 offset    0  1  2  3   4  5  6  7   8  9  a  b   c  d  e  f  0123456789abcdef

Record of type 0 (handle 0x0000)
000f0100  00 14 00 00  01 02 00 e0  03 03 80 9e  cb 7f 00 00  .......à....Ë...
000f0110  00 00 37 00  41 77 61 72  64 20 53 6f  66 74 77 61  ..7.Award Softwa
000f0120  72 65 20 49  6e 74 65 72  6e 61 74 69  6f 6e 61 6c  re International
000f0130  2c 20 49 6e  63 2e 00 46  31 30 00 30  31 2f 30 35  , Inc..F10.01/05
000f0140  2f 32 30 30  35 00 00                               /2005..

Record of type 1 (handle 0x0001)
000f0140                        01  19 01 00 01  02 03 04 ff         ........ÿ
000f0150  ff ff ff ff  ff ff ff ff  ff ff ff ff  ff ff ff 06  ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ.
000f0160  53 65 6d 70  20 54 6f 73  68 69 62 61  20 49 6e 66  Semp Toshiba Inf
000f0170  6f 72 6d 61  74 69 63 61  20 4c 74 64  61 00 53 54  ormatica Ltda.ST
000f0180  49 00 52 65  76 2e 20 31  30 2f 30 30  00 35 30 33  I.Rev. 10/00.503
000f0190  30 37 33 38  39 20 00 00                            07389 ..
                                    vv
Record of type 0 (handle 0x0208, invalid)
000f0190                            00 02 08 02  00 01 02 03          ........
000f01a0  04 20 00 50  34 4d 32 36  36 41 2d 38  32 33 35 00  . .P4M266A-8235.
000f01b0  20 00 20 00  00                                      . ..

Record of type 3 (handle 0x0003, incomplete)
000f01b0                  03 11 03  00 01 03 02  03 04 02 02       ...........
000f01c0  02 02 00 00  00 00 20 00  20 00 20 00  20 00 00 04  ...... . . . ...
000f01d0  23 04 00 01  03 b2 02 34  0f 00 00 ff  fb eb bf 03  #....².4...ÿûë¿.
000f01e0  8d 85 00 10  0e f0 0a 41  04 09 00 0a  00 ff ff 04  .....ð.A.....ÿÿ.
000f01f0  05 06 53 6f  63 6b 65 74  20 34 37 38  00 49 6e 74  ..Socket 478.Int

Put in short, your DMI table is buggy. I have no idea how your Windows
tool is able to recover from this error. I agree that the error is
detectable (no record can be shorter than 4 bytes, there should be only
one type 0 record, and a type 0 record should be at least 22 byte long)
however due to the way DMI tables are constructed, there is no standard
way to recover from this error. Here the solution would be to skip one
byte, but other errors would require a different trick, and I don't
want to add recovery error heuristics to dmidecode.

Even if we modified dmidecode to detect and attempt to recover from
this error, the DMI table is used by a number of operating system
kernels (e.g. Linux) which are not going to be modified.

So the only sane solution here is to get your DMI table fixed. Look for
BIOS updates first, and if you can't find any or they don't solve the
problem, report to the system manufacturer. It should be really easy
for them to fix the table.

As for dmidecode, I will add a check for records shorter than 4 bytes.
This is easy to do, and displaying a warning in this case will make it
more obvious to the user that something's wrong with his/her table.
This check will only detect a small number of errors though. Adding a
per-type length check would also be possible and would catch more
errors, but it would require more code too.

-- 
Jean Delvare