Fuses and floorsweep maps

Every CMP 170HX carries a full GA100 die with parts of it switched off at the factory. The switches are fuses: one-time-programmable bits on the die that disable GPCs (graphics processing clusters, which hold the TPCs and SMs), FBPs and FBPAs (the frame buffer partitions behind the HBM stacks) and features such as PCIe Gen3, NVLink and ECC. The pattern of what is switched off on one card is its floorsweep map. This page covers how to read your own card's map with read-only tools, the fuse model as the community understands it, what the census of many cards found for memory and compute, the RIR records that separate the 8 GB card from the 10 GB card, and what the fuses do and do not let anyone change. Reading fuses with the tools below is safe. Writing fuses is permanent and can brick a card: the one fuse write in use, on the 10 GB card only, is on RIR fuse burn, and the SM unlock is on Full SM unlock.

Read your card's map

gpcprobe reads the GPC, FBP and FBPA fuses without writing anything

matstatman/gpcprobe is a small Linux kernel module plus a Python script. The module maps the first 16 MiB of each NVIDIA card's BAR0 while the NVIDIA driver stays bound, finds up to 16 cards, and only reads: it never writes, never unbinds the driver and needs no reboot. The script prints per card the GPC, FBP, FBPA and FBIO disable and defective masks with active counts, the SM count, the NVLink, PCIe and ECC fuses, and from 2026-09-18 a per-HBM-stack view (which FBPs and FBPAs feed each stack, dies, exposed and maximum GiB). To run it (root needed; rebuild after every kernel upgrade):

1. Install the headers for the running kernel: sudo apt install linux-headers-$(uname -r).
2. Clone the repository and build the module: make.
3. Load it: sudo insmod gpcprobe.ko.
4. Read the fuses: sudo python3 gpc_probe.py.
5. Unload it: sudo rmmod gpcprobe.

On the author's two 8 GB cards it reads FBPs 1, 4, 6 and 11 disabled (6 and 11 physically dead, 1 and 4 only floorswept), 16 of 24 FBPAs active (a 4096-bit bus: 2 full and 4 half stacks), NVLink fused off and both Gen3 fuses set; the GPC fuses differ per die. Its capacity model: stock 8 GiB is 16 FBPAs x 512 MiB, 64 GiB is the same 16 FBPAs x 4 GiB, and 96 GiB would need all 48 die slots; the 10 GB card (10de:2082) is 20 of 24 FBPAs, a 5120-bit bus with 1 GiB dies and a 48 GiB ceiling. matstatman started it on 2026-09-17 ("My kernal module for GPC floorsweep"), written with Qwen 3.8 running on a 170HX; Waka324 later posted a userspace variant (rbray89 gist) for systems that allow direct register access. jjb found an integer bug in the module's read call that can oops the kernel for offsets near 4 GiB; low severity, root only, the script never sends such offsets, and a fix was opened as a pull request. The repository has no LICENSE file; gpcprobe.c is marked GPL-2.0. More on the tool: Gpcprobe.

Proven 8 GB and 10 GB
Source: repo github.com/matstatman/gpcprobe by matstatman on GitHub
Source: @cmdrwaka324, 2026-09-17
Source: @matstatman, 2026-09-17
Source: @dufrelic, 2026-09-17
Source: @matstatman, 2026-09-17
Source: @wakeupmbrc1, 2026-09-17
Source: @deaddudehangin, 2026-09-18
Source: @matstatman, 2026-09-18
Source: @jjb01957, 2026-09-18
Source: @okrasit., 2026-09-18
Source: @con3po7016, 2026-09-23
Source: @cute_sc2, 2026-09-26
Source: @reggie7756, 2026-09-26
Source: @jjb01957, 2026-09-27
Source: @cmdrwaka324, 2026-09-29
Source: @globalapathy, 2026-10-01
Source: @matstatman, 2026-10-09
Source: @n2dcrypt, 2026-10-09
Source: @globalapathy, 2026-10-09
Source: @newman_08462, 2026-10-09
Source: @matstatman, 2026-10-09
Source: @globalapathy, 2026-10-09

Example gpc_probe.py output from an 8 GB card

GlobalApathy posted the output of sudo python3 gpc_probe.py for one 8 GB card on 2026-10-01. Use it as a reference for what the probe prints:

Fuse	Value	Bits set	Active
OPT_GPC_DISABLE	0x00000045	0, 2, 6	5 of 8
OPT_GPC_DEFECTIVE	0x00000000	none	8 of 8
OPT_FBP_DISABLE	0x00000852	1, 4, 6, 11	8 of 12
OPT_FBP_DEFECTIVE	0x00000840	6, 11	10 of 12
OPT_FBPA_DISABLE and OPT_FBIO_DISABLE	0x00c0330c	2, 3, 8, 9, 12, 13, 22, 23	16 of 24
OPT_FBPA_DEFECTIVE and OPT_FBIO_DEFECTIVE	0x00c03000	12, 13, 22, 23	20 of 24

So GPCs 0, 2 and 6 are disabled but not defective, and FBPs 1 and 4 are disabled but not defective. He described the card as having "a couple defective memory partitions".

Reported 8 GB
Source: @globalapathy, 2026-10-01

gpcprobe on 10 GB cards: GPC 5 healthy, 3 disabled, 0 or 1 defective; FBP 10, 2, 2

