RE: [Freeipmi-devel] Re: Fujitsu's iRMC S2 - support for "get SEL entry long text" within ipmi-oem

[Albert Chu]

Hey Holger,

(BTW, I'm splitting this thread into two, so the response to the other
part is in the new thread).
 
> I had intended to add this into ipmi-sel, but w/o a mobo to test on I
> > let it pass.  If you're game to test a patch for me, I'd be glad to
> > implement it into ipmi-sel.  I'm busy right now, so it may take some
> > time for me to get a patch together.
> 
> I can try to understand/dive into ipmi-sel and come up with something
> for review. This would definitely be the better place to implement
> this feature. 

If you can, that'd be great (LMK if you begin something, so I won't
start to work on it too).  Because this wouldn't be a straight OEM code
-> string conversion (you're instead calling another Fujitsu IPMI call),
there will be subtleties that I know I'm going to mess up on that you
may just know off the top of your head.

The key OEM extension support would be added into
libfreeipmi/src/sel-parse/.  If you take a look in there, you'll already
see a whole bunch of files for SEL OEM extension support for Dell,
Inventec, Quanta, etc.  I imagine a Fujitsu equivalent could just be
plugged right in.  Based on the Dan's e-mail:

----
System Firmware Progress | System Firmware Error ; Unspecified ; OEM
Event Data3 code = 5Fh
----

This would need a
"ipmi_sel_parse_output_fujitsu_event_data3_discrete_oem" equivalent
call, so that the event data 3 OEM code could be converted into a
string.

I imagine other situations that perhaps you'd also want to implement a 

ipmi_sel_parse_output_fujitsu_event_data2_event_data3()

equivalent function when event data 2 & 3 are OEM codes.

Note that when you're putting things into the functions I've listed, the
output from the ipmi-sel tool wouldn't be like Dan's patch.  Instead you
would see:

System Firmware Progress | System Firmware Error ; Unspecified ;
FUJITSU OEM OUTPUT

instead of

System Firmware Progress | FUJITSU OEM OUTPUT

Now

----
<snip>
OEM Reserved | Event Offset = 00h ; OEM Event Data2 code = 83h ; OEM
Event Data3 code = 4Dh
----

Is a different beast.  I imagine we'd want an output of:

OEM Reserved | FUJITSU OEM OUTPUT

instead of

OEM Reserved | EVENT STRING ; FUJITSU OEM OUTPUT

The situation of OEM event in data 1, 2, and 3 does not have a
"callback".  So we'd have to stick one in for that.

> > Short term, I think we can add this patch into ipmi-oem as an extra OEM
> > option for Fujitsu motherboards.
> > 
> > BTW, what mobo are you running this on, so I can document in the future.
> > 
> 
> This feature/OEM command is available on all current BMC's from
> Fujitsu, even on the previous generation. The intention is to provide
> a consistent SEL translation and severity assignment across different
> tools.

That's definitely a good thing.  Unfortunately, not all vendors are that
consistent.  So internally I've added motherboard product IDs as I can
verify the OEM support works for a particular product ID.  In
manpages/documents I list the specific motherboards I've testd on. But
since you work with Fujitsu, if you can verify a range of Fujitsu
products, we can support/document that range.

Al

> This also works for time stamped OEM SEL entries which we use for a
> limited auditing (e.g. login or power control from IP a.b.c.d). 
> Unfortunately due to memory constrains in the previous BMC generation
> the maximum length of a single response is limited to 64bytes, while
> on the current product line you should be able to get the full
> 100bytes translated SEL text with a single request at least over LAN.
> Maximum (non standard) KCS transfer size is also different between
> current (255) and previous (64) generation, so the code should compare
> the data received with the total length reported in the response. 
> 
> If you want to double check for support of this OEM command beforehand, you 
> can evaluate the Get Device Id response:
> Vendor ID: 0x2880
> ProductId: should be >= 0x0200

On Tue, 2010-08-17 at 08:14 -0700, Liebig, Holger wrote:
> > 
> > Hi Dan,
> > 
> > > In the fact, it would be better to use the function as part of
> > > interpret-oem-data within ipmi-sel, but it require better knowledge of
> > > current implementation of ipmi-sel than I have. Someone with better
> > > skills may implement it (using the code from patch). Then I can help
> > > with testing, if necessary.
> > 
> > I had intended to add this into ipmi-sel, but w/o a mobo to test on I
> > let it pass.  If you're game to test a patch for me, I'd be glad to
> > implement it into ipmi-sel.  I'm busy right now, so it may take some
> > time for me to get a patch together.
> 
> I can try to understand/dive into ipmi-sel and come up with something for 
> review. This would definitely be the better place to implement this feature. 
> But first I have to find an issue with the SDR cache: Al any idea why Get SDR 
> might try to read only 5 Bytes from Offset 0 instead of the previous 16bytes 
> when reading the last record 1770 (see attached debug output)?
> 
> > 
> > Short term, I think we can add this patch into ipmi-oem as an extra OEM
> > option for Fujitsu motherboards.
> > 
> > BTW, what mobo are you running this on, so I can document in the future.
> > 
> 
> This feature/OEM command is available on all current BMC's from Fujitsu, even 
> on the previous generation. The intention is to provide a consistent SEL 
> translation and severity assignment across different tools. This also works 
> for time stamped OEM SEL entries which we use for a limited auditing (e.g. 
> login or power control from IP a.b.c.d). 
> Unfortunately due to memory constrains in the previous BMC generation the 
> maximum length of a single response is limited to 64bytes, while on the 
> current product line you should be able to get the full 100bytes translated 
> SEL text with a single request at least over LAN. Maximum (non standard) KCS 
> transfer size is also different between current (255) and previous (64) 
> generation, so the code should compare the data received with the total 
> length reported in the response. 
> 
> If you want to double check for support of this OEM command beforehand, you 
> can evaluate the Get Device Id response:
> Vendor ID: 0x2880
> ProductId: should be >= 0x0200
> 
> Holger
> 
-- 
Albert Chu
address@hidden
Computer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory