All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joe Perches <joe@perches.com>
To: Tyler Baicar <tbaicar@codeaurora.org>,
	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@vge
Subject: Re: [PATCH V10 07/10] efi: print unrecognized CPER section
Date: Wed, 15 Feb 2017 12:07:03 -0800	[thread overview]
Message-ID: <1487189223.6214.60.camel@perches.com> (raw)
In-Reply-To: <1487188282-2568-8-git-send-email-tbaicar@codeaurora.org>

On Wed, 2017-02-15 at 12:51 -0700, Tyler Baicar wrote:
> UEFI spec allows for non-standard section in Common Platform Error
> Record. This is defined in section N.2.3 of UEFI version 2.5.
> 
> Currently if the CPER section's type (UUID) does not match with
> one of the section types that the kernel knows how to parse, the
> section is skipped. Therefore, user is not able to see
> such CPER data, for instance, error record of non-standard section.
> 
> For above mentioned case, this change prints out the raw data in
> hex in dmesg buffer. Data length is taken from Error Data length
> field of Generic Error Data Entry.
> 
> Following is a sample output from dmesg:
> [  115.771702] {1}[Hardware Error]: Hardware error from APEI Generic Hardware Error Source: 2
> [  115.779042] {1}[Hardware Error]: It has been corrected by h/w and requires no further action
> [  115.787456] {1}[Hardware Error]: event severity: corrected
> [  115.792927] {1}[Hardware Error]:  Error 0, type: corrected
> [  115.798415] {1}[Hardware Error]:  fru_id: 00000000-0000-0000-0000-000000000000
> [  115.805596] {1}[Hardware Error]:  fru_text:
> [  115.816105] {1}[Hardware Error]:  section type: d2e2621c-f936-468d-0d84-15a4ed015c8b
> [  115.823880] {1}[Hardware Error]:  section length: 88
> [  115.828779] {1}[Hardware Error]:   00000000: 01000001 00000002 5f434345 525f4543
> [  115.836153] {1}[Hardware Error]:   00000010: 0000574d 00000000 00000000 00000000
> [  115.843531] {1}[Hardware Error]:   00000020: 00000000 00000000 00000000 00000000
> [  115.850908] {1}[Hardware Error]:   00000030: 00000000 00000000 00000000 00000000
> [  115.858288] {1}[Hardware Error]:   00000040: fe800000 00000000 00000004 5f434345
> [  115.865665] {1}[Hardware Error]:   00000050: 525f4543 0000574d
> 
> Signed-off-by: Tyler Baicar <tbaicar@codeaurora.org>
> Signed-off-by: Jonathan (Zhixiong) Zhang <zjzhang@codeaurora.org>
> ---
>  drivers/firmware/efi/cper.c | 12 ++++++++++--
>  1 file changed, 10 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/firmware/efi/cper.c b/drivers/firmware/efi/cper.c
> index c2b0a12..48cb8ee 100644
> --- a/drivers/firmware/efi/cper.c
> +++ b/drivers/firmware/efi/cper.c
> @@ -591,8 +591,16 @@ static void cper_estatus_print_section(
>  			cper_print_proc_arm(newpfx, arm_err);
>  		else
>  			goto err_section_too_small;
> -	} else
> -		printk("%s""section type: unknown, %pUl\n", newpfx, sec_type);
> +	} else {
> +		const void *unknown_err;
> +
> +		unknown_err = acpi_hest_generic_data_payload(gdata);
> +		printk("%ssection type: %pUl\n", newpfx, sec_type);
> +		printk("%ssection length: %d\n", newpfx,
> +		       gdata->error_data_length);
> +		print_hex_dump(newpfx, "", DUMP_PREFIX_OFFSET, 16, 4,
> +			       unknown_err, gdata->error_data_length, 0);

I suggest using true instead of 0 for the last argument

		print_hex_dump(newpfx, "", DUMP_PREFIX_OFFSET, 16, 4,
			       unknown_err, gdata->error_data_length, true);

It might help make deciphering the hex block a little easier.

WARNING: multiple messages have this Message-ID (diff)
From: Joe Perches <joe@perches.com>
To: Tyler Baicar <tbaicar@codeaurora.org>,
	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, devel@acpica.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
Subject: Re: [PATCH V10 07/10] efi: print unrecognized CPER section
Date: Wed, 15 Feb 2017 12:07:03 -0800	[thread overview]
Message-ID: <1487189223.6214.60.camel@perches.com> (raw)
In-Reply-To: <1487188282-2568-8-git-send-email-tbaicar@codeaurora.org>

On Wed, 2017-02-15 at 12:51 -0700, Tyler Baicar wrote:
> UEFI spec allows for non-standard section in Common Platform Error
> Record. This is defined in section N.2.3 of UEFI version 2.5.
> 
> Currently if the CPER section's type (UUID) does not match with
> one of the section types that the kernel knows how to parse, the
> section is skipped. Therefore, user is not able to see
> such CPER data, for instance, error record of non-standard section.
> 
> For above mentioned case, this change prints out the raw data in
> hex in dmesg buffer. Data length is taken from Error Data length
> field of Generic Error Data Entry.
> 
> Following is a sample output from dmesg:
> [  115.771702] {1}[Hardware Error]: Hardware error from APEI Generic Hardware Error Source: 2
> [  115.779042] {1}[Hardware Error]: It has been corrected by h/w and requires no further action
> [  115.787456] {1}[Hardware Error]: event severity: corrected
> [  115.792927] {1}[Hardware Error]:  Error 0, type: corrected
> [  115.798415] {1}[Hardware Error]:  fru_id: 00000000-0000-0000-0000-000000000000
> [  115.805596] {1}[Hardware Error]:  fru_text:
> [  115.816105] {1}[Hardware Error]:  section type: d2e2621c-f936-468d-0d84-15a4ed015c8b
> [  115.823880] {1}[Hardware Error]:  section length: 88
> [  115.828779] {1}[Hardware Error]:   00000000: 01000001 00000002 5f434345 525f4543
> [  115.836153] {1}[Hardware Error]:   00000010: 0000574d 00000000 00000000 00000000
> [  115.843531] {1}[Hardware Error]:   00000020: 00000000 00000000 00000000 00000000
> [  115.850908] {1}[Hardware Error]:   00000030: 00000000 00000000 00000000 00000000
> [  115.858288] {1}[Hardware Error]:   00000040: fe800000 00000000 00000004 5f434345
> [  115.865665] {1}[Hardware Error]:   00000050: 525f4543 0000574d
> 
> Signed-off-by: Tyler Baicar <tbaicar@codeaurora.org>
> Signed-off-by: Jonathan (Zhixiong) Zhang <zjzhang@codeaurora.org>
> ---
>  drivers/firmware/efi/cper.c | 12 ++++++++++--
>  1 file changed, 10 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/firmware/efi/cper.c b/drivers/firmware/efi/cper.c
> index c2b0a12..48cb8ee 100644
> --- a/drivers/firmware/efi/cper.c
> +++ b/drivers/firmware/efi/cper.c
> @@ -591,8 +591,16 @@ static void cper_estatus_print_section(
>  			cper_print_proc_arm(newpfx, arm_err);
>  		else
>  			goto err_section_too_small;
> -	} else
> -		printk("%s""section type: unknown, %pUl\n", newpfx, sec_type);
> +	} else {
> +		const void *unknown_err;
> +
> +		unknown_err = acpi_hest_generic_data_payload(gdata);
> +		printk("%ssection type: %pUl\n", newpfx, sec_type);
> +		printk("%ssection length: %d\n", newpfx,
> +		       gdata->error_data_length);
> +		print_hex_dump(newpfx, "", DUMP_PREFIX_OFFSET, 16, 4,
> +			       unknown_err, gdata->error_data_length, 0);

I suggest using true instead of 0 for the last argument

		print_hex_dump(newpfx, "", DUMP_PREFIX_OFFSET, 16, 4,
			       unknown_err, gdata->error_data_length, true);

It might help make deciphering the hex block a little easier.

WARNING: multiple messages have this Message-ID (diff)
From: joe@perches.com (Joe Perches)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH V10 07/10] efi: print unrecognized CPER section
Date: Wed, 15 Feb 2017 12:07:03 -0800	[thread overview]
Message-ID: <1487189223.6214.60.camel@perches.com> (raw)
In-Reply-To: <1487188282-2568-8-git-send-email-tbaicar@codeaurora.org>

