summaryrefslogtreecommitdiffstats
path: root/src/usr/ipmibase
diff options
context:
space:
mode:
authorBill Hoffa <wghoffa@us.ibm.com>2019-04-01 15:32:52 -0500
committerDaniel M. Crowell <dcrowell@us.ibm.com>2019-04-08 13:06:17 -0500
commitecf2201cee8cdd3e6eca7d56897fbdf108e59bf5 (patch)
tree77d19a13d5b17a634d98c09abcf7d6b38cd0db9e /src/usr/ipmibase
parent1dc4c34f591ff7a2295e73a4355eb918e37a0b3e (diff)
downloadtalos-hostboot-ecf2201cee8cdd3e6eca7d56897fbdf108e59bf5.tar.gz
talos-hostboot-ecf2201cee8cdd3e6eca7d56897fbdf108e59bf5.zip
Modify IPMI Timeout Value
-- Currently the Timeout value for an IPMI message is assigned when the message is placed in the queue. The timeout value is the same whether we have 0 or 100 messages in the queue which leads to the occasional IPMI timeout when the BMC is sent a lot of messages in a short period of time. -- This fix is to implement the timeout as a per message timeout. I.E. if the message being put on the queue is the 3rd message on the queue it would get a timeout of 3x the timeout value. Change-Id: Ieb328d96144f2b1fe9dc39f57191e86cf4821c2c CQ: SW461931 Reviewed-on: http://rchgit01.rchland.ibm.com/gerrit1/75538 Tested-by: Jenkins Server <pfd-jenkins+hostboot@us.ibm.com> Tested-by: Jenkins OP Build CI <op-jenkins+hostboot@us.ibm.com> Reviewed-by: Ilya Smirnov <ismirno@us.ibm.com> Tested-by: FSP CI Jenkins <fsp-CI-jenkins+hostboot@us.ibm.com> Tested-by: Jenkins OP HW <op-hw-jenkins+hostboot@us.ibm.com> Reviewed-by: Christian R. Geddes <crgeddes@us.ibm.com> Reviewed-by: Daniel M. Crowell <dcrowell@us.ibm.com>
Diffstat (limited to 'src/usr/ipmibase')
-rw-r--r--src/usr/ipmibase/ipmirp.C12
1 files changed, 7 insertions, 5 deletions
diff --git a/src/usr/ipmibase/ipmirp.C b/src/usr/ipmibase/ipmirp.C
index 2def821bb..0bb785949 100644
--- a/src/usr/ipmibase/ipmirp.C
+++ b/src/usr/ipmibase/ipmirp.C
@@ -935,8 +935,12 @@ void IpmiRP::queueForResponse(IPMI::Message& i_msg)
mutex_lock(&iv_mutex);
// BMC request-to-response times are always seconds, 1 - 30.
- // And I don't think we care about roll over here.
- i_msg.iv_timeout.tv_sec += iv_bmc_timeout;
+ // And I don't think we care about roll over here. Enforce the
+ // timeout as a timeout per-message. Meaning if there are 2
+ // messages on the timeout queue, make the timeout of this message
+ // iv_bmc_timeout + iv_bmc_timeout*2
+ i_msg.iv_timeout.tv_sec +=
+ (iv_bmc_timeout + (iv_bmc_timeout*iv_timeoutq.size()) );
// Put this message on the response queue so we can find it later
// for a response and on the timeout queue so if it times out
@@ -944,9 +948,7 @@ void IpmiRP::queueForResponse(IPMI::Message& i_msg)
// timeout - mostly. Every message sent before the BMC tells us
// the timeout (at least one message) will have the shortest possible
// timeout. The BMC might lengthen the timeout, but can not shorten
- // it. All messages after that will have the same timeout. So the
- // timeout queue is "sorted."
-
+ // it.
iv_respondq[i_msg.iv_seq] = i_msg.iv_msg;
iv_timeoutq.push_back(i_msg.iv_msg);
OpenPOWER on IntegriCloud