Re: [Freeipmi-devel] Re: Patch for Fujitsu OEM Sensor Types and SEL decoding

[Albert Chu]

Hey Holger,

I finally got to this patch.  I've created a branch for this:

svn co svn://svn.sv.gnu.org/freeipmi/branches/fujitsu-0-8-0

I had to re-work a few things for consistency to the other code
(subtleties I'm sure you just missed, no biggie).

Not counting the code cleanup, I did alter how you reported the Fujitsu
OEM stuff in the SEL for system event records.  From what I can tell,
this is what your code would do:

normal output

"OEM Event X ; OEM Data2 = X ; OEM Data3 = X"

your original output

"Fujitsu Long String from OEM cmd ; OEM Data2 = X ; OEM Data3 = X"

because there is no Fujitsu calls for the OEM data2 & data3.

So I altered it in two ways.

A) rather than call get-long-text for every event, fall through to only
retrieve the appropriate Fujitsu event message from the many Fujitsu
string tables you provided (e.g. ipmi_sensor_type_oem_fujitsu_i2c_bus).

B) instead, whenever event event-data2 and event-data3 are OEM specific,
call get-long-text.

So my changed output would hopefully be like this:

"Fujitsu Event String From Array ; Fujitsu Long String from OEM cmd"

In the current code committed, I've left a few comments of "Holger: XXX"
b/c there are likely Fujitsu OEM-isms that I'm unaware of and thus the
code is incorrect.  Some of the things I'm unsure about:

1) For the OEM sensor types you've reported, are they for
event-reading-type-code 0x6F only?  Or are OEM event-reading-types in
play (or only possible)?  If so, some adjustments will need to be made.

2) Could OEM extensions occur for event data2 or data3 but not both?
Currently, no Fujitsu OEM call is made for those circumstances.

Also, for what I believe will be cleaner output, I've removed the
severity string output under some circumstances.  It doesn't seem to fit
correctly into the output.  For those who want the severity output for
each event, I'm thinking of implementing a new option, something like
--output-oem-event-string.  When the user specifies this option, it will
always output the the Get-long-string, no matter what.  I know a few
other manufacturers who have similar "get SEL event string" like IPMI
OEM commands, so it would be good for future expansion too.

There's probably a lot above to grok, take your time and get back to me
whenever you can.

Thanks,

Al

P.S.  I'll have to forward port this branch into the head trunk
afterwards, but we'll deal with that later on.  Shouldn't be too
difficult, but there may be 1 or 2 things you'd like to add to take
advantage of newer features in the head branch.

On Mon, 2010-08-30 at 07:51 -0700, Al Chu wrote:
> Hey Holger,
> 
> Thanks for the patch.  Just skimming it casually, it looks good.  1 or 2
> nits here and there and I'm sure I'll notice 1 or 2 things on closer
> inspection.  On this particular comment:
> 
> +/*
> + * HLiebig: TODO:
> + * This should take a sensor_type & event_reading_code combination
> + * It is currently called for sensor specific (0x6F) only.
> + */
>  int
>  ipmi_get_oem_sensor_type_message (uint32_t manufacturer_id,
>                                    uint16_t product_id,
> 
> I think I know the problem you're describing.  Up until now, all OEM
> messages were "generic" (e.g. event reading type code => a string
> mapping) or "specific" (e.g. event reading type code == 0x6F &
> sensor_type is OEM).  So it was just like the IPMI spec.
> 
> However, I just hit an intel motherboard where every OEM event reading
> type code and sensor type together match some specific string mapping.
> So I created a new ipmi_get_oem_specific_message() (that's the current
> name atleast) where you pass in an event-reading-type-code and
> sensor-type. Is this the type of function you needed?  I can't quite
> tell in the code, b/c you may have programmed around the lack of that
> function.
> 
> If you do need that function, how about I finish my intel motherboard
> patch and then we can iterate a bit.
> 
> Al
> 
> On Fri, 2010-08-27 at 04:35 -0700, Liebig, Holger wrote:
> > Hi all,
> > The attached patch against freeipmi-0.8.9 adds Fujitsu iRMC S1 / iRMC S2 
> > OEM specific Sensor type decoding to ipmi-sensors and integrates the 
> > Fujitsu OEM command 'Get SEL Entry Long Text' into ipmi-sel. The use of 
> > this OEM IPMI command has been reviewed and slightly adapted to older iRMC 
> > S1 systems in ipmi-oem (partial read and smaller text). The OEM decoding is 
> > activated with --interpret-oem-data. There is still room for improvement, 
> > but it's a starting point.
> > 
> > Some notes regarding ipmi-sel:
> > The OEM command currently hooks into the OEM Record and event (%e) decoding 
> > only. If the command is successful completed, further event decoding should 
> > not really be required, but is currently executed by the generic decoding 
> > routines from freeipmi. As a result, some information might be redundant in 
> > the final output for threshold based sensors (e.g trigger).
> > 
> > Reading of the SEL normally does not require any elevated privilege, but 
> > the used OEM IPMI command requires Admin privilege, so a hint is added to 
> > the output. Dependend from the command line arguments you will get the 
> > following outputs:
> > 
> > No additional arguments:
> > 20   | Aug-27-2010 | 05:00:16 | Manufacturer ID = Fujitsu Siemens Computers 
> > (2880h) | OEM defined = 10h 02h C0h A8h 33h 6Ah
> > 
> > --interpret-oem-data
> > 20   | Aug-27-2010 | 05:00:16 | Manufacturer ID = Fujitsu Siemens Computers 
> > (2880h) | (admin privilege required for full OEM decoding) OEM defined = 
> > 10h 02h C0h A8h 33h 6Ah  
> > 
> > --interpret-oem-data -l admin
> > 20   | Aug-27-2010 | 05:00:16 | Manufacturer ID = Fujitsu Siemens Computers 
> > (2880h) | INFORMATIONAL: iRMC Browser user 'admin' AVR Session started from 
> > 192.168.51.106
> > 
> > 
> > And for ipmi-sensors:
> > No additional arguments
> > 2000 | DIMM-1A          | OEM Reserved            | N/A        | N/A   | 
> > 'Unrecognized State'
> > 
> > --interpret-oem-data
> > 2000 | DIMM-1A          | OEM Memory Status       | N/A        | N/A   | 
> > 'OK'
> > 
> > Holger
> > 
-- 
Albert Chu
address@hidden
Computer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory