[Top][All Lists]
[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