linux-kernel - Re: [EDAC_ABI PATCH v13 01/26] amd64_edac: convert driver to use the new edac ABI

lists.openwall.net		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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 07 May 2012 13:59:24 -0300
From:	Mauro Carvalho Chehab <mchehab@...hat.com>
To:	Borislav Petkov <bp@...64.org>
CC:	Linux Edac Mailing List <linux-edac@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Doug Thompson <norsk5@...oo.com>,
	Borislav Petkov <borislav.petkov@....com>
Subject: Re: [EDAC_ABI PATCH v13 01/26] amd64_edac: convert driver to use
 the new edac ABI

Em 07-05-2012 13:17, Borislav Petkov escreveu:
> On Mon, May 07, 2012 at 01:12:24PM -0300, Mauro Carvalho Chehab wrote:
>> That happens because the EDAC core couldn't find any EDAC labels for the affected
>> memory.
>>
>> There are two reasons for seeing a "unknown memory":
>> 	1) there's no label information. This is fixed by:
>> 	   http://git.kernel.org/?p=linux/kernel/git/mchehab/linux-edac.git;a=commit;h=b14dbb9b8220f8e07634125bf0e315f739cbf501
>> 	2) there's no info about the label e. g. something like the old 
>> 	   edac_mc_handle_ce_no_info().
>>
>> As csrow and channel info is filled on your log, it is very likely to be
>> caused by (1) and that you didn't load the labels for this system with edac-ctl.
>>
>> If you had a table with the labels for your motherboard at /etc/edac/labels.db
>> and run "edac-ctl --load" during your system init (that's the default on RHEL/Fedora,
>> not sure what other distros do), the message would be like:
>>
>> EDAC MC0: CE amd64_edac on DIMM_4B (csrow 3 channel 1 page 0x5bac7 offset 0x388 grain 0 syndrome 0xb1be )
>>
>>> IOW, simply having:
>>>
>>> [ 2377.742279] EDAC MC0: CE amd64_edac (csrow:3 channel:1 page:0x5bac7 offset:0x388 grain:0 syndrome:0xb1be)
>>>
>>> is much better IMO.
>>>
>>> Also, formatting that info with ":" makes the data even easily
>>> understandable and parseable.
>>
>> Ok. I'll write a patch to replace it at the end of the series.
> 
> Why not rebase this patch? Your tree is not merged anywhere yet.

This change has nothing to do with "amd64_edac: convert driver to use the new edac ABI",
but to the previous patch.

It is possible to merge it with the previous patch that made the changes
at the edac_mc core, but that would require to re-review that patch, and will
loose the history about this specific change.

If all you want is to have this change applied before the amd64 patch, for you
to better test it, I've re-based it on my experimental tree to be between
the two patches:
	http://git.infradead.org/users/mchehab/edac.git/commitdiff/3f4610491cc58dda8c737378212559dce77adde2

Anyway, if you still prefer that I merge it with "edac: Change internal representation to work with layers"
patch, I can do it.

Regards,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/