CMP170HX 80GB Memory Lab

Preliminary research notebook, updated 7 September 2026. Documentation only; a runnable reproducer and public evidence bundle are not included yet.

This is a research notebook about additional, simultaneously independent memory on the NVIDIA CMP 170HX. It records failures, useful controls, corrections and open ideas—not an “80 GB unlocked” success announcement.

The established 40-GB-class operating configuration works. Requalifying that baseline is not this project's task. The experiments here investigate a separate, patched configuration reporting an 80 GiB address space. A larger reported size, successful allocation or correct control record does not establish more usable physical memory.

Current findings

• In the tested 36 + 4 + 36 GiB hybrid arrangement, upper writes corrupted corresponding lower allocations. A gap and a different use for the upper region did not provide independent capacity.
• Five small write-only controls used the same test executable. After a large allocation-only prelude, writing many different target addresses produced a delayed cleanup fault; repeatedly writing a smaller target region did not reproduce that fault in its observation window.
• The same larger-target control completed without new tracked GPU faults when run alone or after a much smaller, ten-handle prelude. This narrows the investigation but does not isolate physical placement, cache behavior or an allocator defect.
• In an earlier, separate controlled pair, leaving the last 16 MiB of the same allocation untouched avoided the observed exit fault; touching the full allocation did not. The verified working set was about 39.2 GiB, not additional capacity above 40 GiB, and a later successful management query did not prove a healthy new CUDA context.
• An older “76 GiB ALL CLEAN” report does not provide a sound capacity proof: its result-copy path was not checked. That is a validation gap, not proof that a particular run returned a false result.
• A bounded driver trace now observes the requested 64 MiB allocation through the VID/PMA return path without exhausting its log budget. This is progress in observing allocation paths, not proof of data integrity, physical placement or extra memory.
• A subsequently built and run CMPH3 trace captures conditional host-PMA base metadata. Four allocation-only controls show a first large/user-request candidate base of 614 MiB, including ten-handle requests of 40152 and 40156 MiB. Both exited without tracked faults through 60 seconds. Their metadata endpoints bracket a hypothesized folded reservation boundary, but no data overwrite, causal mechanism or extra independent capacity is established. See the new CMPH3 results.
• A later equal-volume contrast allocated 40156 MiB and verified 40152 MiB in both arms using the same executable: leaving 4 MiB untouched at the end avoided the observed cleanup fault; leaving 4 MiB untouched at the start did not. Both data checks passed. This supports range-sensitive lifecycle behavior, not additional capacity or an identified physical defect. See the data and exclusion controls.

See Results, Method and evidence requirements, and Ideas and priorities. GB is a decimal unit; MiB and GiB are binary units. “40-GB-class” is the established operating label; all numerical test sizes use the units explicitly shown.

What this notebook does not contain yet

The findings are currently backed by private, locally audited experiment archives. This notebook does not yet include a runnable reproducer, test source, CPU oracle or raw record bundle. A minimal reproducer and its evidence must be selected, anonymized and reviewed before their separate release. Artifact fingerprints in the results document are provenance references, not download links or claims that those files are included here.

Tests can leave the experimental GPU/driver state unhealthy and require recovery. Nothing here is an unattended installation or test procedure. There are no automatic retries, deployment instructions or executable test commands in this notebook.

PCIe Gen2/DDA work is a separate topic: CMP 170HX DDA Gen2 repository. That work is not a proof of extra memory capacity. This memory notebook is intentionally separate.

No license for third-party code, firmware or binaries is assigned by these documents. Any later code release needs its own provenance and license review.

Prior work, sources and acknowledgements

This lab builds on the work of the CMP 170HX research and unlock community. We did not originate the unlock. The driver work, published experiments and shared failure analyses below made this investigation possible; our contribution is a continuing set of controlled follow-up tests, evidence checks and openly documented outcomes.

• Unlock research: Jon Pry's June 2026 preprint, A Canary in the Crypto Mine: Defeating Stack Protection in a GPU Secure Coprocessor, provides early technical background. An early public discussion of the unlock links that research. These are provenance references, not our own capacity-validation results.
• Software foundation: amoghmunikote/cmpunlocker supplies the community unlock/driver patch work on which our experimental driver line is based. The underlying driver source is NVIDIA/open-gpu-kernel-modules. The supported 8-to-64-GB and 10-to-40-GB profiles must remain distinct from experimental extended-memory claims.
• The reported 75–76 GiB result: cuddylac997's CMP 170HX 80GB geometry / GSP-DMA report reports successful kernel-side checks up to 76 GiB on three cards, alongside H2D/DMA and teardown failures. It is an important starting point for investigating different access paths, not a stable full-workload result independently reproduced by this lab. Its included hbm45.cu does not check the result-counter D2H copy's return status; that validation gap limits what a clean printout proves without establishing that those particular copies failed.
• Community technical record: Consensus-Protocol's memory-geometry documentation and 80-GB frontier record collect geometry analysis and reported 77.5/72 GiB driverless-refire results, including their lifecycle limits. We use them as research leads, not as a claim that our current setup has reproduced them.
• Fold and alias investigation: Icyoung's WALL_ALIAS_DECODE analysis documents upper-write/lower-corruption relationships and sub-page offsets. This informs our alias questions; its address formulas and proposed explanations must not be transferred to a different allocation layout without measurement.
• Practical community documentation: abobasixseven/unlock-cmp-170hx documents use of the patched driver and explicitly points back to the underlying cmpunlocker project. It is a related guide, not a separate claim of authorship for the original unlock.

Thank you to the original researchers, maintainers and experimenters for sharing both progress and failures. References distinguish software foundations, external reports and our own observations; linking a source does not independently validate all of its claims or authorize replaying its procedures. Sources checked on 6 September 2026.

Human–AI collaboration

This is a joint human–AI lab notebook. The human contributor provides the hardware, practical experience, research ideas and project direction; AI assistants help develop tests, inspect source and logs, challenge interpretations and maintain the documentation. In short: a human working with AI—or, on some days, AI working with a human.

AI assistance is not a substitute for evidence, and a second AI review is not independent human validation. We distinguish hypotheses from measured results, retain failures and correct unsupported conclusions. Claims of usable capacity must stand on reproducible measurements, not on an assistant's confidence.