Jump to content
Toggle search
Toggle menu
CMP Wiki
Toggle preferences menu
Toggle personal menu
Not logged in
Your IP address will be publicly visible if you make any edits.

Driver and unlock failures

From CMP Wiki
More actions

This page covers failures while installing or running the patched driver (cmpunlocker and its forks), the tools built on it (170tune, the RIR tools), kernel and GSP problems, P2P, and the operations that cannot be undone. For the unlock procedure itself see Driver unlock; for what each variant can unlock see Unlocks.

Before you install

  • cmpunlocker refuses any driver version not listed in its driver/VERSION file (at commit 2c7e2ec: 615.78.08, 615.71.10, 615.71.09, 610.57.04, 610.43.03, 610.43.02). It needs the nvidia-open driver with its libraries and firmware already installed, kernel headers for the running kernel, root, Python 3 with PyYAML, network access on the first install, and Secure Boot off (the patched modules are unsigned).
    Source: repo github.com/amoghmunikote/cmpunlocker by amoghmunikote on GitHub, posted by @rh3dai, 2026-10-08
  • The installer removes DKMS nvidia modules, so re-run it after every kernel upgrade. After installing, do a cold boot (shutdown -h now, then power on), then check sudo ./verify.sh, sudo dmesg | grep SEC2_DEBUG and nvidia-smi --query-gpu=pcie.link.gen.current,pcie.link.gen.max --format=csv (expect 2, 2).
    Source: repo github.com/amoghmunikote/cmpunlocker by amoghmunikote on GitHub, posted by @rh3dai, 2026-10-08
  • Use driver 615.71.09. Do not use 615.78.08 (next section).
  • Hold the kernel and every nvidia package (for example with apt-mark hold). A kernel upgrade makes DKMS build stock modules, and a new nvidia package overwrites the patched ones; either way the cards silently come back at 8 GB. Rebuild and reinstall the patched modules before taking a held upgrade, and identify modules by sha256 rather than srcversion.
    Source: @darkmaniac7, 2026-10-21 (lab notes)
  • Pin the driver version and the fork commit you run. Upstream master has been idle since 2026-10-07, v0.5 is probably the last feature release, and forks may go stale.
    Source: @darkmaniac7, 2026-10-22 (lab notes)
  • Only one NVreg_RegistryDwords line, and one NVreg_RegistryDwordsPerDevice line, takes effect: a second file or line silently replaces the first instead of merging. Check what the driver received in /proc/driver/nvidia/params, and run update-initramfs -u after a change if nvidia loads from the initramfs.
    Source: @darkmaniac7, 2026-10-21 (lab notes)
    Source: @darkmaniac7, 2026-10-29 (lab notes)
  • While testing, never leave a P2P, static-BAR1 or ECC option file in modprobe.d across a boot: those options have no fallback.
    Source: @darkmaniac7, 2026-10-19 (lab notes, darkmaniac7/cmp170hx-esxi)
  • Forks are not interchangeable. The Morrowmake fork carries P2P but drops the ECC patches and does not list 615.78.08 or 615.71.10. The asm64-hooligan fork is pinned to 610.43.0x and needs a cold reboot after install and after removal. Use the fork your recipe was measured on.
    Source: repo github.com/asm64-hooligan/cmpunlocker by asm64-hooligan on GitHub, posted by @rh3dai, 2026-10-04
    Source: repo github.com/Morrowmake/cmpunlocker by Morrowmake on GitHub, posted by @trustinter, 2026-10-07
  • On a host with other NVIDIA cards, pass --profile=8gb or --profile=10gb yourself. An older installer took the profile from the first GPU in nvidia-smi order, and an RTX 3080 10 GB in the same host produced a wrong 10gb profile twice.
    Source: repo github.com/Consensus-Protocol/cmp170hx by Consensus-Protocol on GitHub, posted by @rrickk420, 2026-10-09

Driver 615.78.08

Proven Upstream cmpunlocker lists 615.78.08 as supported (commit 2d10f89, "Add support for nvidia-open 615.78.08"). In October every field report on it failed:

  • The unlock installed with no errors, but the cards failed to train PCIe 2.0 at boot and showed in lspci but not in nvidia-smi. Downgrading to 615.71.09 loaded the unlock on the first try.
    Source: @drew_2, 2026-10-10
  • cmpunlocker did not work on 615.78.08; the boot loader (Booter) image changed in that release. Advice given: keep using the old booter.
    Source: @zagitta, 2026-10-17
    Source: @scallion_9883, 2026-10-17
  • Installing v0.5 with ECC errored out on 615.78.08. A second member confirmed 615.78.08 failed for him and 615.71.09 worked.
    Source: @catchyuser, 2026-10-20
    Source: @.henrykrinkle, 2026-10-20
  • The installer's Gen2 training and nvidia-smi both misbehave on the modified 615.78.08 driver.
    Source: @djpandaman, 2026-10-10

Fix: install 615.71.09 (610.57.04 is the older fallback). See Known bad combinations.

615.71.09 with RTX PRO 6000 cards in the same VM

Warning With nvidia-open 615.71.09 plus cmpunlocker in a VM that also holds RTX PRO 6000 (GB202) cards, the unlock itself worked (both CMPs at 65536 MiB), but any real CUDA context wedged: the Blackwells logged krcWatchdog: GPU is probably locked, every new GPU process hung at exit in uvm_va_space_destroy, nvidia-smi pollers piled up in D state, and only a VM reset cleared it. Setting uvm_enable_va_space_mm=0 and uvm_disable_hmm=1 did not fix it. NVIDIA lists the symptom as a known 615.71.09 issue. The lab ported the unlock down to 580.178.04 instead; 615.71.09 with cmpunlocker is fine on bare metal without those cards.

Source: @darkmaniac7, 2026-10-21 (lab notes, darkmaniac7/cmp170hx-esxi)
Source: @darkmaniac7, 2026-10-25 (lab notes, darkmaniac7/cmp170hx-esxi)

The card still shows 8 GB or 10 GB after the install

Work through these in order.
Source: repo github.com/Consensus-Protocol/cmp170hx by Consensus-Protocol on GitHub, posted by @rrickk420, 2026-10-09

  1. Cold boot. Shut down, switch off or unplug the PSU, wait, power on. An OS reboot is not enough after the first install. If memory stays at the stock size, power off completely before booting.
    Source: repo github.com/Morrowmake/cmpunlocker by Morrowmake on GitHub, posted by @trustinter, 2026-10-07
  2. Did the patched module run? sudo dmesg | grep SEC2_DEBUG. No output at all means the stock module loaded.
  3. Which module loaded? modinfo -n nvidia must point under updates/cmpunlocker/. A stock DKMS copy under updates/dkms shadows the patched module and the card shows only 8 GiB: run dkms remove nvidia/<version> --all, depmod -a, update-initramfs -u, confirm with modinfo -n nvidia, then shut down fully.
    Source: repo github.com/PixelML/club-170hx by PixelML on GitHub, posted by @c133, 2026-10-20
  4. Version mismatch. If nvidia-smi reports a driver/library version mismatch, the old module is still loaded. Reboot. Every memory.total reading taken through a mismatched nvidia-smi is meaningless.
  5. Multi-GPU host. When a patched and a stock nvidia.ko both sit under the updates path, depmod picks one and silently drops the other. Keep only the cmpunlocker copy there.
  6. After any driver or kernel update, check again: the card can silently fall back to its stock memory size instead of failing loudly.
    Source: repo github.com/PixelML/club-170hx by PixelML on GitHub, posted by @c133, 2026-10-20
  7. If it still misbehaves: run the uninstall script, cold boot, install again, cold boot.
    Source: @_orrorin, 2026-10-10

Build and install errors

  • Debian 13: stdarg.h: No such file or directory. On Debian 13.4 (kernel 6.12.113+deb13-amd64) with nvidia-open 615.71.09 and cmpunlocker 2d10f89 the module build failed with that error. Giving the build separate kernel source and build directories in driver/build.sh (KSRC="/lib/modules/${KVER}/source" and KSOUT="/lib/modules/${KVER}/build", passed to make modules as SYSSRC and SYSOUT) fixed it. Full write-up on Discord. Reported
    Source: @vipic, 2026-10-18
  • Build breaks after switching to a mainline kernel on Ubuntu: use the distribution kernel and install headers for the kernel you actually booted.
    Source: repo github.com/Consensus-Protocol/cmp170hx by Consensus-Protocol on GitHub, posted by @rrickk420, 2026-10-09
  • vGPU-and-others branch fails the build validator. The validator (tools/read-constants.py, errors such as "built but not declared") wants every patch in PATCH_ORDER declared under unlocks: in common/constants.yaml. One member declared the branch's three vGPU patches (vgpu-kvm-build.patch, vgpu-ga100-host.patch, vgpu-umd-version.patch, each with registers: {}) before the ecc: block, ran the validator for the 10gb profile and installed with --profile=10gb. He did not say whether vGPU then worked. Script on Discord. Reported
    Source: @arabus_74064, 2026-10-27
  • memtest_vulkan fails with loader_scanned_icd_add: Could not get 'vkCreateInstance' for libGLX_nvidia.so.0: the driver was installed with --no-install-libglvnd. Reinstalling with libglvnd fixed it. Reported
    Source: @alanoo, 2026-10-05

Kernel and desktop problems

  • On kernel 7.2.11, cmpunlocker's link retraining broke on a 10 GB card until the owner moved off 7.2.11 and rolled back the NVIDIA driver. He suspects a clash with the gpu_unlock module (the consumer-card tensor unlock), "possibly not aiming just for 3090 cards". Reported
    Source: @lycorascence, 2026-10-23
  • Tools that read BAR0 from userspace (170tune, the RIR tool) need iomem=relaxed on the kernel command line.
    Source: repo github.com/cachenetics/170tune by cachenetics on GitHub, posted by @rh3dai, 2026-10-04
    Source: @lycorascence, 2026-10-20
  • On a newer kernel, CONFIG_IO_STRICT_DEVMEM blocked the RIR tool; the LTS kernel with the oldest driver cmpunlocker supports worked.
    Source: @lycorascence, 2026-10-23
  • The gpcprobe kernel module must be rebuilt after every kernel upgrade.
    Source: repo github.com/matstatman/gpcprobe by matstatman on GitHub, posted by @matstatman, 2026-10-20
  • Do unlock and driver experiments on a headless host. The nvidia module often refuses to unload while a desktop holds it, and one developer reinstalled the OS after a botched nvidia.ko deploy on bare metal; test driver patches in a VM where you can.
    Source: repo github.com/Consensus-Protocol/cmp170hx by Consensus-Protocol on GitHub, posted by @rrickk420, 2026-10-09

GSP problems

  • A card that fails GSP init on every boot after an Xid: see Xid errors (Xid 1 and 119) and Recovery.
  • GSP turned off: one member applied the unlock, built a driver that keeps the unlock in place, then loaded the proprietary driver with NVreg_EnableGpuFirmware=0. The unlock survived the driver reload and there were no GSP panics. Another member doubts it unlocks anything new; the open driver needs GSP-RM, so this means the closed driver with CPU-RM. Reported
    Source: @zarknoth, 2026-10-27
    Source: @matstatman, 2026-10-27
    Source: @petrikrohn_26497, 2026-10-27
  • On the 10 GB card the unicast FBPA0 PLL register window is orphaned in hardware. The SEC2 booter faults when it touches it, which kills GSP init if forced; vektorprime's fork skips that window on the 10 GB card.
    Source: repo github.com/vektorprime/cmpunlocker by vektorprime on GitHub, posted by @rh3dai, 2026-10-04

170tune preflight fails

Symptom: [FAIL] FBPA privilege masks (unlock), "FBPA privilege masks are closed - host register writes will be dropped", or PLL PLM 0xBADF2010, MEM PLM 0xFFFFFFFF. A 0xBADF.... read is a PRI error: the register window is fenced.
Source: @rh3dai, 2026-10-04

