dmidecode-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [dmidecode] [PATCH v4] update dmidecode to parse Modern Management C


From: Neil Horman
Subject: Re: [dmidecode] [PATCH v4] update dmidecode to parse Modern Management Controller blocks
Date: Mon, 10 Sep 2018 14:37:34 -0400
User-agent: Mutt/1.10.1 (2018-07-13)

On Mon, Sep 10, 2018 at 05:01:37PM +0200, Jean Delvare wrote:
> Hi Neil,
> 
> On Fri, 7 Sep 2018 13:59:46 -0400, Neil Horman wrote:
> > I'll have an updated patch to you shortly.  To answer your question above, 
> > yes,
> > and no.  The system I'm currently testing on (A lenovo, for which I 
> > provided you
> > the SMBIOS dump), is in production now, but has a back level firmware.  
> > They are
> > expected to have an updated firmware that reports the correct SMBIOS level 
> > of
> > 3.0.2, and corrects the errors we've found in their type 42 structure 
> > shortly.
> > On that system the only critical problems I've found are:
> > 
> > 1) The fact that it reports SMBIOS version 3.0.0 rather than 3.0.2
> 
> You mean 3.2.0.
> 
Yes, sorry

> > 2) The fact that its protcol record count is at offset 0x7 rather than 0x6.
> > 
> > 3) The protcol count field is incorrect (reports 0x9c rather than 0x1)
> 
> My interpretation of the breakage is different. I think that the main
> bug in the current Lenovo implementation is that the byte 0x9c is
> extraneous and should not be there. It would make sense as "length of
> all protocol records", but the specification does not mention such a
> byte (nor is it needed). If you remove that byte from the stream, the
> structure is decoded properly, as far as I can see. There's only a
Thats possible, certainly.  I've reported the issue to Lenovo, and they are
working on updating the firmware.  They should report back to me shortly what
their analysis of the situation is.

> minor issue with the USB serial number, but we are no longer attempting
> to decode it so it doesn't really matter.
> 
Agreed, I don't see any need to report that information, as it doesn't help me
identify the BMC network interface anyway (sysfs doesn't report the serial
number either).

> > If I modify the dmidecode tool to adjust for items 1 and 2, this patch 
> > properly
> > reports all information up to an including the first protocol record, after
> > which it returns, as the second protocol record exceeds the overall length 
> > of
> > the structure.
> 
> Not sure if we are talking about the same DMI table then. In the one
> you sent to me, there's only one protocol record (with extra 0x00s at
> the end).
> 
I think we are. I agree there is only one protocol record.  The question is how
to interpret the garbage around it.  I assumed that the protocol count was a
byte farther on than it should have been (the offset of 0x7+n instead of 0x6+n),
and that worked, but reported the protocol record count as 0x9c rather than the
expected 0x1.  The first record decoded properly, and then other records were
all zero.  You are suggesting that the 0x9c value is just an exraneous extra
byte in the stream (which I'm perfectly willing to believe).  either way, moving
the byte stream cursor up by a byte, or dropping that byte from the stream
should result in a very simmilar decode pattern.  And the responsible party for
the fix is the same either way: lenovo has to update their firmware.

> Anyway, I'd rather modify the tables with an hexadecimal editor to make
> them compliant, than modify dmidecode to properly parse broken tables.
> In the latter case, you don't really prove how the unmodified dmidecode
> would behave with sane tables.
> 
> I have modified the DMI table you sent to me, to make it compliant.
> I'll share it with you in private.
> 
Ok, thank you.

> > So I'm reasonably confident the patch is very close to correct, given that 
> > its
> > allowed us to identify errors in vendors SMBIOS layout.
> 
> Properly detecting and dealing with invalid formats is certainly nice.
> 
> > While I don't have them yet, I am expecting both an updated firmware for my
> > current system which will fix items (1) (2) and (3) above, as well as a 
> > system
> > from another vendor that hopefully will have a more robust bmc that allows 
> > me to
> > configure other types of network configurations (ipv vs v4 and dhcp 
> > addressing
> > vs static, etc).  I hope to have those in hand in the next few weeks.
> 
> I would appreciate if you share with me whatever you are allowed to
> share with me.
> 
I'll be happy to share them with you as soon as I have them in hand.  We're
expecting rough weather down here this week, so things might get interrupted,
but I'll get you an update on delivery status as soon as possible

> I'll review v5 of your patch later today.
> 
Thanks!
Neil

> -- 
> Jean Delvare
> SUSE L3 Support
> 



reply via email to

[Prev in Thread] Current Thread [Next in Thread]