-
Notifications
You must be signed in to change notification settings - Fork 6
Appendix Artifacts
What this page covers. A catalogue of the technical artifacts that survive from the CMP 170HX unlock effort: Falcon firmware disassemblies, gadget atlases, ROP payload generators, read-only probe scripts, register dumps, driver patch files, and the long-form writeups. For each artifact this page records what it contains, how big it is, when it appeared, and why it matters. It is a map of the primary evidence, not a tutorial. For what the artifacts collectively establish, see How the unlock works and the register reference.
Two numbers frame the collection. 131 text and code files were archived out of the two Discord
servers, alongside 1,121 attachments in total (the remainder are overwhelmingly screenshots and
photographs). Separately, 13 git trees of the shipping unlocker (master plus 12 unreleased
branches) and a handful of external repositories and gists were snapshotted. Everything below is
drawn from those.
!!! note "Naming and attribution" Artifacts are cited by filename, size and date only. No authorship is recorded anywhere in this wiki. Several files were posted more than once, sometimes in different channels and sometimes lightly edited; where that happened it is called out, because double-counting a re-post as an independent observation is a real error that occurred at least once in the source material.
The SEC2 booter_load microcode is the object of the entire exploit. It is an AES-encrypted,
RSA-3072-PSS-signed Heavy Secure (HS) Falcon image of roughly 60,160 bytes, with the 384-byte
detached signature spliced in at PATCH_LOC = 0x8900. The debug variant decrypts with NVIDIA's
public AES-128-ECB test key, and the debug and production images are the same size, which is what
made a clean-room disassembly viable at all. See
Falcon and the Booter.
| Artifact | Size | Date | Contents |
|---|---|---|---|
booter_load_515_dbg_disasm.asm.txt |
389,197 B | 2026-06-30 | Disassembly of the 515-branch booter, posted as a worked template for producing the 580 equivalent. The first firmware listing in the corpus. |
booter_load_ga100_dbg_seccode.fuc5.asm |
545,149 B | 2026-07-01 | The raw envydis -m fuc5 output for the decrypted GA100 debug secure core. This is the base artifact: every gadget address used by every later tool is an instruction boundary in this file. Posted 2026-07-01T12:40:37Z. |
booter_load_ga100_dbg_seccode.annotated.fuc5.asm |
591,794 B | 2026-07-03 | The same listing with LLM-generated per-function and per-block comments. |
booter_load_ga100_dbg_seccode.annotated.fuc5_v2.asm |
607,702 B | 2026-07-09 | The working reference: 11,875 lines, per-function banners, and every lcall carrying an inline comment naming the callee in the form lcall 0x1234 // my_function($r10, $r11). An immutable backup copy was re-posted on 2026-07-18 specifically so that search sessions could not accidentally edit it. |
booter_load_ga100_OVERVIEW.md |
14,164 B | 2026-07-03 | A narrative walkthrough of the booter, generated by feeding the raw assembly to a language model. |
!!! warning "The overview document is unverified by construction"
The overview was posted with the caveat that its author had "no idea what part of it is
hallucinated". It contradicts itself in at least one place: section 2 correctly identifies CSB
0x9100 bit 31 as FALCON_CSBERRSTAT.VALID, a fault flag, while its own key-constants table
still calls it a busy/poll bit. The fault reading is correct because the code branches to a
self-loop when the bit is set rather than looping while it is set. All function names in the
project (csb_write, memcpy, wpr_region_program and the rest) are inferred from
behaviour; the binary has no symbol table. Verify against the annotated listing, which
preserves the original instruction lines byte for byte.
The code image ends at 0x86ff. Any address in a payload above that is a DMEM pointer, not code.
These are the artifacts that turned a 600 kB listing into something you can build a ROP chain from. They matter far beyond their size, because they are what establishes that the shipping exploit's constants were derivable from clean-room material. See the ROP chain and clean room and provenance.
| Artifact | Size | Date | Contents |
|---|---|---|---|
register_gadget_atlas.md |
33,060 B | 2026-07-10 | Machine-generated from the raw disassembly. Lists a gadget only if interprocedural reach analysis proves the target register still holds the set value at the ret, including inside called functions. Carries a controllability summary per register (poppable via mpopaddret, mov-setters, ld-setters, zeroers) and per-row caveats: canary(r15==r9) means the path runs a stack-canary compare, via-call means a real subfunction executes, data-branch means a conditional depends on state you must set. Posted 2026-07-10T13:40:14Z. |
Bar0RegWrite.txt |
2,769 B | 2026-07-02 | A hand-extracted listing of the 0x10aa BAR0 write routine, instruction by instruction, showing mov $r3 0x6340 / ld b32 $r9 D[$r3] (the canary load) followed by the argument moves. This is the primitive the whole exploit is built on. |
DIRECT_ENGINE_FINDINGS.md |
4,503 B | 2026-07-15 | Analysis of the direct write gadget at 0x8224: iowrs I[$r10] $r11 followed by the 0x9100 CSB status check and lcall 0x1d0f report path. |
The_missing_piece_per-FBPA_hal |
2,353 B | 2026-07-12 | A per-FBPA half-capacity-fuse hypothesis naming FUSE_HALF_FBPA_EN 0x82049C, STATUS_HALF_FBPA 0x820C00, CTRL_OPT_FBPA 0x820818 and STATUS_FBP 0x820D38. Preserved as a hypothesis, not a result: whether STATUS_FBPA is writable at all or purely a fuse-merge output was asked and never answered. |
The atlas entries for 0x0cbd ("$r10 <- $r0, canary(r15==r9), via-call, mpopaddret $r3 0x4")
and 0x1fbd ("$r11 <- $r10, canary(r15==r9), via-call, mpopaddret $r2 0x4") describe precisely
the roles those gadgets play in the shipping driver patch, eight days before that patch existed.
| Artifact | Size | Date | Purpose |
|---|---|---|---|
extract-firmware-nouveau.py |
32,942 B | 2026-07-01 | The Nouveau firmware extractor, patched for GA100. The stock script fails because the generated C array names took the form kgspBinArchiveBooter{LOAD}Ucode_{GPU}_BINDATA_LABEL_IMAGE_{fuse.upper()}_data, with the fuse suffix present on some architectures and absent on others. Produces booter_load_dbg/prod, booter_unload_dbg/prod and bootloader blobs. |
extract-firmware-nouveau-ga100-raw.py |
32,972 B | 2026-07-05 | The same tool, further patched to emit raw booters with headers and signatures stripped, leaving 0x100 unencrypted bytes at the head. |
fwsec_patch.py |
1,655 B | 2026-06-30 | First-generation FWSEC patcher. |
fwsec_overcopy_test.sh |
2,543 B | 2026-06-30 | The experiment that demonstrated the driver patcher worked: overwrite a section and observe the effect. |
load_custom_bin.py |
16,937 B | 2026-07-01 | Standalone Falcon loader, argparse [-h] [--pci] [--dmem-out ADDR NDWORDS] [--timeout] [--no-engine-reset] [--quiet] plus a positional binary. |
patcher.py |
15,753 B | 2026-07-02 | GSP firmware patcher: signature bypass plus a "thermal trampoline", written against driver 580.159.03. |
patch_gsp.py |
2,563 B | 2026-07-11 | ELF64 surgery on gsp_tu10x.bin: parse e_shoff 0x28, e_shentsize 0x3A, e_shnum 0x3C, e_shstrndx 0x3E, locate .fwsignature_ga100, overwrite in place, patch sh_size to 0xF800, append .shstrtab to end of file, rewrite e_shoff. |
scan_dmem.py |
10,160 B | 2026-07-16 | The safer ELF variant, using pyelftools and appending the replacement section at EOF honouring sh_addralign. Also drives a full DMEM sweep: iterate DMEM_ADDR in steps of 4, build a dump payload per value, patch the firmware, reload the modules, optionally FLR. |
!!! note "Superseded"
Every tool in this section that patches gsp_tu10x.bin on disk was superseded on 2026-07-18 by
the in-driver approach, in which pSignatureMemdesc is enlarged to 0xf800 bytes and filled in
memory. No ELF surgery, no firmware file to back up or restore, and the payload can be rebuilt
between Booter firings. See driver patches. Residue survives: the
shipping remove.sh still deletes five gsp_tu10x.bin.cmpunlocker.* suffixes.
A separate correction is worth preserving: gsp_tu10x.bin was never the disassembly target. It
is the GSP RISC-V ELF payload the booter validates, not the booter. Ghidra emitted roughly 100 MB of
C from it and riscv64-unknown-elf-objdump roughly 1.5 GB of assembly. The real target is about
25 kB and disassembles to about 390 kB. The file was still the right delivery vehicle, which is
why the confusion persisted.
The payload listings are plain text tables of DMEM address to value, hand-written and reviewed by eye. They are the most legible artifacts in the collection and the best entry point for understanding the chain.
| Artifact | Size | Date | Contents |
|---|---|---|---|
170HX_ROP_payload_v1.txt |
2,530 B | 2026-07-05 | First chain. Canary global 6340 = FACEB13D; the write value 02779000 at FF3C destined for $r0; canary addresses at FF40/FF44. Posted explicitly as untested. |
170HX_ROP_payload_v2.txt |
2,648 B / 2,918 B | 2026-07-08 | Two revisions the same day. The second fixes a bug and moves the return address to main() to 0x8119. |
170HX_ROP_payload_v3.txt |
3,034 B | 2026-07-09 | Four BAR0 writes with a rejoin through booter_load_wpr_main() for possible WPR2 release. Header notes that FEAT_OVR_SM_SPD and FEAT_OVR_SM_SPD_1 must still be set from the host after the PLM unlock. |
stack_gen.py |
4,482 B | 2026-07-04 | Frame generator: an initial mpopaddret $r6 0x4 block then three 5-word mpopaddret $r2 0x4 blocks per frame, return addresses 0x1fb9, 0x1fbd, 0x8224, exit 0x79e7, payload_size 0xF700, dma_target 0x0900, stack_start 0xf75c. |
builder.py |
9,810 B | 2026-07-01 | Payload builder, Mode A (throttle write, halting exit). Its header names the vulnerability precisely: booterVerifyLsSignatures_TU10X at IMEM 0x29C4 calls lcall 0x0601 (booterIssueDma_HAL) with $r10 = 0x0900 and size = sizeOfSignature, with no bounds check. |
payloadn.py, payload-lnject.py, payload_v3.py
|
2,285 / 4,592 / 2,200 B | 2026-07-08 to 07-09 | Successive Python payload injectors. |
unlc.py |
1,919 B | 2026-07-12 | The minimal host-side demonstrator: once the FEAT PLM is open, SS0 and SS1 are ordinary BAR0 writes. This two-step model is exactly what the shipping patch implements. |
!!! danger "stack_gen.py v1 could not have worked"
Its first release zeroed every canary slot. The reference word at D[0x6340] must be replicated
into each frame or __stack_chk_fail at 0x7dd9 fires. The author flagged it at post time and
later payloads write the marker into every frame. Preserved because the failure mode is
instructive, not because the file is usable.
refire_chain_v6.py (27,769 B, 2026-07-24) performs the entire unlock from userspace with no
NVIDIA driver loaded, using only the Python standard library. It maps BAR0 as 16 MiB, treats SEC2
as base 0x00840000, resets the Falcon, loads NS code to IMEM 0 unsecure and HS code to IMEM[ns]
secure, loads DMEM, sets MAILBOX0/1 to the WprMeta physical address, starts the CPU, and overflows
the signed Booter's signature-read DMA repeatedly. Modes: --compute, --memory 40, --memory 80,
--pcie-gen2, --pcie-retrain, --all.
!!! warning "Experimental"
This is a parallel, non-shipping path. It is not part of cmpunlocker. Its prerequisites are
strict: root, the GPU unbound from any nvidia driver, a signed GA100 booter_load HS image,
echo 16 | sudo tee /proc/sys/vm/nr_hugepages, and intel_iommu=off or iommu=pt so that DMA
physical addresses are host-physical. It ships a 10 GB WprMeta template only, so it cannot
be applied unmodified to a 0x20C2 card. Its --memory 80 mode claims "80 GB LMR HW-verified",
which most plausibly means the register accepted the write, not that 80 GB is usable. See
the 80 GB question.
These never obsoleted. They are measurement instruments, not unlockers, and they remain the correct way to verify any claim on this page.
| Artifact | Size | Date | What it does |
|---|---|---|---|
probe.sh (mmio-probe) |
19,061 B | first 2026-05-31, archived copy 2026-07-07 | Self-contained bash plus inline Python. Read-only mmaps /sys/bus/pci/devices/<BDF>/resource0 and dumps roughly 120 to 130 named registers plus 24 per-FBPA reads at FBPA_BASE 0x900000, FBPA_STRIDE 0x4000. Emits registers.json, lspci.txt, nvidia-smi.txt, gpu-summary.csv, probe.log, tarred to /tmp/mmio-probe-<host>-<stamp>.tar.gz. Optionally compiles a CUDA PTX special-register dumper (nvcc -arch=sm_70) so SM count is measured rather than reported. It never writes to BAR0.
|
ga100_topology_report.py |
4,848 B then 8,128 B | 2026-07-24 | Read-only BAR0 mmap dumping only the registers that determine how many SMs a GA100 board enumerates, for cross-unit comparison. The second revision adds an inforom grab. |
pcielink.sh |
4,944 B | 2026-07-24 | The standard PCIe field-report collector. Decodes, on both endpoint and parent bridge, CAP_EXP+0c.l (LnkCap), +2c.l (LnkCap2), +10.w (LnkCtl), +12.w (LnkSta), +24.l (DevCap2), +28.w (DevCtl2), +30.w (LnkCtl2), +32.w (LnkSta2), plus sysfs speed/width, nvidia-smi pcie.link.gen, AER counters and the count of SEC2_DEBUG dmesg lines. |
A100 probe kit: probe.py + README.md + sweep.sh
|
9,132 / 3,022 / 3,007 B | 2026-07-20 | Three-step opt-in-write workflow on a donor A100: inventory read-only, then sweep.sh forces Gen1/2/3 and auto-restores via an EXIT trap, then probe.py write-test --confirm writes and immediately restores 0x880a8, 0x8c044 and 0x88088, classifying each as WROTE-OK or REJECTED(PLM?). Masked-read sentinel 0xBADF5040. An earlier 11,472 B probe.py preceded it the same day. |
check_fold.py |
not archived as a file | 2026-07-24 | The authoritative test for whether unlocked VRAM is real: allocate all free VRAM minus 2 GiB, write each 64 KB page's own index with a PTX sm_80 kernel, read every page back. Must be dense, because the fold aliases at a channel-interleave offset. Output REAL, NO FOLD or FOLD/mismatch @<pageindex>. |
cuda_dbg.py |
not archived as a file | 2026-07-19 | Lighter alias test: cuMemGetInfo_v2, then cuMemAlloc_v2 at 64, 60, 56, 52, 48, 44, 42 GiB until one succeeds; write 0xAAAA0000 at offset 0 and 0xBBBB0000 at 40 GiB, read offset 0. Reading back 0xBBBB0000 means the space aliases. |
!!! note "Two documented defects in probe.sh"
Line 9 of its header promises a /dev/mem fallback that does not exist; the resolution block
ends in ERROR: cannot find resource0 and exit 2. And the catalogue predates the unlock, so it
contains no entry for 0x001fa7c4, 0x001fa7cc, 0x001fa824/0x001fa828, 0x009a0148 or
0x00100ce0: the five registers the shipping unlock actually manipulates. Adding them is the
single most valuable change anyone could make and needs no hardware.
Reading BAR0 needs root plus CAP_SYS_RAWIO, which containerised GPU hosts drop; the probe
then raises cannot open .../resource0 (EPERM) even as root.
Raw captures are the load-bearing evidence for most of the register reference. See the register index.
| Artifact | Size | Date | Contents |
|---|---|---|---|
regs_01.txt |
16,103 B | 2026-07-12 | Targeted, annotated register reads on a stock card: SM_ISSUE_RATE_MODIFIER 0x00504204 = 0xbadf1201, FECS_FEAT_OVERRIDE 0x00409664 = 0xbadf5040, FEAT_OVR_ECC_PLM 0x00823800 = 0xffffff8f, FEAT_OVR_PLM 0x00823804 = 0xffffff8f, FEAT_OVR_QUADRO 0x00823808 = 0x00000081 (the sources attribute 0x00000081 to a post-unlock probe rather than a stock card, so do not read this one as either), FEAT_OVR_ECC 0x0082380c = 0x00888888, and more, each with a one-line purpose note. |
PLM range scan (save.sh) |
13,544 B raw / 12,265 B cleaned | 2026-07-16 / 07-18 | A script(1) typescript covering 0x823800 to 0x823FFC, 510 address/value pairs, 28 seconds of wall time (Script started 22:51:04+07:00, Script done 22:51:32+07:00), complete with the operator fumbling a command line first. Eleven registers in the block 0x823800 to 0x82382C are live, plus 0x823B00, for twelve live dwords in total. Two addresses, 0x823828 and 0x823850, are absent from the dump altogether, which is why the scan carries 510 pairs and not the 512 a complete step-4 sweep of the window would produce. Everything else reads 0xBADF5040. The cleaned copy posted two days later in a different channel is byte-equivalent across all 510 pairs. It is one observation, not two.
|
a100.json |
84,011 B | 2026-07-20 | Full inventory from a real A100, the differential reference against which 170HX fuse readings are interpreted. |
a100_native_unbound.json, gen_native.json, gen1.json, gen2.json, gen3.json
|
33,259 / 33,259 / 33,273 / 33,271 / 33,271 B | 2026-07-20 | The forced-generation sweep set from the donor A100. Write tests on that card did not succeed, so only read data exists. |
a100-80g.json |
1,367 B | 2026-07-20 | Short dump from a rented A100 80 GB. |
registers.json |
23,254 B | 2026-07-25 | A probe dump from a CMP 90HX, used for cross-family comparison. |
ga100_topology_output.txt |
3,345 B | 2026-07-24 | Topology report output from a live card. |
reg-ref-a100-vs-170hx.csv |
1,857 B | 2026-07-27 | Two days of live A100 versus native 8 GB 170HX strap and fuse comparison, hunting a PCIe Gen3 strap. The negative result is the finding; the approach was declared a dead end and the 170HX side lacked full per-FBPA capture. |
00_33_31_scanning_lspci.txt |
16,427 B | 2026-06-25 | Early full lspci scan. |
dmesg_large.txt |
7,405 B | 2026-07-09 | Kernel log from the experiment testing whether anything important sits in DMEM after the signature. |
bendy2pcielink.txt |
2,579 B | 2026-07-24 | An archived pcielink.sh field report. |
| Artifact | Size | Date | Contents |
|---|---|---|---|
patch.diff |
35,867 B | 2026-07-18 | 887 lines across 11 files: the diff extracted from the leaked package by diffing its bundled open-modules tree against upstream tag 610.43.03. Posted at 18:01:15Z. Historically decisive: see clean room and provenance. |
cmpunlocker shipping patch set |
37,415 B | 2026-07-18 | Six patches, 890 lines, 10 target files: 0001-sec2-postbl-plm-ss-cfg.patch (19,741 B), 0002-booter-verify.patch (3,988 B), 0003-late-pma.patch (10,580 B), 0004-bar0-pramin-clamp.patch (861 B), 0005-ce-scrub-workarounds.patch (1,642 B), 0006-persistent-sw-state.patch (603 B). |
0007-pcie-gen2.patch, 0008-pcie-gen2-probe-retrain.patch
|
branch-only | 2026-07-23 onward | The unreleased Gen2 work. 0007 pushes a 23-entry xp3gTable through the Booter payload primitive; 0008 adds nv_cmp170hx_retrain_gen2() to kernel-open/nvidia/nv.c. See PCIe Gen2. |
mod.txt |
1,725 B | 2026-07-12 | A hand-written kernel hunk defining CMP170HX_WPR2_SAFE_LIMIT 0x0A00000000ULL (40 GB) and clamping pWprMeta->fbSize above it with a warning. An early, independent expression of the WPR2 sizing problem. |
Guide_SM.sh |
9,127 B | 2026-07-12 | Full-pipeline driver: stage 1, FLR, unload, unlock. |
nuke.sh |
7,359 B | 2026-07-16 | PLM batch test v3: patched GSP, ROP, FLR, kill, FLR, read PLMs with no driver loaded. Ran a 27-address persistence sweep in 9 cycles of 3, two FLRs per cycle. Used canary 0xFACEB13D at CANARY_ADDR 0x6340, DMA_TARGET 0x0800. |
test_580.sh (three revisions), test_580v6.sh, scaffold_580.sh, driver.sh, a.sh, b.sh
|
3.8 to 7.7 kB | 2026-07-08 to 07-12 | The 580-branch experiment harnesses, including a STRAP-write fix and an 0x65 status hunt. |
cmp170hx-gen2-setup.sh |
12,389 B | 2026-07-26 | Standalone Gen2 enabler, distinct from the in-driver branch approach. Its own header states the scope precisely: Gen1 at about 0.85 GB/s to Gen2 at about 1.71 GB/s, exactly 2x, with the 64 GB unlock, compute and HBM bandwidth untouched, no VBIOS flash and no kernel command line change. |
build-llama-170hx.sh |
3,802 B | 2026-07-27 | Reproducible llama.cpp container build for this card. |
!!! danger "The gpuValidateRegOps bypass is in patch.diff only"
patch.diff inserts return NV_OK; as the first statement of gpuValidateRegOps,
unconditionally, for all GPUs, disabling register read/write validation entirely. That change is
absent from the shipping cmpunlocker tree and from all twelve unreleased branches. Any
text attributing it to the shipped tool is wrong.
| Artifact | Size | Date | What it argues |
|---|---|---|---|
ROP_CHAINS_1180f8_nibble_writeup_20260715.md |
9,628 B | 2026-07-15 | The handoff-state problem, stated as a requirements table: after a driverless fire, resetPLM 0x8403C4 must read 0xff (because 0x8f blocks SEC2 SFTRESET), WPR2 0x1FA824/28 must be cleared, and 1180f8 bits [31:28] must be 0x1. The first two were solved; the nibble was not. Also documents the +0x18 DMEM per write frame stride and tabulates D[0xFF50] through D[0xFF84]. Posted 2026-07-15T18:48:10Z. |
WRITEUP.md + WRITEUP_EXPLAINED.md
|
12,950 + 12,335 B | 2026-07-23 | The FFMA throttle investigation on a 0x2082 card: 0.315 TFLOPS measured against 25.27 TFLOPS theoretical, 14 binary patches to the GSP firmware plus multiple kernel module modifications, none of which moved the throttle. Its conclusion, that the limit is fuse-enforced and unreachable from firmware, is a valuable negative result and is refuted only by the entirely different SEC2 route. |
CMP_170HX_40GB_UNLOCK_GUIDE.md |
11,994 B | 2026-07-22 | The single-load 40 GB driver patch explained end to end: one modprobe, no FLR, no firmware swapping, with the modprobe-time sequence written out step by step. |
PCIE_GEN1_LOCK.md |
15,467 B | 2026-07-24 | The PCIe speed-cap field manual. Opens by separating speed from width and keeping width (the 24-capacitor C1100 to C1350 solder mod) explicitly out of scope. Status line: "Software and keyless-firmware surface exhausted; remaining paths are physical." |
ga100_fbpa_hbm_timing_registers.md |
23,682 B | 2026-07-25 | HBM timing register definitions over 0x9A0200 to 0x9A0300 within the broadcast FBPA range 0x009A0000 to 0x009A3FFF, with the critical observation that CONFIG0.USE_TIMING_REGS (bit 31 of 0x9A0290) reads 0, so the active parameters are the internally generated TIMING*_GEN shadows, not the raw TIMING*/CONFIG* values. |
untitled.md |
5,814 B | 2026-07-17 | Personal architecture notes, posted with the author's own self-rating that roughly 10 percent has reliable proofs or sources, and a warning that assembling all chat points into a document would produce many wrong conclusions. |
README.txt |
4,637 B | 2026-07-18 | Accompanying notes for the leaked package. |
| Artifact | Size | Date | Contents |
|---|---|---|---|
170hx-tuning-guide.md |
26,987 B | 2026-07-27 | Ships with the 170tune harness. Written against one named reference card (GA100, 70 SM, 64 GB unlocked, driver 610.43.03, 300 W VBIOS 92.00.6D.00.0A, PCIe Gen2 x4) and explicit that per-card silicon varies, with a "qualifying a new card" procedure before any offset is trusted on a different unit. Also a record of closed dead ends, so none gets walked twice. |
170HX-benchmark-results.md |
5,290 B | 2026-07-27 | Eight unlocked 64 GB cards, driver 610.43.02, sm_80, PCIe Gen1 x4 and no cap mod. Per-card torch GEMM: FP16 162.7 TFLOPS tensor, BF16 171.4 TFLOPS tensor. |
GLM-5.2-benchmark-report.md |
7,999 B | 2026-07-24 | A negative-result report worth keeping: the 467 GB 4-bit quant could not be loaded because the host's 88 GB of system RAM is far below what llama.cpp's load-time compute-graph pass needs, pinning RSS at about 87.6 GB with no progress. A host-side failure, not a card limitation. |
cublas_benchmark1 |
826,072 B | 2026-07-16 | An x86-64 ELF executable, dynamically linked against ld-linux-x86-64.so.2. A compiled binary distributed for others to run, not a results log. |
See performance and LLM inference for what these numbers mean in context.
Being explicit about gaps is part of the catalogue.
-
No booter binary. The signed HS image and its detached signature are named by the tools
(
booter_load_580_image.bin,booter_load_580_sig.bin, expected undercmp170hx_boot_bins/verified_hs/) but are not in the archive. - No 8 GB WprMeta capture. The driverless chain's 256-byte template came from a real 10 GB boot. Capturing the 8 GB equivalent is a small, unblocked task.
- No hash comparison of the debug and production booter images. The bindata archive makes it trivial, and it would settle whether they are byte-identical or merely the same size.
- No emulator. The Falcon emulator described in the academic paper was never released.
- No Driver Modification Guides. The two private documents that would settle several provenance questions do not exist in this source set.
-
No
verify.shonmaster, and no Gen2 check in any branch copy of it. -
masterhas notools/directory.probe.sh,pcielink.sh,check_fold.py,cuda_dbg.py, the A100 probe kit and the refire chain were all distributed out of band. Cloning the repository will not get you any of them.
Start
Hardware
- Board And Variants
- Fuses And OTP
- GA100 Silicon
- Memory Subsystem
- NVLink Hardware
- Overview
- PCIe Subsystem
- Power Delivery
- Thermals
- VBIOS
Unlock
- Compute Throttle
- Driver Patches
- Falcon And Booter
- How It Works
- Memory Geometry
- Overview
- PCIe Gen2
- Privilege Level Masks
- Register Reference
- ROP Chain
Procedures
Operations
Frontier
History
Appendix