On 2026-09-30 Lycorascence posted the "Misc fuses" block of gpcprobe from his 10 GB card: spare floorsweep, FB config and half-FBPA fuses all clear (everything active), the ECC fuse FUSE_ECC_EN clear, and the secure-GSP-debug-disable and display-status fuses set. On 2026-10-07 GhostInTheDatacenter ran gpcprobe on a 10 GB card reported as "NVIDIA CMP 170HX 40 GiB": GPC healthy 5, disabled 3, defective 1; FBP healthy 10, disabled 2, defective 2. matstatman: 1 defective GPC is pretty good, 0 defective is "god mode". Two days later Ghost found two 10 GB cards with GPC 5/3/0 and FBP 10/2/2, the best he could source. These counts are what buyers were checking before paying.

Reported 10 GB
Source: @lycorascence, 2026-09-30
Source: @ghostinthedatacenter_87281, 2026-10-07
Source: @matstatman, 2026-10-07

Reading the output: "disabled" already includes "defective"

Civiloid corrected a thread on 2026-09-18: in probe output "disabled" already includes "defective", so do not add the two ("you probably counted total as health + disabled + defective"). The full GA100 has 8 GPCs and 128 SMs, not 9 GPCs. Defective SMs can exist inside GPCs that are not defective. cibernox noted that one defective GPC would leave the A100's 108 SMs if everything else were unlocked; Miséricorde noted that zero defective would mean a full GA100.

Reported 8 GB and 10 GB
Source: @civiloid, 2026-09-18
Source: @cibernox, 2026-09-18
Source: @wakeupmbrc1, 2026-09-18

mfj4's read-only GPC probe

On 2026-09-17 mfj4 posted a Python script that reads BAR0 read-only through the card's sysfs resource0 (root needed) and decodes the GPC disable and GPC defective fuses into disabled clusters, defective clusters and "disabled but not defective". You edit its card list to your own PCI addresses from lspci | grep -i nvidia. It never writes to BAR0. It was the first community fuse census tool; gpcprobe appeared the same day. Pointer: the script itself is in the Discord post linked below and is not re-hosted here until the author agrees.

Proven 8 GB and 10 GB
Source: @mfj4, 2026-09-17
Source: @dottoreargus, 2026-09-17

The older register-probe script and the defective rule

An older read-only script, found in June via Petri Krohn and reshared by mrpandagod (Discord), reports which GPCs and FBs are marked defective and which are merely disabled. CUTE said on 2026-09-09 that you can read a card and see whether SMs or HBM stacks are defective or just disabled, on the 10 GB card too. In the same thread Humvee55 described the 10 GB card as 5 stacks, "40gb - 48 if 6th stack is not marked defective". mrpandagod (2026-10-17): "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". Zagitta read the GPC defective fuse as 0 on his card. mrpandagod added that the same register carries a Gen3 disable bit, but that bit alone did not enable Gen3. Feralzi: an 8 GB card can read 96 GB but crashes when the dead dies are touched; the fifth and sixth stacks cannot be enabled on the 8 GB card today.

Reported 8 GB and 10 GB
Source: @scallion_9883, 2026-09-09
Source: @cute_sc2, 2026-09-09
Source: @djpandaman, 2026-10-17
Source: @xanthefin, 2026-10-17
Source: @zagitta, 2026-10-17
Source: @shirogeek, 2026-10-17
Source: @feralzi, 2026-10-17

Two readings of OPT_FBPA_DISABLE 0x00c0330c

The value on most 8 GB cards, in the order the readings were posted:

• Petri Krohn (2026-09-10) read 0x00c0330c, the value on Newman's 8 GB cards, in binary as 6 disabled FBPs spread over 6 HBM2 stacks. Source: @petrikrohn_26497, 2026-09-10
• gpcprobe decodes the same value as 16 of 24 FBPAs active (2 full and 4 half stacks), with OPT_FBP_DISABLE 0x852 meaning FBPs 1, 4, 6 and 11 off. Source: repo github.com/matstatman/gpcprobe by matstatman on GitHub

Contested 8 GB

Humvee55's probe.sh and fuses gist

Humvee55 maintains probe.sh, which pulls fuse values and VBIOS data from a running card; nvflash alone is enough for the VBIOS dump. On 2026-07-22 the current probe.sh lived in JRex286's fork of Humvee55's fuses gist (gist, probe.sh), which also holds a GA100 VBIOS comparison table: CMP 170HX against A100 PCIe against DRIVE A100. Humvee55 stressed that the compute override is set in the fuses, not the VBIOS ("will need the fuses to see compute override. it lives in fuses, not vbios"), so fuse dumps are what you need to study it. He offered a more robust private script on request.

Reported 8 GB and 10 GB
Source: @scallion_9883, 2026-07-22
Source: @serplay228, 2026-07-22

A script that reads the Gen3 disable fuse

On 2026-09-29 mrpandagod posted a read-only Python script that reads the Gen3 speed-disable fuse (OPT_DISABLE_GEN3_SPEED) through sysfs and checks one bit: 0 means the fuse is unblown and Gen3 could be enabled in software ("STATUS: FUSE UNBLOWN!"), 1 means it is blown and the card is clamped to Gen2. Find the card with lspci -d 10de:. He said it should run on a stock card without the unlocker. Lycorascence (10 GB) got "OSError: [Errno 22] Invalid argument" at the memory map, and mrpandagod said he would re-test on his 8 GB card; not verified working in this period. A later read-only lab snapshot found the fuse set (1) on four production 8 GB cards; see PCIe Gen3 on the 10 GB card for what that means.

Reported 8 GB and 10 GB
Source: @djpandaman, 2026-09-29
Source: @lycorascence, 2026-09-29
Source: @darkmaniac7, 2026-10-18 (lab notes)

Reading the per-FBPA memory configuration (CSTATUS)

