Skip to content

extdeps.micron: identify MTA36ADS2G72PZ and give the corpus a Micron authority - #11155

Closed
briansrls wants to merge 4 commits into
mainfrom
session/clever-heron-234
Closed

briansrls wants to merge 4 commits into
mainfrom
session/clever-heron-234

Conversation

@briansrls

Copy link
Copy Markdown
Contributor

Auto-opened by session-dashboard for session clever-heron-234.
Pushing to session/clever-heron-234 advances this PR.

Worker attestation

Before flipping this PR to ready for review, confirm each item:

  • Title describes the change (not the session id or branch).
  • PR body summarises what and why (replace the TODO below).
  • Tests run: name the command (e.g. npm test, cargo test) and the result.
  • If this closes a work item, the body contains a Closes #N directive.
  • No commits on this branch are surprises (no fork/cherry-pick I did not make).
  • No secrets / credentials / large binaries staged.

Summary

TODO: replace this paragraph with one or two sentences naming the change and its motivation. Reviewers read this first.

Test plan

  • TODO: list the commands that ran (or "no tests changed; relied on CI") and the outcome.

Brian Searls and others added 4 commits September 12, 2026 01:56
…ue and numbering sheet

Identify the Mt. Collins unit-1 "2DRx4" quartet from Micron's data: a 16 GB, 2Rx4,
DDR4-2133 CL15, ECC, registered, very-low-profile (18.75 mm) RDIMM built from 18
dual-die packages of two 4 Gb dies (SPD byte 6 = 0x91: non-monolithic, 2 dies,
multi-load stack; numbering field DS = "VLP Dual-Die w/Temp Sensor"). The trained
sibling MTA36ASF2G72PZ (SF = FBGA, monolithic, 31.25 mm) is carried as the control;
Micron's two SPD images are byte-identical at every organization and timing byte and
differ only at package type, nominal height, raw card and module attributes.

The corpus's DramDieStacking axis had no honest arm for a multi-load stack, so
DualDiePackage is added on JEDEC's own three-way classification; the Altra admission
fold now answers "not among the listed classes" for it, kept distinct from a withdrawal.

Second half (docs/plans/micron-mta36ads2g72pz-identification.md): the OEM SEL family
0f de 70 .. is preserved raw. The only public serializer (meta-ampere
dimm_train_fail_log.sh) writes sensor 0xeb and a byte-3 low nibble of 4; the 0xde
serializer is not public, and the tail is ambiguous even under the cousin schema, so
no decoder is minted. Neither Micron part is on the Altra AVL Issue 1.15, which carries
no 16 GB 2Rx4 row from any vendor.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01XAQV5DkCKgGqrGAZd44vqx
…n provenance already said

Review 64247 on #11124: the row's comment states 72 dies on 36 dual-die packages while the
field read MonolithicDie -- an unstated divergence the new stacking arm now makes sayable.
Repointed with the reason beside it; no consumer folds this row's stacking today.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01XAQV5DkCKgGqrGAZd44vqx
…n, not authority

The Mt. Collins unit-1 SOL capture prints byte 6 = 0x91 for the ADS part and refuses the
mixed socket on byte-6 disagreement -- a mixing rule, not a verdict on a uniform ADS fill.
Quoted beside the rows and in the survey; the rows still cite Micron.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01XAQV5DkCKgGqrGAZd44vqx
The firmware refusal quotes byte 6 and not the equally-differing height and raw-card bytes;
recorded as the favoured reading with the hedge that a first-mismatch comparator proves
nothing about later bytes, and the discriminating population that would settle it.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01XAQV5DkCKgGqrGAZd44vqx
@briansrls
briansrls marked this pull request as ready for review September 12, 2026 05:54
@chatgpt-codex-connector

chatgpt-codex-connector Bot commented Sep 12, 2026 •

Copy link
Copy Markdown

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review Status Commit Review trigger
📝 Code Review ✅ Completed 2026-09-12T06:07:01.851275Z fafec55 Draft marked ready
ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: fafec557e2

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

// monolithic and would have been admitted as a class it does not belong to.
test fn w_a_dual_die_registered_module_is_not_among_the_listed_classes() -> Bool {
let reg_ddp = DramModuleClass { buffering: Registered, stacking: DualDiePackage }
!altra_admits_module_class(c: reg_ddp)

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 Badge Preserve the unknown standing for dual-die RDIMMs

For any registered DDP such as the newly added ADS module, this assertion makes altra_admits_module_class return the same false used for genuinely refused classes. That contradicts the evidence recorded in docs/plans/micron-mta36ads2g72pz-identification.md:28-39, which says Ampere neither admits nor refuses DDPs, and the Boolean API cannot preserve the prose-only distinction between an unlisted class and a rejection. Consequently, qualification consumers will reject an unestablished configuration; represent this case with an explicit unknown/unestablished standing (or establish that generic RDIMM support includes DDP) instead of pinning it to false.

Useful? React with 👍 / 👎.

@gunbai-bot

gunbai-bot Bot commented Sep 12, 2026

Copy link
Copy Markdown
Contributor

Closing as superseded, and this one would have caused a small regression if landed.

Its content is already on main via #11124 (68e0a2a5da0), which review 64391 also noticed. This PR was auto-opened on session/clever-heron-234 after that squash-merge: the squash flattens the branch's commits so the branch is no longer an ancestor of main, and the PR diff re-proposes work that has landed. #11151 was the same phantom on the same branch and is already closed.

Verified by per-file content comparison against main rather than by the PR diff, which is misleading here. Eight of the nine files are byte-identical to main. The ninth is not, and it is the reason this is worth a comment rather than a silent close:

 data scope_carrier_paths: List<String> = [
   ...
-  "dag/extdeps/ebay/browse.dag",
-  "dag/extdeps/ebay/marketplace_account_deletion.dag"
+  "dag/extdeps/ebay/browse.dag"
 ]

Main is ahead of this branch there. dag/extdeps/ebay/marketplace_account_deletion.dag was added to scope_carrier_paths by another lane after this branch was cut, so merging this PR would delete that row. An approving review of content that matches a prior landing does not catch that, because the regression is in what the branch lacks, not in what it adds.

The lane that produced this work is closed and its work is landed. Any further Micron modelling should be a fresh lane against current main, not a revival of this branch.

A note on method, since I nearly got this backwards on the sibling PR: a two-dot git diff main branch across the whole tree shows thousands of deletions and reads as "merging this would wipe other lanes' work". That is an artifact of the branch being behind main and is not merge risk — GitHub merges against the merge base. The reliable question is per-file content, which is what the comparison above reports, and it is also what surfaced the one difference that actually mattered.

— sent from eager-owl-205

@gunbai-bot gunbai-bot Bot closed this Sep 12, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant