Unlock internals: detailed research notes
From CMP Wiki
More actions
Archived evidence snapshot. This preserves revision 1606, saved November 11, 2026 of the former hub body verbatim, including historical statuses and open questions. For current findings and priorities, use the developer status hub. This is an evidence reference, not the current status page.
Developers: choose a topic
Current status · Latest research · Register map · Fuse model · 8 GB memory · 10 GB memory · SMs · PCIe Gen2 · Gen3/Gen4 · ECC · NVLink.
To contribute, start with the evidence checklist and the task links under each topic. For installation, use Driver unlock; for user-facing feature status, use Unlocks. Current summaries reviewed 2026-11-10; dated observations remain attributed below.
This page is for people working on the unlocks themselves. It pools what the community and the lab know at register and fuse level about the hardware NVIDIA gated on the CMP 170HX, says where each target stands, who is working on it and what the next concrete step is. It is a hub: each section is a summary, and the long form with every post and source stays on the page it links to. If you only want to unlock a card, start at Unlocks and Driver unlock instead.
Three rules of thumb before the detail:
- Use reviewed read allowlists; some registers clear or advance state when read. Keep the driver bound when using gpcprobe. Writing fuses is permanent. On a card that cmpunlocker's passthrough service had armed, unbinding the driver to read BAR0 left the card unable to rebind until a cold power cycle. Source: @darkmaniac7, 2026-11-05 (lab notes) See HBM identity tools for the read-to-advance case. Source: @darkmaniac7, 2026-11-10 (lab notes)
- Disabled and defective masks identify investigation candidates; they do not prove that healthy, connected HBM is present. mrpandagod reported: "if it's marked defective I've found it's truly defective. disabled can be enabled and I haven't found any time that logic failed". Keep that experience separate from a capacity measurement. Source: @djpandaman, 2026-10-17
Source: @zorg33, 2026-10-22 Source: @darkmaniac7, 2026-11-10 (lab notes) - A capacity claim counts only after a dense write of address-dependent data over every reported byte and a full read-back. Writes above 40 GB on a 10 GB card completed without errors and changed the contents of the first 40 GB. Source: @lxtend, 2026-08-10
Statuses follow Status taxonomy. "Dead end" is not a status badge: it marks a route that was tried or argued down and is listed on Dead ends: what was tried and did not work.
Status board
Reviewed 2026-11-10; the new lab census covers the 8 GB variant only. The two cards are the 8 GB card (10de:20c2, SK hynix HBM) and the 10 GB card (10de:2082, Samsung HBM). The board is an index: every row is backed, with its sources, in the section for that target below.
| Target | Card | Status | Who is on it | Next step or open question | Long form |
|---|---|---|---|---|---|
| Memory to 64 GB | 8 GB | Proven | mainline cmpunlocker (Amogh) | none open; keep verifying with a dense write and read-back | Driver unlock |
| Memory past 64 GB | 8 GB | Theory; disabled-but-not-defective partitions are observed, extra physical capacity is unverified | the lab, CUTE, matstatman | establish access to an inactive HBM site, then reversible mapping and unique-address validation | Latest census and open questions |
| 96 GB | 8 GB | Contested; no validated result from the eight-card lab census | nobody with a method | demonstrate distinct storage above the existing 64 GiB range, with the method and full validation posted | Rumours and claims to verify#8 GB card at 80 or 96 GB |
| Memory to 40 GB | 10 GB | Proven | mainline cmpunlocker | none open | Memory unlock on the 10 GB card |
| 48 GB (sixth stack) | 10 GB | Reported, card-dependent | mrpandagod, lxwx (170hx-rir-tool) | a published recipe; a fuse census that predicts which cards qualify | Memory unlock on the 10 GB card#48 GB (the 6th stack, if it is good) |
| 80 GB | 10 GB | Contested; not achieved | no new progress reported since July | symbolise the recurring GSP fault addresses; read the MMU lock registers; a driverless unique-data test above 40 GB | The 10 GB card: provenance and the 80 GB question |
| 70 to 74 SMs | both | Proven | mainline cmpunlocker | none open | Full SM unlock |
| More than 74 SMs | 8 GB | Contested; the tested ordinary override path is exhausted on all eight lab cards | CUTE (an 80 SM claim, unpublished), the lab (register analysis) | qualify a different enable path and demonstrate more than 74 working SMs | SM findings and open questions |
| Up to 128 SMs | 10 GB | Proven after the RIR burn | lxwx, mrpandagod, xeax, w123s999, orrorin | why some cards stop at 80; a per-card mask sweep that others can run | Full SM unlock#10 GB: how far it goes |
| Reading fuses and floorsweep | both | Proven | matstatman (gpcprobe), lxwx (170hx-rir-tool), ahnguyen17 (ga100-fuse-re) | a settled FBPA-to-stack map; more full-card dumps | Fuses and floorsweep maps |
| RIR burn that clears the software-override gate | 10 GB | Proven | lxwx (tool), Humvee55, mrpandagod | keep slots: one pair is enough | RIR fuse burn |
| The same gate on the 8 GB card | 8 GB | Reported: no free RIR slot; reuse of the one factory record is untested and rated no-go | nobody burning | where the factory record points; do not burn on a hypothesis | Fuses and floorsweep maps#RIR records |
| FBPA PLL and the HBM clock lever | both | Reported, with a Warning for cards with FBPA0 fused off | vektorprime, RH-3D, the lab, Zagitta (gpu-unlock) | root cause of the card that fails every unlock and tune pairing | 170tune |
| ECC enable | 8 GB | enablement Proven; correction Contested | Amogh, Zagitta (fault injection), CUTE (row remapping, unpublished) | a fault-injection or weak-cell result | ECC |
| ECC enable | 10 GB | enablement Reported; correction Contested; GSP boot failure on some cards Reported | Amogh, AlexBrandes (pull request #68; closed without merging on 2026-11-10 UTC), Zagitta (fault injection), CUTE (row remapping, unpublished) | an independent check of the patch proposed in pull request #68; a fault-injection or weak-cell result | ECC |
| PCIe Gen2 | both | Proven | mainline cmpunlocker | cards whose booter write for the Gen2/3 override is refused | Gen2 link retrain |
| PCIe Gen3 | 10 GB | Proven after the RIR burn | lxwx, mrpandagod, evanrodgers | none open | PCIe Gen3 on the 10 GB card |
| PCIe Gen4 | 10 GB | Reported (behind a PLX switch) | mrpandagod | a second report on a Gen4 host, with the capacitor mod | PCIe Gen3 on the 10 GB card#Numbers / state |
| PCIe Gen3 | 8 GB | fused off, nothing released; a one-time route through the last RIR record is Reported on some cards and carries a Warning | CUTE (leads, nothing noteworthy yet) | a route that does not spend the last RIR record | PCIe Gen3 on the 10 GB card#Why the 8 GB card is stuck at Gen2 |
| NVLink | 10 GB | Theory: hardware rework in progress, software side Contested, no trained link | GhostInTheDatacenter (board rework), mrpandagod (software), CUTE, cuddylac997, Morrowmake | the first trained link, then a second builder (board card T-301) | NVLink |
| NVLink | 8 GB | no path | nobody | needs several unlocks the 8 GB card does not have | NVLink |
| VBIOS: a modified or re-signed image | both | Dead end (dropped 2026-08-23) | nobody | none | VBIOS and firmware#Why custom images do not boot |
| VBIOS: in-memory loaders | both | Reported | Panchovix (vix), wanghar (6D without flashing), Humvee55 and Zagitta (P-states) | second reports; nothing here reaches the fuse-gated limits | VBIOS and firmware |
| Unlock without a patched driver (gpu-unlock 3.0) | 8 GB shown | Reported: announced, not released | Zagitta | release and a second report | cmpunlocker forks |
Where research stands (2026-11-09), in the order posted. OB88594: for the 10 GB card the endpoint is clear and only published recipes are missing, while the 8 GB card has no clear endpoint and no route to confirm one. Zagitta: all the information is out there, just not wrapped up in a form ordinary users can follow. Humvee55: progress continues, much slower, and the problems left are the hard ones; to his knowledge the 8 GB card has no such unlock.
Contested 8 GB and 10 GB
Source: @ob88594, 2026-11-09
Source: @zagitta, 2026-11-09
Source: @scallion_9883, 2026-11-09
Research update: November 10, 2026
No additional usable VRAM, SMs, throughput or fault-recovery capability was unlocked in this pass. Eight 8 GB-origin cards already report 65,536 MiB (64 GiB) and 74 SMs each under their existing unlock. This pass combines register observations, cached capability queries and a documented RRL metadata query, offline firmware analysis and synthetic tool fixtures; it is not a fresh dense-memory or performance qualification. Driver and installed GSP file: 615.71.09. The research tools requested no raw GPU-register writes, resets, driver replacement, remap-table updates or fuse programming. Source: @darkmaniac7, 2026-11-10 (lab notes)
| Question | Observed on all eight cards | What remains unresolved |
|---|---|---|
| More memory? | 16 active FBPAs; 4 disabled but not marked defective; 4 marked defective. HBM_CFG0 is 0xa7, already selecting 16 banks. |
Physical presence and health behind inactive sites, an enable path, and unique storage above 64 GiB. Details |
| More compute? | Effective TPC disable equals fused disable; ordinary overrides are already 0xff. Both downstream PD/DS tables total 37 TPCs (74 SMs); nine cached SM issue-rate fields all use the SDK's full-speed encoding. |
A different physical-enable mechanism. Changing counts or a software flag is not a demonstrated SM unlock. Details |
| Row remapping? | RRL metadata version 1.0 is available and matches the installed loader. The initialization gate at 0x823828 bit0 is clear. |
Override semantics, successful initialization and complete restoration. Post-loader processing handles rows within the current topology. Details |
| Fault recovery? | The dedicated cached global-poison capability query returns disabled. ECC reports enabled with zero counters; remapped rows and retired pages report N/A. |
Functional correction and recovery tests. These are different capabilities; zero counters do not prove correction. Details |
The most useful next memory work is to identify a GA100 training command and its unit selector, or establish a qualified identity transport to an inactive HBM site. A selected RMFbLinkTraining policy path has been recovered offline; one followed consumer is MemorySystem StateUnload, which clears software mode state and performs cache-region lifecycle work. It is not a recovered HBM training-start command. Relative aperture offsets from that branch are not raw BAR0 recipes. Source: @darkmaniac7, 2026-11-10 (lab notes)
Evidence levels matter: register readback, changed effective topology, driver enumeration, distinct physical storage and sustained correctness/performance are separate milestones. The results above are lab observations and static analysis, with no new unlock promoted to Proven.
Fuses, floorsweep and RIR: the gate model
Almost every open target on the board runs into the same gate, so it comes first. Long form: Fuses and floorsweep maps, RIR fuse burn.
What is known
- Reported maximum GA100 topology. The cited scaling-register values describe 8 GPCs of 8 TPCs (128 SMs), 12 FBPs, 24 FBPAs and 12 NVLinks; the cited stock configurations have 5 active GPCs, 35 TPCs and 70 SMs. Architectural maxima do not establish working units on a particular card. Source: repo github.com/Consensus-Protocol/cmp170hx by Consensus-Protocol on GitHub, posted by @darkmaniac7, 2026-07-28 (lab notes)
- Three layers. One-time-programmable (OTP) fuses burn once. Most GA100 fuses are "fuseless" fuses that can be rewritten while the software override is allowed. An RIR record (one of 16) can mask an OTP fuse. Masking the fuse that disables the software override makes the rewritable layer usable again, and that layer gates SMs, PCIe speed, NVLink and memory. Source: @cute_sc2, 2026-09-30
Source: @djpandaman, 2026-09-24 - Shadow state. Fuse rows are read at early boot and copied into a shadow state, and the values read later come from that copy. This is Miséricorde's explanation, with the 10 GB RIR result as his evidence, not a measurement. Source: @wakeupmbrc1, 2026-10-28
- The array. 512 rows of 32 fuses; the mapping from row and offset to meaning sits in an encrypted NVIDIA file, and comparing dumps from several cards reconstructs parts of it. Source: @petrikrohn_26497, 2026-09-25
- The gate reads the same on both cards.
DISABLE_SW_OVERRIDE_STATUSreads 1 andEN_SW_OVERRIDEreads 0 on the lab's 8 GB cards and on a stock 10 GB card. Source: @darkmaniac7, 2026-10-22 (lab notes)
Source: @darkshad03, 2026-10-04 - The real split is RIR occupancy. The 8 GB card ships with 15 of 16 RIR slots invalidated and one live factory record; the 10 GB card ships with all 16 blank. Two 8 GB cards dumped read-only were byte-identical. Fuse bits only go from 0 to 1, so a used slot cannot take a new record. Source: @marklintonca, 2026-10-10
Source: @zarquon3157, 2026-09-28
Source: repo github.com/ahnguyen17/ga100-fuse-re by ahnguyen17 on GitHub, posted by @darkmaniac7, 2026-10-18 (lab notes) - The 10 GB burn. The gate fuse exists twice on the die (a primary and a redundant row), so the burn writes two RIR records. After that everything else is the volatile software override, lost at every reboot. Under the linear record layout the pair that clears the gate is
0x00150095; an earlier packing guess,0x15011401in row 0, changed nothing and used up a row. Use the tool, not hand-written values. Source: @_orrorin, 2026-10-10
Source: @petrikrohn_26497, 2026-10-10
Source: @lxtend, 2026-10-10
Source: @scallion_9883, 2026-10-16 - The TPC status logic.
STATUS = OPT | (RECONFIG & ~OVR): a TPC is off when its OTP bit is set, or when its soft RECONFIG bit is set and the override bit is not. The 70 to 74 SM step clears four SMs that sat behind a RECONFIG bit. Source: @akuchen_66498, 2026-09-26 - The floorsweep control registers only remove. The effective mask is OTP OR software control: clearing disable bits does nothing, and setting one more disable bit turned off another TPC (68 SMs instead of 70). Source: @akuchen_66498, 2026-08-09
Source: @scallion_9883, 2026-07-21 - September community census of eight 8 GB cards. Read with gpcprobe:
OPT_FBP_DISABLE 0x852(FBPs 1, 4, 6, 11),OPT_FBP_DEFECTIVE 0x840(FBPs 6, 11),OPT_FBPA_DISABLE 0x00c0330c(8 disabled, 16 active FBPAs). The GPC disable masks vary per die. Source: @con3po7016, 2026-09-23
Register map
Addresses in this table are BAR0 offsets. Values belong to the named card sample and build. The driver treats the broader 0xBADxxxxx prefix as a possible PRI error; checking only 0xBADFxxxx misses other error encodings. Historical 0xbadf2010 decodes as FECS_PRI_ORPHAN in the GA100-selected public decoder. That category alone does not establish floorsweeping, absent DRAM or the cause of an inaccessible window. Source: @darkmaniac7, 2026-11-10 (lab notes)
| Address | Name | What it is and what was read | Source |
|---|---|---|---|
0x820040 |
EN_SW_OVERRIDE | the software fuse override enable; 0 on stock cards of both kinds | Source: @darkmaniac7, 2026-10-21 (lab notes) |
0x820084 |
DISABLE_SW_OVERRIDE_STATUS | bit 0 = 1: the override is fuse-disabled. 1 on every 170HX read until the 10 GB RIR burn clears it | Source: @darkmaniac7, 2026-10-21 (lab notes) Source: @darkshad03, 2026-10-04 |
0x820050 |
IFF_RECORD pointer | 0x01fb01e8 on 8 GB and 10 GB cards |
Source: @darkmaniac7, 2026-10-22 (lab notes) Source: @darkshad03, 2026-10-04 |
0x820060 |
DEBUGCTRL | the fuse controller's debug control. The RIR tools latch a bit here; "debugctrl rwl bit cannot be latched" means the controller is not reachable | Source: @lycorascence, 2026-10-20 |
0x820228 |
OPT_ECC_EN | 0 on four 8 GB cards (the fuse says ECC is not enabled) | Source: @darkmaniac7, 2026-10-21 (lab notes) |
0x82022C |
OPT_GPC_DISABLE_CP | named as the register to read on a 10 GB card that would not boot with a bad GPC6; that thread is unresolved | Source: @djpandaman, 2026-10-11 |
0x820250 |
OPT_DISABLE_GEN3_SPEED | bit 0 = 1 clamps the link capability to Gen2. 1 on every stock card read | Source: @djpandaman, 2026-09-29 Source: @matstatman, 2026-09-06 Source: @darkmaniac7, 2026-10-18 (lab notes) |
0x82057c |
FUSE_PCIE_GEN23_DIS (OPT_GEN23) | 1 on stock cards | Source: @matstatman, 2026-09-06 Source: @darkmaniac7, 2026-10-18 (lab notes) |
0x820580 |
FUSE_PCIE_GEN3_DIS (OPT_PCIE_BOOT_GEN3_DIS) | 1 on stock cards; a different register from 0x820250, and the 10 GB Gen3 route needs both cleared |
Source: @matstatman, 2026-09-06 Source: @darkmaniac7, 2026-10-18 (lab notes) |
0x820520 |
FUSE_PCIE_MAGIC_D | 0x16680000 on the 170HX against 0x00200000 on an A100; bit 25 is the Gen4 disable |
Source: @darkmaniac7, 2026-10-18 (lab notes) Source: @darkshad03, 2026-10-04 |
0x820584 |
FUSE_DEVID_SW_OVR_DIS | 1: the device ID cannot be overridden in software | Source: @darkmaniac7, 2026-10-18 (lab notes) |
0x8203f0 |
FUSE_FEAT_OVR_DIS | 0 on the 8 GB cards read (1 would mean the feature-override class is dead) | Source: @darkmaniac7, 2026-10-18 (lab notes) |
0x8205c4 |
OPT_GPC_DEFECTIVE | 0 on Zagitta's card (no GPC marked defective) | Source: @zagitta, 2026-10-17 |
0x820760 + 4 x GPC |
OPT_TPC_DISABLE rows | the fused TPC disable row of each GPC | Source: @darkmaniac7, 2026-10-22 (lab notes) |
0x820c38 + 4 x GPC |
RECONFIG STATUS rows | equal to fused TPC disable on every GPC of all eight unlocked lab cards; the tested ordinary override path has no remaining soft-disabled TPC candidate | Source: @darkmaniac7, 2026-11-10 (lab notes) |
0x823804 |
feature-override PLM (SS0 and SS1) | 0xffffffff once the unlock has opened it |
Source: @darkmaniac7, 2026-10-22 (lab notes) |
0x82381c, 0x823820 |
SM speed selectors SS0, SS1 | 0x88888888 and 0x00000008 after the compute unlock; written every boot by cmpunlocker |
Source: @darkmaniac7, 2026-10-22 (lab notes) |
0x82380c, 0x823810, 0x82382c |
ECC feature overrides | stock 0x00888888, 0x002aaaaa, 0x0000000a; with the v0.5 ECC patch 0x00999999, 0x003ffebf, 0x0000000f |
Source: @darkmaniac7, 2026-10-18 (lab notes) Source: repo github.com/amoghmunikote/cmpunlocker by amoghmunikote on GitHub |
0x823814 |
FEATURE_READOUT | 0x00000233 stock, 0xec8ff233 with ECC on; bit16 is DRAM ECC. In the selected GSP recovery path, bit9 participates in the global-poison query, with a conditional fallback to 0x82039c bit0. These fields do not prove functional correction |
Source: @darkmaniac7, 2026-10-19 (lab notes) Source: @darkmaniac7, 2026-11-10 (lab notes) |
0x9a038c |
HBM_CFG0 | 0xa7 on all eight cards; the selected firmware decoder interprets bit1 as 16 banks. Configuration evidence, not physical-density or address-uniqueness proof |
Source: @darkmaniac7, 2026-11-10 (lab notes) |
0x823828 |
HBM row-remap initialization gate readout (reverse-engineered) | 0x6 on all eight cards: bit0 is clear. The selected GSP initializer skips RRL initialization on zero. Separate from ECC-enabled reporting |
Source: @darkmaniac7, 2026-11-10 (lab notes) |
0x823824 |
HBM row-remap override candidate; encoding unresolved | 1 on three cards and 0 on five, while the readout gate is clear on all eight. Neither value is a demonstrated enable recipe for row repair; ECC-enabled status is separate |
Source: @darkmaniac7, 2026-11-10 (lab notes) |
0x82033c |
Global-poison override prerequisite; field name unresolved | Low nibble is 0x2 on all eight; the selected override routine requires a nonzero value. Passing this prerequisite does not establish activation or rollback |
Source: @darkmaniac7, 2026-11-10 (lab notes) |
0x1373a0 |
JTAG-related clock readout | 0x9 on all eight; bit3 is already set; the GA100-selected callback reads that bit. This does not establish working scan transport or access to fuse/configuration chains |
Source: @darkmaniac7, 2026-11-10 (lab notes) |
0x406028 |
PD TPC-count table base | Four words; the nibble counts total 37 TPCs on every card, matching the DS table at 0x405870. Logical topology data, not a physical-enable control |
Source: @darkmaniac7, 2026-11-10 (lab notes) |
0x405870 |
DS TPC-count table base | Four words; the nibble counts total 37 TPCs on every card. Table positions are not established physical fuse GPC indices | Source: @darkmaniac7, 2026-11-10 (lab notes) |
0x820840 |
TPC-control index2; separate MIG attribution unresolved | Overlaps the GA100-selected 0x820838 + 4*i TPC-control writer. Do not treat a community MIG association as a validated dedicated MIG register |
Source: @darkmaniac7, 2026-11-10 (lab notes) |
0x9a0148 |
FBPA PLM | 0xffffffff (open) on an unlocked card |
Source: @darkmaniac7, 2026-10-25 (lab notes) |
0x9a0168 |
FBPA_MEM PLM | 0xffffffcf (host write bit clear) unless the driver carries the HBM-control opens |
Source: @darkmaniac7, 2026-10-25 (lab notes) |
0x9a3c7c, 0x9a3c80, 0x9a3c84 |
broadcast FBPA_PLL0, 1, 2 PLMs | 0xffffffcf unless opened; these carry the multicast HBM clock write |
Source: @darkmaniac7, 2026-10-25 (lab notes) |
0x903c7c |
unicast FBPA0_PLL PLM | a PRI error on a card whose FBP0 is floor-swept, and orphaned on the 10 GB card. Do not put it in a boot-time PLM table | Source: @darkmaniac7, 2026-10-25 (lab notes) Source: @rh3dai, 2026-10-04 |
0x9a0204 |
FBPA_CFG1 | memory geometry: 0x02779000 for 64 GB on the 8 GB card, 0x02669000 for 40 GB on the 10 GB card |
Source: @darkmaniac7, 2026-11-05 (lab notes) Source: @programmerboi, 2026-10-25 |
0x100ce0 |
MMU LMR (local memory range) | 0x0000020B for 64 GB, 0x0000028A for 40 GB, 0x0000028B for the 80 GB geometry |
Source: @darkmaniac7, 2026-10-22 (lab notes) Source: @programmerboi, 2026-10-25 Source: @_j3ns, 2026-07-20 |
0x9a0470 |
FBPA_ECC_CTRL | 0 stock, 0x41 with ECC on |
Source: @darkmaniac7, 2026-10-19 (lab notes) |
0x8872c |
NV_XVE_FUSE_OVERRIDE | 0x6 with the Gen2 patch. 0xA (the Gen3 pair) eventually wedged a card under VFIO |
Source: @darkmaniac7, 2026-10-18 (lab notes) Source: @ropuls, 2026-10-08 |
0x8c040 |
XP link config, maximum rate field | reverse-encoded: 3 = Gen1, 2 = Gen2, 1 = Gen3 | Source: @darkmaniac7, 2026-10-19 (lab notes) |
Floorsweep control shadows: CTRL_OPT_FBP and CTRL_OPT_FBPA read 0 on all eight unlocked lab cards, and effective status equals the fused disable values. Source: @darkmaniac7, 2026-11-10 (lab notes)
Tools that read
- gpcprobe (matstatman): a read-only kernel module that maps BAR0 with the driver bound and prints the GPC, FBP, FBPA and FBIO disable and defective masks, the SM count and the NVLink, PCIe and ECC fuses. In its output "disabled" already includes "defective". Source: repo github.com/matstatman/gpcprobe by matstatman on GitHub
Source: @civiloid, 2026-09-18 - 170hx-rir-tool (lxwx): only
--statusis pure register reads. The dump commands drive the fuse controller without changing fuses, and the volatile--sw-writecommands abort unless the gate has been cleared by a burn. Source: @lxtend, 2026-10-10
Source: repo github.com/lixiangwuxian/170hx-rir-tool by lixiangwuxian on GitHub, posted by @darkmaniac7, 2026-10-18 (lab notes) - ga100-fuse-re (ahnguyen17): read-only notes on the fuse layout, the RIR macro and the 80 GiB fold; its own verdict on burning a working card is no-go. Use it as a cross-check before trusting any burn list. Source: repo github.com/ahnguyen17/ga100-fuse-re by ahnguyen17 on GitHub
- Reviewed BAR0 snapshots can be taken with the driver bound. Raw fuse rows and RIR occupancy need a fuse-controller transaction, and arbitrary register reads are not automatically non-affecting. Source: @darkmaniac7, 2026-11-10 (lab notes)
HBM identity tools and stateful reads
Source review of matstatman/hbmmon at commit 5e28735 found a stateful IEEE1500 identity protocol: control writes select a stream and DATA reads advance it. Even the --read-only frontend reads DATA for temperature. Synthetic 16-FBPA fixtures recorded 16 such reads in hbmmon and 4 in hbmmap; effects on hardware were not measured. Source: @darkmaniac7, 2026-11-10 (lab notes) Source: repo github.com/matstatman/hbmmon by matstatman on GitHub
The pinned tool's liveness filter rejects only the BADF prefix. Synthetic broader BAD-prefix values and 0xffffffff were accepted as live; this is a source-fixture result, not an observed lab-card failure. Restoration and retry handling also need review before a bounded experiment. The repository does not supply its nine required permission-opening addresses or a demonstrated inactive-site transport. An identity read, even if obtained, would still need mapping and unique-storage validation before supporting an extra-capacity claim. Source: @darkmaniac7, 2026-11-10 (lab notes)
Host2JTAG: prior work and remaining gaps
This avenue has prior experiments. August reports describe standard-mode attempts returning zeros or hanging GSP, including a cluster-3 hang. The November lab census finds the five published access masks open and the relevant clock bit already enabled on all eight; those prerequisites do not establish access to configuration chains. Source: @akuchen_66498, 2026-08-09 Source: @akuchen_66498, 2026-08-09 Source: @darkmaniac7, 2026-11-10 (lab notes)
The recovered CPU-driver transport routines belong to NVSwitch. A separate override-initialization sequence involving 0x82013c is selected for TU102/TU116, while GA100 selects a no-op. Neither is a qualified CMP scan recipe. A GA100 transport, instruction/chain directory and capture-versus-update semantics remain missing. Source: @darkmaniac7, 2026-11-10 (lab notes)
Tried and failed
- Writing the NV_FUSE_OPT registers from BAR0. K2V wrote the GPC disable option with its privilege mask opened: no effect, and the Gen3 disable option behaved the same for someone else. Samuel Hayden: the values can be written but are ignored. K2V's conclusion: only OPT fuses with a matching feature-override register can be changed from BAR0, and ECC is the example. Source: @k2v0008, 2026-08-03
Source: @samuel_hayden., 2026-08-03 - Clearing bits in the floorsweep control registers. Remove-only, above. Source: @scallion_9883, 2026-07-21
- The first RIR write attempt (one record, early script) did not help; the working route is the two-record burn. Source: @_orrorin, 2026-10-10
- A "broken" fuse. CUTE reported breaking fuses on both cards: a broken fuse reads as neither 1 nor 0, and he was not sure it is useful. Source: @cute_sc2, 2026-10-02
Open questions
- Which fuse bit the 8 GB card's one live factory record points at. It looked reachable on one card and closed on another; it is a hypothesis and nobody has burned on it. Source: @marklintonca, 2026-10-10
Source: repo github.com/ahnguyen17/ga100-fuse-re by ahnguyen17 on GitHub, posted by @darkmaniac7, 2026-10-18 (lab notes) - Whether both disable fuses of some feature sit on one physical row, so that a single record could enable it; and whether debug mode can be enabled on 8 GB cards at all. Both are Petri Krohn's untested ideas. Source: @petrikrohn_26497, 2026-10-01
- Whether a different hardware ID could be burned on the 8 GB card. mrpandagod: the remaining record is partly written, a new value has to be a binary superset of the current one, and that makes turning the override disable off impossible; the hardware-ID idea is untested. Source: @djpandaman, 2026-10-28
- A read-only register and fuse dump from a fully unlocked 10 GB card, to diff against 8 GB cards. Asked for on 2026-10-31; no result posted. Source: @n2dcrypt, 2026-10-31
- The FBPA-to-stack map. gpcprobe's map was questioned and an alternative proposed; the author agreed the script has shortcomings. Source: @zarquon3157, 2026-09-28
Source: @matstatman, 2026-09-28
Memory on the 8 GB card: past 64 GB
Long form: Floorsweep read of the 8 GB card: gated versus defective partitions, Fuses and floorsweep maps#Memory: the FBP and FBPA census, Rumours and claims to verify#8 GB card at 80 or 96 GB, 8 GB card#Memory.
What is known
- 64 GB is 16 of 24 FBPAs at 4 GiB each (stock 8 GiB is the same 16 FBPAs at 512 MiB); 96 GiB would need all 24. The unlock rewrites the geometry (
FBPA_CFG1 0x02779000, LMR0x0000020B), not the floorsweep. Source: repo github.com/matstatman/gpcprobe by matstatman on GitHub
Source: @darkmaniac7, 2026-10-22 (lab notes) - The lab's eight-card census, November 10: every card has 8 FBPs active, 2 disabled but not marked defective and 2 marked defective; 16 of 24 FBPAs are active, 4 disabled but not marked defective and 4 marked defective. This does not establish 80 GiB of physically connected, healthy memory. No additional capacity was enabled or validated. Source: @darkmaniac7, 2026-11-10 (lab notes)
- The masks differ by card. Six have FBP disable/defective masks
0x852 / 0x840; the other two have0x2d / 0x9and0x2d / 0x24. The eighth-card capture is complete. Never copy another card's partition mask. Source: @darkmaniac7, 2026-11-10 (lab notes) - No additional-partition enable path is qualified. The software override is fuse-disabled, the FBP/FBPA control shadows read 0, and the recorded RIR layout has no free slot. Capacity arithmetic cannot substitute for a working enable mechanism and unique-data validation. Source: @darkmaniac7, 2026-11-05 (lab notes) Source: @darkmaniac7, 2026-11-10 (lab notes)
- Reading is not using. Feralzi: an 8 GB card can read 96 GB but crashes when the dead dies are touched. Source: @feralzi, 2026-10-17
- The fuse-RE notes' verdict. An RIR route to more VRAM is rated dead, and a fuseless-fuse record that would clear the FBP disable bits is rated incomplete and has never been burned. Good data, not actionable. Source: repo github.com/ahnguyen17/ga100-fuse-re by ahnguyen17 on GitHub, posted by @darkmaniac7, 2026-10-03 (lab notes)
Tried and failed
- Writing the fuse option registers from BAR0, and clearing floorsweep control bits: see the gate model above. Source: @k2v0008, 2026-08-09
- The monthly "96 GB" and "128 GB" screenshots. Zagitta: a new flavour turns up every month with "0 hard evidence"; the 128 GB figures were two 64 GB cards reported as one. Source: @zagitta, 2026-11-04
- A VBIOS route to more memory and the "64 GB unlocked VBIOS" files: Dead ends: what was tried and did not work#VBIOS and flashing, VBIOS and firmware#The "64 GB unlocked VBIOS" repos (bogus).
Open questions
- Whether populated, bonded and healthy DRAM sits behind the inactive channels. The current masks cannot answer this. A qualified identity transport, reversible mapping and dense unique-data validation are still needed. Source: @darkmaniac7, 2026-11-10 (lab notes)
- matstatman proposed row remapping as a possible route toward 96 GB. The recovered RRL post-loader path filters rows against the current effective FBIO topology; it is not an extra-partition enable mechanism. A separate enable path would still be needed. Source: @matstatman, 2026-11-04 Source: @darkmaniac7, 2026-11-10 (lab notes)
- Whether the two "defective" FBPs on almost every card are really dead. Petri Krohn doubted it ("this cannot be true", most likely two stages of disabling); the lab's read treats them as defective. Source: @petrikrohn_26497, 2026-10-10
- Whether units can be re-enabled with GSP off (the closed driver with CPU-RM). One member carried the unlock across a driver reload that way; nobody has tried a floorsweep change under it. Source: @zarknoth, 2026-10-27
Source: @matstatman, 2026-10-27 - Follow the remaining training-policy consumers to an actual firmware command and unit selector. The traced StateUnload/cache branch does not supply one; no training setting has been changed. Source: @darkmaniac7, 2026-11-10 (lab notes)
Board. D-072 and D-056 (Dev and research); T-029 (CMP testing).
Memory on the 10 GB card: 40, 48 and the 80 GB wall
Long form: Memory unlock on the 10 GB card, The 10 GB card: provenance and the 80 GB question.
What is known
- 40 GB. Five stacks of 8 GB: CFG1
0x009a0204 = 0x02669000, LMR0x00100ce0 = 0x0000028A. Plan for about 37 to 38 GiB usable. Source: @programmerboi, 2026-10-25
Source: @cuddylac997, 2026-08-13 - 48 GB. It needs the RIR burn and a sixth stack that is disabled, not defective (gpcprobe
OPT_FBP_DISABLE 0x840with every DEFECTIVE mask 0). mrpandagod counted 6 of 30 cards at 48 GB. On a stock 10 GB probe both off FBPs read defective (OPT_FBP_DISABLE 0x12,OPT_FBP_DEFECTIVE 0x12). Source: @bigfoot1144, 2026-10-19
Source: @djpandaman, 2026-10-17
Source: @cuddylac997, 2026-10-07
Source: @darkshad03, 2026-10-04 - The 80 GB geometry reports, then folds. With LMR
0x0000028Bnvidia-smi shows 80 GB; the read-only fuse RE of a Samsung card found the aperture folds at about 16 KB above the expected address, so the upper half aliases the lower. Humvee55, a co-author of the paper that used a 10 GB card, now believes the apparent extra capacity is aliasing in L2. Source: repo github.com/ahnguyen17/ga100-fuse-re by ahnguyen17 on GitHub
Source: @scallion_9883, 2026-10-16 - What the GSP does. On the public 80 GB method a 39.7 GB burn passes, then about 10 seconds after the workload exits the GSP crashes; after a function-level reset the card is back at its native 10 GB geometry. MaitOPS: the crash hits the same point on several cards and points to the GSP's memory allocation map. Source: @jovial_dolphin_29796, 2026-07-27
Source: @_maitops, 2026-09-19 - The late-PMA patch overlapped the GSP's reserved region on the 80 GB geometry (a hazard only above about 79 GiB); fixed in ggualerz's branch
fix/late-pma-wpr2-overlap. Source: repo github.com/ggualerz/cmp170hx10g-to-80g by ggualerz on GitHub - Latest word. mrpandagod (2026-10-29): "it works perfectly with the small caveat of never being able to write to the upper half region". OB88594 (2026-10-30): "There is no new progress compared to three months ago". Source: @djpandaman, 2026-10-29
Source: @ob88594, 2026-10-30
Tried and failed
- The LMR value alone. Building with
0x28B"doesnt help much" with the crash above 40 GB. Source: @lxtend, 2026-07-20 - Reaching the HBM control registers with the exploit as it stood in July: out of reach, so no quick path. Source: @samuel_hayden., 2026-07-26
- The DMA gist. cuddylac997's analysis blamed a GSP DMA-tracking table; a clean test to 76 GiB did not reproduce for others, the staging-buffer workaround was retracted, and he took it down ("A lot of it was wrong"). Source: @cuddylac997, 2026-09-30
Source: @lycorascence, 2026-09-30
Source: @cuddylac997, 2026-10-01 - Getting around the fold. Writes always landed in the lower 40 GB. Source: @deaddudehangin, 2026-10-03
- Refresh, downclocking, cooling, VRM parts and strap swaps: each has its own entry on The 10 GB card: provenance and the 80 GB question#The 80 GB branch and why it fails.
Open questions
- Symbolise the recurring GSP fault addresses (
0x5b2ba28,0x5335ab0) against the exact GSP build, to tell whether the 40 GB cap is gated on device ID or fuses, or is hard. Source: @cuddylac997, 2026-09-30 - Read the
NV_PFB_PRI_MMU_LOCKaddress and privilege-mask registers on a 10 GB card: an MMU-locked range might explain the ceiling near 40 GiB. Nobody answered. Source: @okrasit., 2026-09-30 - Petri Krohn's test: apply the geometry with the driverless unlocker, do not load the driver, and write then read back more than 40 GB of unique data through the frame buffer. He disputes the folding reading. Source: @petrikrohn_26497, 2026-08-12
- Do writes to the upper region from a peer GPU behave differently? Asked on 2026-10-30, no answer. Source: @turbine, 2026-10-30
- The evidence behind the software FBPA override attempt dated 2026-07-14 in the research wiki: the patch, the register dumps before and after. Requested, not supplied. Source: @cuddylac997, 2026-10-02
GPCs and SMs
Long form: Full SM unlock, Fuses and floorsweep maps#Compute: GPCs, TPCs and SMs.
What is known
- 70 to 74 on both cards is the RECONFIG override, in mainline since the SMs branch of 2026-09-24. The patched driver logs it as
RECONF: REENABLE gpc3 elig=0x1 OVR 0x0->0x1 STATUS 0x1->0x0. Source: @_j3ns, 2026-09-24
Source: @akuchen_66498, 2026-09-26 - 8 GB card: the ordinary override path is exhausted on this sample. On all eight cards, effective TPC disable equals the fused rows on every GPC and the ordinary overrides are already
0xff. This rules out remaining soft-disabled TPCs through that mechanism, not every hypothetical reversible path. Source: @darkmaniac7, 2026-11-10 (lab notes) - The lab's eight-card read: 5 active GPCs and 37 TPCs (74 SMs) per card. The downstream PD and DS tables independently agree on 37 TPCs, and all nine cached SM issue-rate fields are
0, the SDK full-speed encoding. No additional divider was found in this mechanism and no new throughput gain was measured. Source: @darkmaniac7, 2026-11-10 (lab notes) - 10 GB card: 74 to 80 is software only; 80 to 128 needs
EN_SW_OVERRIDE, which needs the RIR burn. The last cores came from overridingOPT_TPC_DISABLE; lxwx reached 128 SMs at full clock. Source: @djpandaman, 2026-10-10
Source: @lxtend, 2026-10-17 - Per-card masks. Mainline does not do this. The workflow is: unlock with the RIR tool, test which locked parts work, build a mask that leaves out the defective parts. Source: @xeax, 2026-10-25
- Disable masks vary per die, the totals do not (
0x13,0x15,0x25,0x45,0x85and0xa8seen, all leaving 5 GPCs). A tool must not hard-code a mask read from someone else's card. Source: repo github.com/Consensus-Protocol/cmp170hx by Consensus-Protocol on GitHub, posted by @darkmaniac7, 2026-07-28 (lab notes)
Tried and failed
- Writing the GPC disable register on an 8 GB card: no effect. Source: @k2v0008, 2026-08-03
- The AI-generated "SEC2 patch" diffs that claimed 30 SMs per GPU: the files they patch do not exist in the 610.43.03 tree, and the STATUS 1 to 0 transition they read as a rollback is the enable. Source: @arabus_74064, 2026-09-25
Source: @akuchen_66498, 2026-09-26 - Going past 80 on some 10 GB cards: two owners stop at exactly 80, and reaching for the three disabled GPCs made one card drop. Source: @_orrorin, 2026-10-25
Source: @zhiyu52_64083, 2026-10-29
Open questions
- CUTE's 80 SM unlock on 8 GB cards: claimed on 2026-10-02 ("not on every card"), with no method, proof or numbers posted since. Source: @cute_sc2, 2026-10-02
- Why some 10 GB cards stop at 80: operator error (OB88594) or heavily binned dies (xeax)? Which TPCs in the disabled GPCs are bad on those cards? Source: @ob88594, 2026-10-25
Source: @xeax, 2026-10-25
Source: @djpandaman, 2026-10-29 - An 8 GB card with no defective GPC exists in several hands (GPC 5 healthy, 3 disabled, 0 defective). What it would take to enable them is the gate question above. Source: @bvls7857, 2026-11-04
FBPA PLL and the HBM clock registers
Long form: 170tune, Driver and unlock failures#170tune preflight fails, cmpunlocker forks, VBIOS and firmware#Stock VBIOS inventory.
What is known
- The clock is NDIV x 27 MHz. Stock NDIV: 45 (1215 MHz) on the 10 GB card, 54 (1458 MHz) on the 8 GB card with the 250 W VBIOS, 64 (1728 MHz) with the 300 W VBIOS. Source: @c133, 2026-10-22
- The lever needs privilege masks the core unlock does not open. On two unlocked 8 GB cards the FBPA PLM read open, but FBPA_MEM and the broadcast FBPA_PLL0, 1 and 2 masks read
0xffffffcf, so a host write of the PLL coefficient is dropped. The masks are opened only by the booter rounds during GSP boot, so the driver has to carry those entries. Source: @darkmaniac7, 2026-10-25 (lab notes) - Which lineage opens what. asm64-hooligan opens only the broadcast window; 170tune's live lever writes the unicast FBPA0 window (
0x00903c7c,0x00903c98); vektorprime'sfbpa-pll-170tunebranch opens both on the 8 GB card and skips the unicast row on the 10 GB card, where that window is orphaned in hardware and faults the booter. Source: @rh3dai, 2026-10-04
Source: @vektor_prime, 2026-10-07 - FBPA0 is not always alive. Upstream
hbm_mclkreads and writes through FBPA0; on a card with FBP0 floor-swept it reads0xbadf2010and would write that value into every FBPA. The fixed builds use the first live FBPA fromOPT_FBPA_DISABLE. Source: @darkmaniac7, 2026-10-25 (lab notes) - The lab's volatile result: HBM from 1458 to 1728 MHz on 8 GB cards with the 250 W VBIOS, about 18 % more bandwidth, zero errors, bit-exact. Source: @darkmaniac7, 2026-10-25 (lab notes)
Tried and failed
- Warning A unicast FBPA0_PLL entry in the boot-time PLM table broke card init (
RmInitAdapter0x62) on a card whose FBP0 is floor-swept; the previous modules and a power cycle brought it back. Rule: never put a per-FBPA unicast register in a PLM table that is fatal on a read-back mismatch. Source: @darkmaniac7, 2026-10-25 (lab notes) - Warning Two of eight cards did not boot on the
fbpa-pll-170tunelineage (GSP booter error0xffff); they came back on a lineage that writes no PLL registers. Read each card's fuse map first and skip PLL tuning on a card without a live FBPA0. The FBPA0 explanation is a warning, not a proven mechanism. Source: @darkmaniac7, 2026-10-27 (lab notes) - One card of 36 fails 170tune preflight on every pairing tried while unlocking normally to 74 SMs. Source: @rh3dai, 2026-10-04
Source: @drew_2, 2026-10-12 - A DRAM timing value (
tCCD_L = 3in the asm64 fork) hard-hangs the controller until a reboot. Source: repo github.com/asm64-hooligan/cmpunlocker by asm64-hooligan on GitHub
Open questions
- Root cause of the card that fails every pairing. Source: @rh3dai, 2026-10-04
- gpu-unlock is integrating 170tune-style HBM downclocking; Zagitta had "no luck" getting HBM settings to stick the day before. Not released. Source: @zagitta, 2026-11-07
- Live NDIV and power caps reset whenever the serving engine restarts on the lab's rig; a tune has to be re-applied. Source: @darkmaniac7, 2026-10-25 (lab notes)
GSP boot behaviour
There is no single long-form page for this; the facts live on Driver unlock, Driver and unlock failures#GSP problems, Xid errors and Recovery.
What is known
- Mainline applies its PLM, SM-selector and memory-geometry writes during GSP bootstrap. The patched driver opens the privilege masks in that window, then writes the SM speed selectors and the memory geometry. The compute half survives a function-level reset; the geometry is re-applied every GSP boot, which is why the patched modules must load each boot. Source: repo github.com/amoghmunikote/cmpunlocker by amoghmunikote on GitHub
Source: repo github.com/Consensus-Protocol/cmp170hx by Consensus-Protocol on GitHub - The Gen2 writes land in the same window, and the card opens its Gen2 advertisement on its own schedule a fraction of a second later.
journalctl -k -b 0 | grep 'SEC2_DEBUG: PCIe'tells the three failure cases apart: no lines (patch bypassed), read-back mismatches (writes rejected), or matching read-backs with no window (new, worth reporting). Source: @kmike84, 2026-09-01 - A refused write shows as status 0xffff.
PCIe xp3g booter FAILED to set OPT_GEN23after attempts that log status=0xffff is the signature of the boot path refusing the Gen2/3 override; the card keeps working at Gen1. Source: @_j3ns, 2026-07-23
Source: @samuel_hayden., 2026-07-23 - A window that is not there can kill init. The 10 GB card's unicast FBPA0 PLL window and a floor-swept FBP0 on an 8 GB card both faulted the boot when a PLM entry was fired at them. Source: @rh3dai, 2026-10-04
Source: @darkmaniac7, 2026-10-25 (lab notes) - ECC can stop GSP boot on some 10 GB cards (Xid 1, 119 and 140 whenever ECC was armed on one of two cards), per pull request #68 (closed without merging on 2026-11-10 UTC). Source: repo github.com/AlexBrandes/cmpunlocker by AlexBrandes on GitHub
- An in-memory VBIOS override is applied at GSP load, too late to touch anything still locked on the 8 GB card. Source: @scallion_9883, 2026-10-17
- Passthrough reset restrictions. The passthrough service applies NO_BUS_RESET. On the lab's armed configuration, driver unbind prevented rebind until a cold power cycle. Source: repo github.com/amoghmunikote/cmpunlocker by amoghmunikote on GitHub Source: @darkmaniac7, 2026-11-05 (lab notes)
- Floorsweep experiments outlive a driver reload. Units disabled through the control shadows came back only after an FLR or a reboot, and a runtime FLR left the card in a "GPU requires reset" state. Source: @akuchen_66498, 2026-08-09
- GSP off. Loading the proprietary driver with
NVreg_EnableGpuFirmware=0after an unlock kept the register changes with no GSP panics. matstatman doubts it unlocks anything new. Source: @zarknoth, 2026-10-27
Source: @matstatman, 2026-10-27
Open questions
- Does the 40 GB cap on the 10 GB card live in a CMP-specific GSP firmware or in shared firmware branching on device ID or fuses? Source: @cuddylac997, 2026-09-30
- Does the public 80 GB method fail because the geometry changes too late in startup, leaving early firmware state at 10 GB? ti's hypothesis, unproven. Source: @jovial_dolphin_29796, 2026-07-27
- gpu-unlock 3.0 applies the unlock from a standalone kernel module before the stock driver loads. Announced, no release date. Source: @zagitta, 2026-11-05
ECC
Long form: ECC, Memory errors and ECC.
ECC status: 8 GB enablement Proven; 10 GB enablement Reported, with GSP boot failures on some cards. Error correction remains Contested. The 2026-11-10 error-reduction result is one person's result on one 10 GB card and has not been independently repeated. Read the measurements and limits.
Evidence: lab enablement test 2026-10-19; 10 GB report 2026-11-10. Summary reviewed: 2026-11-10. A review is not a new hardware test. Source: @darkmaniac7, 2026-10-19 (lab notes) Source: repo github.com/AlexBrandes/cmpunlocker by AlexBrandes on GitHub
PR #68: the 10 GB ECC boot-failure proposal was closed without merging on 2026-11-10 UTC. Its proposed per-card opt-in remains fork work; this pull request did not change mainline. The reported hardware results still need independent confirmation. See the tested versions and card limits.
Upstream state checked: 2026-11-10. Hardware report date: 2026-11-10. Source: repo github.com/AlexBrandes/cmpunlocker by AlexBrandes on GitHub Source: repo github.com/amoghmunikote/cmpunlocker by amoghmunikote on GitHub
What is known
- Three patches.
ecc-enable.patchwrites the feature overrides (0x0082380c = 0x00999999,0x00823810 = 0x003ffebf,0x0082382c = 0x0000000f), the ECC control (0x009a0470 = 0x00000041) and LTCG dstcfg0 (0x0017e318 = 0x00000001);ecc-fbpa-static.patchforces the driver's per-FBPA ECC flag for both device IDs;ecc-reporting.patchwires the counters through. Source: repo github.com/amoghmunikote/cmpunlocker by amoghmunikote on GitHub - The bits flip. On one 8 GB card with three controls, all 14 protected writes landed,
FEATURE_READOUTwent from0x00000233to0xec8ff233,FBPA_ECC_CTRLfrom 0 to0x41, and a 60 GiB write and verify passed. That shows state, not correction. Source: @darkmaniac7, 2026-10-19 (lab notes) - ECC configuration uses feature overrides. The patches change override state while
OPT_ECC_ENstill reads 0 in the cited captures. This establishes configuration and readback, not successful error correction. Source: @darkmaniac7, 2026-10-21 (lab notes) Source: @k2v0008, 2026-08-03 - The HBM side. The mode-register write in the commit targets bits 1:0 (DM/ECC mode) of an HBM2e mode register; a Samsung HBM2 part may need a different configuration than an HBM2e part. Source: @zarquon3157, 2026-10-05
- 10 GB card. Pull request #68 reports that master runs the 8 GB sequence on every 10 GB card and that both of its author's 10 GB cards failed GSP boot with it; with a 10 GB order one booted with ECC and one still failed. It proposes ECC off by default there with a per-card opt-in. Current PR state: closed without merging on 2026-11-10 UTC; the proposed patch remains a reported experiment. Source: repo github.com/AlexBrandes/cmpunlocker by AlexBrandes on GitHub
- Row remapping (the A100's automatic HBM repair) is present but locked on the 170HX, per CUTE; his card-level fix is announced and unpublished. Source: @cute_sc2, 2026-08-29
Source: @cute_sc2, 2026-10-02
Row remapping and fault recovery
November 10 lab queries found RRL (InfoROM row-remapping table) metadata version 1.0 on all eight cards, exactly the version accepted by the installed GSP loader. Metadata availability is separate from initialization: 0x823828 bit0 is clear on all eight. The nearby 0x823824 reads 1 on three cards and 0 on five, so 1 alone is not evidence of an enabled gate. Its field encoding and a reversible activation sequence remain unresolved. The object-version query may read its backend and update metadata caches; it does not invoke the RRL loader. Source: @darkmaniac7, 2026-11-10 (lab notes)
Offline analysis shows that post-loader processing filters rows against current effective FBIO topology and performs a per-row command transaction. It is not passive table reading or an additional-partition enable route. GET_REMAPPED_ROWS rejects uninitialized state before fetching rows, so it does not expose the raw table beforehand. No remap-table update or row-remap hardware command was executed in this research pass. Source: @darkmaniac7, 2026-11-10 (lab notes)
The dedicated cached global-poison capability query returns disabled on every card. Public GA100 code uses that capability for dynamic page offlining and error containment. The recovered RmGlobalPoisonOverride routine ORs bits into a register, while recovery capability state is established during initialization. Restoring one register would not demonstrate restoration of driver and firmware state. ECC-enabled status, correction, row repair and fault containment remain separate claims. No recovery override or fault-injection test was performed. Source: @darkmaniac7, 2026-11-10 (lab notes)
Contested: does it correct?
- On a card with about 5,000 single-bit errors per 5-minute run, enabling ECC corrected none of them. Source: @zombielurker, 2026-10-05
- With ECC on, an unstable card crashes with an Xid instead of silently generating garbage. Source: @ichundes, 2026-10-07
- Pull request #68's data point: at an HBM clock of 1647 MHz on one 10 GB card, 2,025 to 2,229 errors per run with ECC off against 3, 6, 0 and 3 with ECC on. One card, one person. Source: repo github.com/AlexBrandes/cmpunlocker by AlexBrandes on GitHub
- "ECC enabled" also shows on unrelated cards after the unlock, which may be reporting only; the lab saw no counter move and no proof of correction. Source: @arabus_74064, 2026-10-05
Source: @darkmaniac7, 2026-10-21 (lab notes)
Contested 8 GB and 10 GB
Tried and failed
- Studebaker's July probe wrote an ECC-on value to
0x82380cand read it back, but the boot path revalidated the setting on each bootstrap and rejected it. The v0.5 sequence later got through. Source: @_studebaker_, 2026-07-29 - K2V flipped two registers and got an image full of ECC errors; an InfoROM swap did not help. Source: @k2v0008, 2026-08-08
- The Maxwell-era Quadro VBIOS trick: Dead ends: what was tried and did not work#ECC.
Open questions
- A fault-injection result. Zagitta says HBM ECC fault injection works in gpu-unlock 3.0, so correction can be checked; no result posted. Source: @zagitta, 2026-11-05
- A second 10 GB owner running pull request #68, and the 615.78.08 build on hardware. Source: repo github.com/AlexBrandes/cmpunlocker by AlexBrandes on GitHub
- A natural, repeatable single-bit fault re-tested under the ECC patch: see Memory errors and ECC for how to test real correction.
PCIe Gen2
Long form: Gen2 link retrain, Gen2 by platform.
What is known
- There is no physical Gen2 disable fuse. The enable overrides a fuse-derived default during bootstrap, which lets the link capability reach Gen2. Source: @djpandaman, 2026-10-09
- Two patches and a service.
pcie-gen2.patchwrites the link-rate and fuse-override settings,pcie-gen2-probe-retrain.patchhandles the retrain, and an early-boot service loops the link-control retrain to catch the window. With the patch,NV_XVE_FUSE_OVERRIDEreads0x6. Source: repo github.com/amoghmunikote/cmpunlocker by amoghmunikote on GitHub
Source: @darkmaniac7, 2026-10-18 (lab notes) RMPcieLinkSpeedbits 1:0: 0x1 enables Gen2, 0x2 disables it. Source: @meromgreen, 2026-07-29- Straps do nothing: the card's own controller rewrites the link, and there is no Gen3 override register of the same kind. Source: @samuel_hayden., 2026-07-26
Tried and failed
- Cards where the Gen2/3 override write is refused: the link capability stays at Gen1 (LnkCap
0x00456101), a write to the target link speed reverts at once, and the retrain service has nothing to retrain to. No fix was found. Source: @cibernox, 2026-09-12
Source: @honest_swan_40057, 2026-08-13
Open questions
- Why the same VBIOS (92.00.6D.00.0A) holds Gen2 on one owner's card with a 1536M carveout and refuses it on another's: does the carveout let the write through? Asked, never confirmed. Source: @honest_swan_40057, 2026-08-13
PCIe Gen3 and Gen4
Long form: PCIe Gen3 on the 10 GB card.
What is known
- Gen3 and Gen4 are real fuses. Three registers read 1 on every stock card of both kinds (
0x820250,0x82057c,0x820580); Gen4 has its own disable bit, and Amogh counted four fuses for Gen4 against one for Gen3. Source: @djpandaman, 2026-10-08
Source: @darkshad03, 2026-10-04
Source: @_j3ns, 2026-09-06 - The 10 GB route (after the RIR burn): a probe-time software fuse override (
EN_SW_OVERRIDE 0x00820040, then clear0x00820250bit 0 and0x00820580bit 0), a Gen3 register block after GSP boot, and a Gen1 to Gen2 to Gen3 retrain through the RM controlNV2080_CTRL_CMD_BUS_SET_PCIE_SPEED. OnlyLnkSta: Speed 8GT/scounts as success. Source: @lxtend, 2026-10-12
Source: repo github.com/lixiangwuxian/170hx_tips by lixiangwuxian on GitHub
Source: repo github.com/evanrodgers/cmp-170hx-rir-burn-util by evanrodgers on GitHub - Gen4 was validated by mrpandagod behind a PLX switch; without the capacitor mod it falls back to 8 GT/s. Source: @djpandaman, 2026-10-09
Source: @djpandaman, 2026-10-08 - 8 GB card. The recipe checks
0x820084bit 0 first and stops when it is set, and it is set. On some cards (Humvee55: about 1 in 20, later 5 to 10 %) the remaining factory RIR record could be redirected to void the Gen3-disable row, once; CUTE advises against it because it could make later unlocks harder. Source: @darkmaniac7, 2026-10-21 (lab notes)
Source: @scallion_9883, 2026-10-01
Source: @cute_sc2, 2026-09-24
Tried and failed
- The VBIOS route: the bits that need to change are signature enforced. Source: @_j3ns, 2026-08-05
- Warning A blind Gen3 retrain while the capability reports Gen2 takes the card off the bus (BAR0 unmaps). Pull request #37's retrain did this on a lab card, a PCI rescan hung, and recovery needed a chassis power cycle; the pull request was closed unmerged. Source: @djpandaman, 2026-09-24
Source: @darkmaniac7, 2026-10-14 (lab notes) - Warning Forcing Gen3 through the XP and XVE registers on an 8 GB card (one card, one try): 8 of 9 writes took, the link-control target of 3 was refused, and the card sat at Gen1 x8 until a power cycle. Source: @darkmaniac7, 2026-10-21 (lab notes)
- The Gen3 branch kernel oops: the retrain code mapped
0x90000bytes of BAR0 and then read offset0x820250. Map0x1000000. Source: @ins_mniac, 2026-09-06
Open questions
- Any 8 GB route that does not spend the last record. CUTE (2026-11-05): nothing out yet, some good leads, nothing noteworthy. Source: @cute_sc2, 2026-11-05
- A Gen4 report on a Gen4 host, not behind a switch.
NVLink
Long form: NVLink.
What is known
- Three blockers. A fuse (
OPT_NVLINK_DISABLEreads0x2on a stock 10 GB probe); a VBIOS without the bootstrap image for the on-die link-training microcontrollers; and missing board parts (termination resistors, and U11, the bridge clock generator GS7612S5MA-R, unpopulated). Source: @darkshad03, 2026-10-04
Source: @djpandaman, 2026-10-05
Source: @onemillionkates, 2026-10-05
Source: @_orrorin, 2026-10-12 - The connector pins are populated and reach the core on the eight cards CUTE measured. Source: @cute_sc2, 2026-10-05
- 10 GB hardware rework. GhostInTheDatacenter fitted the missing parts on a 10 GB card and wrote "From everything I see, I have it NVLink unlocked"; no trained link yet. Parts he named: GS7612S5MA-R (the schematic part) and AP22811AW5-7 for the 3.3 V rail; AP2151WGDICT is the wrong equivalent. On 2026-11-07 he was waiting on the last replacement part. Source: @ghostinthedatacenter_87281, 2026-10-30
Source: @ghostinthedatacenter_87281, 2026-11-05
Source: @ghostinthedatacenter_87281, 2026-11-07 - 10 GB software side. mrpandagod: unlocked "in software. hardware part still needs to be tested", and only for the 10 GB card. Not public. Source: @djpandaman, 2026-10-28
- CUTE's separate lead: first indications point to "uninitialized silicon, but active". Source: @cute_sc2, 2026-10-30
- 8 GB card: no path; the rework alone is not enough because enabling it also takes several unlocks. Source: @lia_oc, 2026-10-22
Source: @ghostinthedatacenter_87281, 2026-10-28
Contested
- Is the VBIOS signed? CUTE: yes, checked at load, and a failing image is refused. mrpandagod: the missing image "lacks SCP", so it could be injected. Source: @cute_sc2, 2026-09-16
Source: @djpandaman, 2026-10-05
Contested 8 GB and 10 GB
Tried and failed
- The first bridge test on two cards (2026-09-22): nothing enumerated. Source: @onemillionkates, 2026-09-23
- Reading the boot-log NVLink line as links coming up: Dead ends: what was tried and did not work#NVLink.
Open questions
- The first trained link on a reworked 10 GB card, then a second builder: board card T-301.
- A bill of materials: Ghost said he will document one if it works. Source: @ghostinthedatacenter_87281, 2026-10-24
VBIOS and loaders
Long form: VBIOS and firmware, Flashing the 300 W VBIOS, P-states and idle power.
What is known
- Why driver-loaded overrides work (Petri Krohn's model, background, not a measurement): the driver loads firmware into the card's microcontrollers, the data sections are cleartext, and the boot ROM only checks the ROM copy at power-up. Source: @petrikrohn_26497, 2026-10-20
- The vix loaders (Panchovix) start GSP with an override image held in memory; the flash chip is never written. Their device table has no 170HX entry and GA100 firmware is outside their audit. lxwx reports the Linux loader working on a 10 GB card for a 300 W limit. Source: repo github.com/Panchovix/nvidia-linux-vbios-vix-loader by Panchovix on GitHub
Source: @lxtend, 2026-10-20 - The 300 W power-limit bytes sit outside the signed section. Source: @xanthefin, 2026-10-18
- 6D behaviour without flashing (wanghar/cmp170hx-6d-VBIOS-upgrade, verified on one card): clee calls it "a method of booting the 6D VBIOS image without having to flash it". Source: @c133, 2026-11-07
- P-states. Humvee55: the 170HX has a single P-state; a P-state transplant works and can override VF offsets. Zagitta: the PMU halts after startup on the CMP, so P-states alone save nothing. Source: @scallion_9883, 2026-11-06
Source: @scallion_9883, 2026-11-06
Source: @zagitta, 2026-11-06
Tried and failed
- A modified or re-signed image. Amogh worked on a custom VBIOS in August, said he would not publish re-signing steps, and dropped the route on 2026-08-23. This page carries no signing detail either. Source: @_j3ns, 2026-08-07
Source: @_j3ns, 2026-08-23 - Cross-flashing an A100 image, and the "64 GB unlocked VBIOS" files: VBIOS and firmware#Why custom images do not boot, Dead ends: what was tried and did not work#VBIOS and flashing.
What cmpunlocker and its forks do
Long form: Driver unlock, cmpunlocker forks, P2P, Resizable BAR and BAR1 64 GB.
- Mainline (amoghmunikote/cmpunlocker) is 14 source patches to NVIDIA's open kernel modules, applied in a fixed order: sec2-postbl-plm-ss-cfg (opens the privilege masks, writes SS0, SS1 and the geometry), booter-verify, late-pma (hands the memory above the stock size to the allocator), bar0-pramin-clamp (keeps the CPU window into VRAM inside the first 8 GiB), ce-scrub-workarounds, persistent-sw-state, pcie-gen2, pcie-gen2-probe-retrain, name-string, bar1-resize-unlock, cmp-sku-mask, ecc-enable, ecc-fbpa-static, ecc-reporting. Every patch is gated on the two 170HX device IDs. Source: repo github.com/amoghmunikote/cmpunlocker by amoghmunikote on GitHub
Source: repo github.com/Consensus-Protocol/cmp170hx by Consensus-Protocol on GitHub - What master does not do (2026-10-27): Gen3 or Gen4, the 10 GB card past 40 GB, more than 74 SMs, NVLink. Source: @lia_oc, 2026-10-22
- Morrowmake: adds mailbox P2P by opening the trap 31 PLM through the boot path only when
ForceP2Pis set; master drops the ECC patches, thep2p-eccbranch carries both. Source: @mountains1605, 2026-10-20
Source: @darkmaniac7, 2026-10-27 (lab notes) - vektorprime (branch
fbpa-pll-170tune) and akumaburn/cmpunlocker2: the FBPA PLL and memory privilege-mask opens that 170tune needs. Source: @vektor_prime, 2026-10-07
Source: @phoenixone7, 2026-09-17 - asm64-hooligan: one-file unlock on 610.43.0x with a compile-time HBM clock (
--mclk-ndiv), DRAM timing scaling and mailbox P2P in a 512 KB window; no ECC. Source: @c133, 2026-10-22 - AlexBrandes (branch
ecc-10gb-opt-in, pull request #68) and duckblaster (a kernel 7 build patch): the two newest forks. Source: repo github.com/AlexBrandes/cmpunlocker by AlexBrandes on GitHub
Source: repo github.com/duckblaster/cmpunlocker by duckblaster on GitHub - The leaked unlocker writes the PLM table exactly as cmpunlocker does and unlocks nothing extra. Source: @lxtend, 2026-07-22
- gpu-unlock (Zagitta): a standalone kernel module that unlocks before the stock driver loads; version 3.0 with CMP support is announced, not released. Source: @zagitta, 2026-11-05
The fork-by-fork table (drivers, ECC, P2P path, last commit) is on cmpunlocker forks#Fork comparison.
How to contribute a finding
- State the evidence level. Separate live observation, source analysis, synthetic fixture and hypothesis. For reverse engineering, pin the exact driver/firmware hash and chip dispatch. For an unlock, show effective topology, distinct physical storage or working units, and sustained correctness/performance; a register readback or enumeration screenshot alone is insufficient.
- Post it on the cmpunlocker Discord first, with the card (
10de:20c2or10de:2082), the VBIOS, the driver and unlock build, the exact command or register, and the value before and after. A read that differs from the register map above is a finding. - Then put it here. Sign in with Discord (see Contributing), edit the section for the target, and end the fact with a status badge and
{{Source|handle=you|date=the date|link=your Discord message link}}. Statuses are on Status taxonomy; Proven is never typed by hand on an unlock. - A new unlock gets its own page through the Add an unlock box on Unlocks; a reproduction of someone else's result is a confirmation on that page.
- Open questions and tests go on the board: the Dev and research project on the board (how it works: Board how-to).
- Do not paste someone else's long write-up or private notes. Link the Discord message and summarise. No card serial numbers, no keys, no signing material.
Related
Unlocks, Driver unlock, cmpunlocker forks, Fuses and floorsweep maps, Floorsweep read of the 8 GB card: gated versus defective partitions, RIR fuse burn, Full SM unlock, Memory unlock on the 10 GB card, The 10 GB card: provenance and the 80 GB question, ECC, Memory errors and ECC, Gen2 link retrain, PCIe Gen3 on the 10 GB card, NVLink, VBIOS and firmware, Flashing the 300 W VBIOS, 170tune, gpcprobe, 170hx-rir-tool, Driver and unlock failures, Verifying an unlock, Dead ends: what was tried and did not work, Rumours and claims to verify, Unlock history: who found what, and when.