gpu unlock error -110: a warm reboot is not a cold boot
A gpu_unlock error -110 timeout means the log caught the card no longer answering. A gpu_unlock install that lands here often starts working after a real power cycle, but a timeout that survives a cold boot needs topology or hardware diagnosis. A reboot is not a power cycle.
gpu unlock -110 is a timeout, not an absent card
The two lines arrive together, and the second one is the one that gets quoted.
NVRM: GPU 0000:01:00.0: GPU is lost. Reboot the system to recover this GPU
nvidia: probe of 0000:01:00.0 failed with error -110-110 is ETIMEDOUT. The driver waited for the device to answer and the wait ran out. That is a different shape from -2, where a file was missing, and from -16, where another driver already owned the device. In both of those the card responded; here it did not.
The log line is also worth more than the number, because GPU is lost is the driver describing its own state rather than the card's. The device is still on the bus. It is not answering the way the probe needs it to, and the sentence in the log already tells you what the driver thinks the fix is.
Why gpu unlock -110 follows a warm boot
A reboot restarts the operating system. It does not remove power from the PCIe slot, so the card comes back up carrying whatever state it had when the machine went down. A cold boot is the other thing: the rails drop, the card reinitialises from nothing, and the previous attempt leaves no trace in it.
The reports cited on this page involve boots that were not cold, which is why gpu_unlock error -110 timeout starts as a boot-state question rather than a hardware verdict.
issue #23 is a pair of 3090s on AlmaLinux, issue #20 is the same arrangement on Fedora, and issue #38 is a 3090 in a Thunderbolt enclosure. [issue #23]
-110
ETIMEDOUT — the device stopped answering
Not a missing driver and not a card that fell out of its slot.
1000µs
Timing budget in the eGPU report
Thunderbolt adds a transport layer that a slot does not have, and the probe has a budget for it.
That is the practical difference a gpu_unlock error -110 timeout makes: one is a failure you can clear in a minute, the other looks permanent. Nothing in the module is corrupted by a timeout. What is left behind is a device in a state the next probe cannot talk to.
Why the card disappears after a gpu unlock timeout
The honest version of the report is that after a gpu_unlock error -110 timeout the card stops being usable to the driver until the machine loses power. nvidia-smi has nothing to show, lspci still lists the device, and the natural conclusion is a dead card.
That conclusion is wrong often enough to be worth stating: the same hardware comes back on the next cold boot in issue #23. [issue #23]
The README describes the underlying behaviour from the other direction, in its rollback notes: if the firmware will not settle, the module keeps its DMA buffer until the next power cycle, and the instruction is to shut down rather than retry. [official README]
So a retry loop is the worst available strategy here. Each attempt runs against a device that was already left in the wrong state, and each one makes the next reboot look more like a hardware failure.
The gpu unlock -110 recovery, in order
Start with this recovery sequence, and stop repeating it if the timeout survives a full power cycle. The first step is the one people skip.
step 1
Shut the machine down
A restart is the failure mode, not a smaller version of the fix. The operating system has to stop and the machine has to stay off.step 2
Remove power, not just the session
Switch the PSU off at the back or pull the cable. On a laptop, shut down, unplug the charger, and remove the battery only if the model makes it user-accessible; otherwise use the manufacturer’s documented hard power-reset procedure. Standby power keeps the card alive otherwise.step 3
Wait for the rails to drain
A few seconds after the fans stop is not the same as the board being empty. Press the power button once with the cable out if your board keeps a charge.step 4
Cold start and read the probe line
If the module runs, the log prints the unlock chain. If the next boot prints -110 again, the card never got a clean start and step 2 was incomplete.
journalctl -k -b | grep gpu_unlock
lspci -nnk -s 0000:01:00.0The first command answers whether the module ran at all, which is the question that decides whether you are still in this failure. The second shows which driver holds the device now. A cold boot that prints -110 again is information: the device did not get the power cycle, or the install has a second problem underneath this one.
What each restart does to gpu unlock
Not every way of "restarting" is equivalent, and the difference is the whole reason this page exists.
- Power behaviour per restart type, and what the unlock looks like afterwards.
Shutdown, power removed, cold start
- What the card does
- Reinitialises from nothing
- Unlock afterwards
- Reapplied at boot by the module
Reboot
- What the card does
- Keeps power and its previous state
- Unlock afterwards
- Not reapplied, and a failed probe can repeat
Suspend to RAM
- What the card does
- Powered off during sleep
- Unlock afterwards
- Reapplied before nvidia resumes the card
Suspend to idle
- What the card does
- Keeps power through the sleep
- Unlock afterwards
- Still in place; the module reads it back
The suspend rows are documented behaviour rather than luck: the module's suspend notifier runs ahead of the one nvidia uses to resume its cards, so the write is back before the driver looks at the device. [official README]
The warm reboot row is the failure this heading describes, and it is the row most advice on the internet gets wrong. Restarting is the one action that reproduces the failure.
An external GPU adds its own timing on top. In issue #38 the probe runs against a budget_us=1000 limit over Thunderbolt 3, and a timeout there can mean the enclosure answered too slowly rather than not at all. [issue #38]
Sequence matters in that setup too: power the enclosure, let the host enumerate it, and only then rely on the boot that unlocks it.
When to stop retrying gpu unlock
A -110 that survives a real cold boot is a different problem, and a few of those are outside anything a reinstall can reach.
- The PCIe segment drops as a whole. On a PEX880xx switch with five 3090s, issue #260 reports DPC and Xid 79 rather than a single unhappy card. That is topology, and it is fixed by isolating the segment or by changing the layout, not by another power cycle.
- The guest is not the right place to debug. A
-110inside a virtual machine belongs to the host, because the host owns the reset path the guest cannot see. - The card is not in the table. A device ID outside the supported list is skipped rather than timed out, but a laptop that powers its discrete GPU down can produce a card that is present and unavailable for a different reason. The gpu unlock compatibility table settles membership in one lookup.
That last one is where laptop reports usually belong. The unlock is a register write, and a machine that cuts power to its discrete GPU between workloads resets it silently, which is the subject of the gpu-unlock laptop page.
Your next gpu unlock step
Cold boot first, then read the log. If the module prints its chain, the failure is behind you and the only remaining question is whether the card is doing the work you expected, which the no-speedup page covers.
If the log is empty rather than timed out, you are in the install-stage family and the gpu unlock install page is where the ordering rules live.
A gpu_unlock error -110 timeout that comes back after all of the above is a topology or power question rather than an install one, and the list above is the short version of it. If it now prints a different code, the troubleshooting index has one page per failure, and -16 is the one most often confused with this one.
Checked VERSION 2.0.0commit fd56c1d