From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S976379AbdDXRxG (ORCPT ); Mon, 24 Apr 2017 13:53:06 -0400 Received: from mail.skyhub.de ([5.9.137.197]:59622 "EHLO mail.skyhub.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S976350AbdDXRwo (ORCPT ); Mon, 24 Apr 2017 13:52:44 -0400 Date: Mon, 24 Apr 2017 19:52:40 +0200 From: Borislav Petkov To: "Baicar, Tyler" Cc: christoffer.dall@linaro.org, marc.zyngier@arm.com, pbonzini@redhat.com, rkrcmar@redhat.com, linux@armlinux.org.uk, catalin.marinas@arm.com, will.deacon@arm.com, rjw@rjwysocki.net, lenb@kernel.org, matt@codeblueprint.co.uk, robert.moore@intel.com, lv.zheng@intel.com, nkaje@codeaurora.org, zjzhang@codeaurora.org, mark.rutland@arm.com, james.morse@arm.com, akpm@linux-foundation.org, eun.taik.lee@samsung.com, sandeepa.s.prabhu@gmail.com, labbott@redhat.com, shijie.huang@arm.com, rruigrok@codeaurora.org, paul.gortmaker@windriver.com, tn@semihalf.com, fu.wei@linaro.org, rostedt@goodmis.org, bristot@redhat.com, linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org, linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org, linux-efi@vger.kernel.org, Suzuki.Poulose@arm.com, punit.agrawal@arm.com, astone@redhat.com, harba@codeaurora.org, hanjun.guo@linaro.org, john.garry@huawei.com, shiju.jose@huawei.com, joe@perches.com, rafael@kernel.org, tony.luck@intel.com, gengdongjiu@huawei.com, xiexiuqi@huawei.com Subject: Re: [PATCH V15 04/11] efi: parse ARM processor error Message-ID: <20170424175240.3nvhbxzwicxnk6og@pd.tnic> References: <1492556723-9189-1-git-send-email-tbaicar@codeaurora.org> <1492556723-9189-5-git-send-email-tbaicar@codeaurora.org> <20170421175527.fjwnqd22jz7br5yu@pd.tnic> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Apr 21, 2017 at 12:22:09PM -0600, Baicar, Tyler wrote: > I guess it's not really needed. It just may be useful considering there can > be numerous error info structures, numerous context info structures, and a > variable length vendor information section. I can move this print to only in > the length check failure cases. And? Why does the user care? I mean, it is good for debugging when you wanna see you're parsing the error info data properly but otherwise it doesn't improve the error reporting one bit. > Because these are part of the error information structure. I wouldn't think > FW would populate error information structures that are different versions > in the same processor error, but it could be possible from the spec (at > least once there are different versions of the table). Same argument as above. > There is an error information 64 bit value in the ARM processor error > information structure. (UEFI spec 2.6 table 261) So that's IP-dependent and explained in the following tables. Any plans on decoding that too? > Why's that? Dumping this vendor specific error information is similar to the > unrecognized CPER section reporting which is also meant for vendor specific > information https://lkml.org/lkml/2017/4/18/751 And how do those naked bytes help the user understand the error happening? Even in your example you have: [ 140.739210] {1}[Hardware Error]: 00000000: 4d415201 4d492031 453a4d45 435f4343 .RAM1 IMEM:ECC_C [ 140.739214] {1}[Hardware Error]: 00000010: 53515f45 44525f42 00000000 00000000 E_QSB_RD........ Which looks like some correctable ECC DRAM error and is actually begging to be decoded in a human-readable form. So let's do that completely and not dump partially decoded information. -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply.