Tesla V100 16G PCIe on Dell Precision 7920T

[Donalaren]

Hello, I am in urgent need of your assistance. I am attempting to use a Tesla V100 16G PCIe graphics card on a Dell Precision 7920T.

System
Motherboard: Dell Precision 7920T
Card: Tesla V100 16G PCIe
System: Ubuntu 22.04
RAM: 64G

• Memory Map IO above 4GB is enabled.
• There is no CSM in BIOS of Dell 7920T.
• BIOS version is updated (2.50.0).

Description
I first attempted this on Ubuntu 22.04 using @xCuri0 's ReBarState. Followed this method, after building and running RebarState, set the value to 32. But this approach proved ineffective. After rebooting and reopening the RebarState, I can see the Current ReBarState 32/Unlimited. nvidia-smi still can't see my Tesla V100 ( lspci | grep -i nvidia correctly identified the GPU model 0000:73:00.0 3D controller: NVIDIA Corporation GV100GL [Tesla V100 PCIe 16GB] (rev a1)).
Through dmesg I can see:

[   45.605811] nvidia 0000:73:00.0: enabling device (0140 -> 0142)
[   45.606250] NVRM: This PCI I/O region assigned to your NVIDIA device is invalid:
               NVRM: BAR1 is 0M @ 0x0 (PCI:0000:73:00.0)
[   45.606542] nvidia: probe of 0000:73:00.0 failed with error -1

This is consistent with the situation without ReBarState. I have only followed this method to build and run ReBarState on the Ubuntu system without making any modifications to the BIOS. My actions were as follows:

git clone https://github.com/xCuri0/ReBarUEFI.git
cd ReBarUEFI/ReBarState
mkdir build
cd build
cmake ..
make
sudo ./ReBarState

So I suspect ReBarState may not be functioning. How to verify if the RebarState is working in this scenario?
Note that I'm not suspecting the software itself; I believe my execution may be incorrect. Any suggestions would be most gratefully received.

[xCuri0]

@Donalaren Tesla V100 and all NVIDIA datacenter GPUs don't use Resizable BAR they just has a large BAR by default, the issue here is likely with your BIOS configuration.

Dell 7920T should be recent enough to not have the weird issues on older motherboards requiring UEFIPatches.

All ReBarState does is read/write the ReBarState EFI variable which you could also read yourself but it's going to give the same result as what you're seeing.

EDIT: Seems like you aren't running ReBarUEFI modded BIOS even, in that case ReBarState does absolutely nothing.

[Donalaren]

Thank you very much for your reply; it has given me renewed hope.

Do you believe RebarState cannot resolve this compatibility issue with the Tesla V100? Yet I've observed on other websites that they've addressed Tesla GPU problems (including Tesla P100 and Tesla P40). Moreover, they all mention switching the GPU mode to graphics mode via NVFlash. However, NVFlash currently fails to detect my Tesla GPU, I suspect this stems from the absence of Rebar, as per this webpage. Regardless, Rebar is essential, so I intend to give it a try.

Thus, we return to the RebarState software. I acknowledge it is an extremely useful tool—thank you for sharing it—but I seem to have yet to grasp how to utilise it properly. Clearly, my understanding of this statement was flawed. I mistakenly believed that , I only needed to run ReBarState without modifying BIOS on the Ubuntu system.
Right, I understand now. Even if I wish to implement Resizable BAR on a Linux system, I still need to flash the modified BIOS using hardware BIOS flasher such as CH341A. However, I encountered difficulties when carrying out the first step Adding FFS module. Dell's BIOS file is in .exe format, which UEFITool cannot recognise. I've observed that some Dell workstations have successfully implemented Rebar in List of tested motherboards. How might one resolve this issue about the EXE format?

[xCuri0]

Tesla V100 isn't a rebar GPU it's going to make no difference.

[Donalaren]

Thank you for your suggestion. Yes, I asked my Dell sales representative, who has more hands-on experience with this machine. They explicitly told me that the Tesla graphics card is not compatible with this workstation. I also couldn't find any successful compatibility cases online for Dell 7920T and Tesla V100.

1. Given this, I believe the BIOS configuration should be fine. And, I carefully reviewed the BIOS settings and found no other relevant configurations besides the “Above 4G” option. Attached is my BIOS setup guide.
   precision-7920-tower.pdf

2. I've tried pci=realloc too, but I still get the same error

[ 2175.144379] NVRM: This PCI I/O region assigned to your NVIDIA device is invalid:
               NVRM: BAR1 is 0M @ 0x0 (PCI:0000:73:00.0)
[ 2175.144672] nvidia: probe of 0000:73:00.0 failed with error -1
[ 2175.144767] NVRM: The NVIDIA probe routine failed for 1 device(s).
[ 2175.144771] NVRM: None of the NVIDIA devices were initialized.
[ 2175.146208] nvidia-nvlink: Unregistered Nvlink Core, major device number 235

3. Next, I might start by researching DSDT editing.

[xCuri0]

Have you looked into IntelRCSetup ? An issue similar to this is mentioned in common issues and can be fixed in it https://github.com/xCuri0/ReBarUEFI/wiki/Common-issues-(and-fixes)#system-wont-boot-with-large-vram-16gb-or-multi-gpu

I recommend not to try DSDT patching because PCIe is way more complicated on HEDT/server boards which makes it less likely to work.

[Donalaren]

There is no IntelRCSetup in the BIOS of Dell 7920T. I tested the consumer-grade GeForce RTX 4070 and successfully got it working on the 7920T, which is easy. Additionally, the Tesla V100 was successfully configured on the MSI Z790 motherboard. In comparison, the Dell motherboard has significantly limited functionality, including graphics card configuration and manual fans configuration, despite potentially offering higher reliability.