The two positions, in the order posted:

• insomniac (2026-09-03) posted a ChatGPT-suggested read-only check: read the memory-amount status (CSTATUS_RAMAMOUNT) of each of the 24 FBPAs from BAR0 and count the values. 0x00000800 means CMP-style 2 GiB per FBPA, 0x000007FF A100 or DRIVE-style about 2 GiB, 0x00001000 CMP-style 4 GiB, and 0xBADFxxxx a disabled or floorswept FBPA. On tony's 32 GB card 16 FBPAs read 0x00000800 and 8 read 0xBADFxxxx (32 GB cards (subsystem 10de:1586)). Source: @ins_mniac, 2026-09-03
  Source: @tony_smartecom, 2026-09-03
• The upstream cmpunlocker commit a3ea84b measured that this status register is derived from CFG1 (512 MB per FBPA native, 2048 at the unlock CFG1), so the value reflects the programmed configuration and does not by itself prove what memory is physically present. Source: repo github.com/amoghmunikote/cmpunlocker by amoghmunikote on GitHub

Contested 8 GB and 10 GB

Register names people compare between an A100 and a 170HX

On 2026-07-27 gk_hun asked owners for dumps of the fuse registers for the device ID (DEVIDA, DEVIDB) and its software-override disable (DEVID_SW_OVR_DIS), the PCIe generation fuses (GEN23_DIS, GEN3_DIS), the software-override enable and disable (EN_SW_OVERRIDE, DIS_SW_OVR), the feature-override disable (FEAT_OVR_DIS), and the HBM CFG1 and CSTATUS registers per FBPA. Samuel Hayden answered with a CSV (reg-ref-a100-vs-170hx.csv) comparing them on a live A100 and on his native 8 GB card (10de:20c2) with an untouched VBIOS; he did not yet have the full FBPA set. The CSV is an attachment in the thread and was not read for this page.

Reported 8 GB and 10 GB
Source: @gk_hun, 2026-07-27
Source: @samuel_hayden., 2026-07-27

The fuse model

GA100 fuse basics: a 512 x 32 array and an encrypted map

Petri Krohn (2026-09-25): the 170HX limits are implemented both in firmware and in one-time-programmable fuses on the die. The firmware limits are mostly overcome; the fused limits remain, and newer results were under a 30-day embargo. The GA100 fuse array is 512 rows of 32 fuses. The mapping from row and offset to meaning is indirect and sits in an encrypted NVIDIA file, but dumping fuse maps from several cards and comparing them can reconstruct parts of it. There are hardware and software ways to override blown fuses, and the software paths depend on hardware paths being open. He said the 8 GB card is harder to unlock than the 10 GB card, and that the GV100 (CMP 100-210) fuse mapping has been decrypted in duggasco/CMP100-210.

Reported 8 GB and 10 GB
Source: @petrikrohn_26497, 2026-09-25

OTP fuses, resettable fuses and RIR masking

CUTE described the GA100 fuse model: OTP fuses burn once and never reset, while "fuseless" fuses can be reset. Most A100 fuses are fuseless. An OTP fuse can be masked with an RIR record (Redundant Information Row) that overrides its original value. Masking the "software override disable" fuse makes the fuseless fuses writable again, which is how features gated by them (SMs, PCIe 4.0, NVLink, memory) can be enabled; disabled memory also sits behind soft fuses. mrpandagod put it this way: board fuses are "blown" (OTP, irreversible) but mostly gate logic rather than destroy function, so the workarounds manipulate the read value or get around the gating downstream; he cited the original 64 GB unlock as a bypassed clamp. Lycorascence warned that general chatbots give wrong answers about this card (one asker quoted Gemini saying e-fuses cannot be circumvented).

Proven 8 GB and 10 GB
Source: @djpandaman, 2026-09-24
Source: @ins_mniac, 2026-09-24
Source: @lycorascence, 2026-09-30
Source: @cute_sc2, 2026-09-30

Fuseless Fuse rows and the 16 RIR records (pointer)

A longer explainer by @petrikrohn_26497 (Petri Krohn) of how the GA100 fuse array, its Fuseless Fuse (FF) rows and its 16 RIR records fit together, with additions by @jjb01957 (jjb) and @teabox6792 (taebox), exists; see Discord. (Pointer: the explainer waits for the author before the wiki uses it as its fuse model, since fuse work is permanent.) Source: @petrikrohn_26497, 2026-10-01
Source: @jjb01957, 2026-10-01
Source: @teabox6792, 2026-10-01

Fuses, not the VBIOS, define the SKU

AKuchen (2026-08-24): "The burned fuses detemrine the SKU and the SKU determines the registers and capabilities". Flashing even an A100 VBIOS only affects the unsigned areas of the flash, so the VBIOS does not unlock anything, and the BIOS has no influence on the device-ID-driven fuses; the relevant registers exist on the CMP 170HX but the fuses prevent them from being read. meatsus: the only reason a VBIOS would not transfer from a Chinese-unlocked card is if a new device ID had been fused. Dino asked whether a fuse change would allow flashing the A100 VBIOS without the signing key; Amogh said "Technically, it does but it's not just a simple re-fuse", and that he had not tried a fuse burn. More on firmware: VBIOS and firmware.

Theory
Source: @akuchen_66498, 2026-08-24
Source: @meatsus, 2026-08-24
Source: @dino_38975, 2026-08-24
Source: @_j3ns, 2026-08-24
Source: @benesmann123, 2026-08-24

Active, disabled and defective

On 2026-09-04 CUTE relayed a hint that NVIDIA marks each SM, ROP or HBM die as active, disabled (off but functional) or defective (permanent), and that disabled units could in theory be re-enabled with a custom signed VBIOS or a way around the fuses. On 2026-09-16 DaLZy asked whether CUTE's cards had all 4 FBPs marked "disabled", and CUTE confirmed "just disabled, not defective"; DaLZy's own card shows 2 FBPs as defective. Miséricorde posted screenshots asking whether people understood the two terms, and Josh linked the earlier discussion. On 2026-09-26 CUTE said units marked defective are actually defective while units marked disabled are fully working, that binning happens before a die is assigned to a product, and that forcing a defective unit on risks a brick that cannot be recovered; regaly countered that some units may be disabled only to meet supply. The fuse state differs from card to card, which matters for how much memory could ever be recovered.

Reported 8 GB and 10 GB
Source: @reggie7756, 2026-09-04
Source: @_maitops, 2026-09-04
Source: @cute_sc2, 2026-09-04
Source: @dalzyyy, 2026-09-16
Source: @cute_sc2, 2026-09-16
Source: @wakeupmbrc1, 2026-09-16
Source: @_____josh_____, 2026-09-16
Source: @reggie7756, 2026-09-26
Source: @cute_sc2, 2026-09-26

Are "disabled" units fully working?

The positions, in the order posted (2026-09-16). Nobody tested "disabled" units under sustained load in this exchange.

• CUTE: a card's config fuses can be read and show whether a unit is defective or merely disabled. Most of his 8 GB cards report all 6 HBM dies with full stacks present, just deactivated; on 21 of 21 cards "80/96gb of hbm" read as working and every card shows over 100 SMs (the cards expose 70 in use). He concluded that most if not all CMP 170HX are fully working A100s that were nerfed, and that the fuses are mainly market segmentation: non-working SMs or memory are fused off as "defective", working ones as "disabled". Source: @cute_sc2, 2026-09-16
  Source: @cute_sc2, 2026-09-16
• quark2world: with no NVLink, nerfed PCIe and nerfed cores it is "still an A66"; segmond said reality says otherwise. Source: @quark2world, 2026-09-16
  Source: @segmond, 2026-09-16
• Josh: the fuses exist to keep users away from genuinely bad silicon (imperfect COVID-era bins, possibly about 50% yield). Source: @_____josh_____, 2026-09-16
• DaLZy: 50% yield on TSMC 7 nm in 2020 is not credible; the fuses serve price discrimination. Source: @dalzyyy, 2026-09-16

Contested 8 GB

Every GA100 has some memory disabled (theory)

mrpandagod (2026-09-28): every GA100 card, from the CMP 170HX 10 GB to the A100 80GB, has some memory disabled. Disabled units fall into several categories: broken or defective, physically off, gated by one of about three fuse mechanisms (whether a unit can be unlocked depends on what the fuse gates and whether it is writable or signed), and fused off. Con3po's simpler framing: "disabled" parts might be unlocked, "defective" ones are just broken. mrpandagod called NVLink pairing the realistic route to a working 80 or 128 GB.

Theory 8 GB and 10 GB
Source: @djpandaman, 2026-09-28
Source: @con3po7016, 2026-09-28

Are PCIe Gen3/Gen4, ECC and NVLink fused off?

Naturidride asked on 2026-09-13 whether PCIe 3.0/4.0, ECC and NVLink each have their own fuse, so that a proper unlock could never be software-only. honzapat_CZ: fuses work the other way round; a fully capable A100 die is binned and limiting fuses are burnt into it. GalyGames: the fuses are inside the die itself, not a removable part on the board. Con3po answered "Yes". No test or evidence was posted in that thread. Later read-only register work answered it: PCIe Gen3/Gen4, NVLink and ECC each have their own fuse, and all read as fused off on production cards; see PCIe Gen3 on the 10 GB card, NVLink and ECC.

Theory
Source: @darcidride, 2026-09-13
Source: @honzapat_cz, 2026-09-13
Source: @galygious, 2026-09-13
Source: @con3po7016, 2026-09-13
Source: @darkmaniac7, 2026-10-21 (lab notes)

Fused quality class: leaky part (1/4)

matstatman posted on 2026-09-26 a readout from his 170HX showing NVIDIA's fused quality classification of the GPU: "Indicate the exact quality level of GPU: leaky part (1/4)". The message did not name the tool or the register.

Reported
Source: @matstatman, 2026-09-26

Memory: the FBP and FBPA census

The 8 GB memory floorsweep is the same on every card

