A Dual-GPU Linux Desktop That Kept Freezing: From NVIDIA Xid Errors to Two BIOS Switches
My CachyOS + Niri machine froze three times in two days. The system was alive the whole time; the RTX 4060 driving the displays was the problem. Here is how I tracked down two different failure modes, and the wrong turns along the way.
In two days my desktop froze three times. The screen stopped, the mouse and keyboard did nothing, and Ctrl+Alt+F3 would not switch to a text console. Every time, the only way out was a reboot.
It turned out that the system itself was fine the whole time. The problem was the RTX 4060 driving my displays, and the three freezes were two different faults that needed two separate fixes in the BIOS.
The machine
| Item | Details |
|---|---|
| OS | CachyOS (Arch-based), kernel 7.2.6 |
| Desktop | Niri (Wayland compositor) + Noctalia |
| Motherboard | ASUS ROG STRIX Z690-A GAMING WIFI D4, BIOS 2103 |
| GPU 1 | RTX 2080 Ti in the CPU-attached x16 slot, compute only (ComfyUI) |
| GPU 2 | RTX 4060 in a chipset-attached x4 slot, both monitors plugged into it |
| Driver | NVIDIA open kernel modules 615.71.09 |
That last GPU row turns out to matter a lot.
A frozen screen is not a dead system
The first instinct is “the machine hung”. It is worth separating two cases:
- Display frozen: nothing on screen changes, but processes keep running
- System hung: the kernel itself is stuck and nothing works
The simple test is to connect from another device, over SSH or any remote session. During the third freeze I was connected from another device, and commands ran normally: 47 GB of RAM free, load average under 1. The system was alive; I just could not see it.
That also explains why Ctrl+Alt+F3 did nothing. Switching to a text console needs the same GPU to put pixels on the screen. Niri’s log shows it did receive the switch request (pausing session), but the kernel immediately started printing:
[nvidia-drm] [GPU ID 0x00000800] Flip event timeout on head 0
[nvidia-drm] [GPU ID 0x00000800] Flip event timeout on head 1So “try Ctrl+Alt+F3 and see if you get a console” is not a useful test in this situation, even though it was the first thing suggested to me.
The logs: three freezes, two failure modes
journalctl -k -b -N shows kernel logs from earlier boots. The three freezes:
| Time | First error | Type |
|---|---|---|
| 9/24 04:10 | Xid 119: GSP unresponsive for 45 s, driver then resets the GPU | PCIe communication |
| 9/24 21:06 | mapping multiple BARs → Xid 31 → Xid 56 |
BAR1 window |
| 9/25 00:00 | PCIe CmpltTO → AER: device recovery failed → Xid 56 |
PCIe communication |
Every error came from PCI:0000:08:00, the 4060. The 2080 Ti never reported anything.
Failure mode 1: the BAR1 window is too small
The 21:06 freeze started with these lines:
NVRM: dmaAllocMapping_GM107: can't alloc VA space for mapping.
resource sanity check: requesting [mem 0x402fd60000-0x403008ffff],
which spans more than 0000:08:00.0 [mem 0x4020000000-0x402fffffff 64bit pref]
caller __nv_drm_gem_nvkms_map+0xb0/0x120 [nvidia_drm] mapping multiple BARsBAR1 is the address window the CPU uses to reach video memory. On this 4060 it was 0x4020000000-0x402fffffff, only 256 MB. The driver tried to map a range that ran past the end of that window and the mapping failed. Chrome then hit an Xid 31 (GPU page fault), the display engine reported Xid 56, the driver’s watchdog logged GPU is probably locked, and the desktop froze.
Only about 1 GB of VRAM was in use at the time. The card was not out of memory; it was out of window.
/sys/bus/pci/devices/0000:08:00.0/resource1_resize showed the 4060 supports a BAR of up to 8 GB. Resizable BAR was simply off in the BIOS, so it got the default 256 MB.
Failure mode 2: PCIe completion timeouts
The 00:00 freeze was a completely different story, with no BAR errors at all:
pcieport 0000:00:1c.4: AER: Multiple Uncorrectable (Non-Fatal) error message received from 0000:08:00.0
nvidia 0000:08:00.0: PCIe Bus Error: severity=Uncorrectable (Non-Fatal), type=Transaction Layer
nvidia 0000:08:00.0: [14] CmpltTO (First)
nvidia 0000:08:00.0: AER: can't recover (no error_detected callback)
pcieport 0000:00:1c.4: AER: device recovery failed
NVRM: Xid (PCI:0000:08:00): 56, CMDre 00000005 00000240 ffffffff 00000007 00000000CmpltTO is a Completion Timeout: the CPU sent a request to the GPU and never got an answer. The kernel’s PCIe error recovery (AER) tried to rescue the card, but the nvidia driver does not implement the recovery callback, so recovery failed. From that point the GPU was effectively gone from the bus, and only a reboot could bring it back.
The 04:10 freeze was an Xid 119: the driver waited 45 seconds for the GPU’s GSP processor to respond and gave up. Same symptom, a request goes out and no answer comes back, so I put it in the same group.
Why the 4060, and not the 2080 Ti
Here is the PCIe topology (lspci -tv):
-[0000:00]-+-01.0-[01]----00.0 RTX 2080 Ti ← CPU-attached x16
...
+-1c.1-[06]----00.0 ASMedia SATA controller
+-1c.3-[07]----00.0 Intel I225-V Ethernet
+-1c.4-[08]--+-00.0 RTX 4060 ← chipset-attached x4The two slots take very different paths:
- 2080 Ti: CPU → slot. Short traces, nothing in between.
- 4060: CPU → DMI link → Z690 chipset → slot. A longer path, sharing the chipset with the SATA controller and the NIC.
My first guess was that x4 bandwidth was not enough. That was wrong. Two 1080p monitors need very little bandwidth, and x4 is plenty. Too little bandwidth makes things slow and choppy; it does not make a device vanish from the bus.
The real issue is link reliability. PCIe has a power-saving feature called ASPM that puts an idle link into a low-power state and wakes it when there is traffic. Every wake-up means the two ends renegotiate the link. A link with little signal margin occasionally fails that step, and the failure shows up exactly as a request timeout.
I cannot prove this directly: the log records the timeout, not the link state just before it. But ASPM is the most common source of instability on a link like this, and the easiest one to rule out.
The fix: two switches in the BIOS
On this ASUS board, press Del to enter the BIOS and F7 for Advanced Mode:
| Setting | Fixes | Location (ASUS Z690; names vary slightly by version) |
|---|---|---|
| Above 4G Decoding + Resizable BAR → Enabled | Failure mode 1 | Advanced → PCI Subsystem Settings |
| ASPM options → Disabled | Failure mode 2 | Advanced → Platform Misc Configuration, plus the PCH / DMI ASPM options |
Checking that it worked
After rebooting, check BAR1 first:
nvidia-smi -q -i 1 | grep -A1 "BAR1 Memory Usage"BAR1 Memory Usage
Total : 8192 MiBThe address range in the kernel log changed too:
# before
pci 0000:08:00.0: BAR 1 [mem 0x4020000000-0x402fffffff 64bit pref] # 256 MB
# after
pci 0000:08:00.0: BAR 1 [mem 0x4000000000-0x41ffffffff 64bit pref] # 8 GBASPM lives in the PCIe Link Control register, which needs root to read:
sudo lspci -vvs 00:1c.4 | grep LnkCtl:
sudo lspci -vvs 08:00.0 | grep LnkCtl:Check both ends of the link, the chipset root port and the GPU. After the change, both show:
LnkCtl: ASPM Disabled; RCB 64 bytes, LnkDisable- CommClk+One trap here: the boot log contains ACPI FADT declares the system doesn't support PCIe ASPM, which looks like proof that ASPM is off. But on this machine that line appears in every boot, including the ones before I changed the BIOS. It only means the kernel leaves ASPM alone and defers to the BIOS. It says nothing about what the BIOS actually set. I used it as evidence at first and only caught the mistake by checking older logs.
Also, nvidia-smi shows the 4060’s link at Gen1 when idle. That is the driver lowering link speed to save power, which is separate from ASPM. It goes back up under load.
Wrong turns
The mistakes made during this investigation:
- Blaming x4 bandwidth. The real issue was link reliability. Bandwidth affects speed; it does not make devices drop off the bus.
- Using Ctrl+Alt+F3 to tell whether the system was alive. When the display GPU itself is gone, the console switch needs that same GPU, so the test tells you nothing. Connecting from another device is the test that works.
- Treating the FADT log line as proof ASPM was off. It appears in logs from before the BIOS change too.
- Treating three freezes as one bug. There were two faults: a BAR1 window that was too small, and PCIe completion timeouts. Fixing only one would have left the other.
Still open
- Since the BIOS change the machine has run for more than 8 hours without a freeze, but it needs a few more days of normal use.
- A few hours before the 00:00 freeze, another device behind the chipset (
04:00.0, an NVMe device with a Realtek controller that the system does not expose as a disk) logged one non-fatal AER error. It happened once and caused no problems, but it sits on the chipset side as well. If it keeps happening, the chipset path as a whole may have weak signal quality. - If the freezes come back, the next steps in order: update the BIOS (2103 dates from 2022), swap the two cards so the display GPU sits in the CPU-attached slot, or move the monitors to the 2080 Ti.
Cheat sheet
Next time the desktop freezes, in this order:
# 1. Connect from another device and confirm the system is alive
uptime; free -h
# 2. GPU and PCIe errors in the current boot
journalctl -k -b | grep -E "Xid|AER|CmpltTO|multiple BARs|Flip event timeout"
# 3. The previous boot, if you already rebooted
journalctl -k -b -1 | grep -E "Xid|AER|CmpltTO|multiple BARs"
# 4. Which card is where, and its link state
lspci -tv
nvidia-smi --query-gpu=index,pci.bus_id,name,display_active,pcie.link.gen.current,pcie.link.width.current --format=csvmapping multiple BARs points to the BAR1 window. CmpltTO or device recovery failed points to the PCIe link.