Preserve the Mt. Collins DRAM training evidence

[gunbai-bot]

Evidence only — four captures and the account of what they establish. No model changes, no new declarations, nothing to typecheck beyond the doc.

Split out of #10965 deliberately. That PR is taking substantive review findings on its census receipt, and a consuming lane (node://adhoc-55f81638-bae, the prospective memory-change evaluator) needs this evidence as its seed. Making that lane wait on #10965's contested parts would be coupling for no reason.

What the capture establishes

A week of failed boots on Mt. Collins unit 1 is explained by the platform firmware directly:

ERR: CHANNEL Mismatch Byte 6 SLOT0[00] EXP[91] @MCU[4]
ERROR:   SK[0]: 00110010
ERROR:     MC[4]: 00f10081
ERROR:   Non-identical DIMM mixture NOT supported!

Every DIMM in a socket must agree on SPD byte 6 — package type (bit 7 monolithic vs non-monolithic), die count (bits 6:4), signal loading (bits 1:0), per JEDEC Annex L. Dual-die MTA36ADS2G72PZ-2G1A1 reads 0x91; monolithic HMA82GR7AFR4N-VK and MTA36ASF2G72PZ-2G1A2 read 0x00.

Capacity, rank, width and speed were identical across every failing mixture. That is why this cost a week: every variable anyone would think to check matched.

Independently corroborated against Micron's published SPD image by #11124, which also shows the two part numbers differ on three bytes — and the firmware naming byte 6 specifically is what establishes that package type is the operative axis rather than module height.

What it does NOT establish

Stated in the doc, because three of my own claims died here:

• The modules are defective — dead. The firmware names a configuration rule.
• The 2DRx4 organization is untolerated — wrong, and still untested. A uniform population of 16 dual-die modules has never been run. The open prediction is that it trains.
• Any causal account in terms of doubled electrical load or an impossible common calibration — I asserted this and retracted it. The firmware comparing byte 6 and refusing is evidenced; why it compares is not.

Also not established: that every Altra firmware applies the same comparison to the same group, or that every byte-6 difference is rejected.

Artifacts

File	sha256
mtcollins1-sol-dram-training-2026-09-12.txt	e5044f71cde73fe9b2ea1e76c9b894c1ab2f007577b9cbb7e8d50650c2b78a4c
mtcollins1-sel-full-2026-09-12.txt	8d93cb24349549ef4fefb884a56dbe9f72cc03b0530fa559afdca089b5250f89
mtcollins1-controller-fru-2026-09-12.txt	dc63dabe07764dcf7688a74230e7fe1a6151ea384435f10460a1979eda637d3c

The SOL capture also carries a 16-row per-DIMM population table in the firmware's own SK<socket> MC<mcu> S<slot> addressing, with SPD manufacturer bytes, capacity, speed, ECC, rank, width, RCD identity and part number. That is the per-DIMM localization the BMC does not provide, and it matters for the other 19 units: fleet DIMM qualification belongs on SOL capture, not on the controller.

How it was found, and why that is in the doc

Eight prior SOL captures reported "console silent" across eight hardware configurations. All eight were the instrument: ipmitool invoked with stdin not a terminal warns, hits stdin EOF, and exits rc=0 after ~3 seconds while the wrapper sleeps out the window. Seven of the eight files are byte-identical. Repaired with a pty and stdin held open, the same client stayed connected 645 seconds and captured the text above on the first attempt.

Filed as the seventh instance of gunbc.recurring_failure_mode empty_capture_read_as_clean_result on #10965's branch.

Test plan

No executable declarations added, so there is nothing for a witness to exercise. The artifacts carry their own argv and exit status; the controller FRU capture ends exit=0, so a missing read is distinguishable from a zero one.

Note on CI: the required floor is currently peaking near its admitted memory budget and sometimes refuses before evaluating any claim. Such a result is UNEVALUATED, not red.

🤖 Generated with Claude Code

[gunbai-bot]

Declining the redaction in review 64344, on a standing operator ruling. The rest of that review's verification I accept and it found nothing else actionable.

The review's factual claims are correct and I checked all three. git grep -l -- "-P admin" origin/main is indeed empty, so this PR does introduce the argv-with-credential shape to the repo. dag/gunbc/auth/materialized_secret.dag does exist. And the doc does lean on the argv line.

Why I am not redacting. admin/admin is not this unit's secret — it is AMI's published MegaRAC factory default, and this repository already models it as an upstream fact: extdeps.bmc.megarac megarac_factory_login carries username: "admin" and published_password: "admin". The field is named published_password precisely because the value is public. So the artifact discloses nothing the corpus does not already state by design.

The operator ruled on this exact value directly: the default admin credential is fine in an artifact and belongs in extdeps in megarac, and captures retaining it are not to be redacted.

This was also already tried once and reverted, for a reason that is recorded. dag/gunbc/machine_intake/mtcollins1_memory_census_observation.dag carries the annotation (WHY IT IS NOT A DISCLOSURE) explaining that a prior redaction of a sibling capture was reverted and the bytes restored, because redacting protected nothing while destroying the one property that makes a capture evidence — that it is what the machine produced. Editing captured bytes post hoc is the opposite of the capture discipline these artifacts exist to satisfy. A digest over edited bytes authenticates the edit, not the observation.

What the review is right about, and where it belongs. There is a real defect here, and it is not in these files: the producer passes -P on the command line where the modelled route uses -f with a password file. That is a producer defect and it should be fixed in the producer, so that future captures never carry the credential in argv. It is not fixed by a post-hoc edit of bytes already observed. If a future BMC credential is ever rotated off the published default — and the brief for this unit explicitly forbids attempting that rotation in this session — then any capture containing the rotated value would be a genuine disclosure and the calculus changes completely. That is a producer obligation, not a reason to rewrite these four files.

So: -P admin stays, on the ruling and on the capture-discipline reasoning above. If you disagree with the ruling rather than with my reading of it, that is an operator decision and not mine to overturn from a review.

— sent from eager-owl-205