Raptor Lake S: 90ms ACPI DPC Spike during C1E Transition (25H2)

[e13mako]

Technical Report: Raptor Lake S (i5-14500) – C1E Transition Failure and ACPI Latency on Windows 11 25H2

To: Intel Community / Engineering Support

Subject: Reproducible 90ms ACPIDevicePowerDpc Spin-Wait during Screen-Off Events

1. Environment

• CPU: Intel® Core™ i5-14500 (Raptor Lake S)
• Platform: Dell OptiPlex 7020 SFF
• BIOS: v1.23.1 (Latest)
• OS: Windows 11 25H2 (Clean Install)
• Reproducibility: Confirmed on 10+ identical units

1. Issue Summary

On Windows 11 25H2, every screen-off event triggers a reproducible ~90ms DPC spike in ACPI.sys!ACPIDevicePowerDpc. The system call stack remains empty throughout the duration despite full symbol resolution, indicating a hardware polling loop or spin-wait in the firmware/OS interface. This behavior is absent in Windows 11 24H2 with identical hardware and BIOS.

1. WPA Trace Evidence

Evidence 1: C1E Transition Failure The CPU fails to transition to the Target State (C1E / State 2) during the screen-off event. 

Evidence 2: 90ms DPC Latency Consistent ~90ms duration recorded for the ACPI DPC. 

Evidence 3: Empty Call Stack (Spin-wait) Empty stack trace suggests the CPU is stalled in a serialized polling loop. 

1. Root Cause Analysis (ACPI Table Inspection)

Preliminary analysis of the DSDT suggests the latency is driven by a specific polling loop within the HID device transition logic. The implementation uses a While loop combined with Sleep(0x04) (4ms), waiting for an Embedded Controller (EC) status flag.

The observed 90ms duration perfectly aligns with approximately 22-23 iterations of this 4ms polling cycle. This serialized wait appears to prevent the CPU from completing the C1E (State 2) transition.

1. Questions for Intel

1. Is the observed C1E transition failure behavior consistent with known Raptor Lake S platform errata when interacting with high-latency ACPI polling?
2. Could changes in the Windows 11 25H2 power management stack be exacerbating timing sensitivities in the HIDD state transition sequence?
3. Does Intel recommend specific BIOS/firmware-level mitigations for "spin-wait" loops triggered by ACPIDevicePowerDpc on this platform?

I have attached the Intel SSU log for further investigation.

[Nikhil_Intel]

Hello e13mako,

Thank you for reaching out to the Intel Community. 

I would like to inform you that we are currently investigating the issue you reported. I am actively working to analyze the behavior and identify the root cause.

I appreciate your patience and understanding while we continue this process. Please rest assured that we will keep you updated on any progress or findings.

If we require any additional information from your side, we will reach out to you.

Thank you for your cooperation.

Best Regards

Nikhil,

Intel Customer Support Technician

[e13mako]

Hello Nikhil,

Thank you for the update. I appreciate Intel’s investigation.

To assist your analysis, I can confirm that this issue is 100% reproducible on a clean Windows 11 25H2 installation by triggering a screen-off event every 60 seconds. All attached screenshots were captured under this automated condition across multiple identical systems.

Observed behavior includes consistent ~80–90 ms DPC spikes in ACPI.sys (ACPIDevicePowerDpc), aligned precisely with display power state transitions. In addition, Intel iaLPSS-related drivers (GPIO/I2C) appear in the DPC stack around the same timing.

While organizational policy prevents sharing raw .etl files, I would be happy to provide additional WPA views or specific breakdowns if helpful.

I would appreciate any insight into whether this behavior aligns with expected C-State transition behavior on Raptor Lake-S platforms, or if further tuning/firmware considerations may apply.

Best regards,

[Nikhil_Intel]

Hello e13mako,

I hope you are doing well.

Thank you for sharing your detailed analysis and observations. We appreciate the clarity around the reproducibility of the issue and the additional context you’ve provided.

To help us move forward, we would like to confirm system environment consistency across all affected units.

Specifically, please confirm whether all systems are running the same environment as shown in the previously shared SSU log, including:

• OS version and build
• BIOS version
• Driver versions
• Power and display configuration settings

If there are any differences across the systems, please collect and share the system environment details (SSU) from those units with differing configurations.

This information will help us accurately compare setups across systems and better understand the observed behavior.

Thank you for your continued cooperation.

Best regards,

Nikhil

Intel Customer Support Technician

[e13mako]

Dear Nikhil,

Thank you for your follow-up.

To further confirm environmental consistency, I have attached SSU logs from three representative systems, including both a clean test unit and production units.

Key observations:

System consistency:
All units are running aligned OS builds, BIOS versions, and driver stacks. The behavior is consistently reproducible across all tested systems.

Persistence on latest BIOS and clean OS:
I have also attached a WPA capture from a clean test unit after updating to the latest BIOS and chipset drivers.
The same pattern of repeated DPC/ISR spikes (involving ACPI.sys and storport.sys) is still clearly observed during idle / screen-off related periods.

C-state behavior (important):
Disabling C-state control does not resolve the issue but instead redistributes latency to other drivers (e.g., storport.sys), resulting in less deterministic but still degraded behavior.

Interpretation:
Given that the issue reproduces on a clean environment with current firmware, it appears less likely to be caused by configuration differences or third-party software.
Instead, this may indicate an interaction within the power management path (e.g., ACPI execution and device activity during low-power state transitions).

At this stage, I am not certain whether this behavior originates primarily from platform firmware, OS power management changes, or their interaction.

I have also submitted a detailed report to Microsoft via Feedback Hub, including WPA traces and reproduction steps, to investigate potential OS-side behavior changes in Windows 11 25H2.

I would appreciate your team's insight into whether this pattern aligns with any known behavior or requires further investigation on the platform side.

Minor variations between systems (e.g., disk usage, serials) exist, but all critical platform components (BIOS, CPU, ME, memory configuration) are aligned.

Best regards,

[Nikhil_Intel]

Hello e13mako,

Thank you for your continued patience and for sharing the details so far.

Based on our internal review, it appears that your system may be an OEM device (such as Dell). The behavior you’re experiencing—related to ACPI DPC spikes during C1E transition—typically points to firmware or operating system-level interaction.

Could you please confirm if your system is an OEM system? If so, we recommend reaching out to your system manufacturer for further assistance, as they are best positioned to provide firmware-level support.

In the meantime, please ensure that your system BIOS/firmware is updated to the latest version available from the OEM. We also note that your operating system is already up to date.

Once we have your confirmation, we’ll be happy to guide you further if needed.

Thank you for your cooperation.

Best regards,

Nikhil

Intel Customer Support

[e13mako]

Dear Nikhil,

Thank you very much for your detailed review and for pointing out the potential relation to C1E transitions.

Your insights have been extremely helpful in narrowing down the scope of the issue, and I truly appreciate the time and expertise you have shared.

Based on your guidance, I will proceed to engage with the OEM (Dell) to further investigate the firmware and OS interaction aspects.

If, during those discussions, it turns out that the behavior may be related to CPU-level behavior or underlying platform implementation, I may reach out again for your further guidance.

For now, I will place this case on hold while I continue discussions with the OEM.

Thank you again for your support and professional assistance throughout this investigation.

Best regards,
e13mako

[Nikhil_Intel · Accepted solution]

Hello e13mako,

I hope you are doing well.

Thank you for confirming that you will be coordinating with the OEM for further support. I appreciate your continued efforts in working through this.

Please let us know how long you would like this case to remain on hold. Alternatively, I can temporarily close this thread for now. If you need further support, you may create a new thread and include the link to this discussion for continuity.

Thanks again, and I look forward to your update.

Best regards,

Nikhil

Intel Customer Support Technician

[e13mako]

Dear Nikhil,

Thank you for your message and for your continued support throughout this investigation.

At this point, I will proceed with coordination on the OEM side based on your insights.
You may go ahead and close this thread for now.

I truly appreciate your assistance in helping clarify the technical direction — it has been very valuable.

If needed, I will reach out again with reference to this discussion.

Best regards,

[Nikhil_Intel]

Hello e13mako,

Thank you for your update, and I appreciate you keeping us informed.

I’m glad to hear you will be proceeding with coordination on the OEM side based on the information shared. As requested, I will go ahead and close this thread. Please note that this discussion will no longer be actively monitored.

If you need any further assistance in the future, feel free to reach out by creating a new thread, and we will be happy to assist you.

Thank you for your patience and cooperation.

Best regards,

Nikhil

Intel Customer Support Technician