This issue has made me look a bit more at what EDAC puts in sysfs. It seems like the current code inherits some useless baggage from the device calls it makes.
E.g. all the "power" subdirectories: $ find /sys/devices/system/edac -name power /sys/devices/system/edac/power /sys/devices/system/edac/mc/mc6/dimm3/power /sys/devices/system/edac/mc/mc6/power /sys/devices/system/edac/mc/mc6/csrow0/power /sys/devices/system/edac/mc/mc6/dimm6/power /sys/devices/system/edac/mc/mc6/dimm0/power /sys/devices/system/edac/mc/mc6/dimm9/power /sys/devices/system/edac/mc/mc4/dimm3/power /sys/devices/system/edac/mc/mc4/power ... total of 50 of these ... $ grep -r . /sys/devices/system/edac/mc/mc6/dimm0/power /sys/devices/system/edac/mc/mc6/dimm0/power/runtime_active_time:0 /sys/devices/system/edac/mc/mc6/dimm0/power/runtime_status:unsupported grep: /sys/devices/system/edac/mc/mc6/dimm0/power/autosuspend_delay_ms: Input/output error /sys/devices/system/edac/mc/mc6/dimm0/power/runtime_suspended_time:0 /sys/devices/system/edac/mc/mc6/dimm0/power/control:auto We don't have stats, nor control of power on a per memory controller or per dimm basis. So all these files are just noise. But ... we are at -rc5. Not sure that we'll figure out, write, test & debug the proper solution in the next 3-4 weeks. So perhaps we should apply -#define EDAC_MAX_MCS 16 +#define EDAC_MAX_MCS 64 as a temporary band-aid to get HPE's 32-socket machine running while we work on the proper fix? -Tony
