Kernel Panic from ACPI Interrupt Overrides in UEFI Secure Boot on HP Z-Series

[snappyjuan]

For the past six months, I’ve been troubleshooting an intermittent kernel panic occurring exclusively on HP Z4 G5 Workstations running Windows 11 Enterprise (23H2) and Linux 6.8.x kernels (Fedora 40, Ubuntu 24.04 LTS) in dual-boot configurations. The panic manifests only under the following hyper-specific conditions: (1) UEFI Secure Boot is enabled with a customized TPM 2.0 policy restricting PCRs 7/8 to Microsoft-signed shims, (2) the system uses an NVMe RAID 0 array (2x WD Black SN850X) configured via Intel VMD 22.x drivers, and (3) a Thunderbolt 4 dock (HP G4) with PCIe tunneling is connected during boot.

The panic occurs unpredictably 10–45 minutes post-boot. On Windows, it triggers a WHEA_UNCORRECTABLE_ERROR (0x124) citing a fatal ACPI error (APIC ID 0x2, GICR_INITRD_OVERRIDE). On Linux, the kernel logs show "IRQ 58: nobody cared" followed by a cascade of ACPI PCC probe failures and eventual slab corruption in the TPM CRB driver. Crucially, disabling Secure Boot or disconnecting the Thunderbolt dock prevents the issue, but both are required for my workflow.

I’ve exhaustively tested firmware revisions (UEFI 1.24.2), TPM firmware (7.85.3710.0), Thunderbolt NVM (44.0), and driver versions. Intel’s VTune Profiler traces show anomalous ACPI _PRT (PCI Routing Table) overrides during D3cold→D0 transitions for the Thunderbolt root port, which should be handled by the kernel’s PCIe ASPM layer. However, the Secure Boot policy appears to lock the TPM’s response to ACPI table modifications mid-suspend, causing a race condition between the Thunderbolt PCIe reset and TPM attestation handshake.

No existing patches (Microsoft KB5037008, Linux acpi=off, or intel_iommu=strict) resolve this. The closest reference is an obscure Intel errata (IA-01354) for "GICv3 LPI Configuration Race with ACPI _DSM," but it lacks implementation details. This seems tied to HP’s UEFI implementation of the GICv3 interrupt controller for Xeon W-2500 series CPUs, which hardcodes ACPI _CRS allocations conflicting with Thunderbolt’s MMIO space.

Has anyone encountered ACPI/TPM/Thunderbolt triage failures under Secure Boot with HP’s custom GIC mappings? Are there undocumented UEFI variables or TPM PCR extension strategies to decouple this dependency?