On 8 GB cards the memory fuses read the same on every card checked, so the 64 GB layout is the SKU definition rather than per-die binning. Con3po read eight cards (from eBay and a server) with gpcprobe on 2026-09-22: on all eight OPT_FBP_DISABLE is 0x852 (FBPs 1, 4, 6, 11), OPT_FBP_DEFECTIVE 0x840 (FBPs 6 and 11) and OPT_FBPA_DISABLE 0x00c0330c, which is 16 of 24 FBPAs, a 4096-bit bus and 64 GiB of a 96 GiB die; every card had 3 GPCs disabled and 70 SMs. The same pattern shows on the tool author's cards and 15 reference cards. The 2026-09-17 census agrees: cibernox's card had FBPs {1, 4, 6, 11} swept with only {6, 11} defective, matstatman's two cards and three of jjb's four had 4 FBPs disabled with 2 defective, and one of jjb's had all 4 defective. Two defective FBPs (one stack) leave a theoretical 80 GB; four leave no extra memory. The FBPA and FBIO defective fuses show bits 12, 13, 22 and 23 on several cards, GlobalApathy's readout of 2026-10-01 included; Miséricorde, who has the same bits, thinks they are not really defective. N2DCRYPT's per-die reading: dies 1 and 4 fully enabled, dies 0 and 2 half enabled and half disabled, dies 3 and 5 half enabled and half defective. Newman's eight-card dump (all eight at 65536 MiB, Gen2 x4, 1890 MHz maximum SM clock) and Mountains' cards also show FBPs 6 and 11 defective. Petri Krohn doubted that almost every card really has those two dead ("this cannot be true", most likely two stages of disabling), and DaLZy relayed that the flags may be the BIOS "spitting nonsense". On the 10 GB card bigfoot found exactly 2 defective FBPs on all six of his cards. The lab's eight-card gpcprobe census: six cards share the stock sweep (FBPs 1, 4, 6, 11 disabled with 6 and 11 defective, FBPAs 12, 13, 22, 23 defective, one of them also with GPC7 defective); two cards show FBPs 0, 2, 3, 5 disabled, each with one dead HBM stack (one with FBP2 defective and FBP3 disabled, the other with FBP0 and FBP3 defective, FBPAs 0, 1, 6, 7 defective and GPC5 defective). Two further lab cards read FBP disable 0x2d with FBP defective 0x24 (FBPs 2 and 5), and 0x852 with 0x840 (FBPs 6 and 11).

Proven 8 GB and 10 GB
Source: @cibernox, 2026-09-17
Source: @matstatman, 2026-09-17
Source: @jjb01957, 2026-09-17
Source: @wakeupmbrc1, 2026-09-17
Source: @civiloid, 2026-09-17
Source: @con3po7016, 2026-09-23
Source: @matstatman, 2026-09-23
Source: @globalapathy, 2026-10-01
Source: @cute_sc2, 2026-10-01
Source: @voidgiraffe, 2026-10-01
Source: @exile_1ck, 2026-10-01
Source: @djpandaman, 2026-10-01
Source: @matstatman, 2026-10-01
Source: @bigfoot1144, 2026-10-09
Source: @n2dcrypt, 2026-10-09
Source: @petrikrohn_26497, 2026-10-09
Source: @newman_08462, 2026-10-09
Source: @mountains1605, 2026-10-09
Source: @dalzyyy, 2026-10-09
Source: @darkmaniac7, 2026-10-22 (lab notes)
Source: @darkmaniac7, 2026-10-27 (lab notes)

Early claim: no defects is typical for 8 GB cards

The two readings, in the order posted:

• 2026-08-27: MaitOPS's first card showed no defective GPC or FBP, and Petri Krohn said "No defects is typical for 8GB cards"; the open problem, he said, is enabling the good but disabled GPCs and FBPs. Gadfly said he was working on the rest of the memory, NVLink and INT8 compute and expected it to be tough; bassRAWR expected prices to rise if anyone unlocked the remaining memory. Source: @_maitops, 2026-08-27
  Source: @petrikrohn_26497, 2026-08-27
  Source: @gadfly3121, 2026-08-27
  Source: @bassrawr, 2026-08-27
• September census: FBP defective bits 6 and 11 were set on every 8 GB card read, while most GPCs were disabled rather than defective (section above). Source: @cibernox, 2026-09-17
  Source: @con3po7016, 2026-09-23

Contested 8 GB

gpcprobe fleet results and the FBPA-to-site map

The positions, all posted on 2026-09-28:

• Zarquon: gpcprobe probably needs a different FBPA-to-site map, and suggested [0,0,1,1,0,0,2,2,1,1,2,2,4,4,3,3,5,5,3,3,5,5,4,4]; matstatman agreed the script has shortcomings. Source: @zarquon3157, 2026-09-28
  Source: @matstatman, 2026-09-28
• replacedriver47's results: 3 cards with 80 GB of non-defective memory and 1 with possibly 64 GB; 3 cards with zero compute defects and 1 with one defective GPC. cibernox: all his cards show 16 GB defective (80 GB maximum in theory), and all but one have 1 defective SM cluster (108 SMs maximum), while the one with none could have 128. Source: @replacedriver47, 2026-09-28
  Source: @cibernox, 2026-09-28
• N2DCRYPT: every card reports the same disabled and defective HBM partitions, which points either to a script error or to a fixed rule applied to all cards. Source: @n2dcrypt, 2026-09-28

Contested

Which FBP belongs to which HBM stack

The two positions, in the order posted (2026-09-28):

• GlobalApathy posted an AI explanation of a memory-layout table from a tool's output: stack 0 = FBPs 0 and 1 (half, FBP1 disabled); stack 1 = FBPs 2 and 3 (full); stack 2 = FBPs 4 and 5 (half, FBP4 disabled); stack 3 = FBPs 6 and 7 (half, FBP6 defective); stack 4 = FBPs 8 and 9 (full); stack 5 = FBPs 10 and 11 (half, FBP11 defective). The AI claimed NVIDIA disabled healthy FBPs 1 and 4 to get a balanced 4096-bit bus around the dead ones. GlobalApathy added that data-path interleaving and bus width decide whether good regions behind bad ones are reachable. Source: @globalapathy, 2026-09-28
• insomniac called it "the standard AI hypothesis" built on guesses, and said a Chinese write-up argues it is very unlikely that some of an HBM stack fails while other parts keep working. Source: @ins_mniac, 2026-09-28

Contested

Later batches look worse-binned (serials starting 621 against 821)

jjb (2026-09-18) found that his earlier-batch cards, with serial numbers starting 621, have fewer defects than his later batch starting 821: the later cards show four defective memory partitions instead of two. He asked owners of larger fleets such as RH-3D to run gpcprobe across batches to confirm; RH-3D reported no errors after a 30-minute test but had not run the script yet. These prefixes do not match the usual serial format (Which card do I have), and which number jjb read is not stated.

Reported
Source: @jjb01957, 2026-09-18
Source: @rh3dai, 2026-09-18

Compute: GPCs, TPCs and SMs

70 SMs at the fuse floor, 74 with the override, on a complete GA100 die

Both SKUs ship at their SM fuse floor: 5 active GPCs, 35 TPCs and 70 SMs at compute capability 8.0 (4480 CUDA cores), raised to 74 by the override (Full SM unlock). By every scaling register the die is a complete GA100: 8 GPCs, 8 TPCs per GPC, 12 FBPs, 24 FBPAs and 12 NVLinks. The GPC disable masks vary per die (0x13, 0x15, 0x25, 0x45, 0x85 and 0xa8 seen, all leaving 5 GPCs) but the totals are constant. On the cards in that census the GPC defective fuses read 0, so the silicon is intact and the cut is subtractive OTP. CTRL_OPT is remove-only, and the shipped configuration enables 54.7% of the die's SMs. On the lab's two 8 GB cards the software override is fuse-disabled (DISABLE_SW_OVERRIDE_STATUS 1, EN_SW_OVERRIDE 0), and the fused TPC disable rows match the RECONFIG status rows on every GPC (three swept GPCs plus three single fused-off TPCs per card). So 74 SMs is the ceiling on an 8 GB card (10de:20c2) without an OTP burn.

Proven 8 GB and 10 GB
Source: repo github.com/Consensus-Protocol/cmp170hx by Consensus-Protocol on GitHub, posted by @darkmaniac7, 2026-07-28 (lab notes)
Source: @darkmaniac7, 2026-10-22 (lab notes)

Writing the floorsweep control does not re-enable SMs: CTRL_OPT is remove-only

AKuchen read 70 of 128 SMs active (multiprocessor count) on 2026-07-22 and traced the floorsweep fuses: the status fuses show the disable pattern per GPC, but writing the matching control register changes nothing and the SM count stays 70. Humvee55: "Ctrl_opt is remove only, not additive, that's why" it cannot re-enable SMs. Humvee55 also said about 37 to 38 SMs remain disabled (about a third of compute) and that GSP on and off works fine; Capone said re-enabling a GPC is going to be hard. The way to re-enable GPCs or SMs was still unknown then; the later 74-SM route is on Full SM unlock. Pointer: the register trace waits for the authors and is not reproduced here.

Proven 8 GB
Source: @scallion_9883, 2026-07-21
Source: @beefbonecapone, 2026-07-22
Source: @akuchen_66498, 2026-07-22

Which GPCs are off differs per card

Studebaker (2026-08-03): GA100 has 8 GPCs and the 170HX has only 5 powered on, so it is about 5/8 of an A100; "I believe we are stuck at the power gate", and GSP decides. K2V: which GPCs are off varies per card. His GPC disable fuse reads 0x49 (GPCs 0, 3 and 6 disabled) but his GPC defect fuse reads 0x8, so GPCs 0 and 6 are fully functional and only GPC3 is defective. Writing the GPC disable register did not work; K2V believes an override path exists because internal engineering VBIOS builds can change the FBIO configuration, which is the same register type as the Gen3 and GPC disables. Asked by arnold civardagezen whether anyone was working on unlocking GPCs, Humvee55 answered "yes".

Reported
Source: @_studebaker_, 2026-08-03
Source: @k2v0008, 2026-08-03
Source: @a.civardagezen, 2026-08-03
Source: @scallion_9883, 2026-08-03

Why three GPCs are always disabled

Every 170HX shows three GPCs disabled. The explanations, in the order posted (2026-09-17):

• Humvee55 calls it the standard 170HX floorsweep spec. In his view the cards are a mixed bag, some good silicon cut down only to be sold as a 170HX and some really defective: clusters marked defective are likely truly bad, those disabled but not marked are probably good, and the same applies to GPCs, TPCs and FBPAs. Source: @scallion_9883, 2026-09-17
• Waka324: a product needs a fixed floor for functional equivalence; too many disabled units miss the performance spec, too few and QC rejects too many dies. Source: @cmdrwaka324, 2026-09-17
• Miséricorde: the CMP cut is mostly artificial commercial segmentation, like the Q2SR (8592+ engineering sample) CPUs, none of which were defective among the 20+ he built with. Source: @wakeupmbrc1, 2026-09-17
• cibernox: the dies were demoted for failing strict A100 memory-error QC and may be fine for hobby use. Source: @cibernox, 2026-09-17

Mark Linton and chonsworth also took part in the thread. Source: @marklintonca, 2026-09-17
Source: @chonsworth, 2026-09-17

Contested 8 GB and 10 GB

Defective GPCs: how common?

The census results, in the order posted:

• 2026-09-17: most disabled GPCs are not marked defective. Sojun's four cards: one with GPCs 0, 1 and 3 disabled and GPC 3 defective (0x0b and 0x08), three with GPCs 0, 1 and 5 disabled and none defective (0x23). dottoreargus: 0x45 (GPCs 0, 2, 6), none defective; DUFRelic: 0x23 and 0x0b, none defective. 1a2b3c0967: about 50% of his cards have at least 1 unit marked defective; cressida eyeballed about 60% disabled-only and 40% with a defective unit, and CUTE agreed. jjb raised the open question: re-enabling healthy GPCs would boost prompt processing. Source: @sojun80, 2026-09-17
  Source: @dottoreargus, 2026-09-17
  Source: @dufrelic, 2026-09-17
  Source: @1a2b3c0967, 2026-09-17
  Source: @cressida1881, 2026-09-17
  Source: @cute_sc2, 2026-09-17
  Source: @jjb01957, 2026-09-17
