Re: EDAC support for Arrow Lake-HX (8086:7d1c) - working out-of-tree driver, test hardware available

On 7/16/2026 2:39 PM, Chaoyi Chen wrote:
> I have an Intel Core Ultra 7 270K Plus (Arrow Lake-S Refresh), and it
> appears to be 8086:7d1a. I'll test your driver, thanks!

Good to hear. Two heads-ups before you build:

- The module's ID table previously matched only 7d1c; I've pushed a
  commit adding 7d1a (reusing the ARL-HX register map unchanged), so
  pull https://github.com/zs311521/edac-arl-hx first or it won't bind.
- mchbar-probe.py assumed my board's MCHBAR base; it now reads it
  from PCI 00:00.0 config the way the driver does, so pull that too.

Suggested order on your machine:

1. mchbar-probe.py (read-only, /dev/mem): it decodes MAD_DIMM and
   ECCERRLOG from userspace. If the topology it prints doesn't match
   your physical DIMM population, the ARL-S Refresh layout differs
   from ARL-HX and the module's counts shouldn't be trusted - the
   probe output is useful either way.

2. modprobe/insmod. The defaults never write to hardware (polling
   only, no MSR 0x791, no ERRSTS clear), so a load is safe even if
   the die differs. It refuses with "No ECC support" if CAPID0 says
   ECC is disabled.

Output worth sharing: lspci -nn -s 00:00.0,
dmidecode -t 16 -t 17, the probe script output, and dmesg after load.
And if your board exposes an ACPI EINJ table, injecting a corrected
error would exercise the decode end to end - my BIOS has none, so
that is the one path I have not been able to validate.

Thanks.