Follow-up, and a correction. First, what you asked for: attached is a dmesg captured on 7.0.0-29.29 with the GPU in the failing state. Second, and more important — while producing it I found that the isolation in my original report was confounded, and I now believe this bug is misattributed to the kernel. This machine has a second, intermittent defect. At boot, the NVIDIA HDA function 0000:02:00.1 sometimes fails its codec probe: snd_hda_intel 0000:02:00.1: azx_get_response timeout, switching to polling mode: last cmd=0x000f0000 snd_hda_intel 0000:02:00.1: Codec #0 probe error; disabling it... snd_hda_intel 0000:02:00.1: no codecs initialized snd_hda_intel 0000:02:00.1: GPU sound probed, but not operational: please add a quirk to driver_denylist When that happens, snd_hda_intel stays bound holding a runtime-PM usage reference it never drops: azx_probe_continue() takes the -ENXIO error path and never reaches the pm_runtime_use_autosuspend/allow/put_autosuspend block, while azx_probe() has already returned 0. Through the quirk_gpu_hda device link (DL_FLAG_PM_RUNTIME — "pci 0000:02:00.1: D0 power state depends on 0000:02:00.0") the reference propagates to the GPU function and pins it at D0/active/usage=1. That is exactly the symptom I reported. I re-checked every boot still held in the persistent journal: boot date kernel probe failed wakeups GPU outcome -7 2026-08-14 -29.29 yes 3 stuck at D0 for 44 h <- the boot this report is based on -6 2026-08-16 -28.28 no 32 healthy -5 2026-08-19 -28.28 no 13 healthy -4 2026-08-20 -28.28 no 5 healthy -3 2026-08-20 -28.28 yes 9 stuck at D0 -1 2026-08-28 -28.28 yes 2 not stuck 0 2026-08-28 -29.29 yes 4 stuck at D0, healthy after rebind Every boot I used as evidence for "-29.29 is broken" carries the probe failure. Every boot I used as evidence for "-28.28 is healthy" does not. Boot -3 shows the same failure producing the same D0 pin on 7.0.0-28.28, so the effect is not specific to -29.29 at all. Direct test today: I booted 7.0.0-29.29 and confirmed the GPU stuck at D0/active/usage=1 with three wakeups inside the first 17 seconds (this is the attached dmesg). I then unbound and rebound only the audio driver, changing nothing else: echo 0000:02:00.1 | sudo tee /sys/bus/pci/drivers/snd_hda_intel/unbind echo 0000:02:00.1 | sudo tee /sys/bus/pci/drivers/snd_hda_intel/bind The codec probed cleanly, and within about 90 seconds both functions reached D3cold — on the same running 7.0.0-29.29 kernel. It has sustained runtime suspend since (runtime_suspended_time 72 s -> 517 s, runtime_active_time frozen, wake counter steady). The second attachment is a dmesg from that healthy state on the same kernel. One thing I cannot explain and am not going to leave out: boot -1 had the probe failure and the GPU still suspended normally. So the failure does not deterministically pin the card. It appears to pin it only when it coincides with the GPU's first RTD3 suspend, which is consistent with the timing in the boots where it did pin. On the suspend/resume step you asked for: I have not performed one. This host is headless, s2idle has never been exercised on it, and the defect is PCI runtime PM (RTD3/D3cold) rather than ACPI system suspend — so I am not certain suspend/resume is the data you need. If it is, tell me and I will arrange physical access and run it. Given all of the above, please close this report as invalid if that is cleanest, or retitle it to the actual defect — snd_hda_intel leaving a runtime-PM reference after a failed codec probe on the NVIDIA HDA function, pinning the GPU at D0 through quirk_gpu_hda. I am glad to gather whatever logs help for the latter; the driver itself suggests a driver_denylist quirk in its own message. Apologies for sending you in the wrong direction. ** Attachment added: "dmesg from 7.0.0-29.29 with the GPU stuck at D0 (HDA codec probe failed on this boot)" https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2163682/+attachment/5996188/+files/dmesg-7.0.0-29-generic.log -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2163682 Title: Regression 7.0.0-28.28 -> 7.0.0-29.29: NVIDIA dGPU never enters runtime suspend (D3cold), idle power +8 W Status in linux package in Ubuntu: Incomplete Bug description: Ubuntu 26.04 LTS, desktop workstation (Dell Precision 3280 CFF) used headless as an LXD host. GPU: NVIDIA GB203GL [RTX PRO 4000 Blackwell SFF Edition] [10de:2c33] (rev a1) audio function [10de:22e9], upstream bridge 00:01.1 [8086:462d] Driver: nvidia-driver-595-open 595.84-0ubuntu0.26.04.1 (NVIDIA open kernel modules 595.84) NVreg_DynamicPowerManagement=0x02, nvidia-drm modeset=0 fbdev=0 With linux-image-7.0.0-28-generic (7.0.0-28.28) the dGPU cycles into runtime suspend normally. After booting linux-image-7.0.0-29-generic (7.0.0-29.29) the card stays in D0/active permanently with power/runtime_usage=1 and never suspends again. Package idle power measured at the wall rises from 10-14 W to about 22 W. The reference (runtime_usage=1) is held by the nvidia driver itself: it survives logging out of the GNOME session, unloading nvidia_drm and nvidia_modeset, and unloading all nvidia modules is worse still (no driver = no P8, +14 W). Cross-check isolating the kernel (same machine, same configuration): kernel nvidia result 7.0.0-28.28 595.71.05 suspends normally (140 and 172 wakeups over two boots) 7.0.0-29.29 595.84 never suspends (3 wakeups, all within the first 15 s of boot) 7.0.0-28.28 595.84 suspends normally <-- same driver as the failing case Last row is the decisive one: identical driver 595.84, identical module set (nvidia, nvidia_uvm, nvidia_modeset, nvidia_drm), identical configuration; only the kernel differs, and the GPU suspends again. The reverse pairing (7.0.0-29 with 595.71.05) is not testable, that driver version is no longer in the archive. Steps to reproduce: 1. Boot 7.0.0-29-generic with nvidia-driver-595-open and NVreg_DynamicPowerManagement=0x02, no CUDA workload, no display attached. 2. Leave the machine idle. 3. cat /sys/bus/pci/devices/0000:02:00.0/power_state -> D0 cat /sys/bus/pci/devices/0000:02:00.0/power/runtime_status -> active cat /sys/bus/pci/devices/0000:02:00.0/power/runtime_usage -> 1 cat /sys/bus/pci/devices/0000:02:00.0/power/runtime_suspended_time -> frozen Expected (and observed on 7.0.0-28.28, ~150 s after boot): power_state D3cold, runtime_status suspended, runtime_usage 0, runtime_suspended_time 142242 ms vs runtime_active_time 8864 ms. Audio function 0000:02:00.1 also D3cold/suspended. Ruled out by measurement, not assumption: GUI session and its GPU clients (gnome-shell/Xwayland/nautilus/gnome-remote-desktop), KMS modules, CUDA/UVM context, VRAM threshold (memory.used 2 MiB against the 200 MB threshold), missing or changed config files, nvidia-persistenced, GPU containers (stopped), d3cold_allowed (1 on GPU, audio function and bridge), and running without the driver at all. The changelog between 7.0.0-28.28 and 7.0.0-29.29 shows no PCI-PM, D3cold, pcieport or ASPM change (CVE fixes plus one amdgpu HMM fix), so the regression is presumably a side effect rather than an intended change. Note on the attached apport data: it was collected while running the *working* kernel 7.0.0-28-generic, because the machine is remote and 7.0.0-29 costs the extra power. Happy to reboot into 7.0.0-29 and attach a second set on request. ProblemType: Bug DistroRelease: Ubuntu 26.04 Package: linux-image-7.0.0-28-generic 7.0.0-28.28 ProcVersionSignature: Ubuntu 7.0.0-28.28-generic 7.0.12 Uname: Linux 7.0.0-28-generic x86_64 NonfreeKernelModules: zfs ApportVersion: 2.34.1-0ubuntu0.1 Architecture: amd64 AudioDevicesInUse: USER PID ACCESS COMMAND /dev/snd/controlC1: gdm-greeter 3041 F.... wireplumber /dev/snd/controlC0: gdm-greeter 3041 F.... wireplumber /dev/snd/seq: gdm-greeter 3003 F.... pipewire CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Mon Aug 17 20:25:43 2026 InstallationDate: Installed on 2026-07-05 (43 days ago) InstallationMedia: Ubuntu 26.04 "Resolute Raccoon" - Release amd64 (20260423.1) Lsusb: Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Lsusb-t: /: Bus 001.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/16p, 480M /: Bus 002.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/9p, 20000M/x2 MachineType: Dell Inc. Precision 3280 Compact ProcEnviron: LANG=en_US.UTF-8 PATH=(custom, no user) SHELL=/bin/bash TERM=xterm-256color ProcFB: ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-7.0.0-28-generic root=/dev/mapper/ubuntu--vg-ubuntu--lv ro quiet crashkernel=2G-4G:320M,4G-32G:512M,32G-64G:1024M,64G-128G:2048M,128G-:4096M RfKill: SourcePackage: linux UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 05/22/2026 dmi.bios.release: 1.24 dmi.bios.vendor: Dell Inc. dmi.bios.version: 1.24.1 dmi.board.name: 0H1DC6 dmi.board.vendor: Dell Inc. dmi.board.version: A00 dmi.chassis.type: 3 dmi.chassis.vendor: Dell Inc. dmi.ec.firmware.release: 1.16 dmi.modalias: dmi:bvnDellInc.:bvr1.24.1:bd05/22/2026:br1.24:efr1.16:svnDellInc.:pnPrecision3280Compact:pvr:rvnDellInc.:rn0H1DC6:rvrA00:cvnDellInc.:ct3:cvr:sku0C81:pfaPrecision: dmi.product.family: Precision dmi.product.name: Precision 3280 Compact dmi.product.sku: 0C81 dmi.sys.vendor: Dell Inc. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2163682/+subscriptions
Комментариев нет:
Отправить комментарий