

Support Case Study

RTX 4060 VFIO Passthrough:
PCIe Dropout Under Load

An RTX 4060 under VFIO GPU passthrough kept hitting PCIe dropout during normal VM workload—config space reading ffffffff, warm reboot required every one to three hours. Database Mart support engineers traced VFIO passthrough failures to the physical PCIe path on server hosting hardware, replaced the GPU, and restored stable GPU passthrough without touching the customer’s VM disks. The customer closed the ticket with no further PCIe dropout after the swap.

01 · Customer

What The Customer Said

Over two weeks the customer’s NOC shared UTC timelines with Database Mart support engineers, approved VFIO passthrough isolation tests on their server hosting node, took the RTX 4060 host out of rotation when asked, verified fixes locally, and closed the ticket once GPU passthrough was stable—no extra login required.

“Thank you for the update and for replacing the GPU on September 28. Since then the server has been running without a single GPU dropout or PCIe error, so there is no need to log in—it is back in normal operation. If the issue returns, we will open a new ticket with exact timestamps and logs. You can close this ticket.”

Customer · October 1, 2026

02 · Resolution

How We Resolved It

September 18, 2026

The GPU Disappeared From PCIe — The VM Stopped With It

A <CUSTOMER_PLATFORM> team runs a Windows VM on a dedicated RTX 4060 host using VFIO GPU passthrough for streaming. Each PCIe dropout removed the card from the bus four times in the first 24 hours of the ticket. Both PCI functions read config=ffffffff; only a warm host reboot restored GPU passthrough for another one to three hours.

The customer removed the host from production on this USA hosting account, granted access via the ticket channel only, and asked for GPU replacement or a different slot while keeping VM disks untouched. They authorized reboots and power-downs while the server was out of rotation.

0000:02:00.0  config=ffffffff
0000:02:00.1  config=ffffffff
lspci: !!! Unknown header type 7f

07:29:43  host booted, card healthy (config=de108228), VM running
08:59:35  first errors (~90 min into uninterrupted GPU use)
09:03:18  root port declares downstream device broken

Runtime PM was already off (power/control = on, d3cold_allowed = 0, vfio-pci disable_idle_d3=1). The same VFIO passthrough stack works on other fleet hosts in our hosting environment—pointing at this machine’s PCIe path or RTX 4060 silicon, not a generic guest driver issue.

September 19 – 22, 2026

Logs Showed Link Failure — Not A Host Crash

Engineers Gary and Sunny confirmed the GPU and HD Audio were on vfio-pci for VFIO passthrough. Failures showed transaction timeouts, failed FLR recovery, and a root port that could not retrain the link (stuck at 2.5 GT/s)—a classic PCIe dropout signature under VFIO GPU passthrough. CPU, memory, and thermals were normal; short stress tests did not instantly reproduce the fault—consistent with long runtime plus hardware path on server hosting gear.

vfio-pci 0000:02:00.0: timed out waiting for pending transaction; performing FLR anyway
vfio-pci 0000:02:00.0: Unable to change power state from D0 to D3hot, device inaccessible
pcieport 0000:00:03.0: broken device, retraining non-functional downstream link at 2.5GT/s
pcieport 0000:00:03.0: Data Link Layer Link Active not set in 100 msec

Onsite work followed with customer approval on their USA hosting node: reseat, contact clean, alternate slot/riser, 8-pin power, cooling check. After September 22 maintenance, the customer verified 8 GT/s ×8 on the RTX 4060 and returned VFIO passthrough to production briefly, noting they would report any recurrence of PCIe dropout.

September 25 – 27, 2026

Seven More PCIe Dropouts — Customer UTC Forensics

After ~43 hours of clean GPU passthrough, the RTX 4060 failed again under normal load. The customer logged seven UTC timestamps (Sep 25–26)—detail Database Mart support called very helpful for proving a hardware pattern in VFIO GPU passthrough. Cycles showed BAR restore, transaction timeout, FLR, then ffffffff config space; gaps between each PCIe dropout ranged from 16 minutes to 9 hours.

“As the reseat and the power and cooling checks did not help, could you please replace the GPU, or move it to a different PCIe slot/riser as planned? The server is out of our rotation.”

Customer · September 27, 2026

Hardware task #42467: riser/slot path, power delivery, then GPU replacement if needed—no production window required.

September 28, 2026

Stress Test Failed After Riser Work — GPU Swapped

Riser reseat and slot path change still reproduced PCIe dropout under stress on this VFIO passthrough host. The team returned, replaced the RTX 4060, and re-ran stability testing with no further GPU passthrough errors on the bench. VM disks were not modified.

September 29 – 30, 2026

Records Reconciled After A Wrong Host IP In One Update

One status email referenced a different host (IP redacted) than the affected server (IP redacted). The customer replied with uptime since 28 Sep 21:47 UTC and LnkSta at 2.5 GT/s vs LnkCap at 8 GT/s—constructive forensics that sped reconciliation.

“Could you please confirm on which server the card was actually replaced? … the PCIe link is currently running at a reduced speed: LnkSta reports 2.5 GT/s while LnkCap is 8 GT/s.”

Customer · September 30, 2026

