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]
Message-ID: <4FA7FF6C.7020404@redhat.com>
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