Searched hist:e5f7508b (Results 1 – 5 of 5) sorted by relevance
| /openbmc/phosphor-logging/extensions/openpower-pels/ |
| H A D | host_interface.hpp | e5f7508b Mon Jan 24 16:09:51 CST 2022 Matt Spinler <spinler@us.ibm.com> PEL: Wait a bit after host up before sending PELs
Wait a minute after the host state switches to running before sending
any PELs to the host. This applies both on a normal boot and also when
the BMC is rebooted when the host is already up.
This is being done for 2 reasons:
1) Give some relief to the PLDM traffic and CPU load that occurs after a
BMC reboot when the host is already up, because the host will also be
exchanging PLDM PDRs with the BMC then and pretty much every
application is also starting up at the time as well.
2) A lot of times on a normal boot the host notifier code ends up having
to do a few retries when it first starts sending the PELs because the
first few commands fail, possibly because the code on the receiving
end isn't quite ready yet.
I arrived at that amount of time by deciding 30 seconds was reasonable,
and then doubling it just to be sure. During testing of the reboots the
minute timeout gave plenty of time for the BMC to get back to BMC ready.
Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I0929a4acdda0a9fe8fbdcd624c5821a642ad83a6
|
| H A D | host_notifier.hpp | e5f7508b Mon Jan 24 16:09:51 CST 2022 Matt Spinler <spinler@us.ibm.com> PEL: Wait a bit after host up before sending PELs
Wait a minute after the host state switches to running before sending
any PELs to the host. This applies both on a normal boot and also when
the BMC is rebooted when the host is already up.
This is being done for 2 reasons:
1) Give some relief to the PLDM traffic and CPU load that occurs after a
BMC reboot when the host is already up, because the host will also be
exchanging PLDM PDRs with the BMC then and pretty much every
application is also starting up at the time as well.
2) A lot of times on a normal boot the host notifier code ends up having
to do a few retries when it first starts sending the PELs because the
first few commands fail, possibly because the code on the receiving
end isn't quite ready yet.
I arrived at that amount of time by deciding 30 seconds was reasonable,
and then doubling it just to be sure. During testing of the reboots the
minute timeout gave plenty of time for the BMC to get back to BMC ready.
Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I0929a4acdda0a9fe8fbdcd624c5821a642ad83a6
|
| H A D | host_notifier.cpp | e5f7508b Mon Jan 24 16:09:51 CST 2022 Matt Spinler <spinler@us.ibm.com> PEL: Wait a bit after host up before sending PELs
Wait a minute after the host state switches to running before sending
any PELs to the host. This applies both on a normal boot and also when
the BMC is rebooted when the host is already up.
This is being done for 2 reasons:
1) Give some relief to the PLDM traffic and CPU load that occurs after a
BMC reboot when the host is already up, because the host will also be
exchanging PLDM PDRs with the BMC then and pretty much every
application is also starting up at the time as well.
2) A lot of times on a normal boot the host notifier code ends up having
to do a few retries when it first starts sending the PELs because the
first few commands fail, possibly because the code on the receiving
end isn't quite ready yet.
I arrived at that amount of time by deciding 30 seconds was reasonable,
and then doubling it just to be sure. During testing of the reboots the
minute timeout gave plenty of time for the BMC to get back to BMC ready.
Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I0929a4acdda0a9fe8fbdcd624c5821a642ad83a6
|
| /openbmc/phosphor-logging/test/openpower-pels/ |
| H A D | host_notifier_test.cpp | e5f7508b Mon Jan 24 16:09:51 CST 2022 Matt Spinler <spinler@us.ibm.com> PEL: Wait a bit after host up before sending PELs
Wait a minute after the host state switches to running before sending
any PELs to the host. This applies both on a normal boot and also when
the BMC is rebooted when the host is already up.
This is being done for 2 reasons:
1) Give some relief to the PLDM traffic and CPU load that occurs after a
BMC reboot when the host is already up, because the host will also be
exchanging PLDM PDRs with the BMC then and pretty much every
application is also starting up at the time as well.
2) A lot of times on a normal boot the host notifier code ends up having
to do a few retries when it first starts sending the PELs because the
first few commands fail, possibly because the code on the receiving
end isn't quite ready yet.
I arrived at that amount of time by deciding 30 seconds was reasonable,
and then doubling it just to be sure. During testing of the reboots the
minute timeout gave plenty of time for the BMC to get back to BMC ready.
Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I0929a4acdda0a9fe8fbdcd624c5821a642ad83a6
|
| H A D | mocks.hpp | e5f7508b Mon Jan 24 16:09:51 CST 2022 Matt Spinler <spinler@us.ibm.com> PEL: Wait a bit after host up before sending PELs
Wait a minute after the host state switches to running before sending
any PELs to the host. This applies both on a normal boot and also when
the BMC is rebooted when the host is already up.
This is being done for 2 reasons:
1) Give some relief to the PLDM traffic and CPU load that occurs after a
BMC reboot when the host is already up, because the host will also be
exchanging PLDM PDRs with the BMC then and pretty much every
application is also starting up at the time as well.
2) A lot of times on a normal boot the host notifier code ends up having
to do a few retries when it first starts sending the PELs because the
first few commands fail, possibly because the code on the receiving
end isn't quite ready yet.
I arrived at that amount of time by deciding 30 seconds was reasonable,
and then doubling it just to be sure. During testing of the reboots the
minute timeout gave plenty of time for the BMC to get back to BMC ready.
Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I0929a4acdda0a9fe8fbdcd624c5821a642ad83a6
|