How often does Solaris sync-up with Intel ACPI CA releases?

We receive updates to the ACPI CA source on a semi-periodic basis from Intel, and I'll do a quick integration into a Solaris workspace using a simple script that handles the “average” case in under 2 minutes. I'll then build a kernel and sanity-test it on a machine or two. The entire process typically takes less than an a half-day, and I can quickly provide feedback to the Intel ACPI CA team. I'll review the changes in the update; if there's something compelling, or it has been more than 4 months since the last time I integrated into Solaris Nevada, I'll do additional testing on a much broader range of machines and start the integration process. This means that Solaris Nevada is usually less than a few months out-of-sync with the very latest Intel sources and represents broad “soak” testing.

Backports to Solaris 10 are demand-driven by escalations and functional-dependencies; for example, as part of the work I did to support the Sun Blade 8000, I backported the integration of ACPI CA release 20060217 to Solaris 10 6/06 (aka Update 2). Individual bug fixes (like CR 6426595) are often backported ala carte.

Intel ACPI CA source release 20060721 integrated into Solaris Nevada build 48

I recently integrated Intel ACPI CA 20060721 into Solaris Nevada; it will be available in build 48. As is the case with most updates to ACPI CA, there are a few enhancements and a few bug fixes. One of the interesting enhancements in this update is to increase compatibility with “the other” ACPI AML interpreter:

Implemented support within the AML interpreter for package objects that contain a larger AML length (package list length) than the package element count. In this case, the length of the package is truncated to match the package element count. Some BIOS code apparently modifies the package length on the fly, and this change supports this behavior. Provides compatibility with the MS AML interpreter. (With assistance from Fiodor Suietov)

This is a good example of how everyone wins with open source – pretty much every non-Microsoft x86 OS today uses Intel ACPI CA. At the risk of tooting my own horn a bit, this update also contains the following bug-fix:

Fixed a memory mapping leak during the deletion of a SystemMemory operation region where a cached memory mapping was not deleted. This became a noticeable problem for operation regions that are defined within frequently used control methods. (Dana Myers)

I found this particular bug while testing on the Sun Blade 8000 (Andromeda); a very intense hot-plug test scenario would reliably fail after precisely 3 hours and 3 minutes, like clock-work. Andromeda's ACPI BIOS is used to implement PCIe hot-plug, so the test scenario was very heavily exercising a portion of the ACPI BIOS which dynamically creates a SystemMemory operation region, leaking a bit of memory-mapping each time. After something like 180 or so hot-plug cycles, this resource was exhausted, leading to the failure. I'm pleased we found this in the lab before a customer did, but I'm more pleased with how quickly the fix was integrated by Bob Moore at Intel. Once again, everyone wins with open source. This is a corner-case problem that won't be seen in the field.

Another change Intel made at my request was to provide support for 64-bit thread Ids – a minor change, but again, one which enhances stability and ease-of-integration.

For a complete list of changes in each ACPI CA release, have a look usr/src/uts/i86pc/io/acpica/changes.txt which is updated with each integration. The previously-integrated release of ACPI CA was 20060317.