Verifying an unlock

An install that reports success can still leave the stock driver running. After every install, kernel change or driver change, check three things in this order: the patched module is the one loaded, the unlock fired, and BAR1 was resized. Then confirm the link, the memory and the compute. Install steps are on Driver unlock, fixes are on Driver and unlock failures, and the full procedure for a newly bought card is on Acceptance checklist.

Quick check after a cold boot (details and sources in the sections below):

cat /proc/driver/nvidia/version                           # must not say dvs-builder
nvidia-smi --query-gpu=index,memory.total --format=csv    # 65536 MiB (8 GB card) or 40960 MiB (10 GB card)
sudo dmesg | grep SEC2_DEBUG                              # lines present: the unlock fired
sudo dmesg | grep "NVRM: CMP BAR1"                        # final size = 65536 MB: BAR1 resized

The patched module is the one running

Three checks when the install finished but nothing changed

Dodo ran ten CMP 170HX cards on HiveOS beta 24.04 with NVIDIA 610.43.03. install.sh finished without errors, but after a cold reboot the patched module was not loaded (2026-07-20). Amogh's three checks for that case:

The patched module exists under /lib/modules/$(uname -r)/updates/cmpunlocker/ and its driver_version, card_profile and unlock_geometry can be read. If it is missing, it was built for a different kernel than the one that booted.
The running nvidia.ko is the patched one. Compare modinfo and srcversion: the running srcversion must equal the srcversion of the cmpunlocker .ko, otherwise the stock module is still running.
The unlock fired: nvidia-smi memory.total (about 40960 MiB on a 10 GB card) and SEC2_DEBUG lines in dmesg | grep SEC2_DEBUG.

Ikyo (2026-09-09) added that "the unlock works" has been said of compute-only unlocks with a stock BAR1 too. Confirm that nvidia-smi reports the full 64 GB memory.total, record which cmpunlocker fork, version and flags you used (for example --no-gen2), and treat the driver line "NVRM: CMP BAR1: final size = ..." as the one unambiguous evidence of the BAR1 resize (see the next section).

Proven 8 GB and 10 GB
Source: @dodo03853, 2026-07-20
Source: @_j3ns, 2026-07-20
Source: @ikyo, 2026-09-09

"Loaded nvidia srcversion != patched": power off fully, then read dmesg

K2V got the installer warning "Loaded nvidia srcversion != patched" on his own PC, and the loaded module switched to the patched one after a cold reboot (2026-07-20). The action that matters is a full power-off, not a warm reboot. Pasteyy. (2026-07-23, Dell R740, open driver 610.43.02 installed with apt, profile 10gb) got the same warning plus "Modules installed but the running driver is still stock (or unload failed)". The installer's own instructions:

Cold reboot: shutdown -h now, then power on.
Confirm /proc/driver/nvidia/version does not say dvs-builder.
Check sudo dmesg | grep SEC2_DEBUG.

After the reboot Pasteyy.'s card still showed 10 GB instead of 40 GB. K2V advised reading dmesg first to see whether the registers were written, noting that many people succeeded without a reboot. The "Skipping BTF generation ... due to unavailability of vmlinux" lines in the build log are harmless. No resolution was posted; if a cold power-off does not help, check the depmod and DKMS precedence (next entry).

Reported 8 GB and 10 GB
Source: @k2v0008, 2026-07-20
Source: @lxtend, 2026-07-20
Source: @pasteyy., 2026-07-23
Source: @k2v0008, 2026-07-23

The stock module loads instead of the patched one: depmod and DKMS

The installer can build and install the patched modules while the kernel still loads the stock ones. ocminer (2026-07-19) found the stock and the cmpunlocker modules both under the single "updates" depmod search entry, so depmod kept one and silently dropped the other; preferring the cmpunlocker module and rebooting fixed it. Zombie (2026-07-29, nvidia-driver-610.43.02-open, Secure Boot off, two new cards) saw the modules reported as installed while the Gen2 verify script printed "still stock", "No SEC2_DEBUG in dmesg" and "failed unlock verification"; the installer had not created a depmod override file, and making one by hand fixed it. bayley_w (2026-08-01, 8 GB card, 250 W VBIOS, Ubuntu 26.04) had nothing in dmesg and 8192 MiB after a reboot (Danske suggested a cold boot or a clean driver reinstall, Amogh asked for the driver version) and traced it to how depmod loads modules on 26.04. meatsus (2026-08-02) posted the fix that worked for several users. Run it one command at a time, with the exact installed driver version in the first:

