JDS5 No-BS AI

Two GPUs, no POST: your second card didn't fail, your firmware ran out of address space

By Daniel S. · July 14, 2026

TL;DR: I put a second 16GB GPU into a workstation and the machine stopped POSTing — fans spinning, no video on any port, no network, never reaching an OS. It looks exactly like a dead card or a dead board. It was neither. Two resizable-BAR GPUs need their full VRAM mapped into the firmware's above-4G address window, and the window was sized for one. The fix is a BIOS knob that, on this machine, is not called "Above 4G Decoding" — and setting it is not the same as it taking effect.

The symptom, precisely

Single card: boots fine, has booted fine for days. Add an identical second card, and:

Every instinct says hardware. The card is DOA, the slot is dead, the PSU can't carry it. I have a genuinely dead GPU of the same model sitting in a box three feet away, which made that instinct very easy to believe.

It's worth being blunt about the thing that makes this expensive to diagnose: a big-BAR card that cannot be mapped hangs the box. It does not boot gracefully with the card ignored. It does not fall back to one GPU and grumble in dmesg. There is no error to read, because the firmware died before it had anywhere to print one. I'd seen the identical signature months earlier on a completely different machine with above-4G decoding switched off — same "no video on any port," same 22 minutes of nothing.

Do not expect graceful degradation. Nothing in the boot chain is going to tell you what's wrong, and that silence is itself the diagnostic clue.

What's actually happening

A modern GPU with Resizable BAR asks the firmware to map its entire VRAM into the CPU's address space in one contiguous region, up above the 4GB line. A 16GB card wants a 16GB window. Two 16GB cards want at least 32GB of above-4G space between them.

The firmware's above-4G window has a size limit, and on most boards it defaults to Auto. Auto looked at the machine as it was — one card — and sized accordingly. Add the second card, and there's no room to map it. The firmware cannot complete PCI enumeration, so it stops. Before POST. Before video init. Before anything that could tell you.

The mental model that gets you out: this is not a power problem or a lane problem, it's an address-space allocation problem, and it fails at the earliest possible moment.

The knob is probably not called what you're expecting

Every forum answer says "enable Above 4G Decoding." On the Lenovo ThinkStation P620 I was building, there is no attribute called "Above 4G Decoding" at all. You can hunt the BIOS menus for it as long as you like; it doesn't exist. Someone following the standard advice will conclude their board doesn't have the setting and go buy a different PSU.

The knob is:

MmioAbove4GLimit    options: Auto | 40 | 42 | 44 | 46 | 48

I set it to 48, the maximum, and disabled Resizable BAR support alongside it. The machine POSTed with both cards and has been stable since.

If you're on a different board, the lesson generalizes: search your firmware's actual attribute list, not the forum's name for the setting. On Linux, if the vendor exposes it, you can dump every knob the firmware has rather than guessing at menu names:

ls /sys/class/firmware-attributes/*/attributes/

That's the authoritative list for your machine. The name in the forum post is from someone else's machine.

Honest caveat: my fix is confounded

I changed two things at once — raised the MMIO limit and disabled Resizable BAR — and the box booted. So I know the pair works. I do not know which one was load-bearing, and I'm not going to pretend otherwise.

This matters practically, because ReBAR-off costs real GPU performance, and I may be paying that for nothing. The experiment to settle it is free and it's on my list: re-enable ReBAR, keep the limit at 48, reboot. If it boots, the window was the constraint all along and I take the performance back. If it hangs, ReBAR was doing real damage and I keep it off with a reason instead of a superstition.

If you hit this, change one knob at a time and you'll know something I don't.

Setting a firmware knob is not the knob taking effect

This is the part I'd most want a stranger to steal, because it burned me inside the same job.

The P620 lets you write BIOS settings from a running Linux over SSH (via the think-lmi driver) — genuinely great, since it means a BIOS change doesn't require a trip to wherever the machine physically lives. But those writes are pending settings. And when you read the value back:

cat /sys/class/firmware-attributes/thinklmi/attributes/ResizableBARSupport/current_value

…it cheerfully echoes back whatever you wrote even if the firmware never applied it. The read-back is not evidence. It's your own input, handed to you in a nice voice.

Demand a positive artifact instead — some observable downstream fact that can only be true if the setting really took. For ReBAR, that artifact is the BAR itself. With ReBAR truly off, a 16GB card's BAR1 collapses from 16GB to 256MB:

lspci -vvv -s <gpu> | grep -i 'Region 1'
# ReBAR ON :  Region 1: Memory at ... [size=16G]
# ReBAR OFF:  Region 1: Memory at ... [size=256M]

That string is the receipt. The read-back is a rumor.

The rescue knob is behind the door it opens

One more trap, and it's the one that decides whether this is a ten-minute fix or a plane ticket.

think-lmi — the thing that lets you fix the BIOS remotely — only exists under a running Linux. /sys/class/firmware-attributes/ is a live-kernel interface. A box that won't POST has no kernel, so it has no knobs.

The remote rescue tool cannot rescue the box from the state you need rescuing from. To reach the knobs, you must first get the machine to boot — which means physically pulling back to the one-card configuration that's known to work, booting that, writing the setting, powering down, reinstalling the second card. The remote path is only available after you've already been standing at the machine.

Plan for that. If a box is going somewhere you can't easily drive to, do your firmware changes while it's still in front of you.

If you can't see it POST, find your out-of-band signal first

The P620 has a 7-segment POST-code display on the board, and the BIOS exposes it as a settable attribute. That sounds like a footnote until you notice this machine's CPU has no integrated graphics — so with the GPUs pulled, there is no video output at all. "Remove everything and see if the bare board POSTs" is the most basic bisection step in hardware troubleshooting, and on this machine it is completely unobservable without that little display.

The 7-seg reports with zero cards installed. It was the only way to bisect a dark box.

Whatever your machine's version of that is — POST display, beep codes, a BMC, a debug LED — learn it before the machine goes dark, not while it's dark and you're guessing.

The checklist

If a machine won't POST after you add a second big-VRAM GPU:

  1. Don't buy anything yet. Fans-spinning-no-video with two big-BAR cards is an address-space symptom far more often than it's a dead card.
  2. Find your firmware's real attribute name. Dump /sys/class/firmware-attributes/*/attributes/ from a working single-card boot. It may not be called "Above 4G Decoding."
  3. Raise the above-4G MMIO limit to comfortably exceed the sum of your cards' VRAM. Two 16GB cards need 32GB+ of window.
  4. Change one knob at a time, unlike me, so your fix means something.
  5. Verify with a positive artifact, not a read-back. lspci BAR sizes, not current_value.
  6. Do it while you can still reach the machine, because the remote knob needs a booting OS.

The card was fine. The slot was fine. The PSU was fine. The firmware just had nowhere to put 32GB.