Flashing the 300 W VBIOS

Most 8 GB cards ship with VBIOS 92.00.67.00.01, the 250 W image. On it the driver reports a GPC and memory VF-offset range of [0 .. +0], so no undervolt can be applied, whatever a tool says it set. The factory 300 W image 92.00.6D.00.0A, which NVIDIA shipped on the same board part number (900-11001-0108-000), exposes an offset range of [-1000 .. +1000], boots the HBM at 1728 MHz instead of 1458 MHz, raises the SM ceiling from 1410 to 1695 MHz, and keeps a 250 W default cap (300 W is the maximum it allows). This page is the flash procedure as run on eight cards in one night, with the numbers before and after. It does not touch the memory or compute unlock, which stays in the driver; see Driver unlock.

The 10 GB card has no 300 W image (its only VBIOS is 92.00.66.00.02); this page is for 8 GB cards. See VBIOS and firmware for the full image inventory.

Why flash it

The 250 W image has no undervolt lever

nvml_oc -i N (the helper 170tune uses) reports allowed range : [0 .. +0] MHz for both the GPC and the memory VF offset on every 92.00.67.00.01 card. An offset call can return success and the driver still drops it; only a readback proves it applied. On the same cards after the flash the range reads [-1000 .. +1000].

Proven 8 GB
Source: @mrpec, 2026-08-01
Source: @unmotivatedgene, 2026-08-23
Source: @darkmaniac7, 2026-10-31 (lab notes)

Same board, same IDs

Both images carry device 10DE:20C2, subsystem 10DE:1585 and board ID 0x030A, and both have been read off cards with board part number 900-11001-0108-000 and die 20C2-105-A1. nvflash accepts the 300 W image on a 250 W card without any override because the IDs match; it is a signed NVIDIA image, not a modified one.

Reported 8 GB
Source: @con3po7016, 2026-08-23
Source: @wakeupmbrc1, 2026-08-30

Before you start

An 8 GB card on 92.00.67.00.01. Read it with nvidia-smi --query-gpu=index,pci.bus_id,vbios_version --format=csv. A card already on 92.00.6D.00.0A has nothing to gain.
nvflash 5.867 for Linux, the x64/nvflash binary from the TechPowerUp download (the zip holds x86, x64, aarch64 and ppc64 builds; the Windows zip is a different download).
The ROM, TechPowerUp VBIOS database entry 268495 (listed there as "CMP 170HX 0 MB"; the size column is wrong). Verify it before it goes near a card: see below. A copy is attached to this page.
A rollback ROM. Save one card's 92.00.67.00.01 image with nvflash -i N --save before you write anything. The static part of the image is identical across cards of the same version, so one dump serves as the rollback for all of them.
A way to power the machine off and on that does not depend on the GPUs: a BMC, or someone at the button. The procedure needs two cold cycles, and a wedged flash controller only clears on a cold cycle.
The driver unloaded, or never loaded. nvflash refuses to write with the NVIDIA kernel module present. The method below boots without it, which also avoids the unbind hang described further down.

Verify the ROM

The TechPowerUp file matched these values exactly:

Field	Value
Version	92.00.6D.00.0A
Build / modification date	06/16/21 / 04/07/22
Size	1,044,480 bytes
Device / subsystem / board ID	0x20C2 / 0x1585 / 0x030A
MD5	a58aae86e72b13d50603c15653350664
SHA1	efad37d514bb94ac345719a0c56d9cd147cddfb7
SHA256	789e8f8d4c70dc9eb114c9fdcef6ed2d00aedf15a1eca522519de02042818723

Two checks that do not depend on a hash:

nvflash --version 300w.rom reads the header from the file only (it does not touch a card) and must print the version, device, subsystem and board IDs above, and License Placeholder : Present.
python3 check_rom.py 300w.rom --expect 300W (attached) checks the structural markers: the NVGI header, the 300 W power bytes E0 93 04 at 0x46045, the strap tier byte 0x44 at 0x41F53 (0x66 there means a forged "64 GB" ROM that bricks the card at boot), an all-zero license region at 0xFE504, and the dual-bank mirror. The same script recognises the 250 W image (--expect 250W) for checking your rollback dump.

Reported 8 GB
Source: repo github.com/polyuij42-del/cmp170hx-vbios-flash by polyuij42-del on GitHub
Source: repo github.com/Consensus-Protocol/cmp170hx by Consensus-Protocol on GitHub

The procedure (driverless boot)