On Wed, 2017-02-15 at 12:51 -0700, Tyler Baicar wrote:
> UEFI spec allows for non-standard section in Common Platform Error
> Record. This is defined in section N.2.3 of UEFI version 2.5.
> 
> Currently if the CPER section's type (UUID) does not match with
> one of the section types that the kernel knows how to parse, the
> section is skipped. Therefore, user is not able to see
> such CPER data, for instance, error record of non-standard section.
> 
> For above mentioned case, this change prints out the raw data in
> hex in dmesg buffer. Data length is taken from Error Data length
> field of Generic Error Data Entry.
> 
> Following is a sample output from dmesg:
> [  115.771702] {1}[Hardware Error]: Hardware error from APEI Generic Hardware Error Source: 2
> [  115.779042] {1}[Hardware Error]: It has been corrected by h/w and requires no further action
> [  115.787456] {1}[Hardware Error]: event severity: corrected
> [  115.792927] {1}[Hardware Error]:  Error 0, type: corrected
> [  115.798415] {1}[Hardware Error]:  fru_id: 00000000-0000-0000-0000-000000000000
> [  115.805596] {1}[Hardware Error]:  fru_text:
> [  115.816105] {1}[Hardware Error]:  section type: d2e2621c-f936-468d-0d84-15a4ed015c8b
> [  115.823880] {1}[Hardware Error]:  section length: 88
> [  115.828779] {1}[Hardware Error]:   00000000: 01000001 00000002 5f434345 525f4543
> [  115.836153] {1}[Hardware Error]:   00000010: 0000574d 00000000 00000000 00000000
> [  115.843531] {1}[Hardware Error]:   00000020: 00000000 00000000 00000000 00000000
> [  115.850908] {1}[Hardware Error]:   00000030: 00000000 00000000 00000000 00000000
> [  115.858288] {1}[Hardware Error]:   00000040: fe800000 00000000 00000004 5f434345
> [  115.865665] {1}[Hardware Error]:   00000050: 525f4543 0000574d
> 
> Signed-off-by: Tyler Baicar <tbaicar@codeaurora.org>
> Signed-off-by: Jonathan (Zhixiong) Zhang <zjzhang@codeaurora.org>
> ---
>  drivers/firmware/efi/cper.c | 12 ++++++++++--
>  1 file changed, 10 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/firmware/efi/cper.c b/drivers/firmware/efi/cper.c
> index c2b0a12..48cb8ee 100644
> --- a/drivers/firmware/efi/cper.c
> +++ b/drivers/firmware/efi/cper.c
> @@ -591,8 +591,16 @@ static void cper_estatus_print_section(
>  			cper_print_proc_arm(newpfx, arm_err);
>  		else
>  			goto err_section_too_small;
> -	} else
> -		printk("%s""section type: unknown, %pUl\n", newpfx, sec_type);
> +	} else {
> +		const void *unknown_err;
> +
> +		unknown_err = acpi_hest_generic_data_payload(gdata);
> +		printk("%ssection type: %pUl\n", newpfx, sec_type);
> +		printk("%ssection length: %d\n", newpfx,
> +		       gdata->error_data_length);
> +		print_hex_dump(newpfx, "", DUMP_PREFIX_OFFSET, 16, 4,
> +			       unknown_err, gdata->error_data_length, 0);

I suggest using true instead of 0 for the last argument

		print_hex_dump(newpfx, "", DUMP_PREFIX_OFFSET, 16, 4,
			       unknown_err, gdata->error_data_length, true);

It might help make deciphering the hex block a little easier.

  reply	other threads:[~2017-02-15 20:07 UTC|newest]

Thread overview: 74+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-15 19:51 [PATCH V10 00/10] Add UEFI 2.6 and ACPI 6.1 updates for RAS on ARM64 Tyler Baicar
2017-02-15 19:51 ` Tyler Baicar
2017-02-15 19:51 ` Tyler Baicar
2017-02-15 19:51 ` Tyler Baicar
2017-02-15 19:51 ` [PATCH V10 01/10] acpi: apei: read ack upon ghes record consumption Tyler Baicar
2017-02-15 19:51   ` Tyler Baicar
2017-02-15 19:51   ` Tyler Baicar
2017-02-15 19:51 ` [PATCH V10 02/10] ras: acpi/apei: cper: generic error data entry v3 per ACPI 6.1 Tyler Baicar
2017-02-15 19:51   ` Tyler Baicar
2017-02-15 19:51   ` Tyler Baicar
2017-02-16 18:25   ` Ard Biesheuvel
2017-02-16 18:25     ` Ard Biesheuvel
2017-02-16 18:25     ` Ard Biesheuvel
2017-02-16 18:25     ` Ard Biesheuvel
2017-02-15 19:51 ` [PATCH V10 03/10] efi: parse ARM processor error Tyler Baicar
2017-02-15 19:51   ` Tyler Baicar
2017-02-15 19:51   ` Tyler Baicar
     [not found]   ` <1487188282-2568-4-git-send-email-tbaicar-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2017-02-16 18:26     ` Ard Biesheuvel
2017-02-16 18:26       ` Ard Biesheuvel
2017-02-16 18:26       ` Ard Biesheuvel
2017-02-16 18:26       ` Ard Biesheuvel
2017-02-15 19:51 ` [PATCH V10 04/10] arm64: exception: handle Synchronous External Abort Tyler Baicar
2017-02-15 19:51   ` Tyler Baicar
2017-02-15 19:51   ` Tyler Baicar
2017-02-15 19:51 ` [PATCH V10 05/10] acpi: apei: handle SEA notification type for ARMv8 Tyler Baicar
2017-02-15 19:51   ` Tyler Baicar
2017-02-15 19:51   ` Tyler Baicar
2017-02-15 19:51   ` Tyler Baicar
2017-02-16 18:32   ` Ard Biesheuvel
2017-02-16 18:32     ` Ard Biesheuvel
2017-02-16 18:32     ` Ard Biesheuvel
2017-02-16 18:32     ` Ard Biesheuvel
2017-02-21 16:52     ` Baicar, Tyler
2017-02-21 16:52       ` Baicar, Tyler
2017-02-21 16:52       ` Baicar, Tyler
2017-02-21 16:52       ` Baicar, Tyler
2017-02-15 19:51 ` [PATCH V10 06/10] acpi: apei: panic OS with fatal error status block Tyler Baicar
2017-02-15 19:51   ` Tyler Baicar
2017-02-15 19:51   ` Tyler Baicar
2017-02-15 19:51 ` [PATCH V10 07/10] efi: print unrecognized CPER section Tyler Baicar
2017-02-15 19:51   ` Tyler Baicar
2017-02-15 19:51   ` Tyler Baicar
2017-02-15 20:07   ` Joe Perches [this message]
2017-02-15 20:07     ` Joe Perches
2017-02-15 20:07     ` Joe Perches
2017-02-15 20:31     ` Baicar, Tyler
2017-02-15 20:31       ` Baicar, Tyler
2017-02-15 20:31       ` Baicar, Tyler
2017-02-15 20:31       ` Baicar, Tyler
2017-02-21 19:10   ` James Morse
2017-02-21 19:10     ` James Morse
2017-02-21 19:10     ` James Morse
2017-02-21 19:39     ` Baicar, Tyler
2017-02-21 19:39       ` Baicar, Tyler
2017-02-21 19:39       ` Baicar, Tyler
     [not found]       ` <9b8aee3f-9ab6-121a-cad0-96a39743de55-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2017-02-22  0:30         ` Joe Perches
2017-02-22  0:30           ` Joe Perches
2017-02-22  0:30           ` Joe Perches
2017-02-22  1:12     ` Russell King - ARM Linux
2017-02-22  1:12       ` Russell King - ARM Linux
2017-02-22  1:12       ` Russell King - ARM Linux
2017-02-22 10:13       ` James Morse
2017-02-22 10:13         ` James Morse
2017-02-22 10:13         ` James Morse
2017-02-15 19:51 ` [PATCH V10 08/10] ras: acpi / apei: generate trace event for " Tyler Baicar
2017-02-15 19:51   ` Tyler Baicar
2017-02-15 19:51   ` Tyler Baicar
2017-02-15 19:51 ` [PATCH V10 09/10] trace, ras: add ARM processor error trace event Tyler Baicar
2017-02-15 19:51   ` Tyler Baicar
2017-02-15 19:51   ` Tyler Baicar
2017-02-15 19:51 ` [PATCH V10 10/10] arm/arm64: KVM: add guest SEA support Tyler Baicar
2017-02-15 19:51   ` Tyler Baicar
2017-02-15 19:51   ` Tyler Baicar
2017-02-15 19:51   ` Tyler Baicar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1487189223.6214.60.camel@perches.com \
    --to=joe@perches.com \
    --cc=akpm@linux-foundation.org \
    --cc=bristot@redhat.com \
    --cc=catalin.marinas@arm.com \
    --cc=christoffer.dall@linaro.org \
    --cc=eun.taik.lee@samsung.com \
    --cc=fu.wei@linaro.org \
    --cc=james.morse@arm.com \
    --cc=kvm@vger.kernel.org \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=labbott@redhat.com \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vge \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=lv.zheng@intel.com \
    --cc=marc.zyngier@arm.com \
    --cc=mark.rutland@arm.com \
    --cc=matt@codeblueprint.co.uk \
    --cc=nkaje@codeaurora.org \
    --cc=paul.gortmaker@windriver.com \
    --cc=pbonzini@redhat.com \
    --cc=rjw@rjwysocki.net \
    --cc=rkrcmar@redhat.com \
    --cc=robert.moore@intel.com \
    --cc=rostedt@goodmis.org \
    --cc=rruigrok@codeaurora.org \
    --cc=sandeepa.s.prabhu@gmail.com \
    --cc=shijie.huang@arm.com \
    --cc=tbaicar@codeaurora.org \
    --cc=tn@semihalf.com \
    --cc=will.deacon@arm.com \
    --cc=zjzhang@codeaurora.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.