NVIDIA / NVIDIA/open-gpu-kernel-modules
Driver cannot initialize GPU (RTX PRO 4000 Blackwell) behind bridge PLX PEX8747 (Supermicro System)
Nobody has claimed this yet.
- Dominant language
- C
- Stars
- 17.4k
- Forks
- 1.9k
- PR merge metrics
- No merged PRs in 30d
Description
NVIDIA Open GPU Kernel Modules Version
595.84 also tried 595.71.05
Please confirm this issue does not happen with the proprietary driver (of the same version). This issue tracker is only for bugs specific to the open kernel driver.
- I confirm that this does not happen with the proprietary driver package.
Operating System and Version
Gentoo Linux (Rolling Release)
Kernel Release
Linux hostname 6.18.35-gentoo-r1 #2 SMP PREEMPT_DYNAMIC Wed Jul 1 13:09:43 CEST 2026 x86_64 Intel(R) Xeon(R) CPU E5-2630 v4 @ 2.20GHz GenuineIntel GNU/Linux
Please confirm you are running a stable release kernel (e.g. not a -rc). We do not accept bug reports for unreleased kernels.
- I am running on a stable kernel release.
Hardware: GPU
NVIDIA RTX PRO 4000 Blackwell
Describe the bug
It seems the driver cannot initialize GPUs behind a PCIe bridge PLX PEX8747 in a Supermicro SYS-2028GR-TR (yeah rather old system, but should be fine for the PRO 4000).
[ 8.606516] NVRM: GPU1 Plx_Pex8747_GetBar0: Device has no BAR0!
[ 9.889042] NVRM: GPU2 Plx_Pex8747_GetBar0: Device has no BAR0!
[ 11.281680] NVRM: GPU at PCI:0000:07:00: GPU-2bead814-a1c4-14fa-56a5-499a8d4c17d4
[ 11.281685] NVRM: Xid (PCI:0000:07:00): 79, GPU has fallen off the bus.
[ 11.281689] NVRM: GPU 0000:07:00.0: GPU has fallen off the bus.
[ 11.281696] NVRM: GPU2 krcRcAndNotifyAllChannels_IMPL: RC all channels for critical error 79.
Rest of the output is in the attached dmesg.txt
A GPU (Blackwell RTX PRO 4000) attached directly to the CPU just works fine.
Turing Cards (RTX 4000-6000) also work(ed) behind the bridge. (some removed for the newer ones)
For the Blackwell GPUs I had to upgrade the driver to the open kernel module but the RTX 6000 still works behind the PLX bridge today.
My guess is, that the driver doesn't know how to handle the memory BAR of a device behind a bridge and instead tries to access the bridge directly?
If you need more logs, I'm happy to provide.
To Reproduce
Just launch the server with the cards attached.
Bug Incidence
Always
nvidia-bug-report.log.gz
More Info
It would be a pity to not use these cards (3 of 4) or to have to buy a server during these times
for 2-4x times the price of the cards itself.
So any help is very appreciated.
Big thanks in advance!
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the attached dmesg.txt, lshw_bus.txt, and nvidia-bug-report.log.gz, focusing on the PLX PEX8747, missing BAR0 messages, and Xid 79. Compare the initialization evidence for the Blackwell GPUs behind the bridge with the directly attached GPU and the working Turing cards. Done means the Blackwell GPUs initialize reliably behind the bridge without the BAR0 errors or GPU-fallen-off-the-bus failure.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- c, linux
- Domain
- operating-systems
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100