[xCuri0]

Are you able to share a full BIOS dump ? I could see if there's any hidden settings in it because there's no way a 2017 workstation doesn't support large BAR.

C621 chipset should support 4G decoding with no issues and I think some have even been updated to have resizable BAR.

[GezelligLLC]

we have dell 7920s and I can certainly provide a copy of the BIOS file from Dell if that will help:
Precision_7820_7920_2.50.0.zip
We are definitely wanting to run intel arc pro b70s in our dells. If you can help we would be eternally grateful

[Icbears]

@Donalaren This information is pretty important to me because I am also looking for a V100 for my 7820T, and they have the same chipset and pcie slots configurations. I noticed that someone tried to use V100 on a 7920T with Windows 10, while he came with the error code (12), which said the V100 does not have enough resources to use. So, I am wondering if it is possible to allocate more pcie bus to slot 2 or 4 where the V100 goes on could help. You may try to get into bios setup->advanced configurations->pcie bus->change into option 1 (with more bus allocated to pcie slot 2 and 4), then boot up to see if the problem can be solved.

[bwtimmermans]

@Donalaren @Icbears
For the record, I have wasted most of my free time this weekend trying to get a V100 16GB working in my T7920 (dual Xeon Gold, 192 GB).

The Dell BIOS is up-to-date (2.46 I think) and I have messed with just about all the BIOS settings I can think of. I have tried the pcie "option 1 & 3" allocations, which assign more resources (AFAI can tell) with the GPU in slot 4 and it makes no difference.

The problem is also, I cannot even get the machine to POST with my regular Quadro video card plus the GPU (tried with different slots). This suggests there is some unusual hardware conflict.

[rodcsoto]

