[BUG] NULL pointer dereference in xe_display_flush_cleanup_work during runtime suspend (Alder Lake + Arc A370M)

[ExtremeLiquidCxr]

System Environment:

OS: Arch Linux (UKI boot, strict lockdown/security policies enabled)

Kernel: 7.0.3-arch1-2 (PREEMPT_DYNAMIC)

CPU/iGPU: Intel Core i7-1260P (Alder Lake-P) | ID: 46a6

dGPU: Intel Arc A370M (DG2) | ID: 5693

Issue Description:
The xe driver encounters a fatal NULL pointer dereference (address: 00000000000005d8) when the power management subsystem attempts to put the display into a runtime suspend state.

The crash occurs specifically during the memory cleanup phase within xe_display_flush_cleanup_work. It appears the driver fails to pass or retain a valid pointer to the display data structure before entering sleep mode. The processor correctly catches the invalid memory access and triggers a kernel panic to prevent data corruption.

Steps to Reproduce:

Boot the system with parameters to strictly bind both GPUs to xe:
xe.force_probe=46a6,5693 i915.force_probe=!46a6,!5693

Allow the system to initialize the DRM devices (both devices probe and initialize successfully).

Wait for the PM subsystem to trigger a runtime suspend (e.g., leaving the system idle shortly after boot).

System triggers a Kernel Panic.

Key Technical Observations:

Targeted Failure: The crash is strictly isolated to the xe driver's display power management logic. Other PCI subsystems (such as Intel AX211 Wi-Fi and Bluetooth) survive the graphical crash and remain fully initialized and functional in the background.

Consistency: The behavior is persistent and identical across multiple kernels (tested from 6.17.x up to 7.0.3), confirming a core logic error in the driver rather than a transient kernel bug.

Hardware State: The system is otherwise completely stable. Thermal states are normal (no fan spin-up or throttling), and security modules (AppArmor, Lockdown) do not interfere with the driver initialization prior to the suspend trigger.

Relevant Call Trace:
Plaintext

BUG: kernel NULL pointer dereference, address: 00000000000005d8
...
xe_display_flush_cleanup_work+0x96/0x140 [xe]
xe_display_pm_runtime_suspend+0x4b/0x90 [xe]
xe_pm_runtime_suspend+0x147/0x300 [xe]
xe_pci_runtime_suspend+0x2a/0xe0 [xe]
pci_pm_runtime_suspend+0x78/0x210

Full dmesg log attached below.

[ExtremeLiquidCxr]

full_previous_boot1.txt

Cross-posting: This issue and the accompanying logs are being cross-posted on GitLab/GitHub to ensure proper visibility across upstream channels.

Sanitization: For security and privacy reasons, the attached full dmesg log has been strictly sanitized. Unique personal identifiers (such as MAC addresses, LUKS UUIDs, Machine IDs, TPM hashes, and local usernames) have been redacted or replaced with obvious placeholders (e.g., XXXX or [REDACTED]).

Data Integrity: Please be assured that all technical data relevant to this bug—including the Call Trace, hardware IDs, register states, memory addresses, and driver initialization sequences—remains completely untouched and 100% intact for accurate debugging

[ExtremeLiquidCxr]

OS: Arch Linux (UKI boot, strict lockdown/security policies enabled) Kernel: 7.0.3-arch1-2 (PREEMPT_DYNAMIC) CPU/iGPU: Intel Core i7-1260P (Alder Lake-P) | ID: 46a6 dGPU: Intel Arc A370M (DG2) | ID: 5693
Issue Description:
The xe driver encounters a fatal NULL pointer dereference (address: 00000000000005d8) when the power management subsystem attempts to put the display into a runtime suspend state.
The crash occurs specifically during the memory cleanup phase within xe_display_flush_cleanup_work. It appears the driver fails to pass or retain a valid pointer to the display data structure before entering sleep mode. The processor correctly catches the invalid memory access and triggers a kernel panic to prevent data corruption.
Steps to Reproduce:
Boot the system with parameters to strictly bind both GPUs to xe: xe.force_probe=46a6,5693 i915.force_probe=! 46a6,! 5693Allow the system to initialize the DRM devices (both devices probe and initialize successfully). Wait for the PM subsystem to trigger a runtime suspend (e.g., leaving the system idle shortly after boot). System triggers a Kernel Panic.
Key Technical Observations:
Targeted Failure: The crash is strictly isolated to the xe driver's display power management logic. Other PCI subsystems (such as Intel AX211 Wi-Fi and Bluetooth) survive the graphical crash and remain fully initialized and functional in the background. Consistency: The behavior is persistent and identical across multiple kernels (tested from 6.17.x up to 7.0.3), confirming a core logic error in the driver rather than a transient kernel bug. Hardware State: The system is otherwise completely stable. Thermal states are normal (no fan spin-up or throttling), and security modules (AppArmor, Lockdown) do not interfere with the driver initialization prior to the suspend trigger.
Relevant Call Trace:
BUG: kernel NULL pointer dereference, address: 00000000000005d8
...
xe_display_flush_cleanup_work+0x96/0x140 [xe]
xe_display_pm_runtime_suspend+0x4b/0x90 [xe]
xe_pm_runtime_suspend+0x147/0x300 [xe]
xe_pci_runtime_suspend+0x2a/0xe0 [xe]
pci_pm_runtime_suspend+0x78/0x210
Full dmesg log attached below.
s-posting: This issue and the accompanying logs are being cross-posted on GitLab/GitHub to ensure proper visibility across upstream channels.
Sanitization: For security and privacy reasons, the attached full dmesg log has been strictly sanitized. Unique personal identifiers (such as MAC addresses, LUKS UUIDs, Machine IDs, TPM hashes, and local usernames) have been redacted or replaced with obvious placeholders (e.g., XXXX or [REDACTED]).
Data Integrity: Please be assured that all technical data relevant to this bug—including the Call Trace, hardware IDs, register states, memory addresses, and driver initialization sequences—remains completely untouched and 100% intact for accurate debugging.

