Rod Burlamaqui's arc-rebar Script Gives an Intel Arc B580 Resizable BAR on a 2015 Supermicro Board With No BIOS Option, Taking VRAM Bandwidth From 15 to 392 GB/s

The test box is the kind of thing people pull out of a datacenter skip: two Xeon E5-2670 v2 chips on an Intel C602 board, “AMI BIOS 3.2 from 2015 — no ReBAR option,” according to the project’s README. Into it went a 12 GB Arc B580, Debian 13 and the xe driver.

Out of the box the card shows the CPU a 256 MiB slice of its memory. A 4K Vulkan blur in ffmpeg “stalls, 0 frames.” After arc-rebar runs at boot, the same filter does 39 to 50 fps, Vulkan sees “one 11.93 GiB heap,” and the largest OpenCL allocation goes from 256 MiB to 1 GiB.

The cause is weirder than “old BIOS.” Arc cards carry their own PCIe switch, and that switch’s upstream port has “its own small BAR (8 MB)” that firmware drops into the same window as the VRAM. When the driver asks to grow the VRAM window, the kernel will release bridge windows “but never a bridge’s own BAR,” so the request fails with -ENOSPC. Burlamaqui’s README is blunt about it: “Free address space is irrelevant; the test machine had 63 GB free above 4 GB.”

Intel’s own engineers found the same snag. In October 2025 Lucas De Marchi posted a kernel patch to release that BAR, and the thread on the Linux kernel mailing list carries Intel’s Ilpo Järvinen saying “this feels quite hacky to me.” Months before that, Icenowy Zheng’s own patch described the culprit as “a mysterious 8MB 64-bit prefetchable BAR.” The README says Intel’s quirk “stalled in review and is not in mainline as of kernel 7.1. This tool does the equivalent from userspace.”

The userspace version is a sysfs trick. Early in boot it unbinds the GPU’s drivers, writes the Resizable BAR control register with setpci, removes the card’s root port and rescans the bus, so the kernel lays out the window again from scratch. Intel’s patch had ruled that out by hand, saying “removing the topmost bridge this quirk targets would result in removing the GPU device as well so no manual workaround for this problem exists.” arc-rebar removes it anyway, from the initramfs, before anything is using the card. If BAR2 comes back without an address, it rolls back “so the machine ends the boot on the old 256 MB rather than with no GPU.” The README adds: “Every exit path returns 0 — boot is never failed.” Burlamaqui credits the remove-and-rescan method to a gist by andersevenrud for a Supermicro H11SSL-i.

Updating the card’s firmware didn’t help. FWCODE 21.1137 to 21.1182 and a new option ROM “changed nothing,” because the limit sits on the host side. Alchemist cards use the same switch design and are still untested.

Patches like Intel’s tend to land eventually, and when one does, arc-rebar says it sees “already at target” and exits. Until then, hardware the firmware vendors abandoned keeps getting a second life from people who read the kernel’s own error messages closely enough to work around them, and expect more of these one-register fixes for cheap used server boards as new GPUs keep assuming Resizable BAR.

The open question is reach. Burlamaqui’s board has the card sitting right on a root port, and the tool refuses anything behind “an external switch, riser, or Thunderbolt.” How many other abandoned boards share that layout is something only more test reports will tell.