ECC

ECC (DRAM and SRAM)
Proven 8 GB and 10 GB
Driver	nvidia-open 610+ (cmpunlocker v0.5)
Unlock build	amoghmunikote/cmpunlocker v0.5
Steps	ECC
Source	link
Confirmations	Reproduced by @68x0 (both), 2026-10-04 · details

Software-based ECC landed in cmpunlocker v0.5 on 2026-10-04 and is credited to Amogh. It is one of the main reasons prices rose after the release. Source: @_j3ns, 2026-10-04 It is not in the Morrowmake P2P fork; you cannot have both ECC and that fork's P2P from one install today.

What it sets

ECC is native on HBM2e and is a separate thing from VRAM capacity; the patch does not change usable memory. Source: @alanoo, 2026-10-05 The MR4 write in the commit targets bits 1:0 (DM/ECC mode) of an HBM2e mode register. The CMP's HBM may be fused rather than keyed; a Samsung HBM2 part may need a different config than an HBM2e part. Source: @zarquon3157, 2026-10-05

Three patches: ecc-enable.patch (feature override 0x0082380c = 0x00999999, 0x00823810 = 0x003ffebf, 0x0082382c = 0x0000000f, ECC control 0x009a0470 = 0x00000041, LTCG dstcfg0 0x0017e318 = 0x00000001), ecc-fbpa-static.patch (forces bEnabledEccFBPA = NV_TRUE for 0x20c2/0x2082) and ecc-reporting.patch (wires the counters through escape.c). (From the cmpunlocker patch set.)

The counters

An investigation of which RM controls nvidia-smi uses found the counters are mostly real, served by GSP, not hardcoded:

Served by GSP (real): 0x20803400 ECC_GET_CLIENT_EXPOSED_COUNTERS, 0x20803401

 ECC_GET_VOLATILE_COUNTS, 0x20803404 ECC_GET_REPAIR_STATUS.

Intercepted: 0x20800133 GPU_QUERY_ECC_CONFIGURATION ("Enabled" hardcoded),

 0x2080014b GET_INFOROM_OBJECT_VERSION (ECC object "6.16"), 0x2080012f legacy status
 (zeroed), 0x20803406 UNREPAIRABLE_MEMORY_FLAG (0).

Ago saw the ECC counter increase on an SRAM error in the NVIDIA Prometheus exporter, consistent with real counters. Source: @alanoo, 2026-10-13

Does it correct errors? (contested)

Contested On a card with about 5,000 single-bit and some multi-bit errors per 5-minute memtest_vulkan run, enabling ECC did not correct any of them, and gpu-burn behaved the same; no one showed a corrected-error counter moving. Source: @zombielurker, 2026-10-05 The counterpoint: with ECC enabled an unstable card crashes with an Xid instead of silently generating garbage, which is itself useful. Source: @ichundes, 2026-10-07

Proven The hardware half does change state. On one 8 GB card, with three other cards as controls, the hardware part of the patch landed all 14 protected writes, FEATURE_READOUT (0x823814) went from 0x00000233 to 0xec8ff233 (DRAM ECC bit 16 set), FBPA_ECC_CTRL (0x9a0470) went from 0 to 0x41, and a 60 GiB write/verify passed with ECC on. This shows the bits flip, not that errors are corrected, and it contradicts an earlier write-up that the ECC readout is latched at power-on. How to test real correction: Memory errors and ECC. Source: @darkmaniac7, 2026-10-19 (lab notes)

Treat ECC as "reported enabled and surfaces errors", not proven to correct VRAM bit errors.

Why keep it on

Xid 48/172 uncorrectable ECC errors in GPC0 traced to an over-aggressive undervolt; lowering the voltage offset fixed it. Keeping ECC on turned a silent-corruption problem into a clean crash that could be diagnosed, even after 170tune's stability test passed. Source: @ichundes, 2026-10-07 See Cooling and power and Troubleshooting.

Known issues

No performance impact on bandwidth is reported from ECC; one decode regression after the 0.4 to 0.5 move was suspected

 to be ECC but not confirmed (see Driver unlock).

ECC also reports "enabled" on unrelated cards (5060, 3050, 3090) after the unlock, which may be reporting only.

 Source: @arabus_74064, 2026-10-05

Status

Enabled and reproduced by others (68x live on master; MistyAshHole ran it clean for 25 h), so "enabled" is Proven; whether it corrects VRAM errors is Contested. See the confirmation below.