Talos™ II skiboot sources https://git.raptorcs.com/git/talos-skiboot/atom?h=master 2017-10-11T05:45:34+00:00 2017-10-11T05:45:34+00:00 Stewart Smith stewart@linux.vnet.ibm.com 2017-10-02T01:08:25+00:00 urn:sha1:696d378d7b7295366e115e89a785640bf72a5043 We had a race condition between FSP Reset/Reload and powering down the system from the host: Roughly: FSP Host --- ---- Power on Power on (inject EPOW) (trigger FSP R/R) Processes EPOW event, starts shutting down calls OPAL_CEC_POWER_DOWN (is still in R/R) gets OPAL_INTERNAL_ERROR, spins in opal_poll_events (FSP comes back) spinning in opal_poll_events (thinks host is running) The call to OPAL_CEC_POWER_DOWN is only made once as the reset/reload error path for fsp_sync_msg() is to return -1, which means we give the OS OPAL_INTERNAL_ERROR, which is fine, except that our own API docs give us the opportunity to return OPAL_BUSY when trying again later may be successful, and we're ambiguous as to if you should retry on OPAL_INTERNAL_ERROR. For reference, the linux code looks like this: >static void __noreturn pnv_power_off(void) >{ > long rc = OPAL_BUSY; > > pnv_prepare_going_down(); > > while (rc == OPAL_BUSY || rc == OPAL_BUSY_EVENT) { > rc = opal_cec_power_down(0); > if (rc == OPAL_BUSY_EVENT) > opal_poll_events(NULL); > else > mdelay(10); > } > for (;;) > opal_poll_events(NULL); >} Which means that *practically* our only option is to return OPAL_BUSY or OPAL_BUSY_EVENT. We choose OPAL_BUSY_EVENT for FSP systems as we do want to ensure we're running pollers to communicate with the FSP and do the final bits of Reset/Reload handling before we power off the system. Additionally, we really should update our documentation to point all of these return codes and what action an OS should take. CC: stable Reported-by: Pridhiviraj Paidipeddi <ppaidipe@linux.vnet.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com> Reviewed-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com> Acked-by: Ananth N Mavinakayanahalli <ananth@linux.vnet.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com> 2016-08-02T08:12:48+00:00 Stewart Smith stewart@linux.vnet.ibm.com 2016-07-27T07:43:17+00:00 urn:sha1:24e7fd3aa79697c019f215e1dd1a270b1b014e89 Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com> 2016-08-02T08:12:48+00:00 Stewart Smith stewart@linux.vnet.ibm.com 2016-07-27T07:43:16+00:00 urn:sha1:925dff3660f9993e655ce45320ec294f8826f7cf Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>