Proven on eight cards in two rounds, 2026-10-31, on a bare-metal Ubuntu box with the cmpunlocker driver build 615.71.09, BMC power control and the tooling attached below. Every write took about 10 seconds. Read the two rules first:

One nvflash operation per card per boot. After a power-on, the first nvflash command that touches a card's flash controller (--check, --save or a write) works; a second one on the same card fails with Falcon In HALT or STOP state or Detecting GPU failed and nothing is written. So the rollback save comes from a card you are not writing in that boot (or from an earlier boot), and the write is the first and only thing you do to each target card. A PCIe remove and rescan of one device (echo 1 > /sys/bus/pci/devices/0000:XX:00.0/remove; echo 1 > /sys/bus/pci/rescan) re-opened the window once in the lab; do not count on it.
nvflash 5.867 ignores -y and refuses piped input. The confirm prompt needs a real terminal. It prints the card's current and replacement version strings before the prompt, and the PCI bus only in its Results table after the operation, so the attached controller confirms on the version strings (current must be 92.00.67.00.01, replacement 92.00.6D.00.0A) and checks the bus afterwards. nvflash's -i index follows PCI bus order, the same order nvidia-smi uses with CUDA_DEVICE_ORDER=PCI_BUS_ID; the Results table confirmed -i 7 = bus C2 on the lab box.

Steps:

Stop everything that holds the GPUs (engines, miners), until lsof /dev/nvidia* shows nothing. Record every card's VBIOS version.
Keep the driver out of the next boot: /etc/modprobe.d/zz-flash-window.conf with install nvidia /bin/false (and the same for nvidia_modeset, nvidia_drm, nvidia_uvm). Mask or disable the units that would start GPU work at boot (docker, miners, any model loader). Note what you changed.
Cold cycle: power off, 30 seconds dark, power on. Confirm lsmod | grep nvidia is empty and that the cards are enumerated with no driver bound.
Save the rollback ROM from a card you will not write this boot: nvflash -i N --save backup.rom, then check_rom.py backup.rom --expect 250W.
Write each target card once: nvflash -i N 300w.rom, answer y at the prompt (or let the attached controller do it). Success looks like a progress bar to 100 %, two verification reads, and A reboot is required for the update to take effect. with exit code 0. Anything else: do not retry that card this boot.
Remove the blacklist, restore the units, cold cycle again.
Verify: nvidia-smi --query-gpu=index,vbios_version,memory.total,clocks.max.memory,power.default_limit,power.max_limit --format=csv should show 92.00.6D.00.0A, your unlocked memory size, 1728 MHz, 250 W default and 300 W maximum; nvml_oc -i N should show the [-1000 .. +1000] range.

The attached window.sh runs those phases (check, prep, flash, restore, verify) with the lab box's unit names and bus map; edit those before using it elsewhere.

Proven 8 GB
Source: @darkmaniac7, 2026-10-31 (lab notes)
Source: repo github.com/polyuij42-del/cmp170hx-vbios-flash by polyuij42-del on GitHub

Why not unbind the driver instead

The repository above spent eighteen script versions on the unbind route. With any process still holding /dev/nvidia*, echo ... > /sys/bus/pci/drivers/nvidia/unbind hangs in the driver's remove path and never returns; on one of its two cards it hung even with zero handles open, and a reboot issued in that state stalled the machine until someone cut the power. Booting with the modules blacklisted sidesteps all of it.

Warning 8 GB
Source: repo github.com/polyuij42-del/cmp170hx-vbios-flash by polyuij42-del on GitHub

Others who flashed it with nvflash

Several owners did the same flash with stock nvflash before the lab did, on Linux and on Windows; none reported a brick from it. The bricks reported on the server came from fuse burns, SPI strap edits and A100 cross-flashes, not from this image.

Reported 8 GB
Source: @c133, 2026-08-23
Source: @c133, 2026-08-27
Source: @shirogeek, 2026-09-06
Source: @derick2k, 2026-09-06
Source: @phoenixone7, 2026-09-16
Source: @wakeupmbrc1, 2026-08-30

Results on eight cards

