lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Date:	Thu, 23 Feb 2012 09:40:18 -0200
From:	Mauro Carvalho Chehab <>
To:	edac-devel <>,
	Linux Kernel Mailing List <>
CC:	"Luck, Tony" <>, Borislav Petkov <>
Subject: latest version of the HERM patches

As discussed previously, the HERM (Hardware Events Report Mecanism)
patches are changing the EDAC/MCE internals, in order to provide
a consistent way of reporting hardware errors, and it is the result
of the discussions during the EDAC meetings:

The changes there consist of:
	- abstracting the memory architecture used by EDAC;
	- provide a proper representation for FB-DIMM memories;
	- add a test mechanism for the error core and applications;
	- add trace events do describe the hardware errors.

We're having a bad time to reach an agreement about the proper
trace format. So, I've rebased my patches to let the trace changes
to happen on a single patch, at the end of the series, and put them

The content there is basically the same as the last patch series I've
proposed, except for one small change: I renamed the internal struct
"dimm_info" to "memset_info". The rationale for it is that the content
of that struct can be a dimm or a rank, depending on the driver. So,
"memory set" is a better name for such struct.

I preserved there the same trace struct as on my last proposal
because we didn't reach an agreement. After having such agreement,
there's just one independent patch that needs to be changed or

This also makes easier to propose a different way, as the patches that
abstract the memory hierarchy also replaces all error calls at edac by
a single function call: edac_mc_handle_error(). So, there's a single
point where the trace call should be added.

Also, as I'm running a test on several different EDAC hardware to check
if the internal changes at the structs didn't break anything,
it also prevents the need to re-test everything, as only the EDAC
core would be affected by a trace change.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists