Driver compatibility
More actions
This page answers one question: does NVIDIA driver X with cmpunlocker version Y work on the 8 GB and the 10 GB CMP 170HX? Each row is one driver version and one outcome, built only from reports already on this wiki, and each row carries the credits of the reports it rests on. It is not a list of everything that works, not a test matrix, and not a replacement for the pages it summarizes: Driver unlock, Driver and unlock failures, Known bad combinations and Operating systems and kernels have the full story.
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). Source: repo github.com/amoghmunikote/cmpunlocker by amoghmunikote on GitHub, posted by @rh3dai, 2026-10-08 615.71.09 is the safe pick; 615.78.08 failed for several owners in October 2026. Source: @.henrykrinkle, 2026-10-20
Driver and cmpunlocker version
| Driver version | cmpunlocker version(s) | 8 GB card | 10 GB card | Result | Notes | Reported by |
|---|---|---|---|---|---|---|
| 615.78.08 | master from 2026-10-08 (commit 2d10f89, "Add support for nvidia-open 615.78.08"); v0.5 with ECC. Which commit each owner ran is not stated. | not stated | not stated | fails Proven | Upstream lists 615.78.08 as supported, but in October every field report on it failed. The install reports no errors, but the cards fail to train PCIe Gen2 at boot and show up in lspci but not in nvidia-smi; downgrading to 615.71.09 loaded the unlock on the first try. 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. The boot loader (Booter) image changed in that release; advice given: keep using the old booter. The installer's Gen2 training and nvidia-smi both misbehave on the modified 615.78.08 driver. The Morrowmake fork's master does not list 615.78.08. Fix: install 615.71.09 (610.57.04 is the older fallback). Details In November KingsizeXXXL could not get 615.78 to work for an unlock inside a Proxmox 9.2 VM either; 615.71.09 was required there (2026-11-07, contested row below).
|
Source: repo github.com/Morrowmake/cmpunlocker by Morrowmake on GitHub, posted by @trustinter, 2026-10-07 Source: @_j3ns, 2026-10-08 Source: @drew_2, 2026-10-10 Source: @drew_2, 2026-10-10 Source: @djpandaman, 2026-10-10 Source: @zagitta, 2026-10-17 Source: @zagitta, 2026-10-17 Source: @scallion_9883, 2026-10-17 Source: @catchyuser, 2026-10-20 Source: @.henrykrinkle, 2026-10-20 Source: @kingsizexxxl, 2026-11-06 Source: @kingsizexxxl, 2026-11-07 |
| 615.78.08 on Proxmox kernel 7.0.14-26-pve (driver and kernel updated together) | amoghmunikote/cmpunlocker (commit not stated) | not stated | not stated | fails Warning | The cards failed at startup, then the unlock retry path wrote into a buffer that was too small and corrupted host memory. Stay on 615.71.09. Card variant not stated. Details | Source: repo github.com/amoghmunikote/cmpunlocker by amoghmunikote on GitHub, posted by @galygious, 2026-10-30 Source: @galygious, 2026-10-31 |
| 615.78.08, customized build | own build, not public: the buffer and retry fixes of draft PR #67 plus a firmware workaround that is not public | not stated | not stated | works (own build only) Reported | Proxmox VE 9.2, kernel 7.0.14-26-pve, three cards used through LXC containers; host module options NVreg_GpuInitOnProbe=0 and NVreg_EnableResizableBar=0; memory, compute and P2P checks passed. The PR does not contain the complete firmware workaround, so the PR alone is not this working build. VM passthrough was not tested with it. See Virtual machines and passthrough.
|
Source: repo github.com/amoghmunikote/cmpunlocker by amoghmunikote on GitHub, posted by @galygious, 2026-10-30 Source: @galygious, 2026-10-31 |
| 615.71.10 | listed in mainline driver/VERSION at 2c7e2ec; not listed on the Morrowmake fork's master
|
no report | no report | no report | Listed as supported; no install result on this driver is recorded on the wiki yet. | Source: repo github.com/amoghmunikote/cmpunlocker by amoghmunikote on GitHub, posted by @rh3dai, 2026-10-08 Source: repo github.com/Morrowmake/cmpunlocker by Morrowmake on GitHub, posted by @trustinter, 2026-10-07 |
| 615.71.09 | v0.4 (615 support added a couple of days before 2026-09-14) and v0.5; commits 2d10f89 and 88e39ce + 6c442ee; Morrowmake --p2p and its p2p-ecc branch (87cb5fd)
|
works | works | works Proven | The most widely confirmed working version. Asked which driver to use for v0.5 on 10 GB cards ("615.71.09?"), the answer was "Yep, can confirm 615 series works just fine". Downgrading from 615.78.08 to 615.71.09 loaded the unlock on the first try, and the v0.5 ECC install worked on it. Reported working: Ubuntu 24.04, kernel 6.8.0, bare metal, 8 cards, Gen2 x16, 64 GB BAR1, P2P and ECC Enabled (Morrowmake p2p-ecc 87cb5fd); Proxmox VE 9.2 on bare metal with a GPU LXC, kernel 7.0.2-6-pve, 4 cards behind two PLX PEX 8747 switches; Debian 13.4 in a PCI passthrough VM, kernel 6.12.113+deb13-amd64, commit 2d10f89, 64 GB after a build fix (stdarg.h) and after dropping bar1-resize-unlock.patch for a compute hang. The PCIe Gen3 guide for the 10 GB card (10de:2082) is written for open kernel modules 615.71.09. Recipe: Mistral Large 4 on 8x 8 GB (llama.cpp lab trial).
|
Source: @_j3ns, 2026-09-13 Source: @_j3ns, 2026-09-14 Source: @68x0, 2026-10-05 Source: @xeax, 2026-10-06 Source: @drew_2, 2026-10-10 Source: @vipic, 2026-10-18 Source: @vipic, 2026-10-18 Source: repo github.com/lixiangwuxian/170hx_tips by lixiangwuxian on GitHub, posted by @lxtend, 2026-10-19 Source: @catchyuser, 2026-10-20 Source: @.henrykrinkle, 2026-10-20 Source: repo github.com/PixelML/club-170hx by PixelML on GitHub, posted by @djpandaman, 2026-10-24 Source: @darkmaniac7, 2026-10-27 (lab notes) Source: @darkmaniac7, 2026-10-29 (lab notes) |
| 615.71.09 in a VM that also holds RTX PRO 6000 (GB202) cards | mainline: commit 2d10f891, installed as --no-iommu --no-passthrough --profile=8gb
|
unlock works (65,536 MiB), CUDA wedges | no report | fails Warning | ESXi 8.0.3 passthrough guest. The unlock itself worked, 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. 615.71.09 with cmpunlocker is fine on bare metal without those cards. Use instead: the unlock ported to 580.178.04 (below), or keep those cards off the shared 615 driver.
|
Source: repo github.com/darkmaniac7/cmp170hx-esxi by darkmaniac7 on GitHub, posted by @darkmaniac7, 2026-10-21 (lab notes) Source: repo github.com/darkmaniac7/cmp170hx-esxi by darkmaniac7 on GitHub, posted by @darkmaniac7, 2026-10-25 (lab notes) |
| 615.71.09 | master before v0.4 (install.sh on 2026-09-10)
|
refused | refused | fails (the installer refuses it) Reported | On 2026-09-10 the installer still refused driver 615.71.09 and required nvidia-open 610.57.04, 610.43.03 or 610.43.02. 615 support came with v0.4 (announced 2026-09-13). | Source: @arabus_74064, 2026-09-10 Source: @_j3ns, 2026-09-14 |
| 615.71.09 or 610.43.x, unlock inside a Proxmox VM (card bound to vfio-pci on the host) | not stated | not stated | not stated | contested Contested | Two owners, opposite results, in the order posted. KingsizeXXXL (Proxmox 9.2, an Ice Lake server that also holds an RTX 4090 with a BF16 unlock, Secure Boot off, UEFI boot, the VM on SeaBIOS at first) could not get it to work on 610.43.03 or 615.78 and found 615.71.09 was required in his setup, which he put down to his server platform; Ikyo had suggested power cycling and moving the VM to OVMF with q35 (whether that change was made is not posted). shad (Proxmox, Ryzen 9 5950X, Asus board, ReBAR enabled, one card at Gen2 x4): 615 never worked for him, 610.43.x always did. Both posted their setup notes as Discord attachments, not reproduced here. Card variants were not stated, and whether the platform decides it is open. See Proxmox Gen2 passthrough and Virtual machines and passthrough. | Source: @kingsizexxxl, 2026-11-06 Source: @kingsizexxxl, 2026-11-06 Source: @ikyo, 2026-11-07 Source: @kingsizexxxl, 2026-11-07 Source: @kingsizexxxl, 2026-11-07 Source: @ikyo, 2026-11-07 Source: @kingsizexxxl, 2026-11-07 Source: @kingsizexxxl, 2026-11-07 Source: @sh.ad, 2026-11-07 Source: @kingsizexxxl, 2026-11-07 Source: @sh.ad, 2026-11-07 Source: @kingsizexxxl, 2026-11-07 |
| 610.57.04 | mainline (accepted before v0.4 and still listed at 2c7e2ec), with cmpunlocker PR #32; v0.3 base plus the bayley/cmpunlocker patch set; Morrowmake | works | no report (one new 10 GB card that never initialized failed on the stock driver too: a card fault, not the driver) | works Proven | A clean 64 GB unlock on 610.57.04 with cmpunlocker PR #32. The Morrowmake fork's four-card P2P result was measured on 610.57.04. Fedora with a custom kernel (7.1.10-cmp): 8x 8 GB behind two PLX8749 switches, Gen2 x4, 64 GB BAR1, BAR1 P2P. 610.57.04 is the older fallback when 615.78.08 fails. A dual-CMP in-guest unlock under Proxmox (Q35, OVMF, driver 610.57.04) needed three changes: serialise the GSP boots, drop the FEAT_OVR_ECC_PLM write, and keep bar1-resize-unlock.patch off. Recipes: GLM 5.3 Flash on 2x 8 GB (ExLlamaV3 TP2), MiMo V2.6 Flash on 4x 8 GB, Qwen3.8 Flash Next on 1x 8 GB (ElectroHobo 3 bpw), Qwen3.8 Flash Next on 2x 8 GB (ElectroHobo W4A16 TP2), Qwen3.8 Flash Next on 4x 8 GB, DeepSeek V4.1 Flash on 8x 8 GB (Zanooda PP8), DeepSeek V4.1 Flash on 4x 8 GB plus RTX PRO 6000 (ExLlamaV3 TP5).
|
Source: @zingy90210, 2026-08-23 Source: @darkmaniac7, 2026-09-04 (lab notes) Source: repo github.com/Johnnydaboy/cmpunlocker by Johnnydaboy on GitHub Source: repo github.com/Schaka/170hx-journey by Schaka on GitHub, posted by @schakaqt, 2026-09-04 Source: repo github.com/Morrowmake/cmpunlocker by Morrowmake on GitHub, posted by @trustinter, 2026-10-07 Source: @youngju10000, 2026-10-08 Source: @ichundes, 2026-10-08 |
| 610.57.04 on Debian 13 with gcc 14 | mainline (version not stated) | not stated | not stated | fails (build) Reported | Kernel 6.17.13+deb13-amd64, headers installed, gcc 14: the unlocker would not build (the exact error was not posted). The NVIDIA module must be compiled with the same compiler the kernel was built with, and it can complain about a gcc that is too new. The reporter then got it working on Ubuntu 24.04, and a second member who hit a similar error on Debian also fixed it by switching to Ubuntu. See Operating systems and kernels. | Source: @redblood_, 2026-09-01 Source: @xanthefin, 2026-09-01 Source: @drack99, 2026-09-01 |
| 610.43.03 | mainline: the August 2026 basic recipe; commits a4de322 (with the repo's patches 0001 to 0008) and 7019bc2; a combined 170HX + CMP 90HX build | works | works | works Proven | The basic recipe (August 2026): install nvidia-open 610.43.03 by hand, download cmpunlocker and run install.sh. Debian 13, kernel 6.12.96+deb13-amd64, bare metal, one 8 GB card (10de:20c2), a4de322 + patches 0001 to 0008: Gen1 x4 to Gen2 x4 after a retrain. Ubuntu Server 22.04 guest under Proxmox VFIO (Q35 + SeaBIOS), cmpunlocker 7019bc2 with --profile=8gb; the experimental Gen2 patch was excluded. A 10 GB card ("CMP 170HX 40GB", 10de:2082) and a CMP 90HX in one Debian 13 / Proxmox host on a combined build of open 610.43.03: Gen2 x4 once pcie-gen2.patch was in the build, and the 40 GB unlock still worked. Recipes: GLM 5.3 Flash on 4x 8 GB (kaka86mm EXL3 + Marlin sidecar + DFlash2), Qwen3.8 Flash Next on 1x 8 GB (iIIusi0n SSD PLE), Qwen3.8 Flash Next on 2x 8 GB (Qwen-Flash-SM80, GDS TEP2), Qwen3.8 27B on 1x 8 GB (W4A16 vLLM).
|
Source: repo github.com/luannanxian/cmp170hx-gen2 by luannanxian on GitHub, posted by @aaasss1456, 2026-07-29 Source: @meatsus, 2026-08-03 Source: @olehborzykh, 2026-09-01 Source: repo github.com/PixelML/club-170hx by PixelML on GitHub, posted by @djpandaman, 2026-10-24 |
| 610.43.03 | mainline (July 2026) | not stated | not stated | fails Reported | Ubuntu 24.04, kernel 6.8.0-111-generic: an NVRM initialization error after every cold reboot, even though SEC2_DEBUG confirmed the registers were written (2026-07-21). Unresolved. Ten cards on HiveOS beta 24.04: install.sh finished without errors, but after a cold reboot the patched module was not loaded (2026-07-20); the three checks for that case are on Verifying an unlock.
|
Source: @dodo03853, 2026-07-20 Source: @_j3ns, 2026-07-20 Source: @k2v0008, 2026-07-21 |
| 610.43.02 | mainline: commit 76f0954; v0.5 or newer (recipe pages also list 360acd7 and 6c442eeb) | works | works | works Proven | Open kernel modules 610.43.02 on an unlocked 8 GB card: compiled, survived reboot, kept 65536 MiB (2026-08-02). The unlock ran fine on 610.43.02 with Ubuntu kernel 7.0.0-30 and gcc 15. Proxmox VE 9.2 host, kernel 7.0.x-pve, cmpunlocker 76f0954 with 610.43.02 patched on the host and the stock 610.43.02 driver in an Ubuntu 24.04.4 guest: the guest sees 65,536 MiB. A 10 GB card on 610.43.02 ran Qwen3.6 27B on 1x 10 GB (SGLang W8A8) at the 40 GiB profile (40,960 MiB) in a KVM virtual machine. Recipes on 8 GB cards: Qwen3.8 Flash Next on 2x 8 GB (mannydelrio PP2), DeepSeek V4 Flash 0731 on 3x 8 GB (PP3 DSpark), Qwen3.8 Flash Next on 2x 8 GB (DUFRelic PP2), DeepSeek V4.1 Flash on 4x 8 GB (GNmac), DeepSeek V4.1 Flash on 4x 8 GB (alanoo fidelity build). | Source: repo github.com/Ciender/CMP-170HX-SGLang-Qwen3.6-Benchmarks by Ciender on GitHub, posted by @makesier, 2026-08-01 Source: @quark2world, 2026-08-02 Source: @robbbbbb7973, 2026-09-01 Source: repo github.com/anoane/01-proxmox-dual-gpu-passthrough by anoane on GitHub, posted by @logy0, 2026-10-10 |
| 610.43.02 | mainline (July 2026), --profile=10gb
|
no report | fails (stayed at 10 GB) | fails Reported | Dell R740, open driver 610.43.02 installed via apt: the installer warned "Loaded nvidia srcversion != patched" and "Modules installed but the running driver is still stock (or unload failed)"; after a cold reboot the card still showed 10 GB instead of 40 GB. No resolution was posted; if a cold reboot does not help, check the DKMS precedence (still stock). | Source: @pasteyy., 2026-07-23 Source: @k2v0008, 2026-07-23 |
| 580.178.04 | the lab's port of the v0.5 core patches (not upstream; the SM override loop left out; 74 SMs from a port of upstream PR #55) | works | no report | works Proven | Ubuntu 24.04 guest, kernel 6.8.0-146-generic, ESXi 8.0.3 passthrough, four 8 GB cards next to other newer NVIDIA GPUs in the same VM. All four cards report 65,536 MiB and pass a 60 GiB address-dependent write/verify on both patterns across VM boots. Stock 580.178.04 drops them back to 8 GiB. Made because 615.71.09 plus cmpunlocker wedged the other GPUs in that VM (row above). The 580.178.04 driver patches are in the cmp170hx-esxi repository; see ESXi. | Source: @darkmaniac7, 2026-10-21 (lab notes) Source: repo github.com/darkmaniac7/cmp170hx-esxi by darkmaniac7 on GitHub, posted by @darkmaniac7, 2026-10-21 (lab notes) Source: repo github.com/amoghmunikote/cmpunlocker by amoghmunikote on GitHub |
Driver families
| Family | What the wiki records | Reported by |
|---|---|---|
| 515 and older | Not unlockable with cmpunlocker: "The exploit only works for 580 and newer", so drivers such as 515 cannot be unlocked with it. | Source: @_j3ns, 2026-08-07 |
| 580 (and the 590 / 595 branch) | On 2026-07-21 the maintainer created the branch clanker/driver-port for "(hopefully working) driver support of 595, 590 and 580"; no result appears in the history. On 2026-08-07 he said he had not ported cmpunlocker to 580 himself but would accept a PR that follows the PR format. A V100 needs the 580 branch, and nothing existed then for the 170HX unlock on 580 (2026-08-22). The lab later ported the v0.5 core patches to 580.178.04 (table above); mainline driver/VERSION lists no 580 driver.
|
Source: @_j3ns, 2026-07-21 Source: @_j3ns, 2026-08-07 Source: @princess_melie, 2026-08-22 Source: @darkmaniac7, 2026-10-21 (lab notes) |
| 610 (610.43.02, 610.43.03, 610.57.04) | The Chinese-origin unlock was the "610 driver unlock", and the maintainer said the driver must be 610 or newer. Until v0.4 the installer accepted only 610.57.04, 610.43.03 and 610.43.02, and the general advice was nvidia-open 610.43.0x; one owner pinned his 610 driver as a precaution in case NVIDIA blocks the unlock in a future driver. All three are still listed at 2c7e2ec. The asm64-hooligan fork is pinned to 610.43.0x; bayley/cmpunlocker supports 610.43.03 and 610.43.02 only. | Source: @_j3ns, 2026-07-18 Source: @eksitus, 2026-07-24 Source: @arabus_74064, 2026-09-10 Source: repo github.com/asm64-hooligan/cmpunlocker by asm64-hooligan on GitHub, posted by @rh3dai, 2026-10-04 Source: repo github.com/bayley/cmpunlocker by bayley on GitHub |
| 615 (615.71.09, 615.71.10, 615.78.08) | Support for 615 came with v0.4 (announced 2026-09-13): memory-management changes and cgroup support, nothing that affects performance. At the time some saw no real advantage over 610 ("unless you have a burning desire to use 615, just install 610-open"), while others pointed to its cgroups-based memory partitioning and the new RmDisableDisplayGlitchPerfLimit registry entry. On one three-card system, asynchronous PCI probing in the R615 driver caused a null KernelGsp crash during boot; a one-line change to PROBE_FORCE_SYNCHRONOUS fixed it. 615.71.09 is the most widely confirmed version; 615.78.08 is listed but fails (table above).
|
Source: @arabus_74064, 2026-09-10 Source: @bayley_w, 2026-09-10 Source: @schakaqt, 2026-09-10 Source: @_j3ns, 2026-09-13 Source: @_j3ns, 2026-09-14 Source: @peter643, 2026-09-14 Source: @xtj7, 2026-10-02 Source: @xeax, 2026-10-06 |
Reported The clanker/driver-port branch in detail. At its tip (153cd6d, 2026-07-21) the branch README called 595.71.05, 590.48.01 and 580.105.08 source-verified (the patches apply cleanly) but not boot-tested on a CMP 170HX. Its driver/VERSION lists twelve driver versions, while driver/patches holds one folder per major version (580, 590, 595, 610) and the build picks the folder by major version, so the other point releases (595.58.03, 595.45.04, 580.95.05, 580.82.09, 580.82.07, 580.76.05, 580.65.06) get a patch set made for a sibling release. No boot report for any of them appears in the history (row above). Source: repo github.com/amoghmunikote/cmpunlocker by amoghmunikote on GitHub, posted by @_j3ns, 2026-07-21
How to read this
- One row per driver version and outcome. A driver can have a works row and one or more fails rows; a fails row names its condition (kernel, OS, VM, other GPUs in the host).
- Result: works means the unlock came up on that driver for the people credited; fails means it did not, or the host misbehaved; no report means the version is listed but nobody has recorded a result here.
- 8 GB card and 10 GB card: what the reports say for that variant. "not stated" means the report does not say which card; "no report" means nothing for that card is on the wiki yet.
- Badges follow the Status taxonomy: Proven only when a second person, or the lab on its own hardware, reproduced it; Reported is one person's post; Warning means hardware or data was at risk.
- cmpunlocker version is a mainline release (v0.4, v0.5) or commit; forks are named (Morrowmake, bayley). Forks carry their own driver lists: see Cmpunlocker forks. Unlockers that are not cmpunlocker (pearlfortune, zerobitcopy/cmp-easyunlock, d3dx9) are not in this table.
- Failures that do not depend on the driver version (no cold boot, a stock DKMS module shadowing the patched one, a kernel upgrade) are on Driver and unlock failures; bugs of one cmpunlocker release (v0.2, v0.3) are under Known issues.
How to add a row
- Sign in with Discord (top right) and edit this page.
- Copy a row and fill in the exact driver version (from
/proc/driver/nvidia/versionornvidia-smi), the cmpunlocker release or commit and the fork, the card variant (8 GB or 10 GB), works or fails, and in Notes the kernel, OS, VM or other GPUs and the exact failure. - Put the credit in the last column, pointing at the Discord message where you posted the result:
{{Source|handle=yourhandle|date=YYYY-MM-DD|link=https://discord.com/channels/...}}. - Mark your own result Reported. A row becomes Proven once a second person's result on the same driver is credited in it. If your result contradicts a row, add your own row and leave theirs as it is.