NVIDIA / NVIDIA/open-gpu-kernel-modules
T1200 (TU117GLM): ACPI power-source/D-notify returns 0x11 (NV_ERR_GPU_NOT_FULL_POWER); kernel suspend notifier then aborts s2idle until reboot
Nobody has claimed this yet.
- Dominant language
- C
- Stars
- 17.4k
- Forks
- 1.9k
- PR merge metrics
- No merged PRs in 30d
Description
NVIDIA Open GPU Kernel Modules Version
610.57.04 (nvidia-open-dkms on Arch)
Please confirm this issue does not happen with the proprietary driver (of the same version). This issue tracker is only for bugs specific to the open kernel driver.
- I confirm that this does not happen with the proprietary driver package.
Not A/B tested. Turing TU117 can still load the closed module; this report is from nvidia-open only. Happy to retest closed vs open if that is required.
Operating System and Version
Arch Linux (Omarchy 4.0.4-1)
Kernel Release
7.2.3-arch1-3 (stable, not -rc)
Please confirm you are running a stable release kernel (e.g. not a -rc). We do not accept bug reports for unreleased kernels.
- I am running on a stable kernel release.
Hardware: GPU
NVIDIA T1200 Laptop GPU, 10de:1fbc (TU117GLM), VBIOS 90.17.89.00.17, GSP firmware 610.57.04
Hybrid: Intel Tiger Lake UHD (8086:9a60) + NVIDIA T1200 at 0000:01:00.0
Describe the bug
On this Intel+NVIDIA laptop, unplugging a Thunderbolt 4 dock (AC loss + display tear-down) while the lid is already closed makes RM reject ACPI power-source and D-notifier events with status=0x11.
In nvstatuscodes.h that is NV_ERR_GPU_NOT_FULL_POWER, not NV_ERR_INVALID_STATE.
nv_pm_notifier() then returns NOTIFY_BAD, so systemd-sleep aborts:
Failed to put system to sleep. System resumed again: Operation not permitted
NVRM: PM hibernate notifier failed: 0x11
NVRM: PM suspend notifier failed: 0x11
After that, every further suspend/hibernate/hybrid-sleep fails the same way until a cold reboot. nvidia-smi still sees the GPU (it does not fall off the bus).
Related but not the same as #1209 (same rm_power_source_change_event ... 0x11 on s2idle power-source change; #1209 was Blackwell + GPU detach + shutdown hang, later closed as an OEM iGPU BIOS setting).
Hardware Profile
- Device: HP ZBook Fury 17.3 inch G8 Mobile Workstation (
HP 886D) - BIOS: T95 Ver. 01.25.00 (2026-06-12)
- CPU: Intel Tiger Lake-H
- GPU: NVIDIA T1200 Laptop GPU (
10de:1fbc) - Dock: HP Thunderbolt 4 Ultra 180W/280W G6 (
thunderbolt 0-3) mem_sleep:[s2idle] deep(default s2idle)
Module params at the time of the failure (and still now):
PreserveVideoMemoryAllocations: 0
UseKernelSuspendNotifiers: 1
EnableS0ixPowerManagement: 0
DynamicPowerManagement: 3
/proc/driver/nvidia/gpus/0000:01:00.0/power:
Runtime D3 status: Disabled by default
Video Memory Off: Supported
S0ix Power Management:
Platform Support: Supported
Status: Disabled
To Reproduce
- Docked on the TB4 dock, lid already closed (clamshell, iGPU/dGPU hybrid, external displays).
- Leave the machine idle on AC. Lid-close-on-AC is ignored (expected).
- Unplug the Thunderbolt dock and walk away without opening the lid.
- Userspace requests sleep (
systemctl suspend,suspend-then-hibernate, orhybrid-sleep— all fail the same way once RM is wedged).
First failure observed after a successful hybrid-sleep resume that coincided with ACPI power-source change + TB re-enumerate/disconnect. After that, undock-with-lid-closed immediately reproduces the abort.
Expected vs. Actual Behavior
Expected: RM brings the GPU to full power if needed, handles AC→battery / D-notify, and the kernel suspend notifier returns NOTIFY_OK. If sleep cannot proceed, RM recovers so a later suspend can succeed without a reboot.
Actual:
- ACPI path fails first:
NVRM: rm_power_source_change_event: Failed to handle Power Source change event, status=0x11
NVRM: RmHandleDNotifierEvent: Failed to handle ACPI D-Notifier event, status=0x11
Those map to RmPowerSourceChangeEvent() → NV2080_CTRL_CMD_PERF_SET_POWERSTATE and RmHandleDNotifierEvent() → NV2080_CTRL_CMD_PERF_SET_AUX_POWER_STATE in src/nvidia/arch/nvalloc/unix/src/osapi.c.
- Kernel suspend notifier then fails and aborts system sleep (
kernel-open/nvidia/nv.c):
status = nv_set_system_power_state(power_state, nv_procfs_pm_action_depth);
if (status != NV_OK) {
nv_printf(NV_DBG_ERRORS, "NVRM: PM %s notifier failed: 0x%x\n", name, status);
return NOTIFY_BAD;
}
-
Rollback also fails (
WARN_ONinnv_restore_user_channels/nv_preempt_user_channels,nv.c:4524/nv.c:4574/nv.c:4872). -
GPU remains in
nvidia-smi, but every subsequent PM notifier returns0x11until reboot. Userspace idle/lid policy retries sleep every ~30–60s; the machine never actually sleeps.
Bug Incidence
Always, once the first 0x11 has occurred on that boot. The unwedge is a full reboot, not nvidia-smi reset.
nvidia-bug-report.log.gz
Not attached (no interactive nvidia-bug-report.sh run). Journal excerpts above are from the failing boot. Can capture nvidia-bug-report.log.gz on request.
More Info
Open-module source on this machine matches the packaged tree at /usr/src/nvidia-610.57.04/.
0x11 in this tree:
NV_STATUS_CODE(NV_ERR_GPU_NOT_FULL_POWER, 0x00000011, "GPU not in full power")
So this looks like RM/GSP refusing register access because the GPU is not at full power in the same window as dock/AC teardown, then the open nv_pm_notifier turning that into a hard system-sleep failure and never recovering.
I can add a full nvidia-bug-report.sh dump or retest with NVreg_EnableS0ixPowerManagement=1 if useful. I have not changed NVIDIA module options as a workaround; userspace policy (delay sleep after undock, do not retry 0x11) is the only local mitigation.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with src/nvidia/arch/nvalloc/unix/src/osapi.c and kernel-open/nvidia/nv.c, focusing on the power-source and D-notifier paths and the nv_pm_notifier rollback locations named in the report. Reproduce the dock-undock sequence with the lid closed and capture the requested diagnostic log if possible. Done means the power event no longer leaves suspend permanently failing with 0x11 until reboot.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- c, linux
- Domain
- operating-systems
- Issue type
- Bug
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 42/100