From: Jan Safranek <jsafrane@redhat.com>
'ipmitool dellem powermonitor' command should convert data from
network-format to the native one, otherwise it shows garbage on ppc/ppc64
platform.
Board Mfg Date. This date is computed by taking the timestamp in the FRU,
which is based off of 1/1/1996 0:0:0 and adding the delta time from
1/1/1970 0:0:0 to 1/1/1996 0:0:0 so that it can be interpreted by Linux time.
This delta time is a hard-coded constant in ipmi_fru.h (secs_from_1970_1996).
This constant is incorrect. The correct delta from those two dates should be
820454400. This is resulting in a Board Mfg Date that is actually 1 hour
earlier than what it should be.
commited for Renzo Hayashi
* validate user input in 'lib/ipmi_sunoem.c', resp. ipmi_sunoem_main()
* 'sunoem sshkey' would accept undefined actions and exit with RC = 0
* RC > 0 and help will be displayed for unknown commands/actions
* "code bumming" - some conditions seemed to be redundant
commited for Duncan Idaho
1] fail when no curses or readline is found, yet
ipmishell is about to be compiled in. ipmishell depends on these two
libraries;
2] add 'ipmishell' line to the % ./configure ; summary output to tell user
whether ipmishell support is enabled or disabled.
Committed for Duncan Idaho
doesn't matter whether printf() outputs at same output as LOG_NOTICE does.
Such
things should be the same for all modules.
Moves argc/help check up in the code, resp. in ipmi_picmg_main(), to
avoid unnecessary query to IPMI dev. It doesn't make sense to query IPMI
device
only to print help and terminate immediately.
Comitted for Duncan Idano
Password is limited to 16 bytes, resp. 20 bytes, for LAN, resp. LAN+,
interface. User name is limited to 16 bytes, no interface limitations.
Reference: SF.net ID#3184687, ID#3001519
Changes done by Duncan Idaho
* return value != 0 when no or not enough params given
* replaces strtol() calls with str2uchar() ones
* invalid input checking and error messages for such events
* ipmi_lanp_main() got slight work-over
Changes return type from int to uint8 since returned value is being assigned
into uint8_t.
Changes return value from (-1) to 0, because of uint8_t. 0 is considered as an
invalid LAN channel anyway, so there is no reason for returning (-1).
Running an "ipmitool sensor list" command on a system where remote sensors are
not on channel 0 results in unexpected behavior. The SDR functions were fixed
in January of 2009 (lib/ipmi_sdr.c, rev 1.86) to use target I2C addresses and
LUNs for non-BMC-owned sensors. Sensors owned by satellite controllers on other
channels were read as if they were on channel 0.
I've fitted patch, posted alongside bug report, to CVS version.