-- Did you ever got it to work? I got the same issue here T7920 (dual Xeon Gold, 192 GB and trying to add the tesla v100. windows detects the cad but it won't enable is. the error message says that cant find enough resources, to disable another device.

[bwtimmermans]

I gave up after trying everything I could. I could not confirm if the V100 was functioning correctly, but I had no reason to think it was faulty. I have found my T7920 to be quite a "difficult" machine. Occasionally it seems to report memory errors depending on where modules placed even though the modules are near identicle and apparently functioning fine. I don't know if this affected the V100 but I don't see how. Could be some really obscure incompatiblity. Either way, very annoying. I'd like to try with a Turing or newer class of GPU.

[alexichrys-bit]

Hello all,

Did anyone ever get this working with the T7920? As fate should have it, I have a T7920 Dual Xeon Silver 4214 lying around and a couple of V100's.

I'd love to get this up and running. @xCuri0 if I send you across the bios dump from the dell executable, do you think you could help identify the hidden variables if they exist?

Much appreciated, and looking forward to hearing from you all.

-A

[Koekieezz]

Not yet... the Discussion OP didn't share the bios dump, so maybe no one took a look after it.

[GezelligLLC]

We have a Dell 7920 with dual xeon processors, and 5820 with single xeon cpu. Dell seemingly refuses to add rebar support into bios for this generation of workstations. I've heard that it can be pretty challenging on these machines because Dell doesn't allow directly loading a modified bios. If anyone has been successful with workstations similar to either of these machines we'd love to hear about it.

[GezelligLLC]

I have 2 intel arc pro b70 cards that I want to install in a Dell Precision 7920T. I have a similar problem noted in this thread and elsewhere, in that my machine won't even boot with even 1 of the cards installed. I've tried every BIOS setting I can identify to remedy this, but to no avail. Dell provides the BIOS via an exe file. I zipped it and uploaded it here:
Precision_7820_7920_2.50.0.zip
Alternatively, the file can be downloaded directly from Dell here: https://www.dell.com/support/home/en-us/drivers/driversdetails?driverid=v0yyp&oscode=w2021&productcode=precision-7920-workstation. Can any of you experts give it a look and see if there's some hidden setting or such that I can change to make this work? Any other guidance would be so very appreciated. There are thousands of these machines in circulation. They're really great server / workstations and would be great to run AI solutions on. It would be a shame to retire such a workhorse simply because it can't run a modern GPU other than Nvidia.

[StevieClear]

Adding another data point: Dell Precision 7920T, dual Xeon Gold (Cascade Lake Refresh 26-core), 384 GB RAM, Tesla V100 32GB PCIe. Same symptoms as @Donalaren and @bwtimmermans — V100 prevents POST entirely in any CPU0 or CPU1 slot. CPU0 actually errors out with 2-4 error code. CPU1 (PCIe 6 and 7) does not error out but they wont POST, I get NUMLOCK light flicker 2-3x and then Darkness washes over....Darker than a black steer's tookus on a moonless prairie night. There was no bottom....

-NVIDIA OEM dongle (030-0571-000), proper EPS power, BIOS 2.50.0, all relevant settings set correctly
-(Above 4G enabled, CSM disabled, Legacy ROMs off). RTX-class consumer GPUs work fine in same chassis.

I'm willing to provide BIOS dumps, diagnostic logs, and test patched BIOSes if @xCuri0 has bandwidth. Currently running production QE calculations (Genuine Condensed matter physics that is for the good of mankind!) on the system without V100 , but available to coordinate testing windows for ReBarUEFI patches if there's any chance this is fixable at firmware level. Wanted to see this thread concluded as I just bought a V100 32GB and don't really want to send it back, we can do this!

help me @xCuri0 ....you're my only hope...

[StevieClear]

Proposed approach — looking for @xCuri0's validation
After more digging, here's my working theory and proposed solution. Would appreciate a sanity check before I commit hardware time.

Root cause hypothesis:
-V100 (16GB and 32GB variants) requires large MMIO address space mapping above 4GB. The Dell 7920 BIOS allocates MMIOHBase / MMIOHSize with defaults sized for typical workstation GPUs (8-16GB max), not datacenter cards. When V100's BAR allocation request exceeds the BIOS's configured high MMIO window, BAR1 maps to 0M @ 0x0 and the card fails to initialize.
-The Memory Map IO above 4GB toggle exposed in setup likely enables the capability but doesn't expose the base/size variables needed to give V100 enough room.

Proposed fix (ReBarUEFI methodology applied to 7920):

1. Extract raw BIOS from chip via CH341A (BIOS 2.50.0, dated 08/11/2025 — newer than what GezelligLLC uploaded)
2. Locate hidden EFI Setup variables for MmiohBase and MmiohSize (likely under IntelSetup-ec87d643-eba4-4bb5-a1e5-3f3e36b20da9 — confirmed present on my system via efivar -l)
3. Modify default values: MMIOH Size = 1024GB, MMIOH Base = 56T (per typical Supermicro server-board convention for similar Intel C621 platforms)
4. Inject ReBarDxe.ffs into appropriate DXE volume
5. Apply patches.txt from ReBarUEFI release
6. Flash modified BIOS to chip via CH341A

What I have:

• Dell Precision 7920 with BIOS 2.50.0
• Three motherboards available — one dead (damaged CPU0 socket) for practice, one production system, one spare incoming
• Can solder (hot-air rework setup ordered)
• CH341A v1.7 + 1.8V adapter + WSON socket on order
• Pre-programmed spare BIOS chip ordered for brick insurance
• Tesla V100 32GB PCIe, NVIDIA dongle (P/N 030-0571-000)
• Time and motivation

What I can contribute back to the community:

• Raw BIOS dump (2.50.0, newer than what's in this thread)
• Detailed test results across both V100 variants
• Public documentation of the entire patch process for the 7920 community
• If this works, I'll make the spare 60K5C motherboard available to anyone in this thread who needs one — at my cost (~$500 including modded BIOS, chip, and shipping). Not trying to make a buck on anyone here, just want the working hardware in the hands of someone who needs it. It was a replacement for a damaged motherboard from an eBay seller, but I'd already bought a new one because I couldn't wait a week to get Quantum ESPRESSO running.

Question for @xCuri0:
Does this theory align with your understanding? Specifically:

1. Are MmiohBase / MmiohSize the right EFI variables to target on Skylake-SP / Cascade Lake (C621)?
2. Are there other Dell-specific hidden variables I should also adjust?
3. Any known gotchas with Dell signature checking that would prevent a modified BIOS from booting (T5810 thread suggested external flash is required)?

Happy to test patches you produce, or develop independently and share results.

— Steve
armadillolabs.io

[GezelligLLC]

Will jump on board and happily test any efforts in this area. We have 7920s and 5820s and would like to install Intel Arc Pro B70s in them. - possibly multiple B70s in each if possible. We'll happily test, try options, report back findings, etc. These are venerable, albeit older workstations. We'd really like to get some more mileage from them via a new use-case. BTW - we also tried the relatively few options in BIOS that, once you enable Thunderbolt, allow you to choose from some preset memory allocation configurations on the PCIe slots. Unfortunately, that didn't seem to make any difference either. Thanks to you all and many kind regards.

[StevieClear]

Figured it out!!! See post below! Good Luck, let me know if i can help

[StevieClear]

SOLVED — Tesla V100 32GB working on Dell Precision 7920T

After ~30 hours, got a Tesla V100 PCIe 32GB working on a Dell Precision 7920 Tower. Posting full recipe so others can reproduce.

Hardware:

• Dell Precision 7920 Tower, BIOS 2.50.0
• 2× Xeon Gold 6230R (Cascade Lake Refresh, 26-core)
• 384 GB DDR4-2666 LRDIMM ECC
• Ubuntu Server 24.04.2 LTS, kernel 6.8

Root cause:
Dell ships the T7920 with SocketCommonRcConfig.MmiohBase = 0 and MmiohSize = 0 (verified by dumping the EFI variable). This is the encoded version of "MMIOH disabled" — even with Above 4G Decoding enabled in BIOS, the IIO never allocates a 64-bit prefetchable window for the bridge that the V100's 32 GB BAR1 needs. Result: BAR1 is 0M @ 0x0 error from the NVIDIA driver.

The Dell PowerEdge R7920 Rack BIOS exposes an "MMIO Base" menu option (512GB/12TB/56TB). The T7920 Tower BIOS has the same underlying Intel Purley code but Dell stripped the menu. The EFI variable is still consumed by the same DXE driver.

Fix — write SocketCommonRcConfig EFI variable via UEFI Shell:

1. Dump BIOS to confirm the variable exists: flashrom -p internal:laptop=this_is_not_a_laptop -l biosonly.layout -i bios -r bios.bin from running Ubuntu (no CH341A needed). Extract with UEFIExtract, find SocketCommonRcConfig (GUID 4402ca38-808f-4279-bcec-5baf8d59092f, 114 bytes).
2. Boot UEFI Shell from USB (used pbatard's shellx64.efi from EDK2 stable202602).
3. Write the variable with: setvar SocketCommonRcConfig -guid 4402ca38-808f-4279-bcec-5baf8d59092f -bs -rt -nv =H000200000400030202010000060600000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
   DataSize should be 0x72 (Hex)

This sets:

• MmiohBase = 0x0200 (512 GB — matches Dell R7920 conservative default for V100, keeps allocations within V100's 44-bit addressing limit)
• MmiohSize = 0x0004 (= 256 GB index — large enough to enable the bridge prefetchable window)
• Other bytes are Dell's stock defaults (MmcfgBase=3, MmcfgSize=2, IsocEn=2, NumaEn=1, etc.)

5. Syntax notes for UEFI Shell setvar (cost me hours):

• Use =H with continuous hex string, no spaces, no 0x per byte
• = and =fs0:\file.bin syntax does NOT work in this shell build — writes the literal string as variable contents
• Total = 228 hex chars after =H (= 114 bytes)

6. Verify with dmpstore -guid 4402ca38-808f-4279-bcec-5baf8d59092f SocketCommonRcConfig — DataSize should be 0x72, first 16 bytes 00 02 00 00 04 00 03 02 02 01 00 00 06 06 00 00.

Additional requirements that turned out to matter:

• V100 must be the only GPU. Adding a display GPU (e.g., GT 710) on this BIOS config causes BAR allocation chaos and POST hangs. Tower goes fully headless for V100 use — SSH is the interface. Use a separate display GPU during BIOS access and remove it before flipping to V100-production mode.
• V100 in slot 2 specifically. Slot 4, 6, 7 all failed POST in our testing. Slot 2 is Dell's primary GPU slot (CPU2-side x16) and BIOS allocates to it first.
• Both PCIe power cables on the SAME PSU rail — Dell T7920 has two P10 power cables and one P12. Using P10+P12 (mixed rails) caused intermittent POST failures. Switching to P10+P10 (same rail) was a meaningful improvement.
• BIOS settings: "Memory Map IO above 4GB = Enabled", "BIOS Hot-Plug Support = Enabled", "PCIe Bus Allocation = Option1", "Limit System Memory to less than 1TB = Enabled", "Primary Video
  Slot = SLOT 5" (or any empty slot — keeps BIOS from trying to display-init the V100).
• Linux kernel grub: pci=realloc=on (lets kernel resize BAR windows after BIOS hands off; needed even with the EFI variable fix).

Holy Crap I can't believe I figured it out, hopefully this helps.... @GezelligLLC @Donalaren @bwtimmermans Let me know if anyone has questions, happy to help!!

Good Luck out there!

[StevieClear]

I was asking myself the same question, I would imagine it is possible with some tinkering.
-The MmiohBase=0x0200, MmiohSize=0x0004 config we wrote allocates a 256 GB MMIOH window per IIO stack which is enough for multiple 32Gb BARs. — and each Xeon Gold has its own IIO. So you'd place:

• V100 1 in slot 2 (CPU2 IIO stack)
• V100 2 in slot 4 or 7 (CPU1 IIO stack)

Each card gets its own bridge with its own independently-allocated 64-bit prefetchable window. No resource contention between them,
because they're on different physical IIOs. The single-GPU heterogeneous failure mode I hit (V100 + GT 710) shouldn't apply to symmetric dual-V100 — both cards present identically to BIOS, no display-vs-compute arbitration mess. however I have not gone back to add my GT710 since I got the V100 working and I have just been running it headless. I will have to go back and see if it works.
-Theoretical max: 3 V100s (slots 2, 4, 7 — the only ones that are full-x16 electrical AND physically large enough for a full-height double-wide card).
-Slots to avoid: 1, 3, 5 won't physically fit a V100. Slot 6 is a trap — x16 mechanically but only x4 electrically wired, link training fails.

The hard blocker for T7920 specifically:

V100 PCIe needs two 8-pin EPS power connectors (250W TDP). In our single-V100 testing, cross-rail powering (P10 + P12) caused
intermittent POST failures. Same-rail (P10 + P10) was required for stable operation.

So the real issue with 2 is free Power Supply cables, if you had an extra power supply I would assume its doable. I will at least confirm I can run 2 x GPUS when I get a chance to reboot it. I ended up removing my GT 710 video card just to eliminate variables so I was constantly going back and forth when I had to make BIOS level changes from F12 boot menu. It took me dozens of attempts and was a pain in the ass having to pull and add back the video card. Collectively took me 30-60 hours over the course of a week+. I am just happy it worked and wanted to share my success to help anyone else struggling as I was doubting it was even possible at times. Good Luck! let me know if I can help, I will probably post a link to my Github or website for reference later on today as a walk through guide.

[StevieClear]

Yeah It was a little daunting, I had to enter in 228 digits manually, but most of them were zeros. I highly recommend using the function:
"dmpstore -guid 4402ca38-808f-4279-bcec-5baf8d59092f SocketCommonRcConfig"

You want to ensure that your DataSize = 0x72 at the end - THIS IS IMPORTANT
MOST of those will be trailing zeros, but I accidentally counted wrong a few times and had to re enter, but going back and checking after it silently accepts your input is a savior. As long as you correct before you reboot you will be fine.

[GezelligLLC]

@StevieClear - I know this a a really big ask, and I honestly don't even know if / how this might work.... But, if I don't ask the question, well....: Are you willing to share a copy of your modded BIOS? I've never done this sort of work before and it is far more intimidating for us mere mortals than for pros like you who can sort through HEX codes and such. That is so far beyond my knowledge base that I'm struggling to tackle it. Frankly, I don't even know if I could update my BIOS with yours, given Dell's constraints vis-a-vis BIOS updates. Would you kindly share your thoughts on this? Please know, I'm not looking for the Easy Button, I'm just looking for the "avoid really screwing this up" button :-)

[StevieClear]

Steve:
Just FYI I used Claude to generate this response so If something doesnt make sense please just respond and I will address it. There were just a lot of steps here so I got AI to help, Trust me I know this sounds daunting, but it actually wasn't that bad,

1. Make a USB stick for Boot Menu
2. Reboot and hammer F12 on/before Dell Logo,
3. enter in the values for "setvar SocketCommonRcConfig -guid 4402ca38-808f-4279-bcec-5baf8d59092f -bs -rt -nv =Hxxx"
   where xxx is the 228 character code below, type carefullly to ensure appropriate syntax.
   When you do it correctly it should silently accept, so don't freak out if you don't get a response,
4. Use "dmpstore -guid" to ensure you entered it correctly, reboot, done!
   What took me so long is that I had to try dozens of combinations until it worked. Hope that Helps!

Claude:
@GezelligLLC — quick clarification before we dive in: I don't actually
have a "modded BIOS" to share, and good news, you don't need one.
Here's what's really happening:

The BIOS on my machine is stock Dell 2.50.0. I didn't change a single
bit of the BIOS image itself. What I changed was one tiny config
setting (114 bytes) stored in your machine's NVRAM — a separate piece
of memory that the BIOS reads at boot. The "fix" is just telling the
BIOS to use the right value for one setting that Dell stripped from
the menu.

Also important: you can't share BIOS dumps between Dell machines. Dell
BIOS files contain machine-specific stuff (your serial number, asset
tag, network card MAC address, microcode for your specific CPUs).
Flashing my dump onto your machine would either brick it or refuse to
boot. So even if I gave you my file, it wouldn't help — and it would
probably hurt.

The good news: the fix is the same on every T7920. You just need to do
it yourself once. It's about 15 minutes total. Here's the
step-by-step:

STEP 1 — Make a UEFI Shell USB stick (5 min)

Grab any USB stick (4 GB+ is fine), format it FAT32. Download
shellx64.efi from here:
https://github.com/pbatard/UEFI-Shell/releases (latest release, the
"shellx64.efi" file)

On the USB stick, create the folder path EFI/BOOT and put the file in
there, RENAMED to BOOTX64.EFI. So the final path should be:
USB:/EFI/BOOT/BOOTX64.EFI

STEP 2 — Boot to UEFI Shell (2 min)

Plug the USB into your 7920. Power on. Hit F12 repeatedly to get the
boot menu. Select your USB drive (it'll show up as "UEFI: "). The UEFI Shell loads — you'll see a "Shell>" prompt.

STEP 3 — Find your USB inside the shell (30 sec)

At the Shell> prompt, type:
fs0:
Then:
ls

You should see "EFI" folder. If not, try fs1: or fs2: until you find your USB.

STEP 4 — Write the BIOS setting (2 min)

This is the magic step. Type exactly this (it's one long line, no breaks):

setvar SocketCommonRcConfig -guid 4402ca38-808f-4279-bcec-5baf8d59092f
-bs -rt -nv =H000200000400030202010000060600000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

Important: that's 228 hex characters after "=H". Type slow,
double-check the GUID has "4279" in the middle (not 4729 — easy typo).
Hit Enter when done.

If you get "unable to set", try this first to reset:
setvar SocketCommonRcConfig -guid 4402ca38-808f-4279-bcec-5baf8d59092f =
Then retype the long command.

STEP 5 — Verify it worked (30 sec)

Type:
dmpstore -guid 4402ca38-808f-4279-bcec-5baf8d59092f SocketCommonRcConfig

You should see DataSize = 0x72 and the first 16 bytes should read:
00 02 00 00 04 00 03 02 02 01 00 00 06 06 00 00

If yes, you're done. Type "exit" to leave the shell, power off the machine.

STEP 6 — Physical setup (5 min)

• Install your V100 (or Arc Pro) in slot 2 (the top double-wide slot)
• Pull any other GPU you have (V100 must be the only GPU — this was a
  separate gotcha I hit)
• For V100 specifically: both PCIe power cables must be on the same
  PSU rail (both labeled P10, not P10+P12). Arc cards may not have this
  issue.
• Close up, plug in, power on
• System will be headless (V100 has no display outputs, Arc Pro B70
  has them). SSH in once it boots.

STEP 7 — Linux side (1 min, only on first boot)

Once you can SSH in or reach a console, edit /etc/default/grub and
change the GRUB_CMDLINE_LINUX_DEFAULT line to:
GRUB_CMDLINE_LINUX_DEFAULT="pci=realloc=on"
Then:
sudo update-grub && sudo reboot

After that reboot, nvidia-smi (or lspci) should show your card and the
driver should load.

If anything breaks, the fix is 100% reversible: boot back into the
UEFI Shell and run:
setvar SocketCommonRcConfig -guid 4402ca38-808f-4279-bcec-5baf8d59092f =
That deletes the variable and Dell's BIOS regenerates the original
(broken) defaults on next boot. You're back to where you started — no
harm done.

Happy to help debug anything specific if you get stuck on a particular
step. I went through this whole process with a Claude AI assistant on
the other side, which is how I figured out the right hex value through
trial and error. The recipe above is the version that worked — you
don't have to do the trial-and-error part.

Good luck. Post-back when it works, would love to add Arc Pro to the
list of confirmed working cards.

---

— Steve

[Ersky79]

Confirming @StevieClear's fix works on a Precision 7820 Tower (single Xeon) with a Tesla V100 PCIe 32GB — nvidia-smi now sees the card with the full 32768 MiB. Thanks Steve, this was the answer after a couple of weeks of chasing it. Adding a few 7820-specific notes

System: Precision 7820 Tower, BIOS 2.52.1, Ubuntu Server 24.04 (kernel 6.8), driver 535.309.01, V100 32GB in slot 2, only GPU, headless.

---

⚠️ Don't copy the 228-char string verbatim — build it from your own dump.

My stock variable differs from Steve's 7920:

Steve's (7920):  00 02 00 00 04 00 03 02 02 01 00 00 06 06 00 00
Mine   (7820):   00 02 00 00 04 00 03 02 02 01 00 00 08 04 00 00
                                                     ^^^^^

Offsets 12–13 are 06 06 on his machine and 08 04 on mine. Those aren't MMIOH — they're other platform settings that legitimately differ between configs. If you paste his exact string into a 7820 you'll silently overwrite them with a dual-Xeon 7920's values.

(@tomuk5's script further down avoids this entirely — setup_var.efi writes MmiohBase/MmiohSize by offset rather than rewriting the whole 114-byte blob, so there's nothing to copy wrong. I did it manually and hit the hazard the hard way; if you're starting fresh, the offset approach is safer.)

Read yours first:

sudo xxd /sys/firmware/efi/efivars/SocketCommonRcConfig-4402ca38-808f-4279-bcec-5baf8d59092f
sudo dd if=/sys/firmware/efi/efivars/SocketCommonRcConfig-4402ca38-808f-4279-bcec-5baf8d59092f of=~/socketrc_backup.bin

The first 4 bytes are efivarfs attributes, not variable data. Change only MmiohBase (offset 0–1 → 00 02) and MmiohSize (offset 4–5 → 04 00), keep everything else as your machine has it, pad to 114 bytes.

---

Entering BIOS Setup and pressing Apply wipes the variable for me.

This cost me two full attempts. Setup seems to keep its own copy of SocketCommonRcConfig and flushes it on Apply, zeroing MmiohBase/MmiohSize again. Verified DataSize = 0x72 with dmpstore, went back into F2 to set Primary Video Slot, rebooted → back to BAR1 is 0M @ 0x0.

Byte 8 is why: it tracks PCIe Bus Allocation (00 = Default, 02 = Option 1). Setup owns this variable.

So the order has to be:

1. All BIOS Setup changes first (Above 4G, PCIe Bus Allocation = Option 1, Limit system memory <1TB, Primary Video Slot = empty slot, POST behaviour)
2. Re-read the variable after those changes, so byte 8 matches
3. Write via UEFI Shell
4. Boot straight to the OS — no F2, no Setup

If you go back into Setup afterwards, redo the write.

---

Other notes from the 7820:

• BIOS 2.52.1 (Jul 2026) works — variable layout unchanged from 2.50.0, and it survived the 2.46.0 → 2.52.1 update untouched.
• pci=realloc=on only. If you'd previously added nocrs while flailing, remove it. pci=realloc,nocrs looks like progress — the kernel assigns BAR1 an address — but the driver still fails RmInitAdapter because nothing backs it. Genuinely misleading while debugging.
• Check your shellx64.efi architecture. I grabbed an ARM64 build by mistake. It fails silently — the stick appears in F12, doesn't boot, drops into Dell SupportAssist "no bootable devices." file BOOTX64.EFI should say PE32+ executable for EFI (application), x86-64.
• Slot 2 works on the 7820, trains x16 (LnkSta: Speed 8GT/s, Width x16).

Success looks like the bridge finally getting a 64-bit prefetchable window:

pci 0000:b2:00.0: bridge window [mem 0x38c000000000-0x38cbffffffff 64bit pref]: assigned
pci 0000:b3:00.0: BAR 1 [mem 0x38c000000000-0x38c7ffffffff 64bit pref]: assigned
pci 0000:b3:00.0: BAR 3 [mem 0x38c800000000-0x38c801ffffff 64bit pref]: assigned
[drm] Initialized nvidia-drm 0.0.0 20160202 for 0000:b3:00.0 on minor 0

[GezelligLLC]

@StevieClear - you're the best! Thanks so much for the detailed explanation and instructions. I followed them carefully and only added 2 validation reboots to make sure I hadn't broken anything. The first was right after saving the BIOS edit. Once that worked fine, I edited the GRUB file, and did the second validation reboot. All went well. I shut down, installed the B70 and sha-bam! Booted perfectly into Ubuntu. One additional note - I left an old AMD Radeon Pro WX 2100 installed in slot 5. That card drives my 2 monitors. Works perfectly with that 2 Gb card in alongside the B70. I don't even need to run headless! I couldn't be more excited, nor could I be more grateful to you and the amazing work you did to make this possible.

I just finished installing and setting up my Intel Arc Pro B70 in Ubuntu - frankly that was MUCH more difficult to accomplish, but it is getting done. Next, I plan to try installing a 2nd B70 in the other CPU's slot 4. I'll update here to let everyone know if it works. Again, thanks a ton!

[GezelligLLC]

We have Precision 5820's with the same issue / problem. Would like to install at least one Intel Arc Pro B70 in those. How might we go about determining if those machines have the same setting available? If so, we'll do essentially the same setting change on those and repurpose 'em too. Can you point me in the right general direction to find out?

[StevieClear]

@StevieClear - We're doing some advanced quantitative analyses for financial systems on one side of the business, with the other side doing some deep R&D into some very sophisticated AI-assisted writing systems. I'd be happy to share / discuss either or both via a more confidential venue. I'm not sure how to privately share contact info in order to facilitate that.

@GezelligLLC I absolutely would! I don't want to break community guidelines, but feel free to reach out here:
https://armadillolabs.io/contact/

I have a pretty interesting angle on all of this to. Would love to talk shop and help out in any way I can.

Thanks

[GezelligLLC]

I posted a message on your website contact page. Looking forward to brainstorming and to hearing your perspectives. BTW, I've been working with Claude to figure out if we can get our 5820 machines similarly configured. I'm waiting on some parts, but this looks very hopeful too. I see so many posts expressing frustration with not being able to enable reBAR on these machines. Pretty absurd when Dell could simply provide the setting via a BIOS update. Easy-peezy. But noooooo! Anyway, if I get the 5820s working, I'll update here with full procedure for doing so.

[StevieClear]

Weird I didn't get it, email Steve@ and I will respond to email, but would love to catch up!

[daverdfw]

@StevieClear - you're the best! Thanks so much for the detailed explanation and instructions. I followed them carefully and only added 2 validation reboots to make sure I hadn't broken anything. The first was right after saving the BIOS edit. Once that worked fine, I edited the GRUB file, and did the second validation reboot. All went well. I shut down, installed the B70 and sha-bam! Booted perfectly into Ubuntu. One additional note - I left an old AMD Radeon Pro WX 2100 installed in slot 5. That card drives my 2 monitors. Works perfectly with that 2 Gb card in alongside the B70. I don't even need to run headless! I couldn't be more excited, nor could I be more grateful to you and the amazing work you did to make this possible.

I just finished installing and setting up my Intel Arc Pro B70 in Ubuntu - frankly that was MUCH more difficult to accomplish, but it is getting done. Next, I plan to try installing a 2nd B70 in the other CPU's slot 4. I'll update here to let everyone know if it works. Again, thanks a ton!

I am trying to do this with a B50 Pro, and linux sees the card, but its saying it cant re-size the BAR. I have the option for Memory above 4GB selected in the bios, any ideas whats going wrong?

[drm] Failed to resize BAR2 to 16384M (-ENOSPC). Consider enabling 'Resizable BAR' support in your BIOS

[tomuk5]

can create a bootable stick for using a script to save having to type it all out

#!/usr/bin/env python3
import os
import sys
import shutil
import urllib.request
import ssl

VAR_NAME = "SocketCommonRcConfig"
VAR_GUID = "4402ca38-808f-4279-bcec-5baf8d59092f"
EFIVAR_PATH = f"/sys/firmware/efi/efivars/{VAR_NAME}-{VAR_GUID}"
STAGING_DIR = "./t7920_usb_patch"

DMI_PRODUCT = "/sys/class/dmi/id/product_name"
DMI_BIOS = "/sys/class/dmi/id/bios_version"
DMI_VENDOR = "/sys/class/dmi/id/sys_vendor"

SHELL_URL = "https://github.com/pbatard/UEFI-Shell/releases/latest/download/shellx64.efi"
TOOL_URL = "https://github.com/datasone/setup_var.efi/releases/latest/download/setup_var.efi"

# Fixed NSH Script utilizing native 512GB Base Allocation parameters
NSH_CONTENT = """@echo -off
cls
if "%1" == "" then
  echo "=========================================================================="
  echo "          Precision 7920 NVRAM Allocation Automation Tool"
  echo "=========================================================================="
  echo " To execute a command, re-run this script with an option argument:"
  echo ""
  echo "   Type:  startup.nsh 1    -> Apply 512GB Base Offset & 256GB Window"
  echo "   Type:  startup.nsh 2    -> Run Live NVRAM Diagnostic Readout"
  echo "=========================================================================="
  goto END
endif

if "%1" == "1" then
  goto APPLY_FIX
endif

if "%1" == "2" then
  goto READ_DIAG
endif

echo "[-] Unknown parameter option. Use '1' or '2'."
goto END

:APPLY_FIX
echo ""
echo "[*] Targeting VarStore: SocketCommonRcConfig"
echo "[*] Setting MmiohBase to 512GB (Offset 0x00, 2-Byte)..."
setup_var.efi SocketCommonRcConfig:0x00(2)=0x0200
echo ""
echo "[*] Setting MmiohSize to 256GB (Offset 0x04, 2-Byte)..."
setup_var.efi SocketCommonRcConfig:0x04(2)=0x0004
echo ""
echo "[+] Configuration successfully written."
echo "Performing hardware reset in 5 seconds..."
stall 5000000
reset -c
goto END

:READ_DIAG
echo ""
echo "[-] Current MmiohBase (Offset 0x00):"
setup_var.efi SocketCommonRcConfig:0x00(2)
echo "[-] Current MmiohSize (Offset 0x04):"
setup_var.efi SocketCommonRcConfig:0x04(2)
echo ""
goto END

:END
"""

def main():
    if os.getuid() != 0:
        print("[-] Error: This script must be executed as root.")
        sys.exit(1)

    print("==========================================================================")
    print("📋 SYSTEM HARDWARE AUDIT & VALIDATION")
    print("==========================================================================")

    vendor, product, bios_ver = "Unknown", "Unknown", "Unknown"
    try:
        if os.path.exists(DMI_VENDOR):
            with open(DMI_VENDOR, "r") as f: vendor = f.read().strip()
        if os.path.exists(DMI_PRODUCT):
            with open(DMI_PRODUCT, "r") as f: product = f.read().strip()
        if os.path.exists(DMI_BIOS):
            with open(DMI_BIOS, "r") as f: bios_ver = f.read().strip()
    except Exception as e:
        print(f"[-] Warning: Failed to parse DMI tables: {e}")

    print(f"[+] Vendor Identity:  {vendor}")
    print(f"[+] Platform Model:   {product}")
    print(f"[+] Active BIOS Ver:  {bios_ver}")

    if "7920" not in product and "7920" not in sys.argv:
        print("\n[!] WARNING: Target platform is not explicitly identified as a Precision 7920.")
        sys.exit(1)

    print("\n==========================================================================")
    print("🔬 NVRAM VALUES & STAGING TARGETS")
    print("==========================================================================")
    if not os.path.exists(EFIVAR_PATH):
        print(f"[-] Error: Could not locate variable {VAR_NAME}.")
        sys.exit(1)

    with open(EFIVAR_PATH, "rb") as f:
        raw_data = f.read()
    
    payload = raw_data[4:]
    current_base = (payload[1] << 8) | payload[0]
    current_size = (payload[5] << 8) | payload[4]
    
    print(f"[+] Live MmiohBase raw offset [0x00]: {hex(current_base)} ({current_base} GB)")
    print(f"    -> Target Patch Value:           0x0200 (512 GB Base Boundary)")
    print(f"[+] Live MmiohSize raw offset [0x04]: {hex(current_size)}")
    print(f"    -> Target Patch Value:           0x0004 (256GB Window Scale)")

    if os.path.exists(STAGING_DIR):
        shutil.rmtree(STAGING_DIR)
    
    boot_dir = os.path.join(STAGING_DIR, "EFI", "BOOT")
    os.makedirs(boot_dir, exist_ok=True)

    ssl_context = ssl._create_unverified_context()
    try:
        print(f"\n[*] Downloading assets...")
        with urllib.request.urlopen(SHELL_URL, context=ssl_context) as response:
            with open(os.path.join(boot_dir, "BOOTX64.EFI"), "wb") as out_file:
                shutil.copyfileobj(response, out_file)
        with urllib.request.urlopen(TOOL_URL, context=ssl_context) as response:
            with open(os.path.join(STAGING_DIR, "setup_var.efi"), "wb") as out_file:
                shutil.copyfileobj(response, out_file)
    except Exception as e:
        print(f"[-] Network Error: {e}")
        sys.exit(1)

    with open(os.path.join(STAGING_DIR, "startup.nsh"), "w", encoding="utf-8") as f:
        f.write(NSH_CONTENT)

    print("\n==========================================================================")
    print("🚀 SUCCESS: STAGING ENVIRONMENT UPDATED TO 512GB BASE")
    print("==========================================================================")
    print(f"Format your USB to FAT32, copy the contents of '{STAGING_DIR}' to the root,")
    print("boot it up, and run: startup.nsh 1")
    print("==========================================================================")

if __name__ == "__main__":
    main()

[GezelligLLC]

Brilliant. Well done

[tomuk5]

Only thing is it changes the settings but this doesnt work with Intel ARC B580 cards as they need resizable bar, trying to find a way to use linux to override the ACPI table and fix the pcie root bridge into 64bit mode and allow larger bar values

[GezelligLLC]

I used the settings and procedure that @StevieClear provided above. I have 3 Intel Arc Pro B70 cards running very happily in one of our T7920s. I also followed a similar, albeit slightly different approach, and now have 2 Intel Arc Pro B70 cards running in a 5820 workstation as well. Both run Linux. Both use llama.cpp. Both perform extremely well and provide inference performance right at advertised benchmarks for these cards. We just couldn't be happier to see this work so well. We've essentially taken machines that were destined for the scrap heap and turned them into inference beasts. I'm attaching 2 PDF files that describe the process for each machine. I had my buddy Claude help create them. Each one presents a step-by-step guide to configuring the BIOS directly from shell. Why would you have to do that, you might ask.... Well, because our illustrious friends at Dell have decided that they should refuse to expose the setting in the BIOS config screen. To be clear, the setting exists in BIOS on both machines - it is simply hidden because Dell won't let you see it. What these guides do is show you how to access the setting and increase it to allow sufficient addressable memory for your machine to boot with these cards installed. I sincerely wish you all the best with your efforts to do great things with these powerful older machines that I believe still have a few years of useful life left in them.
Precision_5820_MMIO_GPU_Unlock_Guide.pdf
Precision_7920_MMIO_GPU_Unlock_Guide.pdf

[hock-dawner]

Thank you all for this! I had been looking how to do this to my T7920 for Intel Arc GPUs. I have an A770 and A750 that I passthrough to Windows VMs on proxmox. I have to run older GPU firmware because of my lack of ReBAR support. I'll keep you posted how it goes.

I also have 2x nvidia V100 that I wanted to try out as well.

[d4vid1]

Hi everyone,

I have a Dell 7820 tower with 128 GB ECC RAM and an NVIDIA GeForce 4060, running BIOS version 2.50 (the latest version currently available). Would it be possible to reduce the boot time ( Windows Loading Delays Keyboard and Mouse not work at Windows Boot (Spinning Dots)) fastboot is on, using the method described above? My computer takes about a minute from the Dell logo to the login screen, whether I’m booting into Windows 11 or Ubuntu 26.04 (I have a dual-boot setup).

Please help me modify the EFI parameters in my BIOS—I suspect that memory training or similar hardware initialization is causing this delay at every startup, F12 Dell Diagnose Tool say Everythink is okay on Fast or Full Test. There’s also no setting in the BIOS to bypass this memory training by saving the training data or anything similar.

Thanks in advance