freeipmi-devel
[Top][All Lists]
Advanced

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

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


From: Al Chu
Subject: [Freeipmi-devel] Re: Patch for Fujitsu OEM Sensor Types and SEL decoding
Date: Mon, 30 Aug 2010 07:51:06 -0700

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




reply via email to

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