Two of the eight (bus 41 and C1) have FBPA0 fused off (one dead HBM stack each). Both took the image and initialised cleanly at 1728 MHz; the driver log after the flash matched the log before it line for line in shape (the unlock's privilege-mask loop prints 54 "Booter failed" lines per card on every boot; that is normal, not damage).

Card (bus)	VBIOS after	Memory	Max mem clock	Default / max cap	Offset range	Note
0 (01)	92.00.6D.00.0A	65536 MiB	1728 MHz	250 / 300 W	-1000 .. +1000
1 (22)	92.00.6D.00.0A	65536 MiB	1728 MHz	250 / 300 W	-1000 .. +1000
2 (41)	92.00.6D.00.0A	65536 MiB	1728 MHz	250 / 300 W	-1000 .. +1000	FBPA0 fused
3 (61)	92.00.6D.00.0A	65536 MiB	1728 MHz	250 / 300 W	-1000 .. +1000
4 (81)	92.00.6D.00.0A	65536 MiB	1728 MHz	250 / 300 W	-1000 .. +1000
5 (A1)	92.00.6D.00.0A	65536 MiB	1728 MHz	250 / 300 W	-1000 .. +1000
6 (C1)	92.00.6D.00.0A	65536 MiB	1728 MHz	250 / 300 W	-1000 .. +1000	FBPA0 fused
7 (C2)	92.00.6D.00.0A	65536 MiB	1728 MHz	250 / 300 W	-1000 .. +1000	first attempt aborted by the controller, window re-opened by a PCIe rescan, second write fine

Zero Xids, zero ECC errors, zero RmInitAdapter failures across four cold cycles.

Proven 8 GB
Source: @darkmaniac7, 2026-10-31 (lab notes)

What it changed

The load is a proof-of-work miner (pearlhash, OneZeroMiner) on all eight cards with the fan wall at 15 % and caps set per card by a thermal governor (230 to 250 W). The rejected shares below were all "Stale share" (a share submitted after the pool changed the job: timing, not a wrong answer); there were no invalid shares.

State	Total hashrate	Core clock range	Temps	Notes
250 W image, offset 0	1,455 TH/s	1215 to 1290 MHz	70 to 79 C	baseline, same caps
300 W image, offset 0	1,459 to 1,470 TH/s	1215 to 1290 MHz	70 to 79 C	HBM 1728 MHz cost nothing on a compute load
300 W image, GPC offset +100	1,525 TH/s	1275 to 1365 MHz	unchanged	20 min soak, 0 Xid
300 W image, GPC offset +130	1,549 TH/s	1290 to 1380 MHz	unchanged	20 min soak, 0 Xid
300 W image, GPC offset +160	1,564 TH/s	1335 to 1410 MHz	unchanged	20 min soak, 0 Xid
300 W image, GPC offset +190	1,579 TH/s	1335 to 1425 MHz	unchanged	20 min soak, 0 Xid
300 W image, GPC offset +220, six cards	1,598 TH/s	1350 to 1440 MHz	unchanged	20 min soak, 0 Xid; two cards still parked by the false alarms
300 W image, GPC offset +220, all eight	1,631 TH/s	1350 to 1440 MHz	unchanged	09:57, after the two parked cards took +160/+190/+220 clean; +11.8 % over the morning baseline. Not a safe point: see the warning below

Power draw stayed at the caps the whole time: the offset lets the core hold a higher clock at the same watts, so the gain comes with no extra heat. Two cards were held back early by a stale share each (a rule that counted any rejected share; it now counts only invalid ones); re-run from +160, both took every rung.

The miner does not qualify an offset for inference

Warning 8 GB
One hour after all eight reached +220 with the miner clean, the lab ran its inference benchmark against GLM 5.3 Flash (TP4) on cards 0 to 3. Single-stream decode measured 268 tok/s against 232 before the undervolt (+15 %), 197 against 181 at two streams; then, one minute in, card 0 (the hottest slot, 77 to 79 C under the miner) began flooding Xid 48 (uncorrectable ECC error in GPC3 GCC) and Xid 172 (uncorrectable SRAM error in GPC 3), 97,000 lines in five minutes, and the engine died. That is the same pair the Discord reports for a too-deep offset. At the same time card 5, which only ever ran the miner, was found in "GPU requires reset" with no Xid at all, about two hours into +220. Lowering the offset does not clear either state: card 0 recovered with nvidia-smi -r, card 5 needed a cold cycle. What this means:

A 20-minute miner soak proves nothing about inference, and not much about a two-hour miner run either. Qualify each

 card against the engine that will serve on it, with a benchmark as the workload rung, and soak for hours, not minutes.

Hot-slot cards have the least margin. Expect them to land well below the cool ones.
+220 is not a safe point on this box. The lab reverted every card to 0 and will re-ladder with inference gating from

 +100 in 30 MHz steps.

Source: @darkmaniac7, 2026-10-31 (lab notes)
Source: @ichundes, 2026-10-07