Its good to see that there is increased activity in the maintenance of
ipmitool and our company
Xyratex would like to contribute back to the project as well. 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 (Patches item #3497103) 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?
May I be granted access to update the source tree or can one of the
maintainers apply these changes?
As has been mentioned before in the forum the snapshot release of 1.8.11
is very old and ought to be updated.
You may wish to consider whether this is done prior or following these
check ins. Also I would have thought
the version string in CVS ought to differentiate itself from the
snapshot build so that users can differentiate
between a snapshot and tip of CVS builds.
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
______________________________________________________________________
This email may contain privileged or confidential information, which should
only be used for the purpose for which it was sent by Xyratex. No further
rights or licenses are granted to use such information. If you are not the
intended recipient of this message, please notify the sender by return and
delete it. You may not use, copy, disclose or rely on the information contained
in it.
Internet email is susceptible to data corruption, interception and unauthorised
amendment for which Xyratex does not accept liability. While we have taken
reasonable precautions to ensure that this email is free of viruses, Xyratex
does not accept liability for the presence of any computer viruses in this
email, nor for any losses caused as a result of viruses.
Xyratex Technology Limited (03134912), Registered in England & Wales,
Registered Office, Langstone Road, Havant, Hampshire, PO9 1SA.
The Xyratex group of companies also includes, Xyratex Ltd, registered in
Bermuda, Xyratex International Inc, registered in California, Xyratex
(Malaysia) Sdn Bhd registered in Malaysia, Xyratex Technology (Wuxi) Co Ltd
registered in The People's Republic of China and Xyratex Japan Limited
registered in Japan.
______________________________________________________________________
------------------------------------------------------------------------------
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
_______________________________________________
Ipmitool-devel mailing list
Ipmitool-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ipmitool-devel
