RIR fuse burn

RIR fuse burn (clears disable_sw_override)
Proven 10 GB
Driver	cmpunlocker-patched driver, or stock nvidia-open 610+
Unlock build	lixiangwuxian/170hx-rir-tool
Steps	RIR fuse burn
Source	link
Confirmations	Reproduced by @lxtend (10 GB), 2026-10-11 · details

Warning This is a permanent, irreversible fuse write. A wrong address can brick the card. It applies only to the 10 GB card (10de:2082). Do not do this unless you understand it.

What it is

The 10 GB card has 16 empty RIR (Redundancy Information Rows) slots. The 8 GB card's RIR rows were burned at the factory, so this does not apply to it. Burning two records clears the disable_sw_override gate fuse. After that, the volatile software fuse override (EN_SW_OVERRIDE) can be used to enable PCIe Gen3, the full 128 SM and (on a lucky card) the 6th HBM stack. The burn by itself unlocks nothing; it only opens the gate. Source: @scallion_9883, 2026-10-16

Humvee55 runs 20 unlocked 10 GB cards (128 SM, Gen3 x16) and 20 8 GB cards: "there is one fuse and one fuse only needed ... RIR the disable software override fuse. everything else can be done in software ... the SW IFF is volatile on reboot, so just don't flash any actual FF/IFF and you'll be fine." Source: @scallion_9883, 2026-10-16

The tool

lixiangwuxian/170hx-rir-tool (MIT, by @lxtend / lxwx), a standalone C tool that mmaps BAR0 and talks to the GA100 fuse block at 0x820000. It reads RIR records, applies volatile SW overrides, and (with two confirmations) burns RIR records. The author's own warning: the project was AI-assisted, validated only by the listed measurements; review cmd_write_rir in the source before running anything. Source: @lxtend, 2026-10-10

The record encoding

The group settled on the GA100 linear layout (an earlier scrambled layout produced a no-op burn):

Bits [15:2] = 14-bit absolute fuse-bit address, bit 1 = data, bit 0 = enable.
A RIR can only turn fuse 0s into 1s; bit 1 carries the value and need not be 1.
Bit 15 is record invalidation (for NVIDIA test mistakes), not an address bit.

The two keystone records are 0x0015 (row 0, bit 5) and 0x0095 (row 1, bit 5), written together as 0x00150095; bit 5 is disable_sw_override (PRI copy at abs bit 5, RED copy at abs bit 37). Source: @_orrorin, 2026-10-10 Source: @djpandaman, 2026-10-10

Prerequisites

From the tool's README:

Linux with the GPU installed, root.
Kernel command line iomem=relaxed (the tool cannot read anything without it).
The cmpunlocker-patched driver, or a stock 610+ driver, despite the tool only using the driver to power the card

 on. Source: @lycorascence, 2026-10-20

If a command reports the DEBUGCTRL RWL bit will not latch, unbind the driver first

 (echo <bdf> > /sys/bus/pci/devices/<bdf>/driver/unbind). Moving to an LTS kernel with the
 oldest cmpunlocker-supported driver avoids CONFIG_IO_DEVMEM_STRICT blocking access.
 Source: @lycorascence, 2026-10-23

Steps

Check first, burn once, then do the rest in software. Commands verbatim from the README:

# 1. Read-only status (shows RIR slots free and whether the gate fuse is 0)
sudo ./ga100_rir 0000:41:00.0
sudo ./ga100_rir 0000:41:00.0 --dump-rir

# 2. The permanent burn: clears disable_sw_override (PRI + RED), consumes 2 of 16 slots
sudo ./ga100_rir 0000:41:00.0 --write-rir 0 0x00950015

# then cold boot; the burn takes effect after a reboot

# 3. After the gate is open (--status shows "fuse : 0"), volatile overrides (lost on reboot):
sudo ./ga100_rir 0000:41:00.0 --sw-enable
sudo ./ga100_rir 0000:41:00.0 --sw-write gen3 0      # Gen3/Gen4 fuse bits
sudo ./ga100_rir 0000:41:00.0 --sw-write ecc 1       # ECC fuse bit

