support for FFDC-only isolation nodes in chip data

Signed-off-by: Zane Shelley <zshelle@us.ibm.com>
Change-Id: Ib457329d31a9f01eb6992e57b11d84c06a63e6e7
diff --git a/src/isolator/hei_isolation_node.cpp b/src/isolator/hei_isolation_node.cpp
index 6791d6f..5bcfff8 100644
--- a/src/isolator/hei_isolation_node.cpp
+++ b/src/isolator/hei_isolation_node.cpp
@@ -39,58 +39,66 @@
         }
     }
 
-    // A rule for i_attnType must exist.
+    // Get the rule for this attention type.
     auto rule_itr = iv_rules.find(i_attnType);
-    HEI_ASSERT(iv_rules.end() != rule_itr);
 
-    // Get the returned BitString for this rule.
-    const BitString* bs = rule_itr->second->getBitString(i_chip);
-
-    // Ensure this BitString is not longer than the maximum bit field.
-    HEI_ASSERT(bs->getBitLen() <= (1 << (sizeof(BitPosition_t) * 8)));
-
-    // Find all active bits for this rule.
-    for (BitPosition_t bit = 0; bit < bs->getBitLen(); bit++)
+    // It is possible that a rule does not exist. The likely scenario is that
+    // this node is intended to only gather FFDC for a specific bit in the
+    // parent node.
+    if (iv_rules.end() != rule_itr)
     {
-        // Continue to the next bit if not active.
-        if (!bs->isBitSet(bit))
-            continue;
+        // Get the returned BitString for this rule.
+        const BitString* bs = rule_itr->second->getBitString(i_chip);
 
-        // At least one active bit was found.
-        o_activeAttn = true;
+        // Ensure this BitString is not longer than the maximum bit field.
+        HEI_ASSERT(bs->getBitLen() <= (1 << (sizeof(BitPosition_t) * 8)));
 
-        // Determine if this attention originated from another register or if it
-        // is a leaf in the isolation tree.
-        auto child_itr = iv_children.find(bit);
-        if (iv_children.end() != child_itr)
+        // Find all active bits for this rule.
+        for (BitPosition_t bit = 0; bit < bs->getBitLen(); bit++)
         {
-            // This bit was driven from an attention from another register.
-            // Continue down the isolation tree to look for more attentions.
-            bool attnFound =
-                child_itr->second->analyze(i_chip, i_attnType, io_isoData);
-            if (!attnFound)
+            // Continue to the next bit if not active.
+            if (!bs->isBitSet(bit))
+                continue;
+
+            // At least one active bit was found.
+            o_activeAttn = true;
+
+            // Determine if this attention originated from another register or
+            // if it is a leaf in the isolation tree.
+            auto child_itr = iv_children.find(bit);
+            if (iv_children.end() != child_itr)
             {
-                // Something went wrong. There should have been an active
-                // attention. It's possible there is a bug in the Chip Data
-                // File. Or, it is also possible some other piece of code is
-                // clearing the attention before this code is able to analyze
-                // it. Another possibility is that the hardware it not behaving
-                // as expected. Since we really don't know what happened, we
-                // should not assert. Instead, add this bit's signature to
-                // io_isoData. If there are no other active attentions, the user
-                // application could use this signature to help determine, and
-                // circumvent, the isolation problem.
+                // This bit was driven from an attention from another register.
+                // Continue down the isolation tree to look for more attentions.
+                bool attnFound =
+                    child_itr->second->analyze(i_chip, i_attnType, io_isoData);
+                if (!attnFound)
+                {
+                    // It is possible the child node is only intended for FFDC.
+                    // See comment near the check for a valid rule above.
+                    // Otherwise, it is possible something went wrong. If there
+                    // should have been an active attention, it's possible there
+                    // is a bug in the Chip Data File. Or, it is also possible
+                    // some other piece of code is clearing the attention before
+                    // this code is able to analyze it. Another possibility is
+                    // that the hardware it not behaving as expected. Since we
+                    // really don't know what happened, we should not assert.
+                    // Instead, add this bit's signature to io_isoData. If there
+                    // are no other active attentions, the user application
+                    // could use this signature to help determine, and
+                    // circumvent, the isolation problem.
+                    io_isoData.addSignature(
+                        Signature{i_chip, iv_id, iv_instance, bit, i_attnType});
+                }
+            }
+            else
+            {
+                // We have reached a leaf in the isolation tree. Add this bit's
+                // signature to io_isoData.
                 io_isoData.addSignature(
                     Signature{i_chip, iv_id, iv_instance, bit, i_attnType});
             }
         }
-        else
-        {
-            // We have reached a leaf in the isolation tree. Add this bit's
-            // signature to io_isoData.
-            io_isoData.addSignature(
-                Signature{i_chip, iv_id, iv_instance, bit, i_attnType});
-        }
     }
 
     // Analysis is complete on this node. So remove it from cv_isolationStack.