Simone
b021fe4087
The open question was how to know whether the memory controller is polling
the DIMM thermal sensors, which is what killed the Broadwell-E attempt's
predecessor and what this driver had no answer for.
Intel documents it. The Xeon Processor Scalable Family datasheet volume 2
(reference 614073, section 3.1.9) puts SMBCNTL on the iMC channel function,
device 10 and 12 function 0, at offsets 0xe88 and 0xe98. SMB_TSOD_POLL_EN
is documented as mutually exclusive with SPD command access, so it answers
the question directly. The driver now reads it on every channel at probe
and refuses to bind if it is set.
This is deliberately weaker than the Broadwell-E driver, which switched the
polling off for the duration of a transfer. Reading and declining is a
smaller claim on hardware the driver does not own and needs no write to a
firmware-configured register. It covers the memory controller only; SMM and
a BMC are still out of reach, which is what the opt-in is for.
On the test system all four channels read 0xac000000: polling disabled,
TSOD_PRESENT empty, which also explains why no jc42 ever appeared at
0x18-0x1f on these DIMMs. Offset 0xe0, where the Broadwell driver has its
TSODCNTL, reads zero on all seven PCU functions here: that layout does not
transfer.
Two more measurements, both recorded in the cover letter:
- the SMBus interface Intel documents, at 0xe80-0xe9c on the iMC, does not
reach the bus on this platform. Issuing SMBCMD with CMD_TRIGGER sets
SMB_RDO and clears SMB_BUSY, but returns 0x00 for a populated DIMM at
0x50, a second one at 0x52 and an empty slot at 0x57 alike, with SMB_SBE
never set. The path this driver uses returns the correct SPD contents
and a NACK for the empty slot. The datasheet does not describe PCU
function 5 at all, so the choice is now stated with data rather than
left for a reviewer to ask about;
- writes are issued on the bus: a byte write to an unpopulated address
returns -ENXIO with the engine reporting the address NACK. This matters
because SMB_DIS_WRT is set in the documented SMBCNTL and is SMM-writable
only, so it evidently governs that interface and not this one.
Engine registers sampled every 2 s for an hour with the driver unloaded:
1791 samples, 0 changes.
Add tools/probe-imc-documented.sh, which produced the comparison above.
Smoke test with the new probe check: 15 checks, 0 failures.
Hardware measurements still owed to the submission
Three scripts, meant to be run by hand on an X299 (or Cascade Lake-X) system
with the PCU function 8086:2085. None of them is run by CI and none is run by
make test.
Output of all three belongs in the cover letter or in a reply on the list, as raw numbers. Do not paraphrase them.
| Script | Answers | Writes to hardware |
|---|---|---|
watch-engine.sh |
Is firmware using the engine on this system? | no |
dump-pcu-config.sh |
Which PCU registers move on their own? Is there a TSOD polling control? | no |
probe-cf8-write.sh |
Is the CF8/CFC write really dropped, and does it raise an SMI? | yes, requires --i-understand |
1. watch-engine.sh — foreign activity (read-only)
Samples the six per-channel registers and reports every change that this system's Linux side did not cause. Run it with the driver unloaded, so that anything observed is firmware.
sudo ./tools/watch-engine.sh --seconds 3600
What the cover letter needs: a run of at least one hour, ideally across a suspend/resume cycle, with the observed change count. A non-zero count on a system means the driver must not be loaded there, and is itself a result worth reporting.
2. dump-pcu-config.sh — register survey (read-only)
Dumps the function's 4 KB config space twice and diffs them, then prints the neighbourhood of the offsets that matter.
sudo ./tools/dump-pcu-config.sh --settle 10
This is the search for the open item F2: the Broadwell-E iMC driver stops the
PCU's TSOD polling for the duration of a transfer by writing 0 to TSODCNTL
at offset 0xe0 of its PCU function, waiting 10 ms for in-flight transactions
to drain, and restoring the value afterwards. No equivalent register has been
identified on 8086:2085. A field that changes on its own with a fixed cadence
is the first candidate.
3. probe-cf8-write.sh — the dropped write (WRITES TO HARDWARE)
This is the only script that writes. It changes the register/offset field of a
command register while the GO bit is clear, which does not start an SMBus
transaction, then reads it back and reports whether the write stuck. It also
reads MSR_SMI_COUNT (0x34) on every CPU before and after.
sudo ./tools/probe-cf8-write.sh --i-understand
Two results matter:
- the value does not read back → the claim "CF8/CFC writes to this function do not take effect" is confirmed on the tested board;
- the SMI delta is 0 → the behaviour is not System Management Mode, and the driver's comments and the cover letter must not say it is.
Requirements: msr-tools (rdmsr), pciutils (setpci, lspci), and the
msr module (modprobe msr).