The write burns records targeting disable_sw_override PRI (row 0 bit 5) and RED (row 1 bit 5). The tool refuses a row whose existing slots are non-zero and differ from the request, saves a before/after backup, and requires two confirmations (type the row number, then BURN). A plain sudo reboot is enough for 99.9% of cases; you do not need hot-swap. Source: @lxtend, 2026-10-13

Register map the tool uses: FUSECTRL 0x00820000, FUSEADDR 0x00820004, FUSERDATA 0x00820008, FUSEWDATA 0x0082000C, EN_SW_OVERRIDE 0x00820040, DEBUGCTRL 0x00820060 (RWL bit 1), DISABLE_SW_OVERRIDE_STATUS 0x00820084, IFF_RECORD 0x00820050. SW-override writes go to the _CP shadow copies, e.g. OPT_GPC_DISABLE_CP 0x0082022C, OPT_NVLINK_DISABLE_CP 0x00820688. (From the repo README.)

Notes

Fuse budget: the 10 GB card shows 16 free slots; you can write 8 times but one write (the pair) is enough. Burn

 consumes 2 slots. Source: @xeax, 2026-10-25

The RIR tool only burns the fuse. It is a separate tool from cmpunlocker; once the RIR is

 overwritten the card unlocks the rest in software according to the research notes, and faults clear on restart.
 Source: @ob88594, 2026-10-26

orrorin's burn plan (rir_burn_plan.md, AI-drafted): Petri Krohn corrected and completed it: row 0

 of the main fuse array reads 0x53557c3d and bit 5 is DISABLE_SW_OVERRIDE; row 1 is a
 redundant duplicate of row 0 with the same fuse at bit 5; both must be zeroed by RIR records, which is the
 0x00150095 pair, and after that everything is software.
 Source: @_orrorin, 2026-10-09

 Source: @petrikrohn_26497, 2026-10-10

Humvee55's method notes (message.txt, 10,097 B, posted earlier in a smaller group): his RIR plus

 software-IFF method for the full 10 GB unlock; his advice was to feed it to an LLM to fill the gaps. Feralzi and
 Lycorascence used it to reach 126-128 SM. Source: @scallion_9883, 2026-10-16

xeax's notes (message.txt, 7,381 B) accompany the 170hx-rir-tool link with the warning not to brick

 the card and the fuse-slot write count. Source: @xeax, 2026-10-25

Paid service: a third party in Chengdu was reported to unlock a 10 GB card for about 500 USD. Source: @ob88594, 2026-10-09 aaasss said a friend had a 10 GB card done at the factory the day before ("8912 cuda core", as posted) and that it was paid software, maybe VBIOS. Source: @aaasss1456, 2026-10-09
Source: @aaasss1456, 2026-10-09 The vendor's text, quoted by AnalyticETH: all changes are permanent in the card, no third-party unlocking software or driver patches, it identifies as an original A100; the first batch takes 10 GB cards and the 8 GB version is "still under development". Source: @analyticeth, 2026-10-09
Source: @analyticeth, 2026-10-09 Miséricorde read it as this same RIR macro burn, not a VBIOS change, and asked how it would then identify as an A100 40G. Source: @wakeupmbrc1, 2026-10-09
Source: @wakeupmbrc1, 2026-10-09 Treat as hearsay.

Known issues / warnings

Warning Targeting the wrong address has a good chance of bricking the card. This is not trial and

 error; the 1.8 V fuse programming is one-shot. Source: @djpandaman, 2026-10-05

Warning Do not spend RIR rows prematurely. A software-only (SW IFF) recipe was shared that does most

 of the work without burning; save your slots until more is discovered. There will be an influx of used 10 GB cards
 with wasted RIRs and no unlock; check the fuse state before buying one.
 Source: @scallion_9883, 2026-10-26

Enabling defective-marked GPCs/FBPAs does not help; those are genuinely defective. Enable only disabled units, and

 mask off the defective TPCs within a defective GPC. Source: @zorg33, 2026-10-22

Status

Burned, read back, survives a cold boot and clears the gate fuse, confirmed by more than one person, so Proven. See the confirmation below. The further unlocks it enables each have their own page.