diff options
| author | William A. Kennington III <wak@google.com> | 2018-05-23 12:35:08 -0700 |
|---|---|---|
| committer | William G. Hoffa <wghoffa@us.ibm.com> | 2018-05-30 09:43:48 -0400 |
| commit | 0aff9f48c7ea871d49c6966c1fa6a71ba4849558 (patch) | |
| tree | 3c430ce677c93a7b1ac28eb8edc391781ceb73e0 /src/usr/secureboot/common | |
| parent | 9bace77a615d1066b1dba8da0987c9da612a1436 (diff) | |
| download | talos-hostboot-0aff9f48c7ea871d49c6966c1fa6a71ba4849558.tar.gz talos-hostboot-0aff9f48c7ea871d49c6966c1fa6a71ba4849558.zip | |
ipmiwatchdog: Limit the number of resets
We send resets after the completion of every istep and in the middle of
some of our known long isteps. In some instances during boot, during
fast isteps or custom routines, we can send 10 or more resets within the
same second. This generates a lot of IPMI traffic and causes the BMC to
spend more time processing resets than is needed. Since our timeout is
relatively long (120s right now), it should be no issue to limit the
number of resets to one reset every 1-2 seconds
I've tested this on a zaius machine and it reduced load on the BMC and
made clean boots a little faster.
Resolves #140
Signed-off-by: William A. Kennington III <wak@google.com>
Change-Id: I60d26af082e1ddb29624fc22a0513b47526978d5
Reviewed-on: http://ralgit01.raleigh.ibm.com/gerrit1/59291
Tested-by: Jenkins Server <pfd-jenkins+hostboot@us.ibm.com>
Tested-by: FSP CI Jenkins <fsp-CI-jenkins+hostboot@us.ibm.com>
Reviewed-by: Daniel M. Crowell <dcrowell@us.ibm.com>
Tested-by: Jenkins OP Build CI <op-jenkins+hostboot@us.ibm.com>
Tested-by: Jenkins OP HW <op-hw-jenkins+hostboot@us.ibm.com>
Reviewed-by: William G. Hoffa <wghoffa@us.ibm.com>
Diffstat (limited to 'src/usr/secureboot/common')
0 files changed, 0 insertions, 0 deletions