• 2026-09-23: Con3po's eight cards had 7 of 8 dies with zero GPCs marked defective; only one card has a genuinely dead GPC (bit 6). Source: @con3po7016, 2026-09-23
  Source: @matstatman, 2026-09-23
• 2026-10-09: matstatman and Mountains: all 8 GB cards seem to have 1 or more defective GPCs. Newman's eight 8 GB cards had the same disabled-GPC setup (one that first looked different was later judged a table error). bigfoot: 2 of his 6 10 GB cards have 0 defective GPCs, the others "still decent". Lycorascence: on his 10 GB card gpcprobe reports the inaccessible parts only as disabled, not defective. lxwx's 10 GB card had all extra GPCs marked defective and crashed with Xid 109 at 128 SMs, which supports "defective" meaning something for GPCs even if not for FBPs. Source: @bigfoot1144, 2026-10-09
  Source: @matstatman, 2026-10-09
  Source: @mountains1605, 2026-10-09
  Source: @newman_08462, 2026-10-09
  Source: @lycorascence, 2026-10-09
  Source: @n2dcrypt, 2026-10-09
• The lab's census found a defective GPC on two of its eight census cards and on one of its two other 8 GB cards; the rest show disabled GPCs only. Source: @darkmaniac7, 2026-10-22 (lab notes)
  Source: @darkmaniac7, 2026-10-27 (lab notes)

Contested 8 GB and 10 GB

July topology dumps: two SMs per active GPC sit behind the RECONFIG register

mrpandagod re-read four July topology dumps (two 8 GB and two 10 GB cards, made with ga100_topology_report.py by another member) on 2026-09-29. The SKU matched within each variant. Some 10 GB cards had manufacturing defects in GPCs 0 and 7 (possibly early production), while another 10 GB card had no broken GPCs, so its GPCs were disabled purely by fuse assignment. Inside the active GPCs, 2 SMs were disabled not by the OPT disable fuse but by a soft reconfiguration register (RECONFIG), which Lycorascence linked to the 4 SMs recently unlocked (70 to 74). Lycorascence's own 10 GB card lists its last memory stack as only disabled, not defective.

Reported 8 GB and 10 GB
Source: @djpandaman, 2026-09-29
Source: @lycorascence, 2026-09-29
Source: @newman_08462, 2026-09-29

RIR records

The real 8 GB versus 10 GB split is RIR occupancy

The software-override gate reads the same on both SKUs: on all 15 cards of a reference cohort, both 170HX units included, the fuse that disables the software override is set, the override enable is 0 and the PCIe fuse fingerprint matches; the DevInit PCIe edit is the same and there is no PCB difference. What differs is the RIR macro. The 8 GB card (10de:20c2, SK Hynix) ships with it consumed: 15 of 16 slots invalidated, one live factory record, none free. The 10 GB card (10de:2082, Samsung) ships blank with all 16 slots free. Mark Linton dumped two 8 GB cards (VBIOS 92.00.6D.00.0A) read-only with a script mirroring lxwx's tool (no burns, no Xid): byte-identical, with exactly that occupancy. GitHub reports say the same: "15/16 slots burned" in ga100-fuse-re (restated by wanghar for two 8 GB cards on 2026-10-10) and "16/16 RIR write slots already written" (armand0e, 2026-10-18). The burn tool refuses non-blank slots, and a used slot cannot take a new record because fuse bits only go from 0 to 1, so the 10 GB gate-clearing burn (RIR fuse burn) has nowhere to go on an 8 GB card. A second idea, reusing the one factory record, depends on where it sits on each die: it looked reachable on one card and closed on another; the readiness verdict is NO-GO and nobody has burned it. Which fuse bit the factory record points at is still a hypothesis; do not burn on it.

Proven 8 GB and 10 GB
Source: @marklintonca, 2026-10-10
Source: repo github.com/lixiangwuxian/170hx-rir-tool by lixiangwuxian on GitHub, posted by @darkmaniac7, 2026-10-10 (lab notes)
Source: repo github.com/ahnguyen17/ga100-fuse-re by ahnguyen17 on GitHub, posted by @darkmaniac7, 2026-10-18 (lab notes)
Source: repo github.com/amoghmunikote/cmpunlocker by amoghmunikote on GitHub, posted by @darkmaniac7, 2026-10-18 (lab notes)
Source: repo github.com/lixiangwuxian/170hx-rir-tool by lixiangwuxian on GitHub, posted by @darkmaniac7, 2026-10-18 (lab notes)

Zarquon's RIR read-out: 8 GB slots invalidated plus one record, 10 GB blank

Zarquon read the fuse RIR records read-only on 2026-09-28; working out how took Qwen Flash three days. On an 8 GB card record rows 0 to 6 are all invalidated; one record in row 7 is active, which he decoded as setting the global poison-disable option, and the last record is invalidated. On a 10 GB card all 16 records are blank, nothing programmed. Both reads put the fuse controller back as it was. Zarquon first thought the 8 GB table was full of patches rather than invalidated "so thought there was an easy option". Big Ptoughneigh ("Now write them") warned that any write test must be safe for both the RIR and the main array or it can brick the card; Mello Jello asked about efuse documentation, and Zarquon worried about read life, citing TSMC 7 nm efuse macro documentation.