FBPA PLL tools stopped two of eight cards from booting

Warning On an 8-card bare-metal box (nvidia-open 615.71.09), the vektorprime fbpa-pll-170tune lineage left two cards unable to boot (GSP booter error 0xffff). Both cards have FBPA0 fused off, with one dead HBM stack each, and the tools write the FBPA0 PLL registers 0x00903c7c / 0x009a0168. The cards came back on the Morrowmake driver lineage, which writes no PLL registers, so this was a boot failure, not permanent damage. admunch888's --mclk-ndiv opens the same registers, and the "NDIV 45 + refresh 24" HBM tune needs them too. Read each card's fuse map first (gpcprobe, OPT_FBPA_DISABLE) and skip FBPA PLL tuning on any card without a live FBPA0; a 0xBADF2010 preflight reading is this case. In a separate driver build, adding the unicast FBPA0 PLL register to the Booter's privilege-mask table broke init on such a card (RmInitAdapter 0x62) until the previous modules were restored and the VM power-cycled.

Source: @darkmaniac7, 2026-10-25 (lab notes, darkmaniac7/cmp170hx-esxi)
Source: @darkmaniac7, 2026-10-27 (lab notes)

  • Upstream hbm_mclk reads and writes the PLL through FBPA0. On a card with FBP0 floor-swept it reads 0xbadf2010 and would write that value into every FBPA; the fixed build (and vektorprime's fbpa-first-active branch) uses the first live FBPA instead.
    Source: @darkmaniac7, 2026-10-25 (lab notes, darkmaniac7/cmp170hx-esxi)
  • Wrong unlock lineage. 170tune's live memory lever writes the unicast FBPA0 PLL window (0x00903c7c/0x00903c98). asm64-hooligan's cmpunlocker opens only the broadcast window 0x009a3c7c, so preflight fails. Use an unlock that opens the unicast window (vektorprime's fbpa-pll-170tune branch with the fbpa-first-active 170tune branch), or set the memory clock at build time with --mclk-ndiv and skip the live ladder. 170tune refuses to tune a driver with a baked-in NDIV. Read the warning above before installing either.
    Source: repo github.com/asm64-hooligan/cmpunlocker by asm64-hooligan on GitHub, posted by @rh3dai, 2026-10-04
    Source: repo github.com/vektorprime/cmpunlocker by vektorprime on GitHub, posted by @rh3dai, 2026-10-04
    Source: repo github.com/vektorprime/170tune by vektorprime on GitHub, posted by @rh3dai, 2026-10-04
    Source: @vektor_prime, 2026-10-08
  • One card fails on every combination. One 8 GB card out of 36 unlocked to 74 SMs on v0.5 but failed preflight with every pairing tried (asm64-hooligan master, cachenetics/170tune, the vektorprime branches, amoghmunikote v0.4 and v0.5). With the vektorprime unlocker it was not found at all after a cold reboot. A second owner saw the same failure on all his cards with cachenetics/170tune plus amoghmunikote master, and again with the vektorprime pair. Workaround: run that card on the plain v0.5 unlock without 170tune. Root cause open. Reported
    Source: @rh3dai, 2026-10-04
    Source: @drew_2, 2026-10-12
  • Upstream removes three privilege gates, which resets the memory tune. The reporter fixed it locally but did not post the fix. Reported
    Source: @feralzi, 2026-10-17
  • 170tune's "HOT pass" cannot complete on water-cooled cards whose HBM stays at 45-50 C. Reported
    Source: @rh3dai, 2026-10-07
  • An NVML offset write can return success while the driver drops it; only a readback proves the offset applied.
    Source: repo github.com/vektorprime/170tune by vektorprime on GitHub, posted by @rh3dai, 2026-10-04
  • To undo a 170tune profile that breaks boot: 170tune persist disable or systemctl mask 170tune-persist.service. Its bootcheck service reverts to stock by itself if the previous boot's apply never checked in.
    Source: repo github.com/cachenetics/170tune by cachenetics on GitHub, posted by @rh3dai, 2026-10-04

P2P does not work

  • Check what the driver reports with nvidia-smi topo -p2p r: GNS means the P2P override was not applied. Then prove bytes arrive with a content check; nvidia-smi topo alone is not proof. On one card a peer copy reported success while 33,423,360 of 33,554,432 bytes came back wrong.
    Source: repo github.com/asm64-hooligan/cmpunlocker by asm64-hooligan on GitHub, posted by @rh3dai, 2026-10-04
    Source: repo github.com/Morrowmake/cmpunlocker by Morrowmake on GitHub, posted by @trustinter, 2026-10-07
  • GNS on any topology: the override is applied too early. A member read the P2P steps in a 2-card guide as only helping cross-root hosts; its author answered that topology is not the blocker. On his box the cmpunlocker 0011 patch set the P2P override before the PCI device ID was populated, so it never took effect and the driver fell back to GSP capabilities, which report GNS for CMP cards on any topology. If nvidia-smi topo -p2p r shows GNS, the ForceP2P=0x11 registry key from the guide should apply to a single switch too (untested there). With P2P working, TP2 on two cards prefilled about 4,900 tok/s at 128k context (TTFT 26 s) against about 2,500 tok/s without it. Full guide: 2x CMP 170HX for LLM inference by ropuls (gist). Reported
    Source: @mountains1605, 2026-10-15
    Source: @cibernox, 2026-10-16
    Source: @ropuls, 2026-10-16
  • The P2P registry string (NVreg_RegistryDwords="RmForceEnableGen2=1;RMPcieLinkSpeed=0x1;RMForceStaticBar1=1;RMPcieP2PType=1;RMForceP2PType=1;ForceP2P=0x11") is global: it applies to every NVIDIA GPU in the host. On a host that also runs an RTX 4080 Super it would force that card to Gen2 too. Reported
    Source: @68x0, 2026-10-13
    Source: @ybryany, 2026-10-14
  • Mailbox P2P behind a PLX switch crashes tensor-parallel inference with Xid 13. Reported
    Source: @ob88594, 2026-10-07
  • Across PCIe root complexes on a Threadripper board (3x 8 GB, an older fork), everything looked configured but no P2P traffic arrived. Suggested fix: build current cmpunlocker and write a local P2P patch for that topology. On another 3-card Threadripper host, pairs on different root buses created BAR1 mappings but DMA hung, so NCCL_P2P_DISABLE=1 and --disable-custom-all-reduce are required there. Reported
    Source: repo github.com/clee/qwen3.8-flash-next-3x170hx by clee on GitHub, posted by @c133, 2026-10-04
    Source: @c133, 2026-10-22
    Source: @djpandaman, 2026-10-22
  • Across CPU sockets. On an 8-card dual-EPYC box, Morrowmake cmpunlocker with --p2p on 615.71.09 gave P2P on every pair including cross-socket pairs: cuDeviceCanAccessPeer 1 everywhere, nvidia-smi topo -p2p r OK, content check 504 of 504, 0 Xids, again after later cold cycles. Earlier posts had said P2P does not work across sockets, or only with the PLX switch attached to both CPUs; those were not measurements. Proven
    Source: @wakeupmbrc1, 2026-10-18
    Source: @endsjeremy, 2026-10-18
    Source: @darkmaniac7, 2026-10-27 (lab notes)
  • Warning ACS redirect. BAR1 P2P across root ports with ACS redirect enabled lost 100% of a 256 MiB device-to-device copy with no error. Turn ACS redirect off; see BIOS and kernel settings.
    Source: @darkmaniac7, 2026-10-19 (lab notes)
    Source: repo github.com/lesj0610/cmpunlocker by lesj0610 on GitHub
  • ForceP2P=0x11 Contested
    • With the registry string above, one member got higher decode and prefill; mailbox setups with the trap armed run byte-exact with ForceP2P=0x11 (or 17).
      Source: @68x0, 2026-10-13
      Source: @darkmaniac7, 2026-10-19 (lab notes)
      Source: repo github.com/bayley/cmpunlocker by bayley on GitHub
      Source: repo github.com/cebeuq/glm53-cmp170hx-recipe by cebeuq on GitHub
    • ForceP2P=0x11 hangs machines, according to bayley's README and another fork's notes.
      Source: @darkmaniac7, 2026-10-19 (lab notes)
      Source: repo github.com/bayley/cmpunlocker by bayley on GitHub
  • Warning On a 610.43.02 GSP, putting RMForceStaticBar1 / RMPcieP2PType into NVreg_RegistryDwords was rejected (NV_ERR_INVALID_REGISTRY_KEY), the GSP's protected memory region stayed up, and only a cold power-off recovered. Put these keys where your fork's instructions say.
    Source: @darkmaniac7, 2026-10-19 (lab notes)
    Source: repo github.com/LingzheZhao/cmpunlocker by LingzheZhao on GitHub
  • NVIDIA's UVM managed-memory test across CMP cards gave Xid 31 then Xid 154 on every GPU; a cold power cycle recovered. Reported
    Source: @darkmaniac7, 2026-10-19 (lab notes)
  • Latency as a P2P check Contested
    • About 14 microseconds per transfer means NCCL picked another, non-P2P path; expect about 1.7 microseconds over a CPU root and 1.4 through a switch.
      Source: @markshowa, 2026-10-17
    • 14 microseconds is fine; the hardware call itself takes 1.5.
      Source: @wakeupmbrc1, 2026-10-17
  • When P2P is forced on a topology that cannot route it (ACS, no IOMMU passthrough, separate root complexes), transfers time out instead of falling back to system memory. A start-up hang at 100% GPU with low power is an all-reduce waiting on broken P2P: try with P2P off.
    Source: repo github.com/asm64-hooligan/cmpunlocker by asm64-hooligan on GitHub, posted by @rh3dai, 2026-10-04
    Source: repo github.com/GNmac-lab/deepseek-v41-flash-1017-cmp170hx by GNmac-lab on GitHub, posted by @greencandle9753, 2026-10-21
  • BAR1 stuck at 64 MB: see Card not detected or BAR allocation fails.

RIR tool and fuse work (10 GB cards)

  • Prerequisites. 170hx-rir-tool needs root, the card unbound from the nvidia driver, iomem=relaxed, and the cmpunlocker-patched driver or a 610+ driver to power the card on. Without the driver it fails with "debugctrl rwl bit cannot be latched" and "fuse controller access is possibly blocked". The author added the driver requirement to the README on 2026-10-20. Proven
    Source: @lycorascence, 2026-10-20
    Source: @lxtend, 2026-10-20
  • Unbinding the card. rmmod takes the whole system down when other NVIDIA cards drive the display and there is no iGPU; unbind only that GPU through its sysfs path instead. Wayland and Xorg grab the headless CMP and block the unbind; excluding it broke the KDE login, and on the LTS kernel unbind and rebind hard-crashed sddm. Disable the desktop and SSH in from another machine. The owner also considered blacklisting the nvidia module; he tried a live disk and booting with and without the NVIDIA driver, and the RIR tool still could not latch the DEBUGCTRL RWL bit until he moved to the LTS kernel (see below). Reported
    Source: @lycorascence, 2026-10-17
    Source: @c133, 2026-10-18
    Source: @lycorascence, 2026-10-20
    Source: @lycorascence, 2026-10-20
    Source: @intervitens, 2026-10-23
  • Read before you write: the tool reports how many RIR slots are used and free. It refuses a row whose existing slots are non-zero and different from the request, saves before and after backups, and asks for two confirmations.
    Source: repo github.com/lixiangwuxian/170hx-rir-tool by lixiangwuxian on GitHub, posted by @lxtend, 2026-10-10
    Source: @lxtend, 2026-10-17
    Source: @programmerboi, 2026-10-25
  • Warning Wrong record encoding. Writing 0x15011401 to RIR row 0 (a "scrambled" packing guess) changed nothing except using up an RIR row. The record pair that clears the override fuse under the linear layout is 0x00150095.
    Source: @lxtend, 2026-10-10
    Source: repo github.com/lixiangwuxian/170hx-rir-tool by lixiangwuxian on GitHub, posted by @lxtend, 2026-10-10
  • Even the RIR tool's dump commands (--dump-rir, --dump-fuses) drive the fuse controller (they change no fuses); only --status is pure register reads. Its volatile --sw-write commands abort unless the disable-software-override gate has first been cleared by an RIR burn; that gate is set on every GA100 probed, including both 170HX variants.
    Source: repo github.com/lixiangwuxian/170hx-rir-tool by lixiangwuxian on GitHub, posted by @lxtend, 2026-10-10
    Source: @darkmaniac7, 2026-10-18 (lab notes)
  • The 170hx_sweep harness circulated on Discord is built for the 10 GB card: it refuses the 8 GB device ID without --force and aborts at its gate check on 8 GB cards by design. Reported
    Source: @darkmaniac7, 2026-10-22 (lab notes)
  • The rir-burn-util refuses 8 GB cards, needs two cold boots (after the burn and after installing the Gen3 driver), and its rollback restores modules and config but never the burn.
    Source: repo github.com/evanrodgers/cmp-170hx-rir-burn-util by evanrodgers on GitHub, posted by @hezz1891, 2026-10-26
  • Warning Software Gen3 attempts on 8 GB cards. Retraining at 8 GT/s while the Gen3 disable fuse is set drops the card off the bus (shown in cmpunlocker commit 80966db). In a related register sweep, an XVE_FUSE_OVERRIDE value of 0xA eventually wedged the device under VFIO while 0x6 stayed stable, and a dead LNKSTA read of 0xffff can make a script log an off-bus card as trained. In a one-card lab test, the XP/XVE register route plus a patched LnkCap left the card stuck at Gen1 x8 until a VM power cycle (no Xid, memory test still passed); do not request Gen3 on a 20c2 card. Upstream PR #37's Gen3 retrain took a card off the bus (BAR0 all ones), PCI remove/rescan did not bring it back and the rescan itself hung; recovery needed a chassis power cycle, and the PR was closed unmerged on 2026-10-14.
    Source: @ropuls, 2026-10-08
    Source: @djpandaman, 2026-10-09
    Source: @darkmaniac7, 2026-10-14 (lab notes)
    Source: @darkmaniac7, 2026-10-21 (lab notes, darkmaniac7/cmp170hx-esxi)
    Source: repo github.com/amoghmunikote/cmpunlocker by amoghmunikote on GitHub

Operations that cannot be undone

RIR burns are permanent

Warning RIR physically changes the silicon and permanently locks a few bits. There are 16 RIR slots, usually written two at a time. Burns have been consistent and relatively safe so far, but some rewrites completely brick the card, and a wrong burn wastes 2-4 slots. Fuse bits only go from 0 to 1; there is no undo.

Source: @djpandaman, 2026-10-10
Source: repo github.com/lixiangwuxian/170hx-rir-tool by lixiangwuxian on GitHub, posted by @lxtend, 2026-10-10

A wrong address can brick the card

Warning RIR programming is not trial and error: "if you target the wrong address there's a good chance of bricking".

Source: @djpandaman, 2026-10-06

8 GB cards have no free RIR

Warning 15 of the 16 slots are used and the 16th is semi-burned; every RIR tool is for the 10 GB card. Do not burn anything on an 8 GB card. Read-only RIR dumps of two 8 GB cards are evidence for discussion, not a basis to burn.

Source: @matstatman, 2026-10-09
Source: @mountains1605, 2026-10-10
Source: @marklintonca, 2026-10-10
Source: @djpandaman, 2026-10-17
Source: @cmdrwaka324, 2026-10-19

Do not spend RIR slots yet

Warning A software-only recipe with volatile SW IFF was shared; use it and keep your slots. Only one fuse needs an RIR burn (the disable-software-override fuse); everything else can be done with SW IFF, which resets on reboot, so "just dont flash any actual FF/IFF". Expect used 10 GB cards with wasted RIR slots; dump the fuses before you buy one.

Source: @scallion_9883, 2026-10-16
Source: @dottoreargus, 2026-10-20
Source: @armand0e, 2026-10-26

Bricked cards during 10 GB development (hearsay)

Warning A post relayed from the Chinese community says the 10 GB unlock was developed on 20 merchant-donated cards and 5 were bricked, perhaps by enabling defective blocks or stacks. Another developer doubts a cold reset would not recover them: errors from enabling the 6th HBM stack always cleared on a cold boot, but doing unlocks one by one through RIR can get you into trouble. How those cards were bricked was asked and not answered, including whether the A01Q revision of the 8 GB card is the one that bricks.

Source: @wakeupmbrc1, 2026-10-09
Source: @djpandaman, 2026-10-09
Source: @dottoreargus, 2026-10-10
Source: @n2dcrypt, 2026-10-11

VBIOS writes

Warning A member recalled a post where a VBIOS TOCTOU test caused permanent damage that restoring the original BIOS did not fix (hearsay). Avoid any "unlock" that burns fuses. The VBIOS restriction bytes sit inside the signed range: a one-byte change there stalls the Booter and the card will not boot the edited image. The 250 W to 300 W power-limit bytes are in the unsigned tail, but nvflash refuses even those edits. A same-model signed 300 W ROM flashes fine; a cross-flashed A100 ROM bricks the card or does nothing. Recovery from a bad flash is physical only, with an SPI clip on the flash chip.

Source: @darkmaniac7, 2026-07-28 (lab notes)
Source: @youngju10000, 2026-10-08
Source: @rrickk420, 2026-10-09
Source: repo github.com/Consensus-Protocol/cmp170hx by Consensus-Protocol on GitHub, posted by @rrickk420, 2026-10-09
Source: @darkmaniac7, 2026-10-25 (lab notes)

"CMP-170HX-64GB-Unlocked-VBIOS" repos are bogus

Warning The repos under that name (344303947, mirrored by justin-kk-coder) were compared to the original VBIOS in August and there was no difference; the author has since closed the repo's issues. The unlock makes no VBIOS change at all. Do not flash anything from them. A flashed ROM that fails its signature check or mis-sizes the memory can leave the card unbootable.

Source: repo github.com/344303947/CMP-170HX-64GB-Unlocked-VBIOS by 344303947 on GitHub, posted by @supasnipa360, 2026-10-18
Source: @c133, 2026-10-18
Source: @xanthefin, 2026-10-18

What the plain unlock changes

Contested

  • cmpunlocker writes volatile registers only: no fuses, no VBIOS, no EEPROM; a power cycle returns the card to stock. A snapshot of the Consensus-Protocol notes (2026-08-22) found no confirmed permanent brick from it, with one unexplained report of a 10 GB card that booted already wedged after a full power-off.
    Source: repo github.com/Consensus-Protocol/cmp170hx by Consensus-Protocol on GitHub, posted by @rrickk420, 2026-10-09
  • The 8 GB unlock writes nothing persistent to the card; only the special 10 GB unlocking writes hardware.
    Source: @ob88594, 2026-10-12
  • Not convinced yet: one member will not apply anything beyond the basic unlock until permanent effects are ruled out.
    Source: @segmond, 2026-10-25

Performance changed after an update

After reinstalling Ubuntu with cmpunlocker v0.5, decode on Qwen 3.8 27B fell to 35 tok/s from 60-80 tok/s on v0.4. dmesg showed no ECC errors; the "no ECC support" line in that dmesg comes from the host's ie31200 EDAC driver, not the GPU. A second member asked whether anyone else saw decode drop after the ECC unlock. Unresolved. Reported
Source: @mowgli8628, 2026-10-18
Source: @matstatman, 2026-10-18
Source: @feralzi, 2026-10-19

Rolling back

Related pages

Imported from the cmpunlocker Discord with credit; see Credits.
Retrieved from "https://cmp.wiki/w/index.php?title=Driver_and_unlock_failures&oldid=450"