Skip to content

Commit

Permalink
Use REL_POS of OMI and not OCMB for calculating hdat DIMM ID's
Browse files Browse the repository at this point in the history
There is a bug in the code where we are attempting to lookup the
REL_POS of an ocmb target while trying to generate the id hdat will
use to uniquely identify a given dimm target. OCMB targets do not
have the REL_POS attribute and if they did it would always be 0,
or it would match the associated DIMM's REL_POS (for single dimm
ocmbs at least). Instead we will use the OMI's REL_POS which should
work because OMI's are 1-1 with OCMB targets.

Change-Id: Ib22307c7f4c2d97a5368fd507fe7b4965135c76e
Reviewed-on: http://rchgit01.rchland.ibm.com/gerrit1/82120
Tested-by: Jenkins Server <pfd-jenkins+hostboot@us.ibm.com>
Reviewed-by: Jayashankar Padath <jayashankar.padath@in.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>
Tested-by: Jenkins OP HW <op-hw-jenkins+hostboot@us.ibm.com>
Reviewed-by: William G Hoffa <wghoffa@us.ibm.com>
Reviewed-by: Daniel M Crowell <dcrowell@us.ibm.com>
  • Loading branch information
crgeddes authored and dcrowell77 committed Aug 14, 2019
1 parent c98af33 commit 0f99620
Showing 1 changed file with 3 additions and 3 deletions.
6 changes: 3 additions & 3 deletions src/usr/hdat/hdatmsvpd.C
Expand Up @@ -2030,11 +2030,11 @@ errlHndl_t HdatMsVpd::hdatLoadMsData(uint32_t &o_size, uint32_t &o_count)

uint32_t l_dimmId = 0;
l_dimmId |=
1 << (31 - l_pOcmbTarget->getAttr
<TARGETING::ATTR_REL_POS>());
1 << (31 - l_pOmiTarget->getAttr
<TARGETING::ATTR_CHIP_UNIT>());
l_dimmId |=
1 << (31 - (l_pmemPortTarget->getAttr
<TARGETING::ATTR_REL_POS>()+16));
<TARGETING::ATTR_CHIP_UNIT>()+16));
l_dimmId |=
1 << (31 - (l_pDimmTarget->getAttr
<TARGETING::ATTR_REL_POS>()+20));
Expand Down

0 comments on commit 0f99620

Please sign in to comment.