sudo dkms remove nvidia/610.43.03 --all
sudo depmod -a
sudo update-initramfs -u

His explanation: depmod resolves alphabetically, so some machines pick the DKMS copy and others the cmpunlocker directory, and the fix is to have no DKMS NVIDIA kernel modules at all. He said the steps would go into install.sh and to use them at your own risk. quark2world had the same symptom, and Aeiou confirmed that removing the DKMS module made the modules load from cmpunlocker on Ubuntu 26.04.

Proven 8 GB and 10 GB
Source: @_j3ns, 2026-07-19
Source: @.ocminer, 2026-07-19
Source: @zombielurker, 2026-07-29
Source: @bayley_w, 2026-08-01
Source: @danske1, 2026-08-01
Source: @_j3ns, 2026-08-01
Source: @quark2world, 2026-08-02
Source: @meatsus, 2026-08-02
Source: @91d5a66bffc978331fac75b68fa86aba, 2026-08-03

The unlock fired

memory.total and SEC2_DEBUG lines

With the unlock in place, nvidia-smi shows the full 65536 MiB on an 8 GB card or 40960 MiB on a 10 GB card; without it the card falls back to the stock 8192 or 10240 MiB. cuddylac997 (2026-09-30, in an LLM-generated post he partly corrected later in the same exchange) tied this to the privilege masks (PLMs) reading 0xffffffff, which shows up as SEC2_DEBUG lines in sudo dmesg | grep SEC2_DEBUG. No SEC2_DEBUG output at all is what the stock-module cases above showed. The same report gives FUSE_FBPA_DISABLE = 0x00c03000 (20 active FBPAs) as the validated fuse baseline of his 10 GB cards; see Which card do I have.

Reported 8 GB and 10 GB
Source: @cuddylac997, 2026-09-30

The installer's summary table and logs/ folder

A successful cmpunlocker run ends with a summary chart with check marks, and the output is also saved under logs/ in the unlocker directory (ju5t5omedude, Amogh, 2026-07-30). The expected memory after a good 8 GB unlock is 65,536 MiB. For a failed run, Amogh asked users to open a support ticket on the Discord and send him the details rather than troubleshoot in #general.

Reported
Source: @ju5t5omedude, 2026-07-30
Source: @_j3ns, 2026-07-30

verify.sh and its pass thresholds

The mainline repository's sequence is sudo ./install.sh --profile=8gb (or --profile=10gb), a cold reboot, sudo ./verify.sh, then sudo dmesg | grep SEC2_DEBUG. verify.sh counts 60000 MiB or more as unlocked on the 8gb profile, and 35000-59999 MiB on the 10gb profile. The install log is logs/install_<timestamp>.log. Always pass --profile on a host with other NVIDIA GPUs: auto-detection reads the first GPU in nvidia-smi order, and an RTX 3080 10 GB caused a wrong 10gb profile twice. The installer removes the nvidia DKMS modules, so re-run it after every kernel upgrade.

Proven 8 GB and 10 GB
Source: repo github.com/amoghmunikote/cmpunlocker by amoghmunikote on GitHub
Source: repo github.com/Consensus-Protocol/cmp170hx by Consensus-Protocol on GitHub
Source: @darkmaniac7, 2026-10-05 (lab notes)

Reading CFG1 and LMR from the card

