MCA region on ARL/CDS: declared length exceeds container and body is entirely 0xDEADBEEF
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 25/100
- Issue type
- Feature
- Clarity
- Needs clarification
- Activity status
- Active
- Tech stack
- rust
- Domain
- operating-systems
Research direction
Start with the README and the MCA ARL/CDS definitions in this repository, then compare the declared length, containing-region size, revision, and repeated 0xDEADBEEF body described in the report. The issue names no source file or test; work is complete when the expected interpretation and the consumer's treatment of this region are established and documented or specified for implementation.
Written by the indexing model from the issue text.
Description
Environment
Intel Core Ultra 9 285HX (Arrow Lake-HX), CPUID C0662. Crash Log records delivered via BERT and surfaced by Windows in Microsoft-Windows-Kernel-WHEA/Errors as CPER Firmware Error Record Reference sections (81212a96-09ed-4996-9471-8d729c8e69ed) with RECORD_ID_CRASHLOG. Analysed offline against the definitions in this repo; iclg itself was not run.
Observation
Across seven retained records, within the ARL/CDS region and immediately following the PUNIT record, there is a header:
version word: 0x3e07f102
record type: MCA (0x3e)
product: 0x7f (ARL/CDS)
header type: 1
revision: 2
declared length: 0x03c2 dwords = 3848 bytes
available: 3008 bytes
The declared extent exceeds the containing region by 840 bytes. The entire 3,000-byte body after the 8-byte header consists of 750 consecutive repetitions of 0xDEADBEEF. This is identical in all seven records.
Questions
Is a region emitted with a declared length larger than its container expected, or does it indicate a truncated capture?
Does a body filled with 0xDEADBEEF indicate that MCA collection did not run, or is it an initialisation pattern with a defined meaning?
Should a consumer treat such a region as absent rather than as data? The tool currently has no way to distinguish the two.
Related coverage note
The record types and revisions this platform emits are PUNIT MTL/NS rev 9 (reason 0x24), UNCORE MTL/NS rev 1, PUNIT ARL/CDS rev 3 (reason 0x09), UNCORE ARL/CDS rev 2, PMC MTL/SS rev 17, PMC_RST MTL/SS rev 1, PMC_TRACE MTL/SS rev 1, and PMC MTL/IOEP rev 5. Of these, only PMC_RST MTL/SS rev 1 has a published layout, and MCA ARL/CDS is published at rev 1 while the emitted header declares rev 2.
I understand from the README that coverage is deliberately limited. Flagging the emitted set in case it is useful for prioritisation.
I can supply section hashes and offsets. I have not attached raw payloads, as they may contain machine-specific data.
- Dominant language
- Rust
- Stars
- 11
- Forks
- 6
- Avg merge
- 1d 10h
- Merged PRs (30d)
- 3
Getting set up
- No Dockerfile or Docker Compose file
- No pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from intel/crashlog
-
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
-
Difficulty 4/5 3-5 days Newbie friendliness 25/100
-
Missing decode definitions for Product ID 0x037: PMC rev 5 / PMC_TRACE rev 1 / PMC_RST rev 1May be free again @psurply claimed this 61 days ago, and no pull request is open. Open
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 61/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
rust-embedded/heapless#694 ·
-
Difficulty 1/5 Under an hour Newbie friendliness 75/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
farion1231/cc-switch#8899 · 2 comments ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
manuscript-lang/manuscript#1364 ·
Maintainers usually reply within 1 day