Additional context and offer for debugging:
I wanted to add that despite the xe_display_flush_cleanup_work panic, the kernel does not completely halt. The system survives in a headless state — network stack, Bluetooth, and security modules (AppArmor, UFW) continue to function normally in the background. The crash is strictly isolated to the display stack.
If it helps the team narrow down the race condition, I am ready to run the following isolated tests and provide the corresponding dmesg / journalctl logs:

Runtime PM Test: Booting with xe.runpm=0 to confirm if explicitly disabling runtime power management completely masks the NULL pointer dereference.
Single GPU Isolation: Forcing the xe driver on only one device at a time (e.g., xe.force_probe=46a6 for iGPU only, or 5693 for dGPU only) while completely disabling i915. This could help determine if the panic is a result of multi-GPU resource synchronization (Deep Link) or if it reproduces on a single isolated unit.

upd-,
Critical architectural observation regarding hybrid Gen 12 + Gen 12.7 setups:
I want to emphasize the severity and the likely architectural root cause of this bug. The panic happens at the earliest initramfs stage during KMS initialization, completely blocking the boot process before the LUKS decryption prompt can even be answered. Both GPUs are killed immediately upon the first display idle trigger.
It appears this is a global synchronization issue for hybrid mobile setups combining Xe-LP (Core 12th gen iGPU) and Alchemist / DG2 (Arc dGPU).
Since the laptop display is physically wired to the iGPU, forcing the xe driver on both devices creates a fatal race condition in xe_display_pm_runtime_suspend. It seems the driver lacks a unified "channel" or synchronization logic to safely handle shared display structures between these two different generations of hardware when transitioning to a low-power state. The iGPU drops the display structure pointer to NULL, and the dGPU immediately hits a dereference panic trying to access it.
This makes the xe driver completely unusable for any laptop with a 12th Gen CPU + Arc dGPU combo, acting as a hard boot-blocker.
I am commenting here because the suggested "solution" is fundamentally broken and highlights a Catch-22 in your current driver stack.
I spent over 4 days debugging a hard kernel panic on a half-dead system, collecting dumps, and isolating the exact race condition in the xe driver. To have this dismissed purely on bureaucratic grounds ("not officially supported") is extremely frustrating, especially given the alternative you suggested.
Here is the reality of using the "officially supported" i915 driver on this DG2 hybrid setup: it completely breaks Vulkan initialization. It throws the following fatal error: vkGetPhysicalDeviceDisplayPlanePropertiesKHR failed with ERROR_OUT_OF_HOST_MEMORY
So, the situation is:

The modern xe driver has a fatal NULL pointer dereference (Kernel Panic) that you refuse to patch.
The legacy i915 driver completely fails to allocate display planes for Vulkan on this hybrid architecture.

I am not going to jump through bureaucratic hoops, open new tabs, and create duplicate issues in the legacy i915 tracker just to be bounced around again.
The logs, the hardware IDs, and the exact point of failure for the kernel panic are all documented right here. If Intel's official stance is to leave a fatal kernel panic unpatched in the modern driver while the legacy driver remains unusable for DG2 hybrid setups, then this platform is effectively dead on Linux.
Do with this information what you will.

P.S. (Follow-up regarding the i915 recommendation):
Just to add to the absurdity of the "switch to i915" suggestion, I just pulled the dmesg logs for i915 on this exact hybrid setup. The display pipeline and dGPU firmware initialization are completely broken at a fundamental level:

i915 0000:00:02.0: [drm] Selective fetch area calculation failed in pipe A PSR2 is failing on the iGPU. This causes transient phantom pixels (FIFO underruns) and completely corrupts the framebuffer LUT at 100% display brightness, resulting in black screens for hardware-accelerated apps (like Spotify).
i915 0000:03:00.0: [drm] GT0: HuC: timed out waiting for MEI GSC The legacy driver cannot even reliably initialize the dGPU firmware without timing out.

These aren't just minor visual glitches; these are deep, hybrid-specific architectural failures. No sane user is going to debug this on a legacy driver. If I were to take your advice and open a ticket for these hardware desyncs and firmware timeouts on the i915 tracker, I wouldn't just get bounced around — I would likely be completely ignored. Nobody there is going to untangle a DG2 hybrid routing nightmare on a deprecated stack.
Pushing users to a legacy driver that literally cannot draw pixels correctly, breaks Vulkan, and fails to load firmware on this hardware is not a solution. It's a dead end.

My original ticket regarding this issue on GitLab was hastily closed by maintainers without a proper fix. I am leaving this fully documented analysis here on GitHub. If this helps any other researcher or user debugging this hybrid routing nightmare on Linux, use this information as you see fit.

[ExtremeLiquidCxr]

Please be aware that forcing the xe driver on only one device at a time will likely work only if your laptop has a physical hardware MUX switch, or if you are using a 13th Gen (or newer) processor where the xe driver is natively prioritized for the iGPU. On standard 12th Gen hybrid laptops without a MUX switch, attempting to isolate the GPU will fail due to the physical display routing.