#40 Settable and shared sensor sdr - Xyratex's changes/contrib
Xyratex would like to contribute back to the project:
Xyratex's principal activity is manufacturing storage devices and as the distinction between server and storage platform has blurred we have
started providing an IPMI interface as an alternative to our main management interface SES (SCSI Enclosure Services). Our system uses a LAN attached BMC managing server type sensors with an IPMB satellite BMC providing accessibility to storage based sensors. The SDR repository is dynamically created by the BMC comprising of both systems device SDRs from the main BMC and satellite MC
We have used ipmitool as the basis for our supported IPMI client and provided the following functions
over and above what resided in CVS in 2011.
1. Support for shared sensors per SDR
- this is provided for discrete sensors in the IPMI specification (principally within byte 24
of the compact sdr).
- this allows us to supply 100s of similar sensors (e.g. for disk drives) with fewer number of
SDRs needing to be held in the repository to speed up the discovery process.
2. Support for the IPMI set sensor reading command (0x30)
- this is provided for discrete sensors to be set by an external client to change the system state
- this allows IPMI interface to not only monitor the system but also to some extent manage the system as well
3. Provision for LUN 1-3 sensors and HPM component access
- use of non zero LUNs to enable to have more sensors than the 256 sensor limit ipmosed per LUN
- increase the number of HPM firmware component limit from 8 to 32.
4. Extend the technique in fru print, to all FRU commands to search SDR repository for FRU location SDR,
in order to locate those FRUs on satellite controllers
5. Extend the framework to interpret OEM sensors and events
- required to handle shared sdr sensors and events
- required to interpret our extensions to standard IPMI sensors
- required to interpret "grouped bits in a discrete sensor" to convey a number such as speed code or ID
within a discrete sensor definition
Whilst we have endeavoured to maintain existing compatibility of ipmitool, without the physical hardware and
knowledge of alternative systems there may be issues which we will attempt to address in the forthcoming weeks.
Should there come to a position where we cannot achieve compatibility then we will aim to provide a solution
which will minimise the differences between our local branch to support our hardware and that which is available
on CVS.
I have taken the tip of CVS from Feb 28 2012 and produced a patch for submission to CVS with a
list of functional changes per file. I would appreciate if developers with alternative equipment can test
these patches on their systems and respond if the proposed changes impact their monitoring processes or just wish
to comment on the modifications.
Following this, how may these patches be applied to CVS?
The files impacted by the proposed changes are :-
ipmi_event.c
increase scope of event commands, supporet for shared SDR sensor
ipmi_sdr.h
ipmi_sdr.c
Shared sensor structure/functions, OEM event types, non zero sensor lun support
ipmievd.c
Shared sensor SDR support
ipmi_sel.h
ipmi_sel.c
Support of OEM and shared sensors
ipmi_sensor.h
ipmi_sensor.c
non zero lun support, set sensor reading, shared sensor sdr support
ipmi_fru.c
search for fru locator SDR for all FRU commands
ipmi_hpmfwupg.c
support for non zero lun
ipmi.h
Xyratex IANA
ipmi_strings.c
Xyratex IANA
ipmitool.1
Documentation changes - fru internaluse, sensor set, sel time set now.
Jon Bamber
Xyratex
Patch for sensor ehancements against CVS 2012/02/28
Fix to locating correct SDR with shared SDR functionality
Added patch to fix an issue with similar adjacent sdrs displaying the wrong sensor id name for sel elist functionality - to be used to modify ipmi_sdr in main patch
Ticket moved from /p/ipmitool/patches/49/
Ehm. So you take big chunk of stuff from header file and put it into .c file???? What for, may I ask???
I actually feel like the amount of work at posted patch will out-weight benefits.