From: james.morse@arm•com (James Morse)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH V8 06/10] acpi: apei: panic OS with fatal error status block
Date: Wed, 15 Feb 2017 12:13:09 +0000 [thread overview]
Message-ID: <58A445D5.7030501@arm.com> (raw)
In-Reply-To: <5b06372d-e389-5157-ccb4-a7b023990d4d@codeaurora.org>
Hi Tyler,
On 13/02/17 22:45, Baicar, Tyler wrote:
> On 2/9/2017 3:48 AM, James Morse wrote:
>> On 01/02/17 17:16, Tyler Baicar wrote:
>>> From: "Jonathan (Zhixiong) Zhang" <zjzhang@codeaurora•org>
>>>
>>> Even if an error status block's severity is fatal, the kernel does not
>>> honor the severity level and panic.
>>>
>>> With the firmware first model, the platform could inform the OS about a
>>> fatal hardware error through the non-NMI GHES notification type. The OS
>>> should panic when a hardware error record is received with this
>>> severity.
>>>
>>> Call panic() after CPER data in error status block is printed if
>>> severity is fatal, before each error section is handled.
>>> diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
>>> index 8756172..86c1f15 100644
>>> --- a/drivers/acpi/apei/ghes.c
>>> +++ b/drivers/acpi/apei/ghes.c
>>> @@ -687,6 +689,13 @@ static int ghes_ack_error(struct acpi_hest_generic_v2
>>> *generic_v2)
>>> return rc;
>>> }
>>> +static void __ghes_call_panic(void)
>>> +{
>>> + if (panic_timeout == 0)
>>> + panic_timeout = ghes_panic_timeout;
>>> + panic("Fatal hardware error!");
>>> +}
>>> +
>> __ghes_panic() also has:
>>> __ghes_print_estatus(KERN_EMERG, ghes->generic, ghes->estatus);
>> Which prints this estatus regardless of rate limiting and cache-ing.
[...]
>>> ghes_estatus_cache_add(ghes->generic, ghes->estatus);
>>> }
>>> + if (ghes_severity(ghes->estatus->error_severity) >= GHES_SEV_PANIC) {
>>> + __ghes_call_panic();
>>> + }
>> I think this ghes_severity() then panic() should go above the:
>>> if (!ghes_estatus_cached(ghes->estatus)) {
>> and we should call __ghes_print_estatus() here too, to make sure the message
>> definitely got out!
> Okay, that makes sense. If we move this up, is there a problem with calling
> __ghes_panic() instead of making the __ghes_print_estatus() and
> __ghes_call_panic() calls here? It looks like that will just add a call to
> oops_begin() and ghes_print_queued_estatus() as well, but this is what
> ghes_notify_nmi() does if the severity is panic.
I don't think the queued stuff is relevant, isn't that just for x86-NMI messages
that it doesn't print out directly?
A quick grep shows arm64 doesn't have oops_begin(), you may have to add some
equivalent mechanism. Lets try and avoid that rabbit hole!
Given __ghes_panic() calls __ghes_print_estatus() too, you could try moving that
into your new __ghes_call_panic().... or whatever results in the least lines
changed!
Thanks,
James
next prev parent reply other threads:[~2017-02-15 12:13 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-01 17:16 [PATCH V8 00/10] Add UEFI 2.6 and ACPI 6.1 updates for RAS on ARM64 Tyler Baicar
2017-02-01 17:16 ` [PATCH V8 01/10] acpi: apei: read ack upon ghes record consumption Tyler Baicar
2017-02-01 17:16 ` [PATCH V8 02/10] ras: acpi/apei: cper: generic error data entry v3 per ACPI 6.1 Tyler Baicar
2017-02-01 17:16 ` [PATCH V8 03/10] efi: parse ARM processor error Tyler Baicar
2017-02-01 17:16 ` [PATCH V8 04/10] arm64: exception: handle Synchronous External Abort Tyler Baicar
2017-02-03 15:59 ` James Morse
2017-02-03 20:24 ` Baicar, Tyler
2017-02-01 17:16 ` [PATCH V8 05/10] acpi: apei: handle SEA notification type for ARMv8 Tyler Baicar
2017-02-01 22:26 ` kbuild test robot
2017-02-03 16:00 ` James Morse
2017-02-03 20:38 ` Baicar, Tyler
2017-02-15 6:24 ` Zhengqiang
2017-02-15 14:58 ` Baicar, Tyler
2017-02-01 17:16 ` [PATCH V8 06/10] acpi: apei: panic OS with fatal error status block Tyler Baicar
2017-02-09 10:48 ` James Morse
2017-02-13 22:45 ` Baicar, Tyler
2017-02-15 12:13 ` James Morse [this message]
2017-02-15 17:07 ` Baicar, Tyler
2017-02-01 17:16 ` [PATCH V8 07/10] efi: print unrecognized CPER section Tyler Baicar
2017-02-01 17:16 ` [PATCH V8 08/10] ras: acpi / apei: generate trace event for " Tyler Baicar
2017-02-01 23:20 ` kbuild test robot
2017-02-15 15:52 ` Steven Rostedt
2017-02-15 16:54 ` Baicar, Tyler
2017-02-15 17:03 ` Steven Rostedt
2017-02-15 17:06 ` Baicar, Tyler
2017-02-01 17:16 ` [PATCH V8 09/10] trace, ras: add ARM processor error trace event Tyler Baicar
2017-02-02 2:34 ` kbuild test robot
2017-02-02 3:15 ` Steven Rostedt
2017-02-03 20:18 ` Baicar, Tyler
2017-02-01 17:16 ` [PATCH V8 10/10] arm/arm64: KVM: add guest SEA support 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=58A445D5.7030501@arm.com \
--to=james.morse@arm$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox