On Fri, Jun 06, 2025 at 12:02:31PM +0200, Jean Delvare wrote:
> On Fri, 6 Jun 2025 10:10:52 +0200, Jean Delvare wrote:
> > In my collection of HPE DMI tables, I see type 202 records of length 25
> > (=0x19, DL380/DL385/DL560 Gen10) and 26 (=0x1A, various Gen10 and Gen10
> > Plus). These lengths are not tested, which causes some available fields
> > not to be displayed on these systems.
>From my collection:
anatevka 1209 % ./do.test | grep 'type 202' | sed 's/^Handle.*DMI/DMI/' | sort
| uniq -c | sort -nk +5
72 DMI type 202, 8 bytes
326 DMI type 202, 9 bytes
16 DMI type 202, 10 bytes 0x0A
208 DMI type 202, 13 bytes 0x0D
456 DMI type 202, 26 bytes 0x1A
256 DMI type 202, 27 bytes 0x1B
580 DMI type 202, 28 bytes 0x1C
Added length checks for 0x19 and 0x1A.
change length check from 0x0B to 0x0D.
the 8 byte records are pre Gen 9 which we don't decode.
>
> BTW, I also see type 202 records of length 13 (=0x0D, DL380/DL560/DL580
> Gen9), which is not tested either. It turns out that all my samples
> have the last 3 bytes set to 0, so adding the length check would not add
> anything to the output anyway in my case. I'll leave it to you whether
> this length check should be added, depending on whether you know of
> Gen9 systems where the UEFI Device Name or Device Name strings are set.
>
> Funny thing is that you test for length 11 (0x0B) and 14 (0x0E) while I
> don't have a type 202 record of these sizes in any of my samples. But my
> collection is far from complete so maybe such cases do exist.
>
> Thanks,
> --
> Jean Delvare
> SUSE L3 Support
--
-----------------------------------------------------------------------------
Jerry Hoemann Software Engineer Hewlett Packard Enterprise
-----------------------------------------------------------------------------
