[SP7][6.19.8] Kernel panic in __dma_tx_complete during s2idle suspend (intel-lpss/idma64/surface_serial_hub)

[serika12345]

Suspend is intermittently failing on a Surface Pro 7. On an affected cycle,
the device becomes completely unresponsive and cannot be resumed with the
power button. A long power-button press is required to force it off.

The pstore log shows that this is not a wake-button failure: the kernel
panics while entering s2idle, shortly after suspending the consoles.

The failure is sporadic. Many suspend/resume cycles complete successfully
with the same kernel.

Environment

• Hardware model: Microsoft Surface Pro 7
• Kernel version:
  Linux surface 6.19.8 #1-NixOS SMP PREEMPT_DYNAMIC Fri Mar 13 16:26:05 UTC 2026 x86_64 GNU/Linux
• Distribution: NixOS 26.05.20260722.b3fe958 using the Microsoft Surface
  hardware profile / linux-surface-patched kernel
• Firmware: UEFI/BIOS 24.109.140 dated 2025-07-21
• Available sleep state: [s2idle] only
• No S3/deep sleep is exposed by the firmware

dmesg output (recovered from pstore)

[39720.016162] PM: suspend entry (s2idle)
[39720.028766] Filesystems sync: 0.012 seconds
[39720.128715] Freezing user space processes
[39720.130226] Freezing user space processes completed (elapsed 0.001 seconds)
[39720.130232] OOM killer disabled.
[39720.130233] Freezing remaining freezable tasks
[39720.131305] Freezing remaining freezable tasks completed (elapsed 0.001 seconds)
[39720.131307] printk: Suspending console(s) (use no_console_suspend to debug)
[39720.154324] intel-lpss 0000:00:1e.0: dma_pool_destroy dma3chan1 busy
[39720.154430] BUG: kernel NULL pointer dereference, address: 0000000000000000
[39720.154432] #PF: supervisor read access in kernel mode
[39720.154433] #PF: error_code(0x0000) - not-present page
[39720.154436] Oops: Oops: 0000 [#1] SMP NOPTI
[39720.154438] CPU: 7 UID: 0 PID: 0 Comm: swapper/7 Not tainted 6.19.8 #1-NixOS PREEMPT(lazy)
[39720.154440] Hardware name: Microsoft Corporation Surface Pro 7/Surface Pro 7, BIOS 24.109.140 07/21/2025
[39720.154441] RIP: 0010:__dma_tx_complete+0x27/0x1a0
[39720.154494] Call Trace:
[39720.154495]  <IRQ>
[39720.154501]  vchan_complete+0x28c/0x2e0 [virt_dma]
[39720.154503]  ? __pfx___dma_tx_complete+0x10/0x10
[39720.154506]  tasklet_action_common+0xc8/0x230
[39720.154510]  handle_softirqs+0xe6/0x2a0
[39720.154518]  __irq_exit_rcu+0xc8/0xf0
[39720.154521]  common_interrupt+0x87/0xa0
[39720.154525]  </IRQ>
...
[39720.216662] Kernel panic - not syncing: Fatal exception in interrupt

Steps to reproduce

1. Boot normally.
2. Suspend using the power button or systemctl suspend.
3. Resume and repeat.
4. Intermittently, the system becomes completely unresponsive while entering
   suspend.
5. Hold the power button to force the device off, then boot again.

Expected behavior

The device should enter s2idle and resume when the power button is pressed.

Actual behavior

The kernel occasionally panics during suspend entry. Since the kernel has
already panicked, pressing the power button does not resume the device.

Affected device path

The device reported by the panic maps to the Surface Serial Hub:

0000:00:1e.0
  driver: intel-lpss
  PCI ID: 8086:34a8
  idma64.4
  dw-apb-uart.4
    serial0-0
      driver: surface_serial_hub
      ACPI ID: MSHW0084

The two DMA channels exposed by this controller are dma3chan0 and
dma3chan1.

Initial analysis

The crash instruction is inside __dma_tx_complete(), which accesses
dma->txchan->device. The NULL value is consistent with dma->txchan
having already been cleared during serial8250_release_dma().

Immediately before the NULL dereference, the kernel reports that the
dma3chan1 pool is still busy. The stack then shows a delayed completion
callback running through vchan_complete.

My current interpretation is that a DMA completion callback can race with
the 8250/idma64 channel teardown during suspend. One possible trigger is
pending Surface Serial Hub traffic while its parent UART is being suspended.
This is an inference from the trace, not yet proven.

The relevant Linux 6.19.8 code paths appear to be:

• drivers/tty/serial/8250/8250_dma.c: __dma_tx_complete() and
  serial8250_release_dma()
• drivers/dma/idma64.c: idma64_terminate_all() and
  idma64_synchronize()
• drivers/dma/virt-dma.c: vchan_complete()
• drivers/platform/surface/aggregator/core.c:
  ssam_serial_hub_pm_suspend()

Related issue

Issue #1552 reports suspend failures on the same Surface Pro 7 UART path:

#1552

That issue contains:

port dw-apb-uart.4:0.0: PM: dpm_run_callback():
pm_runtime_force_suspend+0x0/0x130 returns -16
port dw-apb-uart.4:0.0: PM: failed to suspend: error -16

It may point to the same UART/Surface Serial Hub suspend interaction, but it
does not contain this DMA callback panic, so this appears to be a distinct
failure.

Checks already performed

• The power-button input device is present and works before suspend.
• The gpio-keys device has power/wakeup set to enabled.
• systemd-logind is configured to suspend on the power button.
• Earlier suspend/resume cycles succeed with the same kernel.
• No corresponding i915 error appears at the failing suspend.
• The latest available Surface Pro 7 firmware is installed.

I can provide the complete pstore dump after redacting unrelated Wi-Fi and
Bluetooth addresses. I can also test a diagnostic patch or a per-device PIO
fallback if useful.