[HPE] FWTS test results

Tue Jun 22 04:53:45 UTC 2021

On Mon, Jun 21, 2021 at 9:53 PM Huang, Bryan <bryanhuang at hpe.com> wrote:

> Hi FWTS members,
>
>
>
> Here is TPE HPE Bryan Huang.
>
> We use fwts-live-21.05.00.img.xz and encounter the following FWTS issues,
> if you want to see detail information, attached is the test result.
>
> FWTS tool: https://fwts.ubuntu.com/fwts-live/
>
> Would you please help us to confirm the following information?
>
>
>
>
>
> acpitables: ACPI table headers sanity tests.
>
> Test ACPI spec versus table revisions.
>
> System supports ACPI 0610
>
> FAILED [MEDIUM]      ACPI Table SSDT revision was expected to be 2, got 1.
>
> FAILED [MEDIUM]      ACPI Table APIC revision was expected to be 4, got 3.
>
> FAILED [MEDIUM]      ACPI Table MSCT revision was expected to be 1, got 2.
>
> FAILED [MEDIUM]      ACPI Table PCCT revision was expected to be 1, got 2.
>
> FAILED [MEDIUM]      ACPI Table SSDT revision was expected to be 2, got 1.
>
>
>
>
>
> I tried to trace the acpi_table_check_test2 function of FWTS source code.
> Our units are use acpi_61_rev table as below. If ACPI Table XXXX revision
> is different, is it a BIOS issue?
>
>
>
> File location: src\acpi\acpitables\acpitables.c
>
> /* Supported ACPI tables (see Table 5-30 in ACPI spec)
>
> * Note: OEMx (N/A) and PSDT (deleted) aren't included.
>
> */
>
> static const fwts_acpi_table_rev acpi_61_rev[] = {
>
>       {"APIC", 4},
>
>       {"BERT", 1},
>
>       {"BGRT", 1},
>
>       {"CPEP", 1},
>
>       {"DSDT", 2},
>
>       {"ECDT", 1},
>
>       {"EINJ", 1},
>
>       {"ERST", 1},
>
>       {"FACP", 6},
>
>       {"FPDT", 1},
>
>       {"GTDT", 2},
>
>       {"HEST", 1},
>
>       {"MSCT", 1},
>
>       {"MPST", 1},
>
>       {"NFIT", 1},
>
>       {"PCCT", 1},
>
>       {"PMTT", 1},
>
>       {"RASF", 1},
>
>       {"RSDT", 1},
>
>       {"SBST", 1},
>
>       {"SLIT", 1},
>
>       {"SRAT", 3},
>
>       {"SSDT", 2},
>
>       {"XSDT", 1},
>
>       {NULL, 0xff}     // end of table
>
> };
>
>
>
>
>

This test was recently added and this is a conclusion of ACPI Specification
Work Group (ASWG) discussion - ex. for a BIOS to claim it's ACPI-compliant,
BIOS at least needs to match ACPI tables revision in ACPI spec vs. ACPI
spec version. Therefore, FWTS reports the mismatched table in your BIOS.

Please refer https://uefi.org/node/4185 to for more details, ex.

*Conforming to a given ACPI specification means that each and every
ACPI-related table conforms to the version number for that table that is
listed in that version of the specification.”*

>
>
>
> klog: Scan kernel log for errors and warnings.
>
>
>
> Unit 1:
>
> FAILED [HIGH]      HIGH Kernel message: [ 0.309290] ACPI Error: AE_ALREADY_EXISTS,
> During name lookup/catalog (20190816/psobject-220)
>
> Advice                     This is not exactly a failure but a warning
> from the kernel. The MSR_IA32_ENERGY_PERF_BIAS was initialized and
> defaulted to a high performance bias setting. The kernel has detected this
> and changed it down to a 'normal' bias setting.
>
>
>

I think the advice (it's just an info message) is not for the  above high
failure. The AE_ALREADY_EXISTS (= an ACPI object is created twice) is
likely a BIOS bug

> Unit 2:
>
> FAILED [HIGH]      HIGH Kernel message: [ 0.380305] tpm tpm0: [Firmware
> Bug]: TPM interrupt not working, polling instead
>
> Advice                     This is not exactly a failure but a warning
> from the kernel. The MSR_IA32_ENERGY_PERF_BIAS was initialized and
> defaulted to a high performance bias setting. The kernel has detected this
> and changed it down to a 'normal' bias setting.
>
>
>
>
>
> If we encountered the failed item of HIGH Kernel message, is it a BIOS
> issue?
>
>
>
>
>
>
>
I think the advice (it's just an info message) is not for the  above high
failure. The high failure (a Linux kernel complaint) is observed when TPM's
interrupt pin was not configured correctly. Previous experiences suggest
the interrupt pin for the reference board is not changed for new hardware,
but this depends on your hardware.

>
>
> dmicheck: DMI/SMBIOS table tests.
>
> FAILED [HIGH]      Type 17 expects length of 0x54, has incorrect length of
> 0x5c
>
> SMBIOS Entry Point Structure:
>
> Anchor String          : _SM_
>
> Checksum               : 0x14
>
> Entry Point Length     : 0x1f
>
> Major Version          : 0x03
>
> Minor Version          : 0x02
>
> Maximum Struct Size    : 0x0169
>
> Entry Point Revision   : 0x00
>
> Formatted Area         : 0x00 0x00 0x00 0x00 0x00
>
> Intermediate Anchor    : _DMI_
>
> Intermediate Checksum  : 0x4a
>
> Structure Table Length : 0x1864
>
> Structure Table Address: 0x3ef6d000
>
> # of SMBIOS Structures : 0x006c
>
> SMBIOS BCD Revision    : 32
>
>
>
>
>
> I try to track the FAILED item through SMBIOS SPEC.
>
> DSP0134_3.2.0:
> https://www.dmtf.org/sites/default/files/standards/documents/DSP0134_3.2.0.pdf
>
> I think that SMBIOS type 17 expects length of 0x54 is correct, and it
> should be an issue. Please correct me if my understand is not correct?
>

It should be 0x54 for SMBIOS 3.2 and 0x5c for 3.3+, but your type 17 has
0x5c when you have SMBIOS 3.2:

> …
>
>
>
>
>
>
>
> Thanks.
>
> Best regards,
>
> Bryan
>

-- 
Cheers,
Alex Hung
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/fwts-devel/attachments/20210621/652c52fd/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 15905 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/fwts-devel/attachments/20210621/652c52fd/attachment-0002.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.jpg
Type: image/jpeg
Size: 45455 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/fwts-devel/attachments/20210621/652c52fd/attachment-0003.jpg>