Troubleshooting the dmidecode check

The dmidecode check uses the dmidecode utility to retrieve system information from the SMBIOS tables and checks for consistency across the cluster. Each subtest examines a particular SMBIOS field. If any of the fields differ across the cluster nodes, then the subtest reports a failing result. There are many fields that are compared by the dmidecode check. Here are some examples of how the check reports differences found between nodes.

subtest 'BIOS Information (0x0000): Release Date' failed
- failing hosts compute-00-00 - compute-00-05, compute-00-07 returned: '03/09/2009'
- failing host compute-00-06 returned: '03/12/2009'

In this example, above, the BIOS release date is reported to be different on one of the compute nodes. This implies the BIOS versions are not the same in all the compute nodes.  Note that the dmidecode check does not assume that either of the BIOS release dates is correct, only that the field is not consistent across the cluster.

subtest 'Base Board Information (0x0200): Product Name' failed
- failing hosts compute-00-00 - compute-00-02, compute-00-07 returned: '0AJ123A'
- failing hosts compute-00-03 - compute-00-06 returned: '0AK456A'

The second example indicates that there are two types of motherboards used in the cluster.  This can result from the compute nodes using differing model motherboards or simply different generations of the same motherboard.

subtest 'Memory Device (0x1100): Asset Tag' failed
- failing hosts compute-00-00, compute-00-02 - compute-00-06 returned: '0108001D'
- failing hosts compute-00-01, compute-00-07 returned: '01082803'

The output from the third example shows varying results about the memory used in the nodes. Two of the nodes have a different memory configuration than the rest of the cluster. Using a mix of memory sizes, performance characteristics, etc. can adversely and unexpectedly impact overall cluster performance.

Issues reported by the dmidecode check do not necessarily mean a cluster will exhibit any issues or failures; however, consistency across cluster nodes is highly desirable.  If there are legitimate or desired differences between compute nodes, the Intel® Cluster Checker group capability and/or individual subtest exclusions can be configured to instruct the dmidecode check to ignore specific differences between nodes.

Specifying a group in the dmidecode configuration restricts the consistency check to defined subsets of nodes, and only differences between nodes within a group are reported as issues. For instance, the following configuration option causes the dmidecode check to compare all nodes defined in the mthrbd2 group to each other, but a node in the mthrbrd2 group would not be compared to a node that is not in this group.

  <group name=”mthrbd2”/>

For more information on the groups capability, see this article and the Intel® Cluster Checker User's Guide.

The other way to instruct the dmidecode check to ignore specific differences between nodes is to use the exclude configuration option.  This option ignores a specific field for all nodes but still checks all the remaining fields for consistency across the whole cluster.

  <exclude>Memory Device (0x1100): Asset Tag</exclude>

For more information on the exclude option, see the dmidecode section of the Intel® Cluster Checker Module Reference.

Einzelheiten zur Compiler-Optimierung finden Sie in unserem Optimierungshinweis.