[HPE] FWTS test results

Tue Jun 22 06:35:06 UTC 2021

Hi Alex,

Thanks for your help.

Thanks.
Best regards,
Bryan
From: Alex Hung [mailto:alex.hung at canonical.com]
Sent: Tuesday, June 22, 2021 12:54 PM
To: Huang, Bryan <bryanhuang at hpe.com>
Cc: fwts-devel at lists.ubuntu.com; Kuan, Bob <bob.kuan at hpe.com>; Lin, Kevin (ISS ROMQA) <kevin.lin at hpe.com>; Chuang, Brian (HPE DVT UEFI) <brian.chuang2 at hpe.com>
Subject: Re: [HPE] FWTS test results

On Mon, Jun 21, 2021 at 9:53 PM Huang, Bryan <bryanhuang at hpe.com<mailto: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<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:

[cid:image001.jpg at 01D76773.C925DA00]
…
[cid:image002.jpg at 01D76773.C925DA00]

Thanks.
Best regards,
Bryan

--
Cheers,
Alex Hung
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/fwts-devel/attachments/20210622/d4596288/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 15660 bytes
Desc: image001.jpg
URL: <https://lists.ubuntu.com/archives/fwts-devel/attachments/20210622/d4596288/attachment-0002.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 44518 bytes
Desc: image002.jpg
URL: <https://lists.ubuntu.com/archives/fwts-devel/attachments/20210622/d4596288/attachment-0003.jpg>