Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Manually garded targets incorrectly being resource recovered
Garded targets were not always setting GARD_APPLIED bit in ATTR_HWAS_STATE_CHANGED which was causing ATTR_BLOCK_SPEC_DECONFIG to always be set after a resource recovery. To recreate failure: 1) gard a critical target (gard --md 0x50000) 2) IPL 3) verify resource recoverd (gard --gc fabric) 4) verify ATTR_BLOCK_SPEC_DECONFIG set to 1 (hwsvCmd -y) 5) power down 6) clear previous gard (gard --clr all) 7) gard all XBUSes (gard --md 0xE0000 .. gard --md 0xE0005) 8) IPL 9) verify XBUSes were incorrectly resource recovered (gard --gc fabric) This SPEC_DECONFIG code was added in fips920. We don't believe the fix needs to go back because it requires a double failure and manual garding. The first failure must be a gard of a critical resource, which forces a reconfig. In the field, the failed parts would be replaced and rely on a different bit (RESRC_RECOV) and code path. Also, if this isn't fixed the targets will just be garded again later. This also only applies to Predictive garded parts. Change-Id: I183b74ef200a5034e5dba20c0f64ad8f75763167 CQ:SW454599 Reviewed-on: http://rchgit01.rchland.ibm.com/gerrit1/71929 Tested-by: Jenkins Server <pfd-jenkins+hostboot@us.ibm.com> Tested-by: Jenkins OP Build CI <op-jenkins+hostboot@us.ibm.com> Tested-by: FSP CI Jenkins <fsp-CI-jenkins+hostboot@us.ibm.com> Reviewed-by: Roland Veloz <rveloz@us.ibm.com> Reviewed-by: Christian R. Geddes <crgeddes@us.ibm.com> Reviewed-by: Daniel M. Crowell <dcrowell@us.ibm.com>
- Loading branch information