You are not logged in.
I am looking for help diagnosing intermittent hard freezes on a ThinkPad T15p Gen 3. The machine has frozen across many kernel/NVIDIA versions for more than six months. I am deliberately avoiding broad combinations of kernel parameters and would appreciate advice on the next discriminating test or capture method.
Hardware:
Model: Lenovo ThinkPad T15p Gen 3, 21DA0004GE
CPU: Intel Core i7-12700H (Alder Lake-P)
iGPU: Intel Iris Xe, PCI 8086:46a6, i915 drives the internal panel
dGPU: NVIDIA GeForce RTX 3050 Mobile / GA107M, PCI 10de:25a2
Memory: 32 GiB, 2 x 16 GiB Micron DDR5-4800 CT16G48C40S5.C8A1, non-ECC
Storage: KIOXIA BG5 1 TB NVMe, firmware 1110ANLA
Ethernet: Intel I219-V / e1000e, PCI 8086:1a1f
Firmware: BIOS N3EET44W 1.68 (2026-02-26), EC N3EHT25W
Current Software And Baseline:
Arch Linux kernel: 7.1.8-arch1-3
Plasma: 6.7.4
Session: Plasma Wayland
NVIDIA module/userspace: proprietary 580.178.04
NVIDIA GSP: enabled, firmware 580.178.04
NVIDIA RTD3: disabled (NVreg_DynamicPowerManagement=0)
NVIDIA packages: nvidia-580xx-dkms 580.178.04-1, nvidia-580xx-utils 580.178.04-1
Kernel command line: nvidia_drm.modeset=1 pcie_aspm=off
Sleep state: s2idle only
Microcode: intel-ucode 20260812-1
The NVIDIA module is out-of-tree/DKMS and therefore taints the kernel. I understand that this limits upstream support, but the failures also occurred with NVIDIA open modules.
Symptom:
The usual symptom is a complete-looking freeze: display and input stop responding, virtual TTY switching fails, and a forced power-off is eventually needed. It has happened during ordinary desktop use, paused fullscreen video, browser use, low activity, and once during ddrescue; it is not tied only to high GPU or CPU load.
Intel VT-d and interrupt remapping are enabled by firmware; no DMAR fault was logged. The NMI watchdog was enabled during incidents, but no lockup backtrace persisted. Some, but not all, abruptly ended boots had a Chromium-family browser launched through prime-run; this is correlation only.
Persistent journal records end abruptly and the next boot recovers the ext4 journal / reports an unclean EFI partition. There is no orderly shutdown.
Completed Tests And Negative Evidence:
- Lenovo UEFI Diagnostics "Run All" completed in about 7 hours 45 minutes: 9 passed, 0 failed, 0 warnings; result "U1E5TLGFT-M79L18".
- NVMe SMART and NVMe error log are clean: 0 media/data-integrity errors, 0 error-log entries, healthy PCIe 4.0 x4 link.
- No local pre-freeze signature has been found for NVIDIA Xid/GSP errors, i915 GPU hang/reset, NVMe timeout/reset, PCIe AER/DPC, DMAR faults, MCE/EDAC, thermal shutdown, watchdog/soft-lockup/hard-lockup, RCU stall, panic, or Oops.
- BIOS/EC are current.
- pcie_aspm=off did not stop freezes.
- NVIDIA RTD3 enabled versus disabled did not stop freezes.
- NVIDIA open 610.43.02/610.43.03 and proprietary 580.178.04 both froze.
- Proprietary 580 with GSP disabled also froze repeatedly. GSP is now restored to the normal enabled state because that test was negative.
- The BIOS/EC update to 1.68 did not establish a fix; freezes occurred both before and after the update.
- No consistent correlation with suspend/lid wake, AC state, dock/USB-C hot-plug, or external-display use has been established.
Remote Capture Results:
I have a separate Windows machine on wired Ethernet recording ICMP ping and netconsole. Netconsole uses an explicit receiver MAC and has been verified while the laptop is healthy. Physical Magic SysRq was also verified while healthy.
The results are mixed:
1. In one incident, ping first failed at 03:36:56, but the netconsole receiver later received a routine kernel perf message timestamped about 03:57:44 from the same boot. This proves that at least one CPU and the netpoll transmit path were alive after ICMP stopped. It does not prove normal IP receive, userspace, or the desktop was alive.
2. In a later incident, the same boot had successfully sent physical SysRq blocked-task and all-CPU NMI backtraces over netconsole while healthy. During the actual freeze, ping failed, physical SysRq was attempted but produced no netconsole output, and netconsole became silent. No kernel diagnostic survived.
Thus I may have either two failure classes or one lower-level fault with variable severity. I do not want to overinterpret the final user-journal messages; in one incident the journal stopped at least 30 seconds before the last successful external ping.
Questions:
1. Does the combination of a partial-live incident and a later SysRq/netconsole-dead incident point to a known Alder Lake-P, VT-d interrupt-remapping, PCIe/PCH, i915, or NVIDIA KMS failure mode?
2. Is there a low-risk capture mechanism appropriate for an Arch systemd-boot system when normal netconsole and physical SysRq may both fail?
3. Of these one-variable diagnostic tests, which should come first: intremap=off, a narrow i915/DRM ftrace recorder for partial-live events, or another targeted capture approach?
Please let me know what additional evidence would be most useful before I change another variable.
Offline