Once in a while we stumbled into one unknown warning message on our laptop or desktop machine and wish to know how it affects our machine (in terms of security or performance or powersave.
Today i going to dig into one bug which seems to happen to some of us running GNU/Linux operating system on legacy Bios machine:
ACPI BIOS Warning (bug): 32/64X length mismatch in FADT/Pm1aControlBlock: 16/32
Going to the documentation section for ACPI Component Architecture commissioned by Intel Corporation, we can see a list of documents (pdf and doc format). Intuitively, i select the pdf file under ACPICA user guide and programmer reference and search for the word 'acpi bios'.
This leads me to the page titled 'AcpiBiosWarning and ACPI_BIOS_WARNING'. There is a subtiltle stating "Print a formatted warning string for BIOS/firmware issues." It is a short page with the following functional description :
This function prints a formatted error message using the AcpiOsPrintf and AcpiOsVprintf OSL interfaces. It is intended to be used when the host detects a problem that is specific to the platform BIOS/firmware. The format of the output string is as follows:
ACPI Firmware Warning (ModuleName-LineNumber): <message> [ACPICA version number]
Next on the list, we can see something substantial (1000 or so pages) : 'ACPI Specification Version 6.2' hosted by uefi.org. In this specification, we can find in-depth information about the 'FADT' and 'PM1 Control Block'. Before we go further, let's take a look at some definition as defined that will be relevant to our discussion here:
Legacy BIOS - One form of Host Processor Boor Firmware used on x86 platforms which uses a legacy x86 BIOS structure. This form of host processor boot firmware has been or is being replaced by UEFI.
UEFI - One form of Host Processor Boot Firmware which uses a Unified Extensible Firmware Interface (UEFI) structure (as defined by the UEFI Forum). This is the current host processor boot firmware structure being adopted as a standard in the industry. This term should be used when referring specifically to UEFI code on a platform.
Operating System-directed Power Management (OSPM) - A model of power (and system) management in which the OS plays a central role and uses global information to optimize system behavior for the task at hand.
Advanced Configuration and Power Interface (ACPI) - A method for describing hardware interfaces in terms abstract enough to allow flexible and innovative hardware implementations and concrete enough to allow shrink-wrap OS code to use such hardware interfaces.
ACPI Namespace - A hierarchical tree structure in OS-controlled memory that contains named objects. These objects may be data objects, control method objects, bus/device package objects, and so on. The OS dynamically changes the contents of the namespace at runtime by loading and/or unloading definition blocks from the ACPI Tables that reside in the ACPI system firmware. All the information in the ACPI Namespace comes from the Differentiated System Description Table (DSDT), which contains the Differentiated Definition Block, and one or more other definition blocks.
Root System Description Pointer (RSDP) - An ACPI-compatible system must provide an RSDP in the system's low address space. This structure's only purpose is to provide the physical address of the RSDT and XSDT.
Root System Description Table (RSDT) - A table with the signature 'RSDT', followed by an array of physical pointers to other system description tables. The OS locates that RSDT by following the pointer in the RSDP structure.
Extended Root System Description Table (XSDT) - The XSDT provides identical functionality to the RSDT but accommodates physical addresses of DESCRIPTION HEADERs that are larger than 32 bits. Notice that both the XSDT and the RSDT can be pointed to by the RSDP structure.
Differentiated System Description Table (DSDT) - An OEM must supply a DSDT to an ACPI-compatible OS. The DSDT contains the Differentiated Definition Block, which supplies the implementation and configuration information about the base system, The OS always inserts the DSDT information into the ACPI Namespace at system boot time and never removes it.
Secondary System Description Table (SSDT) - SSDTs are a continuation of the DSDT. Multiple SSDTs can be used as part of a platform description. After the DSDT is loaded into the ACPI Namespace, each secondary description table listed in the RSDT/XSDT with a unique OEM Table ID is loaded. This allows the OEM to provide the base support in one table, while adding smaller system options in other tables.
Fixed ACPI Description Table (FADT) - A table that contains the ACPI Hardware Register Block implementation and configuration details that the OS needs to directly manage the ACPI Hardware Register Blocks, as well as the physical address of the DSDT, which contains other platform implementation and configuration details. An OEM must provide an FADT to an ACPI-compatible OS in the RSDT/XSDT. The OS always inserts the namespace information defined in the Differentiated Definition Block in the DSDT into the ACPI Namespace at system boot time, and the OS never removes it.
Section 4 ACPI HARDWARE SPECIFICATION
Under the main header 'ACPI Register Model' and the given subheader 'ACPI Register Summary' and at the table for 'PM1 Control Registers', we can see that Register 'PM1_CNTa' has Address relative to register block <PM1a_CNT_BLK>.
Under 'PM1 Control Registers', PM1a_CNT_BLK is introduced as a register block needed for the following interface purpose:
1) SCI/SMI routing control/status for power management and general-purpose events
2) Processor power state control/status
3) Global Lock related interfaces
4) System power state controls (sleeping/wake control)
It is stated that the PM1a_CNT_BLK has a PM1x_CNT with a minimum size of 2 bytes.
Further, under the main header 'Fixed Hardware Registers', and subheader 'PM1 Control Grouping' and 1 level under the subheader of title 'PM1 Control Registers':
the fixed hardware feature control bits in the PM1 control registers can be split between 2 registers, PM1a_CNT or PM1b_CNT. Each register grouping are located at a unique 32-bit aligned address, and the pointers, PM1a_CNT_BLK or PM1b_CNT_BLK, can be used to point to the respective registers. The values for these pointers to the register space are kept in the FADT.
Section 5 ACPI Software Programming Model
Under the main header 'ACPI System Description Tables' and subheader 'Fixed ACPI Description Header (FADT)':
FADT defines various fixed hardware ACPI information such as base address for the hardware register blocks such as PM1, Power Management Timer (PM_TMR) and General Purpose Event Register Blocks (GPE) ,etc.
Under the main header 'ACPI System Description Tables' and subheader 'Definition Blocks':
It is a data block in AML format and contains information about hardware implementation details in the form of AML objects that contain data, AML code or other AML objects.
Recall the definition of ACPI Namespace as it is useful in the discussion here.
OSPM "loads" or "unloads" an entire definition block as a logical unit using the AML Load() or LoadTable() operators. These operators allow a Definition Block to load other Definition Blocks, statically or dynamically, which can define new system attributes or build on prior definitions. As OSPM initializes, it loads the DSDT, which contains Differentiated Definition Block, through DSDT pointer retrieved from the FADT. In addition, OSPM will load other definition blocks in the RSDT/XSDT which contains the SSDT definitions. It is claimed that the power of the Definition Block lies in its ability to allow operations through the use of AML operators to be combined in numerous ways to provide functionality to OSPM.
Under the main headers (1)'Definition Block Encoding' and (2)'Control Methods and the ACPI Source Language (ASL)':
The missing link between ASL and the definition blocks is written here. OEM and platform firmware vendors write Definition Blocks using the ACPI Source Language (ASL) and use a translator to produce the byte stream encoding. Within the stream encoding, (1) packaging and object declarations at load-time, and (2) object reference at run-time or package contents.
Encodings of implicit length objects either have fixed length encodings or allow for nested encodings that, at some point, result in an explicit or
implicit fixed length. The first object present in a Definition Block must be a named control method (aka initialization control). Packages are objects that contain an ordered reference to one or more objects. A package can also be considered a vertex of an array, and any object contained within a package can be another package. This permits multidimensional arrays of fixed or dynamic depths and vertices. Below is an example curated from the ACPI Specification to illustrate the control method of the ASL language:
FWTS
Using Ubuntu FWTS tool, i run the following command to glean information for the bug:
fwts oops acpiinfo fadt -f -r apic.log -D | dialog --gauge "Firmware Test Suite" 10 90
A summary of the failures presented by the tool:
Medium failures: 7
fadt: Both 32-bit FIRMWARE_CTRL and 64-bit X_FIRMWARE_CTRL pointers to the FACS
are set but only one is allowed.
fadt: FADT PM1A_EVT_BLK has both a 32-bit and a 64-bit address set; only one should be used.
fadt: FADT PM1A_CNT_BLK field has both the 32-bit and the 64-bit field set.
fadt: FADT PM2_CNT_BLK field has both the 32-bit and the 64-bit field set.
fadt: FADT PM_TMR_BLK field has both the 32-bit and the 64-bit field set.
fadt: 32 and 64 bit versions of FADT pm1_cnt size do not match (0x10 vs 0x20).
rsdp: RSDP: only one of RsdtAddress or XsdtAddress should be non-zero. Both fields are non-zero.
The bug seems to be a result of 32 bit version and 64 bit version of FADT_pm1_cnt size not matching up, which may only be fixed by Lenovo (indirectly using Bios Update) or Intel.
Today i going to dig into one bug which seems to happen to some of us running GNU/Linux operating system on legacy Bios machine:
ACPI BIOS Warning (bug): 32/64X length mismatch in FADT/Pm1aControlBlock: 16/32
Going to the documentation section for ACPI Component Architecture commissioned by Intel Corporation, we can see a list of documents (pdf and doc format). Intuitively, i select the pdf file under ACPICA user guide and programmer reference and search for the word 'acpi bios'.
This leads me to the page titled 'AcpiBiosWarning and ACPI_BIOS_WARNING'. There is a subtiltle stating "Print a formatted warning string for BIOS/firmware issues." It is a short page with the following functional description :
This function prints a formatted error message using the AcpiOsPrintf and AcpiOsVprintf OSL interfaces. It is intended to be used when the host detects a problem that is specific to the platform BIOS/firmware. The format of the output string is as follows:
ACPI Firmware Warning (ModuleName-LineNumber): <message> [ACPICA version number]
Next on the list, we can see something substantial (1000 or so pages) : 'ACPI Specification Version 6.2' hosted by uefi.org. In this specification, we can find in-depth information about the 'FADT' and 'PM1 Control Block'. Before we go further, let's take a look at some definition as defined that will be relevant to our discussion here:
Legacy BIOS - One form of Host Processor Boor Firmware used on x86 platforms which uses a legacy x86 BIOS structure. This form of host processor boot firmware has been or is being replaced by UEFI.
UEFI - One form of Host Processor Boot Firmware which uses a Unified Extensible Firmware Interface (UEFI) structure (as defined by the UEFI Forum). This is the current host processor boot firmware structure being adopted as a standard in the industry. This term should be used when referring specifically to UEFI code on a platform.
Operating System-directed Power Management (OSPM) - A model of power (and system) management in which the OS plays a central role and uses global information to optimize system behavior for the task at hand.
Advanced Configuration and Power Interface (ACPI) - A method for describing hardware interfaces in terms abstract enough to allow flexible and innovative hardware implementations and concrete enough to allow shrink-wrap OS code to use such hardware interfaces.
ACPI Namespace - A hierarchical tree structure in OS-controlled memory that contains named objects. These objects may be data objects, control method objects, bus/device package objects, and so on. The OS dynamically changes the contents of the namespace at runtime by loading and/or unloading definition blocks from the ACPI Tables that reside in the ACPI system firmware. All the information in the ACPI Namespace comes from the Differentiated System Description Table (DSDT), which contains the Differentiated Definition Block, and one or more other definition blocks.
Root System Description Pointer (RSDP) - An ACPI-compatible system must provide an RSDP in the system's low address space. This structure's only purpose is to provide the physical address of the RSDT and XSDT.
Root System Description Table (RSDT) - A table with the signature 'RSDT', followed by an array of physical pointers to other system description tables. The OS locates that RSDT by following the pointer in the RSDP structure.
Extended Root System Description Table (XSDT) - The XSDT provides identical functionality to the RSDT but accommodates physical addresses of DESCRIPTION HEADERs that are larger than 32 bits. Notice that both the XSDT and the RSDT can be pointed to by the RSDP structure.
Differentiated System Description Table (DSDT) - An OEM must supply a DSDT to an ACPI-compatible OS. The DSDT contains the Differentiated Definition Block, which supplies the implementation and configuration information about the base system, The OS always inserts the DSDT information into the ACPI Namespace at system boot time and never removes it.
Secondary System Description Table (SSDT) - SSDTs are a continuation of the DSDT. Multiple SSDTs can be used as part of a platform description. After the DSDT is loaded into the ACPI Namespace, each secondary description table listed in the RSDT/XSDT with a unique OEM Table ID is loaded. This allows the OEM to provide the base support in one table, while adding smaller system options in other tables.
Fixed ACPI Description Table (FADT) - A table that contains the ACPI Hardware Register Block implementation and configuration details that the OS needs to directly manage the ACPI Hardware Register Blocks, as well as the physical address of the DSDT, which contains other platform implementation and configuration details. An OEM must provide an FADT to an ACPI-compatible OS in the RSDT/XSDT. The OS always inserts the namespace information defined in the Differentiated Definition Block in the DSDT into the ACPI Namespace at system boot time, and the OS never removes it.
Section 4 ACPI HARDWARE SPECIFICATION
Under the main header 'ACPI Register Model' and the given subheader 'ACPI Register Summary' and at the table for 'PM1 Control Registers', we can see that Register 'PM1_CNTa' has Address relative to register block <PM1a_CNT_BLK>.
Under 'PM1 Control Registers', PM1a_CNT_BLK is introduced as a register block needed for the following interface purpose:
1) SCI/SMI routing control/status for power management and general-purpose events
2) Processor power state control/status
3) Global Lock related interfaces
4) System power state controls (sleeping/wake control)
It is stated that the PM1a_CNT_BLK has a PM1x_CNT with a minimum size of 2 bytes.
Further, under the main header 'Fixed Hardware Registers', and subheader 'PM1 Control Grouping' and 1 level under the subheader of title 'PM1 Control Registers':
the fixed hardware feature control bits in the PM1 control registers can be split between 2 registers, PM1a_CNT or PM1b_CNT. Each register grouping are located at a unique 32-bit aligned address, and the pointers, PM1a_CNT_BLK or PM1b_CNT_BLK, can be used to point to the respective registers. The values for these pointers to the register space are kept in the FADT.
Section 5 ACPI Software Programming Model
Under the main header 'ACPI System Description Tables' and subheader 'Fixed ACPI Description Header (FADT)':
FADT defines various fixed hardware ACPI information such as base address for the hardware register blocks such as PM1, Power Management Timer (PM_TMR) and General Purpose Event Register Blocks (GPE) ,etc.
Under the main header 'ACPI System Description Tables' and subheader 'Definition Blocks':
It is a data block in AML format and contains information about hardware implementation details in the form of AML objects that contain data, AML code or other AML objects.
Recall the definition of ACPI Namespace as it is useful in the discussion here.
OSPM "loads" or "unloads" an entire definition block as a logical unit using the AML Load() or LoadTable() operators. These operators allow a Definition Block to load other Definition Blocks, statically or dynamically, which can define new system attributes or build on prior definitions. As OSPM initializes, it loads the DSDT, which contains Differentiated Definition Block, through DSDT pointer retrieved from the FADT. In addition, OSPM will load other definition blocks in the RSDT/XSDT which contains the SSDT definitions. It is claimed that the power of the Definition Block lies in its ability to allow operations through the use of AML operators to be combined in numerous ways to provide functionality to OSPM.
Under the main headers (1)'Definition Block Encoding' and (2)'Control Methods and the ACPI Source Language (ASL)':
The missing link between ASL and the definition blocks is written here. OEM and platform firmware vendors write Definition Blocks using the ACPI Source Language (ASL) and use a translator to produce the byte stream encoding. Within the stream encoding, (1) packaging and object declarations at load-time, and (2) object reference at run-time or package contents.
Encodings of implicit length objects either have fixed length encodings or allow for nested encodings that, at some point, result in an explicit or
implicit fixed length. The first object present in a Definition Block must be a named control method (aka initialization control). Packages are objects that contain an ordered reference to one or more objects. A package can also be considered a vertex of an array, and any object contained within a package can be another package. This permits multidimensional arrays of fixed or dynamic depths and vertices. Below is an example curated from the ACPI Specification to illustrate the control method of the ASL language:
// ASL Example
DefinitionBlock (
"forbook.aml", // Output Filename
"DSDT", // Signature
0x02, // DSDT Compliance Revision
"OEM", // OEMID
"forbook", // TABLE ID
0x1000 // OEM Revision
)
{ // start of definition block
OperationRegion(\GIO, SystemIO, 0x125, 0x1)
Field(\GIO, ByteAcc, NoLock, Preserve) {
CT01, 1,
}
Scope(\_SB) // start of scope
Device(PCI0) { // start of device
PowerResource(FET0, 0, 0) { // start of pwr
Method (_ON) {
Store (Ones, CT01) // assert power
Sleep (30) // wait 30ms
}
Method (_OFF) {
Store (Zero, CT01) // assert reset#
}
Method (_STA) {
Return (CT01)
}
} // end of power
} // end of device
} // end of scope
} // end of definition block
FWTS
Using Ubuntu FWTS tool, i run the following command to glean information for the bug:
fwts oops acpiinfo fadt -f -r apic.log -D | dialog --gauge "Firmware Test Suite" 10 90
A summary of the failures presented by the tool:
Medium failures: 7
fadt: Both 32-bit FIRMWARE_CTRL and 64-bit X_FIRMWARE_CTRL pointers to the FACS
are set but only one is allowed.
fadt: FADT PM1A_EVT_BLK has both a 32-bit and a 64-bit address set; only one should be used.
fadt: FADT PM1A_CNT_BLK field has both the 32-bit and the 64-bit field set.
fadt: FADT PM2_CNT_BLK field has both the 32-bit and the 64-bit field set.
fadt: FADT PM_TMR_BLK field has both the 32-bit and the 64-bit field set.
fadt: 32 and 64 bit versions of FADT pm1_cnt size do not match (0x10 vs 0x20).
rsdp: RSDP: only one of RsdtAddress or XsdtAddress should be non-zero. Both fields are non-zero.
The bug seems to be a result of 32 bit version and 64 bit version of FADT_pm1_cnt size not matching up, which may only be fixed by Lenovo (indirectly using Bios Update) or Intel.
Comments
Post a Comment