Open PC on a workbench at night: a graphics card next to the motherboard, whose BIOS chip is highlighted by a beam of light, with a monitor showing red error lines in the background

Ever since I installed openSUSE Tumbleweed on this machine (GNOME on Wayland, NVIDIA RTX 2070), Chromium kept crashing, and I'm fairly sure the same problem was behind various lags and stutters elsewhere in the system too. It went on for months. The kernel log always showed the same NVIDIA driver errors: dmaAllocMapping_GM107: can't alloc VA space for mapping and NV_ERR_NO_MEMORY from mapping_reuse.c. It turned out to be a confirmed NVIDIA driver bug with no fix released, but with an officially confirmed mitigation: Resizable BAR. The catch: my 2019 Turing card doesn't support Resizable BAR. This is the story of how it got it anyway, and what went wrong along the way.

Full disclosure, and honestly one of the cooler aspects of this story: most of the actual work in this project was done by Claude (Anthropic's AI, running as Claude Code on my machine). It researched the bug, diagnosed my system, built and verified the firmware images, wrote the tooling, and talked me through every risky step. My contributions were the hardware side of things: BIOS menus, USB sticks, and keeping my nerve during a ten-minute black screen. I'll write "we" below, because that's what it was.

The symptom

It would strike at random, often on media-heavy websites: the whole system would suddenly slow down massively, sometimes to the point of a complete freeze that could only be fixed with a hard reset. More often it was recoverable: closing or killing Chromium and then waiting for the flood of systemd-coredump processes (spawned by all the crashing Chromium processes, each busily saving a core dump) to finish churning would eventually give me a responsive system back. Beyond these episodes, I also noticed occasional lags and stutters elsewhere on the desktop, which I strongly suspect had the same root cause. dmesg was full of this:

NVRM: dmaAllocMapping_GM107: can't alloc VA space for mapping.
NVRM: nvAssertOkFailedNoLog: Assertion failed: Out of memory [NV_ERR_NO_MEMORY]
      (0x00000051) returned from pReuseMappingDb->pMapCb(...) @ mapping_reuse.c:273
NVRM: nvAssertOkFailedNoLog: Assertion failed: Out of memory [NV_ERR_NO_MEMORY]
      (0x00000051) returned from reusemappingdbMap(...) @ kern_bus_gm107.c:3145
[nvidia-drm] *ERROR* [GPU ID 0x00000400] Failed to map NvKmsKapiMemory
traps: Media[14435] trap invalid opcode ip:... in chrome[...]

If you found this post by searching for these messages: you are not alone, your hardware is fine, and there is a good chance you don't need most of this article. See the mitigations section below.

The diagnosis

This is NVIDIA bug 5762513, a regression introduced around driver 580.126.09 and still present in the 595/610 series as of July 2026. The driver's new "mapping reuse" allocator exhausts BAR1, the PCI window through which the CPU maps GPU memory. On cards without Resizable BAR, that window is only 256 MB. Under Wayland, compositors and browsers create and destroy lots of GPU buffer mappings, the window fragments, allocations start failing, and the browser's GPU process dies.

Key facts, collected from the NVIDIA forum bug thread and GitHub issues (#1132, #1134):

  • It only happens on Wayland; X11 sessions are unaffected.
  • NVIDIA reproduced it in their lab and confirmed: with Resizable BAR enabled, the issue does not occur.
  • There is no driver option to disable the new allocator (the flag is hard-coded in the source).
  • No fixed driver version has been released as of this writing.

Mitigations if you don't want to flash your BIOS

Before we get to the fun part, the sane options:

  • Disable media autoplay in your browser. Several affected users confirmed this alone stopped the crashes.
  • Disable hardware video decode (chrome://flags → "Hardware-accelerated video decode"). This removes the biggest source of mapping churn, at the cost of CPU-side decoding.
  • Use an X11 session, where the bug does not reproduce at all.
  • Enable Resizable BAR in your BIOS. If your GPU is Ampere (RTX 3000) or newer, this is the actual fix and takes two minutes.

My GPU is a Turing RTX 2070 though. Turing supports Resizable BAR in hardware, but NVIDIA never enabled it in the vBIOS: the card only ever advertises BAR sizes up to 256 MB. Which brings us to the interesting route.

NvStrapsReBar: Retrofitting Resizable BAR onto Turing

NvStrapsReBar (a fork of the well-known ReBarUEFI) is a small UEFI DXE driver that gets inserted into your motherboard's BIOS image. At every boot, it reprograms the GPU's hardware straps so the card advertises Resizable BAR sizes up to its full VRAM, and optionally tells the firmware to allocate the large BAR right at POST.

The plan on my Gigabyte B550 AORUS PRO:

  1. Insert the driver (NvStrapsReBar.ffs) into the stock BIOS image using UEFITool 0.28. The image contains two BIOS copies, so it needs to be inserted twice (search for the DxeCore GUID, right-click → "Insert after").
  2. Flash the modified image.
  3. Configure the desired BAR size.

Sounds simple. It was not.

Roadblock 1: Q-Flash refuses modified images

Gigabyte's own flashing tool validates images and rejects anything modified: "Invalid BIOS image." The workaround is flashing the SPI chip directly from Linux with flashrom, which led to two more hurdles:

  • Secure Boot enables kernel lockdown, which blocks flashrom's raw hardware access entirely. It has to be temporarily disabled.
  • openSUSE's kernel additionally ships with strict /dev/mem protection. One boot with iomem=relaxed on the kernel command line (edit the GRUB entry with e; it's not persistent) takes care of that.

After that, flashrom identified the chip cleanly, and the golden rule of flashing applied: read the chip twice, compare checksums, keep the dump as a rollback. Then write with verification:

sudo flashrom -p internal:laptop=this_is_not_a_laptop -c "MX25U25635F" -r backup1.bin
sudo flashrom -p internal:laptop=this_is_not_a_laptop -c "MX25U25635F" -r backup2.bin
sha256sum backup1.bin backup2.bin   # must be identical!
sudo flashrom -p internal:laptop=this_is_not_a_laptop -c "MX25U25635F" -w modded.bin

(The laptop=this_is_not_a_laptop flag is needed because my board doesn't populate the DMI table, so flashrom can't tell it's a desktop.)

Roadblock 2: The board didn't boot, but not for the reason we thought

First attempt: black screen. No POST, ten minutes of nothing. This is where preparation pays off. Gigabyte's Q-Flash Plus can reflash a stock BIOS from a USB stick even when the board won't POST (file renamed to GIGABYTE.bin on a FAT32 stick, dedicated USB port, one button). Board recovered, nerves mostly intact.

The plot twist came during the post-mortem: the board had not rejected the modification. The problem was that we had built the DXE driver ourselves from the project's master branch. That code, as it turned out, doesn't even compile on Linux/GCC without patches, and its CI had been broken for over a year. Our self-built driver simply hung the board during early boot.

Second attempt with the official v0.3 release binary instead: the board POSTed immediately, and the driver reported for duty in its status EFI variable. Lesson learned: when flashing something into your firmware, use the release artifact that hundreds of other systems have already booted, not your own fresh build of an untested branch.

Configuration without Windows

The project's configuration tool is Windows-only, but the configuration itself is just an EFI variable with a layout that can be read from the source code. Claude wrote a small Python script that gathers the GPU's PCI data from sysfs and writes the variable via efivarfs, which does the job on a Linux-only machine. It is released as nvstraps-config on GitHub — read its warnings before use; it is only useful once the DXE driver is flashed, and it speaks the v0.3 format only. What it configures:

  • GPU straps size: looked up automatically from the driver's device registry (RTX 2070 → 8 GB).
  • GPU config: device/subsystem IDs and the BAR0 MMIO address, harvested from /sys/bus/pci/.
  • PCI BAR size: the crucial byte. It makes the DXE driver hook the firmware's PCI allocator so the large BAR is assigned at POST. (We first tried letting the Linux driver resize the BAR at runtime with NVreg_EnableResizableBar=1. That fails on this board because the GPU's sibling functions, USB and audio, occupy the same PCI bridge window and are in use. Firmware-side allocation avoids the problem entirely.)

The result

After one more reboot:

$ nvidia-smi -q -d MEMORY | grep -A2 BAR1
    BAR1 Memory Usage
        Total                                          : 8192 MiB

$ cat /sys/bus/pci/devices/0000:04:00.0/resource1_resize
0000000000003fc0     # 64 MB ... 8 GB advertised — previously 1c0 (max 256 MB)

An 8 GB BAR1 on a 2019 Turing card: the full VRAM is CPU-mappable, and the 256 MB window whose exhaustion caused all those crashes simply no longer exists. GPU-Z on the Windows side of the dual boot confirms Resizable BAR is active there as well.

Is the bug gone for good? Honestly, it's too early for a final verdict. The crashes were sporadic, so only a few weeks of normal use will tell. But the trigger condition has been removed, NVIDIA's own lab testing says the issue doesn't occur with Resizable BAR enabled, and dmesg has stayed clean since the mod. I'll update this post if anything changes.

Should you do this?

Honest answer: only if the soft mitigations aren't enough for you, and only with a tested recovery path. Our checklist for anyone attempting it:

  • Verify your recovery option first (Q-Flash Plus, BIOS flashback, or a hardware programmer) and prepare the recovery stick before flashing anything.
  • Use the official release of NvStrapsReBar, not a self-built binary.
  • Back up your flash chip with flashrom before writing, twice, and compare hashes.
  • Expect the crash-recovery cycle at least once. Budget an evening and your full supply of composure.
  • Remember the maintenance cost: every future BIOS update removes the mod (redo required), and a CMOS clear disables it (one command to re-enable).

Was it worth it? For me, yes: the trigger for the crashes is gone, this old card got a modern feature as a bonus, and I learned more about UEFI internals in one evening than in the ten years before it. And once NVIDIA eventually ships the actual driver fix, the mod loses none of its value. Resizable BAR is a good thing to have anyway.