The install log names the memory geometry it set, for example "Unlock geometry: 40GB per card" on a 10 GB card, followed by the CFG1 and LMR values (arabus, 2026-09-10). To check those registers on the card itself, insomniac (2026-09-03) had tony read BAR0 (the device's resource0 file in sysfs) at offset 0x009A0204 (CFG1) and 0x00100CE0 (LMR), first with sudo od -An -N4 -j <offset> -tx4 .../resource0 and then with a Python pread script. On tony's card both od reads returned "Input/output error", and the card went back to the seller before the Python variant ran. No successful read with this method was posted in that thread, so memory.total and the dmesg lines remain the check.

Reported
Source: @ins_mniac, 2026-09-03
Source: @tony_smartecom, 2026-09-03
Source: @arabus_74064, 2026-09-10

The BAR1 resize: "NVRM: CMP BAR1: final size"

A card can show the full memory and the compute unlock with a stock BAR1, and "the unlock works" was said of both. Ikyo (2026-09-09) named the driver line "NVRM: CMP BAR1: final size = ..." as the one unambiguous evidence of the BAR1 resize. On the lab's 8 GB cards a good resize logs "resize enabled, will attempt up to 64 GB" and then "final size = 65536 MB", and nvidia-smi shows BAR1 Total 65536 MiB:

sudo dmesg | grep "NVRM: CMP BAR1"
nvidia-smi -q | grep -A 3 "BAR1 Memory Usage"

Without the 64 GB BAR1 the 64 GB of VRAM and the compute unlock still work. What is lost is BAR1 P2P: engines fall back to copies through host memory, a speed loss for tensor parallel, not a failure. If BAR1 stays small, see the case notes below and Resizable BAR and BAR1 64 GB.

Proven 8 GB and 10 GB
Source: @ikyo, 2026-09-09
Source: @darkmaniac7, 2026-10-29 (lab notes)

The link

Read the trained link under load: LnkSta or a bandwidth test

Landmark's unlocked cards reported PCIe 1.0 x4 (2026-07-22). chris.via.egnatia: the stock link is 1.0 x4, the capacitor mod raises the width to x16, and the generation stayed Gen1 until the driver Gen2 work landed; giaki3003 argued that for single-card inference this mostly affects load time. How to read the link correctly:

After a retrain, dmesg shows whether the link actually attempts 5 GT/s and falls back to 1.0, or only advertises it (Samuel Hayden).
Read it under load or with ASPM disabled: many cards drop the link to Gen1 at idle (NFA). Amogh's eGPU dock does not support ASPM. In a VM, reboot the host rather than only the guest after installing (Thanos).
NVML and nvidia-smi may still report Gen1 on the 10 GB card. Verify with LnkSta 0x1042, sysfs current_link_speed 5.0 GT/s, or a bandwidth test (Huzifei, 2026-07-28).
Danske (2026-07-29) saw LnkCap 2.5GT/s x16 but LnkSta 5GT/s (overdriven) x4, while ju5t5omedude's pcielink.sh reported "not Gen2". A bandwidth test settled it: Host to Device 1.7 GB/s, Device to Host 1.7 GB/s and Device to Device about 1400 GB/s (the on-card HBM). That is Gen2 x4; Gen1 x4 measures about 0.82 GB/s. Danske's pcie_bandwidth_check.sh clones NVIDIA cuda-samples and builds bandwidthTest on first run (needs nvidia-smi, nvcc, git, cmake and make); he asked people to read the script before running it.
nvtop and Mission Center were considered unreliable for the link generation.

Proven 8 GB and 10 GB
Source: @landmark0700_17532, 2026-07-22
Source: @giaki3003, 2026-07-22
Source: @chris.via.egnatia, 2026-07-22
Source: @samuel_hayden., 2026-07-23
Source: @never_fly_away, 2026-07-23
Source: @_j3ns, 2026-07-23
Source: @thanos8912, 2026-07-24
Source: @huzifei, 2026-07-28
Source: @danske1, 2026-07-29
Source: @ju5t5omedude, 2026-07-29
Source: @danske1, 2026-07-29

lspci: LnkCap is what the card offers, LnkSta is the trained link

Merom Green checked his link after the Gen2 unlock (2026-07-27):

lspci -d 10de:20c2 -vv | grep -E 'LnkCap:|LnkSta:'

His card: LnkCap Port #0, Speed 5GT/s, Width x16, ASPM not supported; LnkSta Speed 5GT/s, Width x4 (downgraded). 5GT/s is PCIe Gen2. "Width x4 (downgraded)" on a stock card means the capacitor mod is not fitted; see PCIe x16 capacitor mod. On a 10 GB card the device id is 10de:2082.

Reported 8 GB
Source: @meromgreen, 2026-07-27

nvidia-smi: one query for link, power brake, power and memory

xanthe_ (2026-08-29) checks the Gen2 result with one query that also shows the power-brake flag, power, temperatures and memory:

nvidia-smi --query-gpu=gpu_name,pcie.link.gen.gpucurrent,pcie.link.gen.current,pcie.link.gen.max,pcie.link.width.current,clocks_event_reasons.hw_power_brake_slowdown,utilization.gpu,power.draw,power.limit,temperature.gpu,temperature.memory,memory.used,memory.total --format=csv

With the Gen2 patch installed but its service not started, his cards read gen 1, 1 with max 2 (x4); with the service started they read 2, 2, 2. If pcie.link.gen.max also reads 1, the Gen2 patch was probably never attempted. He runs sysvinit, not systemd, and adapted the service for it. How each build triggers the retrain is on Gen2 link retrain.

Reported 8 GB
Source: @xanthefin, 2026-08-29
Source: @gleb.shnshn, 2026-08-29

The memory is real

On a stock card memtest covers only the visible 8 GB

datacat asked whether memtest_vulkan runs on cards that are not unlocked. Arcanum explained that memtest sizes its test from the reported capacity, so a stock card does not show errors just for being at 8 GB, and robbbbbb7973 confirmed he tested a stock card and it passed (2026-08-28). Errors in a stock 8 GB test therefore point to real HBM defects, but a pass covers only the visible 8 GB. The same reading applies to a seller's video: Bagster and xanthe_ saw nvidia-smi showing 8G in one, so the card in it had not been unlocked (2026-08-27).

Reported 8 GB
Source: @xanthefin, 2026-08-27
Source: @bagstah, 2026-08-27
Source: @_datacat_, 2026-08-28
Source: @robbbbbb7973, 2026-08-28
Source: @_arcanum_, 2026-08-28

memtest_vulkan: the 5-minute test, then the extended test

memtest_vulkan (GpuZelenograd, zlib licence, v0.6.0) is a Vulkan-compute video memory tester for Linux and Windows that needs a driver with Vulkan 1.1. It runs a standard 5-minute test ("Standard 5-minute test PASSed!") and then, if left alone, an endless extended test with bit-level error statistics (Merom Green). A numeric first argument picks the device and skips the prompt: ./memtest_vulkan 2 tests the second card (Friendsxxii, confirmed by RedPandaMining); with no arguments it shows a device menu and auto-selects after 10 seconds. It leaves 400 MiB untested and otherwise allocates nearly all VRAM (63 GB in nvtop on a 64 GB card); ju5t5omedude found option 1 errored out on his setup. On Linux with several Vulkan drivers, force the NVIDIA one and run it from a terminal:

VK_DRIVER_FILES=/usr/share/vulkan/icd.d/nvidia_icd.json ./memtest_vulkan

Expect the HBM to run hotter than in LLM serving (85-90 C reported with weak cooling). Errors marked "Mode NEXT_RE_READ" mean bits flipped while stored. CUTE: a good card should show no errors even without ECC. A pass is not proof: members report cards that pass it but fail cuda_memtest, gpu-burn -tc or real LLM loads, and the reverse. DaLZy advised buyers to ask the seller to run it with the full 64 GB unlocked before buying.

Proven 8 GB and 10 GB
Source: repo github.com/GpuZelenograd/memtest_vulkan by GpuZelenograd on GitHub, posted by @cute_sc2, 2026-08-09
Source: @dalzyyy, 2026-08-10
Source: @friendsxxii, 2026-08-11
Source: @redpandamining, 2026-08-11
Source: @cute_sc2, 2026-08-11
Source: @ju5t5omedude, 2026-08-12
Source: @bagstah, 2026-08-12
Source: @meromgreen, 2026-08-12

cuda_memtest: structured patterns, and the cap on builds without the late-PMA fix

cuda_memtest (the ComputationalRadiationPhysics fork of the old NCSA/UIUC tester, NCSA licence) became a standard check for unlocked HBM after Amogh said on 2026-07-19 that he used it to test the VRAM. Build it for GA100 (the README example uses 35) and run one terminal per card:

mkdir build && cd build && cmake -DCMAKE_CUDA_ARCHITECTURES=80 .. && make
./cuda_memtest --device 0 --num_passes 1 2>&1

bassRAWR (2026-08-26) recommends running it as well as memtest_vulkan: its structured patterns (walking bits, own address, moving inversions, random sequences, block moves) target specific fault geometries, while memtest_vulkan runs one continuous pattern for hours. Phoenix17 ran it for over two hours on his 8 GB cards with no errors. Far's first run, on an early profile of a 10 GB card, found 1 error within 20 minutes and then ran only when allocating 39 GB or less. Caveat: on builds without the late-PMA fix, testing 100% of an unlocked 64 GB card can report errors in the last few hundred MB (gym, 2026-08-10: consistent across all his cards and absent in memtest_vulkan); capping at about 63.75 GB worked. That is a framebuffer-tail issue, not proof of bad HBM: cap with --max_num_blocks (1 MiB blocks) when in doubt, and see Xid 31 and the reserved top of VRAM.

Proven 8 GB and 10 GB
Source: repo github.com/ComputationalRadiationPhysics/cuda_memtest by ComputationalRadiationPhysics on GitHub, posted by @_j3ns, 2026-07-19
Source: @farawaythrower, 2026-07-19
Source: @jimtjames, 2026-08-10
Source: @bassrawr, 2026-08-26
Source: @phoenixone7, 2026-08-26

10 GB card: 40960 MiB reported, about 37-38 GiB usable

nvidia-smi shows 40960 MiB on an unlocked 10 GB card, but not all of it is usable. cuddylac997 counted about 37.7 GiB usable per card (160 GB pooled over four cards, 2026-08-11) and said a model that goes over the cap of about 37 GB crashes one card and needs a restart (2026-08-13). Size test allocations and models to the usable figure, not to memory.total. More on Memory unlock on the 10 GB card.

Reported 10 GB
Source: @cuddylac997, 2026-08-11
Source: @cuddylac997, 2026-08-13

The compute is real

Before and after on one card: FP32 414 to 13,173 GFLOPS

Kai measured the compute unlock on an 8 GB card with amoghmunikote/cmpunlocker (2026-08-13): FP32 rose from 414 GFLOPS locked to 13,173 GFLOPS unlocked. The memory unlock reached 64 GB nominal (63.5 GB usable) and passed a write and read-back test with 0 errors.

Reported 8 GB
Source: @honest_swan_40057, 2026-08-13

mixbench for a quick reading, and what a build that did not take looks like

On 2026-06-24, while the first compute-unlock builds were being tested, MrLoki89 asked how to measure the patches, since clpeak did not seem the right tool; atsasin answered "I use mixbench cuda/cuda bench". The same day Mr Pec reported a build that did not seem to work on his system: it still showed FP32 0.32 TFLOPS and FP16 5.13 TFLOPS (tool not stated), the locked range.

Reported 8 GB and 10 GB
Source: @serplay228, 2026-06-24
Source: @atsasin2126, 2026-06-24
Source: @mrpec, 2026-06-24

nvidia-bench: one file that also reports BAR1, link and memory

asm64, author of the asm64-hooligan cmpunlocker fork, posted nvidia-bench on 2026-07-28: a single CUDA file (AGPL-3.0 in the LICENSE file, GPLv3 on the README badge) that measures memory latency and bandwidth, PCIe H2D/D2H, CUDA-core and tensor-core throughput, and reports BAR1 size, link generation and width, copy engines, MIG, ECC and the video engines. Linux only, CUDA 11.0 or newer, needs NVML; a run takes about 17 s on one GPU, and --csv prints one header and one data line for scripted sweeps:

nvcc -O3 -gencode arch=compute_80,code=sm_80 -o nvidia_bench nvidia_bench.cu -lnvidia-ml -ldl
./nvidia_bench 0

The README example is an 8 GB card unlocked to 64 GiB with an HBM overclock (memory clock 1971 MHz under load, 1728 MHz rated): 70 SMs, read 1903.46 GB/s, FP32 15.11 TFLOPS, TF32 tensor 112.94, BF16 tensor 228.54, INT8 tensor 465.73 TOPS, PCIe Gen1 x4 at 0.81-0.84 GB/s pinned and BAR1 64 MiB. That is a July 2026 unlock state; later unlocks report 74 SMs, Gen2 and a 64 GB BAR1, so do not quote it as current limits. Studebaker praised the clean output, Pasteyy. said "If you can do core freq + offset, you're better than an A100", and asm64 found a clock offset of 250-300 via NVML stable on his cards.

Reported 8 GB and 10 GB
Source: repo github.com/asm64-hooligan/nvidia-bench by asm64-hooligan on GitHub, posted by @leesle., 2026-07-28
Source: @_studebaker_, 2026-07-28
Source: @leesle., 2026-07-30
Source: @pasteyy., 2026-07-30

Tensor throughput: mmapeak, a GEMM benchmark and what to expect

mmapeak loops tensor-core mma_sync instructions and prints peak dense throughput per data type. Build with mkdir build && cd build && cmake .. && make (CUDA 12.8 or newer) and run ./mmapeak (3 s per kernel by default; -t sets the seconds). On the 170HX only the INT4, INT8, FP16, BF16 and TF32 rows run; FP8, FP6 and FP4 print "not supported". Its numbers sit above real GEMM TFLOPS because it measures issue rate. turbine first posted it (2026-09-21) to compare FP16 accumulate against FP32 accumulate: xtj7's RTX 3090 gave 104.2 against 52.1 TFLOPS, "whereas with the 170hx this stays almost flat". A seller's video sent to OW3 (2026-10-11) showed gpu-burn -tc at about 83,000-84,600 GFLOP/s on a 64 GB card; gym said 83 TFLOPS is close to the expected TF32 tensor throughput, and 150-200 TFLOPS is what BF16/FP16 gives. For a real GEMM figure use zzc0721/torch-performance-test-data; its leaderboard row labelled "NVIDIA Graphics Device(CMP170HX)" (bendy2) reads FP32 12.15, TF32 77.09, FP16 166.48 and BF16 177.91 TFLOPS. More on mmapeak and Benchmarks.

Reported 8 GB and 10 GB
Source: repo github.com/ReinForce-II/mmapeak by ReinForce-II on GitHub, posted by @turbine, 2026-09-21
Source: @xtj7, 2026-09-21
Source: @golden_panda_97088_61593, 2026-10-11
Source: @golden_panda_97088_61593, 2026-10-11
Source: repo github.com/zzc0721/torch-performance-test-data by zzc0721 on GitHub, posted by @jimtjames, 2026-10-11

Pointer: a longer set of authenticity checks by @akuchen_66498 for a claimed SM unlock (SM count, read-only fuse register reads and a GEMM TFLOPS range) exists; see Discord. The expected values wait for the author. Source: @akuchen_66498, 2026-08-12

Case notes

Gen2 but BAR1 stuck at 64 MB or 256 MB

From lab notes, one change per reboot:

No "resize enabled" line in dmesg: check NVreg_EnableResizableBar, and set options nvidia NVreg_EnableResizableBar=1 if it reads 0.
A "final size" below 65536, or kernel "no space for" / "failed to assign" lines near BAR 1: the bridge window cannot take 64 GB. Work in this order: BIOS "Memory Mapped I/O above 4GB" Enabled; give the 64-bit MMIO space the most room (on PowerEdge, "Memory Mapped I/O Base"; a higher base usually leaves more room); add pci=realloc to the kernel line (remove it if NICs or storage break); isolate to one card (two cards behind one bridge need two 64 GB-aligned blocks of 64 GB + 32 MB in one window).
A BIOS ReBAR option is harmless but does nothing by itself.
Verify BAR1 Total 65536 MiB in nvidia-smi; Ikyo's "final size" line above is the driver-side check.

In early August BAR1 was 64 MB on every card because resizable BAR was still disabled in the unlock; later versions resize it. tihohod (2026-09-13) still saw FB Memory Total 65536 MiB with BAR1 Total 64 MiB after install.sh on kernel 7, and a motherboard BIOS update on his ASRock TRX50 from version 11 to 14 fixed it. Try a board BIOS update before giving up on a board. More on Resizable BAR and BAR1 64 GB and Card not detected or BAR allocation fails.

Reported 8 GB and 10 GB
Source: @ikyo, 2026-09-09
Source: @tihohod_, 2026-09-13
Source: @darkmaniac7, 2026-10-29 (lab notes)

Driver unlock, Driver and unlock failures, Acceptance checklist, Testing and burn-in, Memory errors and ECC, Gen2 link retrain, PCIe x16 capacitor mod, Resizable BAR and BAR1 64 GB, Card not detected or BAR allocation fails, Xid 31 and the reserved top of VRAM, Memory unlock on the 10 GB card, Which card do I have, Mmapeak, Benchmarks, Cmpunlocker forks, Troubleshooting.