I’m opening this thread for engineering visibility, as NVIDIA Customer Care asked me to post here. I already have an active support ticket and would like an official confirmation/KB reference from NVIDIA (not just community speculation).
“0.000 Gb/s available PCIe bandwidth, limited by Unknown x0 link at 000f:00:00.0 …”
However, GPU compute appears functional and stable under load:
CUDA samples build successfully (warnings only).
deviceQuery PASS (GB10 detected, CC 12.1).
matrixMul PASS.
cudaTensorCoreGemm runs successfully (~14.4 TFLOPS in sample run).
After load: no NVIDIA Xid errors, no new PCIe AER errors in logs.
nvidia-smi also reports (GPU Link Info):
PCIe Generation: Max = 1, Current = 1
Link Width: Max = 16x, Current = 1x
Questions for NVIDIA / Engineering
Is the boot-time PCIe reporting (root port x0/unknown + endpoint Gen1 x1) expected on DGX Spark / GB10 because the real CPU↔GPU data path is NVLink-C2C (chip-to-chip) rather than PCIe? Or is this a platform/firmware/driver bug in PCIe/DOE probing/reporting?
Are the DOE mailbox timeouts (ABORT timed out / -5) fully benign and safe to ignore?
Is there an official NVIDIA reference (KB / release note / documentation) stating this behavior is expected?
If it’s known/benign: is there a supported mitigation to avoid the noisy/possibly misleading boot messages (“x0/0.000 Gb/s” and DOE mailbox failures), e.g. firmware/BIOS update, driver/kernel update, or a supported kernel parameter to disable the DOE probe?
Repro steps (always reproducible)
Cold boot or reboot → messages appear at boot consistently.
I can provide the full evidence report (including fwupdmgr get-devices/get-updates and CUDA sample outputs) if needed; please tell me the preferred way to attach it here.
Thank you — I’m mainly looking for an official confirmation and whether NVIDIA plans to clean up/disable the misleading PCIe/DOE reporting in a future firmware/driver/kernel update.
PCI information alone is not sufficient context, since link states can change based on workload. The FD results will provide a much clearer picture of what is expected for your unit.
Once complete, please DM me the FD logs. They may contain serial numbers, so it is best not to post them publicly.
While I don’t have support ticket at the moment of writing, on my DGX Spark I am observing the same diagnostics reported by @c_thiede. I will be running the Field Diagnostics shortly. At the same time, I would be grateful if you could share updates on this matter, please, as this may be relevant for other fellow DGX Spark users too. Many thanks in advance!
@c_thiede the PCIe link speed spooked a few DGX Spark users before, me included, but there’s nothing to worry about. Like you said the system works fine!
I ran the official DGX Spark Field Diagnostics tool (partnerdiag --field). Final Result: PASS.
All test groups reported OK (GPU stress, C2C stress, CPU, memory, SSD, power, thermal). CUDA workloads remain stable and I still see no NVIDIA Xid or new AER errors under load.
The original boot-time messages remain reproducible:
root port shows “Speed unknown, Width x0”
endpoint shows Gen1 x1
DOE mailbox timeouts + “0.000 Gb/s / x0 link” message at boot
Per your request, I will DM the FD log bundle to the moderator (not posting publicly since it may contain serial numbers).
→ Question for NVIDIA/engineering:
Given FD PASS and stable workloads, can you confirm whether the PCIe/DOE reporting is expected/ benign on DGX Spark (GB10) (e.g., due to NVLink-C2C being the actual CPU↔GPU data path), and whether there is any planned update or guidance to suppress/clean up the misleading boot-time DOE/x0 messages?
Hi, thanks for sharing the Field Diagnostics logs. As you noted, all tests passed, which indicates your hardware is healthy and performing as expected. Field Diagnostics is designed to give a consolidated view of overall hardware health.
As mentioned earlier in the thread, the boot messages and x1 PCIe messages you’re seeing are expected. This is standard PCIe lane training, an automatic hardware-level process during boot or wake where devices negotiate the optimal link speed. The link can flex up or down depending on workload.
Enjoy your Spark. If you notice specific errors or performance issues, please let me know.