25 March 2014. Summary of changes for version 20140325:
This release is available at https://acpica.org/downloads
1) ACPICA kernel-resident subsystem:
Updated the auto-serialize feature for control methods. This feature automatically serializes all methods that create named objects in order to prevent runtime errors. The update adds support to ignore the currently executing AML SyncLevel when invoking such a method, in order to prevent disruption of any existing SyncLevel priorities that may exist in the AML code. Although the use of SyncLevels is relatively rare, this change fixes a regression where an AE_AML_MUTEX_ORDER exception can appear on some machines starting with the 20140214 release.
Added a new external interface to allow the host to install ACPI tables very early, before the namespace is even created. AcpiInstallTable gives the host additional flexibility for ACPI table management. Tables can be installed directly by the host as if they had originally appeared in the XSDT/RSDT. Installed tables can be SSDTs or other ACPI data tables (anything except the DSDT and FACS). Adds a new file, tbdata.c, along with additional internal restructuring and cleanup. See the ACPICA Reference for interface details. Lv Zheng.
Added validation of the checksum for all incoming dynamically loaded tables (via external interfaces or via AML Load/LoadTable operators). Lv Zheng.
Updated the use of the AcpiOsWaitEventsComplete interface during Notify and GPE handler removal. Restructured calls to eliminate possible race conditions. Lv Zheng.
Added a warning for the use/execution of the ASL/AML Unload (table) operator. This will help detect and identify machines that use this operator if and when it is ever used. This operator has never been seen in the field and the usage model and possible side-effects of the drastic runtime action of a full table removal are unknown.
Reverted the use of #pragma push/pop which was introduced in the 20140214 release. It appears that push and pop are not implemented by enough compilers to make the use of this feature feasible for ACPICA at this time. However, these operators may be deployed in a future ACPICA release.
Added the missing EXPORT_SYMBOL macros for the install and remove SCI handler interfaces.
Source code generation:
1) Disabled the use of the "strchr" macro for the gcc-specific generation. For some versions of gcc, this macro can periodically expose a compiler bug which in turn causes compile-time error(s).
2) Added support for PPC64 compilation. Colin Ian King.
Example Code and Data Size: These are the sizes for the OS-independent acpica.lib produced by the Microsoft Visual C++ 9.0 32-bit compiler. The debug version of the code includes the debug output trace mechanism and has a much larger code and data size.
Non-Debug Version: 97.0K Code, 27.2K Data, 124.2K Total
Debug Version: 189.7K Code, 79.5K Data, 269.2K Total
Non-Debug Version: 96.5K Code, 27.2K Data, 123.7K Total
Debug Version: 188.6K Code, 79.0K Data, 267.6K Total
2) iASL Compiler/Disassembler and Tools:
Disassembler: Added several new features to improve the readability of the resulting ASL code. Extra information is emitted within comment fields in the ASL code:
1) Known _HID/_CID values are decoded to descriptive text.
2) Standard values for the Notify() operator are decoded to descriptive text.
3) Target operands are expanded to full pathnames (in a comment) when possible.
Disassembler: Miscellaneous updates for extern() handling:
1) Abort compiler if file specified by -fe option does not exist.
2) Silence unnecessary warnings about argument count mismatches.
3) Update warning messages concerning unresolved method externals.
4) Emit "UnknownObj" keyword for externals whose type cannot be determined.
1) Added the -a option to display both the ASL syntax and the AML encoding for an input ASL operator. This effectively displays all known information about an ASL operator with one AcpiHelp invocation.
2) Added substring match support (similar to a wildcard) for the -i (_HID/PNP IDs) option.
iASL/Disassembler: Since this tool does not yet support execution on big-endian machines, added detection of endianness and an error message if execution is attempted on big-endian. Support for big-endian within iASL is a feature that is on the ACPICA to-be-done list.
1) Remove option to extract binary files from an acpidump; this function is made obsolete by the AcpiXtract utility.
2) General cleanup of open files and allocated buffers.
Should iasl running on a big endian machine be able to
disassemble a DSDT(and any other acpi table) taken from a
little endian machine?
I tried to do it and I receive:
Error [...] TableHeader length [0xBB040000] greater than the input file size [0x4BB].
As you can see the length bytes are swapped.
The question is, shouldn't it work, ACPI protocol being always little-endian?
Let me report this back.
The problem is traced at: https://bugzilla.kernel.org/show_bug.cgi?id=70891
The delay is either caused by the EC driver or by the ACPICA event handling code.
During the execution of _REG method of the EC device, there will be multiple EC accesses happening.
And each of such EC accesses is suffering from 0.5 seconds delay, which are finally accumulated as 6 seconds boot delay.
There is a failure in the EC driver and the driver will reset controller and retry after 0.5 seconds.
Normally this indicates a gap in the driver's state machine.
We are working on this to find out the root cause.
Thanks for the reporting.
> From: Stanislaw Gruszka [mailto:firstname.lastname@example.org]
> Sent: Tuesday, February 18, 2014 4:39 PM
> On bugzilla https://bugzilla.redhat.com/show_bug.cgi?id=1055228 ,
> Gareth reported 6 second boot delay on 3.12 kernel. Delay does not
> happen if acpi_no_auto_ssdt option is used, nor if kernel is compiled
> with various debug facilities like LOCKDEP (fedora kernel-debug
> variant). We tried to compile kernel with just CONFIG_ACPI_DEBUG=y, on
> that kernel issue was reproducible, but after enable printing messages,
> again issue disappeared (we tried acpi.debug_layer=0xffffffff together
> with acip.debug_level=0x0307ff4f and acip.debug_level=0x03000000,
> links to logs are provided in bugzilla).
> On affected kernels interesting dmesg part looks like below:
> [ 0.212035] [Firmware Bug]: ACPI: BIOS _OSI(Linux) query ignored
> [ 0.217930] ACPI: SSDT 0000000092e6ac18 003D3 (v01 PmRef Cpu0Cst 00003001 INTL 20121220)
> [ 0.218512] ACPI: Dynamic OEM Table Load:
> [ 0.218514] ACPI: SSDT (null) 003D3 (v01 PmRef Cpu0Cst 00003001 INTL 20121220)
> [ 0.222109] ACPI: SSDT 0000000092e6a618 005AA (v01 PmRef ApIst 00003000 INTL 20121220)
> [ 0.222792] ACPI: Dynamic OEM Table Load:
> [ 0.222799] ACPI: SSDT (null) 005AA (v01 PmRef ApIst 00003000 INTL 20121220)
> [ 0.226920] ACPI: SSDT 0000000092e69d98 00119 (v01 PmRef ApCst 00003000 INTL 20121220)
> [ 0.227495] ACPI: Dynamic OEM Table Load:
> [ 0.227497] ACPI: SSDT (null) 00119 (v01 PmRef ApCst 00003000 INTL 20121220)
> [ 6.812869] ACPI: Interpreter enabled
> With acpi_no_auto_ssdt option interesting part looks like this:
> [ 0.203230] [Firmware Bug]: ACPI: BIOS _OSI(Linux) query ignored
> [ 0.203595] ACPI Error: [SGMD] Namespace lookup failure, AE_NOT_FOUND (20130725/psargs-359)
> [ 0.203601] ACPI Error: Method parse/execution failed [\_SB_._OSC] (Node ffff880253859438), AE_NOT_FOUND (20130725/psparse-
> [ 0.206093] ACPI Error: [\_PR_.CPU0._PPC] Namespace lookup failure, AE_NOT_FOUND (20130725/psargs-359)
> [ 0.206102] ACPI Error: Method parse/execution failed [\_SB_.PCI0.LPCB.EC0_.SASU] (Node ffff8802538570a0), AE_NOT_FOUND
> [ 0.206108] ACPI Error: Method parse/execution failed [\_SB_.PCI0.LPCB.EC0_.ECMI] (Node ffff880253857078), AE_NOT_FOUND
> [ 0.206113] ACPI Error: Method parse/execution failed [\_SB_.PCI0.LPCB.EC0_._REG] (Node ffff880253856910), AE_NOT_FOUND
> [ 0.206122] Fail in evaluating the _REG object of EC device. Broken bios is suspected.
> [ 0.206127] ACPI: Interpreter enabled
> Any help to solving this bug would be appreciate. I'm CCing Gareth, he
> can provide more informations if needed.