Reported 8 GB and 10 GB
Source: @zarquon3157, 2026-09-28
Source: @bigptoughneigh, 2026-09-29
Source: @mellojello_, 2026-09-29

The software override is fuse-disabled on 8 GB cards

Replying to an AI-generated analysis of the 80 SM path that replacedriver47 shared (its content is not in the export), okrasit. said the software-override enable is gated by a column fuse. Its status register (FUSE_DISABLE_SW_OVERRIDE_STATUS) reads 1 on 8 GB cards, meaning software override is fuse-disabled there. okrasit. suggested the last RIR might be able to override that fuse; that part is untested.

Reported 8 GB
Source: @okrasit., 2026-10-02
Source: @replacedriver47, 2026-10-02

Pre-Ampere cards have free RIR slots, but writes do not land

BlackSun noted on 2026-09-29, in the context of the 10 GB card's empty RIRs, that pre-Ampere cards also have free RIR slots but no writes land ("Fun fact"). No register details or test results were given, so free RIR slots alone do not imply an unlock route. Other cards: Other CMP cards and other NVIDIA GPUs.

Reported
Source: @blacksun.0, 2026-09-29

What can and cannot be changed

The NV_FUSE_OPT registers ignore writes from BAR0

K2V (2026-08-03) wrote the GPC disable fuse option (NV_FUSE_OPT_GPC_DISABLE, marked read-write in NVIDIA's dev_fuse.h) with its privilege mask opened: no effect. Writing the Gen3 disable option had been tried by someone else with the same result. Samuel Hayden: none of those fuses are writable from BAR0; the values can be read and written but are not used, "they get overruled/ignored by falcon". K2V concluded that only OPT fuses with a matching Feature Override register can be changed through BAR0, for example the ECC feature override, and floated trying ECC (ECC). On 2026-08-09 he named the register more memory would need, NV_FUSE_OPT_FBIO_DISABLE, "But currently we are not able to write registers starting with NV_FUSE_OPT". He framed 64 to 80, 80 to 96 and 64 to 96 GB as the same problem: enabling more FBPs (8 to 10, 10 to 12 or 8 to 12).

Reported 8 GB and 10 GB
Source: @k2v0008, 2026-08-03
Source: @samuel_hayden., 2026-08-03
Source: @k2v0008, 2026-08-09

Device ID override through the software override (theory)

K2V (2026-08-03) shared NVIDIA patent US20150127860A1 as a guide to overriding a GPU's device ID and said it should apply to the 170HX: "just set the enable_SW_OVERRIDE register and then you can set devid via software access". He noted it is of limited direct value for the 170HX, but that the same override logic should be similar for other OPT fuses. On 8 GB cards that override is fuse-disabled (section above). Untested on the card in this history.

Theory
Source: @k2v0008, 2026-08-03

Privilege-mask notes from the July sec2 work (pointer)

A longer exchange by @akuchen_66498 (AKuchen) and @scallion_9883 (Humvee55) on which privilege masks the community driver opens at boot, and which ones that method cannot open, exists; see Discord. (Pointer: these are exploit internals; they wait for the authors and are not reproduced here.) Source: @akuchen_66498, 2026-07-22
Source: @scallion_9883, 2026-07-22

Routes to deeper fuse work on 8 GB cards (theory)

Petri Krohn (2026-10-01): NVIDIA could do it with signed Falcon code that ignores the fuses that block fuse writes. If debug mode could be enabled on 8 GB cards, one could write and sign unrestricted fuse code. Every feature is guarded by several fuses, so normally several RIRs are needed, but if both disable fuses sit on the same physical row a single RIR record might enable a feature. mrpandagod suggested that, depending on how the last factory record is laid out, the trailing spare rows might still be writable. Rumours of an NVIDIA fuse-writing tool offered in China for $10,000 circulated in the same thread: Miséricorde thought Goofish sellers advertising 8 GB unlocks may have such a tool, and OB88594 said such tools and channels exist in China but are NDA-protected. None of this is tested; see Rumours and claims to verify.

Theory 8 GB
Source: @petrikrohn_26497, 2026-10-01
Source: @djpandaman, 2026-10-01
Source: @wakeupmbrc1, 2026-10-01
Source: @ob88594, 2026-10-01

A "broken" fuse reads as neither 1 nor 0

CUTE reported "breaking fuses" on both 8 GB and 10 GB cards on 2026-10-02 and said the result is "not as pretty as it looks": a broken fuse reads as neither 1 nor 0, just broken. He said this should not happen at all, still needed research and might not be useful. replacedriver47 asked whether a broken fuse reads as a random 1 or 0; there was no answer. Fuse changes are permanent, so treat this as experimental and risky.

Reported 8 GB and 10 GB
Source: @cute_sc2, 2026-10-02
Source: @wakeupmbrc1, 2026-10-02
Source: @replacedriver47, 2026-10-02

Related

Gpcprobe, Hbmmon, RIR fuse burn, 170hx-rir-tool, Full SM unlock, Which card do I have, Verifying an unlock, Variant comparison, 8 GB card, 10 GB card, The 10 GB card: provenance and the 80 GB question, Memory unlock on the 10 GB card, 32 GB cards (subsystem 10de:1586), Odd variants and engineering samples, PCIe Gen3 on the 10 GB card, NVLink, ECC, VBIOS and firmware, Compute, data types and missing features, Unlock history: who found what, and when, Other CMP cards and other NVIDIA GPUs, Rumours and claims to verify.

Imported from the cmpunlocker Discord with credit; see Credits.