diff options
author | Mike Jones <mjjones@us.ibm.com> | 2012-05-21 13:15:12 -0500 |
---|---|---|
committer | A. Patrick Williams III <iawillia@us.ibm.com> | 2012-05-24 09:54:45 -0500 |
commit | 8f79484e208c90f4b52d452378550277b09c0599 (patch) | |
tree | 46921fd59d35262a8ca59117533b46d3e622392c /src/usr/targeting/test | |
parent | 1257ee668b165ce17a07f94c5d5deb8d361bd010 (diff) | |
download | talos-hostboot-8f79484e208c90f4b52d452378550277b09c0599.tar.gz talos-hostboot-8f79484e208c90f4b52d452378550277b09c0599.zip |
Decode HWP errors in error log FFDC data properly
HWP errors are detailed in error XML files. The fapiParseAttributeInfo.pl
script parses these XML files and creates an enumeration of rc-values. When a
HWP generates an error, the corresponding rc-value is set in the
fapi::ReturnCode. When Hostboot sees a ReturnCode containing a HWP error, it
creates an error log and adds the rc-value as user-detail-data. The
fapiPlatCreateHwpRcDecoder.pl script generates a user-detail-data parser that
outputs the error description from the error XML files. All well and good.
In the old code, the rc_value enumeration used to be 0, 1, 2, etc. But this
was changed to be a hash-code (for Cronus - so that a particular rc-value
sticks with a particular error across builds), but I forgot to change the
fapiPlatCreateHwpRcDecoder.pl script to use the same hash code algorithm as
fapiParseAttributeInfo.pl, it still thinks that the enumerators are 0, 1, 2.
Therefore, when user-detail-data parsing eventually works, HWP errors will
not be decoded. This fixes the problem
Change-Id: I700973a8dfa8dad43f3b1f66ace7f3e9a010ec68
Reviewed-on: http://gfw160.austin.ibm.com:8080/gerrit/1090
Tested-by: Jenkins Server
Reviewed-by: Van H. Lee <vanlee@us.ibm.com>
Reviewed-by: CAMVAN T. NGUYEN <ctnguyen@us.ibm.com>
Reviewed-by: A. Patrick Williams III <iawillia@us.ibm.com>
Diffstat (limited to 'src/usr/targeting/test')
0 files changed, 0 insertions, 0 deletions