I don't understand NVIDIA's idea of fun. I don't understand Old Huang's (Jensen) idea of fun either.

After my previous Xid 62 adventure, I ran into Xid 109 CTX SWITCH TIMEOUT. This one was worse. At some unknown point, the GPU would log Xid 109 without much fanfare. About ten minutes later, Wi-Fi would stop responding and my SSH session would drop.

Normally that means hauling over a monitor and keyboard for another round of combat. Fortunately, I had an Ethernet cable.

Xid 109: My Own Kernel Was Too Slow

Xid 109 means a GPU context-switch timeout. The driver may terminate the offending channel.

After debugging Xid 62 last time, I immediately rejected the Agent's suggestion that the hardware might be at fault. The actual culprit was my WGSL GPU kernel.

In singlefs, the recovery kernel's mapping_lookup performed a linear scan, twice per unit. At its worst, there were 1,124 mapping entries and 2,264 lookups, giving the overall work roughly O(N²) growth. To make matters worse, task-server initially submitted ten states at once for efficiency. The heavy validation workload kept the GPU busy too long, preventing a timely context switch and triggering Xid 109.

The fix was straightforward:

  • Replace the linear scan in mapping_lookup with binary search.
  • Start with one state per initial dispatch, then adapt the batch size based on measured runtime.
  • Explicitly mark GPU device loss, so a test that never really ran cannot be counted as a successful bug detection. Earlier results need another look under this rule.

After the changes, the longest measured GPU slice was 0.203 seconds. All nine tests passed, and neither RTX 5060 Ti showed a new Xid 109 in the subsequent log checks.

But Why Did Wi-Fi Die Too?

My working theory is that after Xid 109, something went wrong with PCIe or interrupt handling—possibly an interrupt storm—which indirectly wedged the mt7925e Wi-Fi driver.

The PCIe devices on this machine are:

  • RTX 5060 Ti: 10:00.0
  • Wi-Fi: 08:00.0, using mt7925e
  • Ethernet: 07:00.0

The GPU and Wi-Fi share the chipset's upstream path, though they are not on the same downstream PCIe port.

In both incidents, the first DNS failures appeared roughly 10–15 minutes after Xid 109. But I have no direct proof. There were no nobody cared, Disabling IRQ, or PCIe AER messages. The mt7925e timeouts were logged only after I manually reconfigured the network or unloaded the driver. I have also seen Wi-Fi failures without a nearby Xid 109.

After fixing the WGSL kernel, Wi-Fi stayed up for 12 hours. Interesting, but hardly proof of causation.

Recovering Wi-Fi Without Rebooting

I hope you never need these commands. Ethernet was still working, so I connected over SSH:

ssh -i ~/.ssh/id_ed25519 fy5090@192.168.100.1 # 1. Try a lightweight network reconfiguration (leaves Ethernet alone) sudo networkctl reconfigure wlp8s0 # 2. If that fails, bring the Wi-Fi interface down and back up sudo networkctl down wlp8s0 && sudo networkctl up wlp8s0 # 3. Still no luck? Check the actual wpa service name systemctl list-units --all | grep wpa sudo systemctl restart wpa_supplicant # Or: sudo systemctl restart wpa_supplicant@wlp8s0

If the driver itself is completely wedged, those commands may not help. With Ethernet or a local console available, you can try reloading it:

sudo modprobe -r mt7925e sudo modprobe mt7925e

Even unloading the driver can hang, so save your logs first.

One Last Thing

Xid 109 is identified and fixed: the recovery kernel's near-O(N²) lookup was the culprit. The Wi-Fi freeze is still unexplained: the shared PCIe path and interrupt storm remain a hypothesis, not a proven cause.

I've installed wifi-watchdog to capture evidence the next time it happens.

Old Huang is happy, so I'll call him Huang-le (le means "happy").

I'm not happy. NVIDIA wants a lot of dao-le ("dollar").