Check	Expected	Customer observation
PCIe link speed	8 GT/s ×8 cap	2.5 GT/s negotiated
Post-replace uptime	Reboot for swap	Continuous since 28 Sep 21:47 UTC
VFIO config space	Valid IDs	Healthy after reboots
Ticket asset match	Single host	One reply cited wrong IP

Maintenance records confirmed the September 28 replacement on the correct asset. If link speed had stayed degraded, policy was machine migration with matched data disks—RTX 4060 spares were depleted at the time.

October 1, 2026

Closed Stable — Mutual Confirmation

The customer confirmed no PCIe dropout or VFIO passthrough errors since the September 28 RTX 4060 swap. Engineer Angelica closed the ticket as requested and invited a new ticket with timestamps and logs if GPU passthrough fails again.

“We are glad to hear that the server has remained stable since the GPU replacement on September 28, with no further GPU dropouts or PCIe errors reported… We will proceed with closing this ticket as requested.”

Angelica, Support Department · October 1, 2026

# Closure checklist (Oct 1, 2026)
✓ No vfio-pci dropout / FLR storm since GPU swap
✓ No recurring config=ffffffff on 0000:02:00.0 / .1
✓ VM disks never re-imaged or replaced
✓ Production rotation resumed at customer discretion

03 · Guide

Understanding VFIO GPU Passthrough And PCIe Dropout

If you run GPU passthrough inside a VM (VFIO GPU passthrough on server hosting from a USA hosting provider), a guest “GPU driver reinstall” often is not the fix for PCIe dropout. Below is plain-language context for the same VFIO passthrough failure class as this RTX 4060 ticket—what it looks like on hosting infrastructure, what logs mean, and what to send your hosting provider.

Q1What Does PCIe Dropout Mean For VFIO Passthrough?

The host stops seeing the graphics card as a normal PCI device during GPU passthrough. Tools may show config=ffffffff or “unknown header type.” The VM using VFIO GPU passthrough usually crashes or hangs until you reboot the physical server (not just restart the VM). On this RTX 4060 case that PCIe dropout cycle repeated every one to three hours under real workload.

Q2Is This The Same As An NVIDIA Driver Problem?

Often no. With VFIO passthrough, the Linux host typically does not run the NVIDIA driver—the GPU is handed to the VM via vfio-pci for GPU passthrough. Errors like FLR timeouts, “device inaccessible,” and root-port “broken device / retrain failed” point to PCIe dropout on the link or hardware, not a missing guest driver on VFIO GPU passthrough. Compare with another server hosting node that uses the same VFIO passthrough setup if you can.

Q3What Should I Put In A Support Ticket?

Include:

Exact times (UTC) of each failure and whether the VM was actively using the GPU
Host reboot times and whether a warm reboot temporarily fixes the card
Snippets from host logs around the failure (dmesg / journalctl) mentioning vfio-pci or pcieport
Output of lspci -vv for the GPU slot (LnkCap vs LnkSta speeds)
Confirmation whether VM disks must stay untouched

Detailed UTC timelines—as this customer provided on their USA hosting server—speed up correlation with hardware visits when VFIO passthrough shows PCIe dropout.

Q4What Does LnkCap Vs LnkSta Tell Me?

LnkCap is the maximum speed the slot and card can negotiate on this path (width ×8 is common on RTX 4060 hosts). LnkSta is what the link is using right now. Compare them on the same machine—do not assume every RTX 4060 must show 16 GT/s.

An RTX 4060 is a PCIe 4.0 ×8 card (16 GT/s per lane in spec). Many dedicated servers, risers, or secondary slots are wired for PCIe 3.0, where a healthy cap is 8 GT/s ×8—roughly the same bandwidth as PCIe 3.0 ×16 and normal for production. On a Gen4 path you may see 16 GT/s ×8 in LnkCap when healthy. In this case the customer saw 8 GT/s ×8 after maintenance and 2.5 GT/s when the link was failing to retrain.

If the card is idle but LnkSta stays at 2.5 GT/s while LnkCap shows 8 GT/s or 16 GT/s, the link may be degraded or failing to retrain—worth flagging to support even if the VM still boots.

lspci -vv -s 02:00.0 | egrep 'LnkCap|LnkSta'

Q5What Will Support Typically Try On Dedicated GPU Servers?

On managed server hosting from a USA hosting provider, engineers will usually try the following when VFIO GPU passthrough logs point to hardware rather than config:

Correlate your timestamps with host and BMC logs
Reseat the GPU, check power connectors and cooling
Move the card to another slot or riser path
Replace the GPU, or migrate to another machine if the link or chassis is suspect

Short bench tests sometimes pass while hours of production GPU passthrough still hits PCIe dropout—that pattern matches this RTX 4060 VFIO passthrough case on our hosting platform.

Q6I Have Many GPU Servers—How Do I Avoid Confusion?

When replying about hardware work on server hosting, cite one primary IP or asset tag per message, note whether the server was powered off (an RTX 4060 swap requires shutdown), and match maintenance updates to the host where you still run VFIO passthrough. Uptime and link-speed checks from your side—as in late September on this ticket—help your USA hosting provider confirm the right machine before the next GPU passthrough incident.

Last Updated: 10/14/2026

Outline