From: Shuai Xue <xueshuai@linux.alibaba.com>
To: "Luck, Tony" <tony.luck@intel.com>,
"Rafael J. Wysocki" <rafael@kernel.org>
Cc: linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org,
bp@alien8.de, james.morse@arm.com, lenb@kernel.org,
rjw@rjwysocki.net, zhangliguang@linux.alibaba.com,
zhuo.song@linux.alibaba.com
Subject: Re: [PATCH v3] ACPI, APEI, EINJ: Relax platform response timeout to 1 second.
Date: Wed, 27 Oct 2021 10:18:35 +0800 [thread overview]
Message-ID: <cf577ea6-1b9d-210c-24d5-660f2ad5757a@linux.alibaba.com> (raw)
In-Reply-To: <YXg1bWBKja/tqScg@agluck-desk2.amr.corp.intel.com>
Hi Tony,
Thank you for your patient revision. :)
Cheers,
Shuai
On 2021/10/27 AM1:05, Luck, Tony wrote:
> On Tue, Oct 26, 2021 at 03:28:29PM +0800, Shuai Xue wrote:
>> When injecting an error into the platform, the OSPM executes an
>> EXECUTE_OPERATION action to instruct the platform to begin the injection
>> operation. And then, the OSPM busy waits for a while by continually
>> executing CHECK_BUSY_STATUS action until the platform indicates that the
>> operation is complete. More specifically, the platform is limited to
>> respond within 1 millisecond right now. This is too strict for some
>> platforms.
>>
>> For example, in Arm platform, when injecting a Processor Correctable error,
>> the OSPM will warn:
>> Firmware does not respond in time.
>>
>> And a message is printed on the console:
>> echo: write error: Input/output error
>>
>> We observe that the waiting time for DDR error injection is about 10 ms and
>> that for PCIe error injection is about 500 ms in Arm platform.
>>
>> In this patch, we relax the response timeout to 1 second.
>>
>> Signed-off-by: Shuai Xue <xueshuai@linux.alibaba.com>
>
> Reviewed-by: Tony Luck <tony.luck@intel.com>
>
> Rafael: Do you want to take this in the acpi tree? If not, I can
> apply it to the RAS tree (already at -rc7, so in next merge cycle
> after 5.16-rc1 comes out).
>
>> ---
>> Changelog v2 -> v3:
>> - Implemented the timeout in usleep_range instead of msleep.
>> - Dropped command line interface of timeout.
>> - Link to the v1 patch: https://lkml.org/lkml/2021/10/14/1402
>> ---
>> drivers/acpi/apei/einj.c | 15 ++++++++-------
>> 1 file changed, 8 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/acpi/apei/einj.c b/drivers/acpi/apei/einj.c
>> index 133156759551..6e1ff4b62a8f 100644
>> --- a/drivers/acpi/apei/einj.c
>> +++ b/drivers/acpi/apei/einj.c
>> @@ -28,9 +28,10 @@
>> #undef pr_fmt
>> #define pr_fmt(fmt) "EINJ: " fmt
>>
>> -#define SPIN_UNIT 100 /* 100ns */
>> -/* Firmware should respond within 1 milliseconds */
>> -#define FIRMWARE_TIMEOUT (1 * NSEC_PER_MSEC)
>> +#define SLEEP_UNIT_MIN 1000 /* 1ms */
>> +#define SLEEP_UNIT_MAX 5000 /* 5ms */
>> +/* Firmware should respond within 1 seconds */
>> +#define FIRMWARE_TIMEOUT (1 * USEC_PER_SEC)
>> #define ACPI5_VENDOR_BIT BIT(31)
>> #define MEM_ERROR_MASK (ACPI_EINJ_MEMORY_CORRECTABLE | \
>> ACPI_EINJ_MEMORY_UNCORRECTABLE | \
>> @@ -171,13 +172,13 @@ static int einj_get_available_error_type(u32 *type)
>>
>> static int einj_timedout(u64 *t)
>> {
>> - if ((s64)*t < SPIN_UNIT) {
>> + if ((s64)*t < SLEEP_UNIT_MIN) {
>> pr_warn(FW_WARN "Firmware does not respond in time\n");
>> return 1;
>> }
>> - *t -= SPIN_UNIT;
>> - ndelay(SPIN_UNIT);
>> - touch_nmi_watchdog();
>> + *t -= SLEEP_UNIT_MIN;
>> + usleep_range(SLEEP_UNIT_MIN, SLEEP_UNIT_MAX);
>> +
>> return 0;
>> }
>>
>> --
>> 2.20.1.12.g72788fdb
>>
next prev parent reply other threads:[~2021-10-27 2:18 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-15 3:38 [PATCH] ACPI, APEI, EINJ: Relax platform response timeout to 1 second Shuai Xue
2021-10-15 15:37 ` Luck, Tony
2021-10-17 4:06 ` Shuai Xue
2021-10-18 15:40 ` Luck, Tony
2021-10-19 13:33 ` Shuai Xue
2021-10-22 13:44 ` [PATCH v2] " Shuai Xue
2021-10-22 23:54 ` Luck, Tony
2021-10-24 9:10 ` Shuai Xue
2021-10-25 12:49 ` Shuai Xue
2021-10-25 15:59 ` Luck, Tony
2021-10-26 7:28 ` [PATCH v3] " Shuai Xue
2021-10-26 17:05 ` Luck, Tony
2021-10-27 2:18 ` Shuai Xue [this message]
2021-10-27 18:24 ` Rafael J. Wysocki
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=cf577ea6-1b9d-210c-24d5-660f2ad5757a@linux.alibaba.com \
--to=xueshuai@linux.alibaba.com \
--cc=bp@alien8.de \
--cc=james.morse@arm.com \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rafael@kernel.org \
--cc=rjw@rjwysocki.net \
--cc=tony.luck@intel.com \
--cc=zhangliguang@linux.alibaba.com \
--cc=zhuo.song@linux.alibaba.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox