| Message ID | 20231117063220.65093-5-mario.limonciello@amd.com |
|---|---|
| State | Superseded |
| Headers | show |
| Series | Extend time to wait for UIP for some callers | expand |
W dniu 17.11.2023 o 07:32, Mario Limonciello pisze: > Specs don't say anything about UIP being cleared within 10ms. They > only say that UIP won't occur for another 244uS. If a long NMI occurs > while UIP is still updating it might not be possible to get valid > data in 10ms. > > This has been observed in the wild that around s2idle some calls can > take up to 480ms before UIP is clear. > > Adjust callers from outside an interrupt context to wait for up to a > 1s instead of 10ms. > > Reported-by: xmb8dsv4@gmail.com > Closes: https://bugzilla.kernel.org/show_bug.cgi?id=217626 > Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> > --- > arch/x86/kernel/rtc.c | 2 +- > drivers/base/power/trace.c | 2 +- > drivers/rtc/rtc-cmos.c | 2 +- > drivers/rtc/rtc-mc146818-lib.c | 2 +- > 4 files changed, 4 insertions(+), 4 deletions(-) Consider: Fixes: ec5895c0f2d8 ("rtc: mc146818-lib: extract mc146818_avoid_UIP") If you would like to Cc: stable this patch, commit d2a632a8a117 ("rtc: mc146818-lib: reduce RTC_UIP polling period") is a prerequisite. Greetings, Mateusz
diff --git a/arch/x86/kernel/rtc.c b/arch/x86/kernel/rtc.c index 961ebc7f1872..2e7066980f3e 100644 --- a/arch/x86/kernel/rtc.c +++ b/arch/x86/kernel/rtc.c @@ -67,7 +67,7 @@ void mach_get_cmos_time(struct timespec64 *now) return; } - if (mc146818_get_time(&tm, 10)) { + if (mc146818_get_time(&tm, 1000)) { pr_err("Unable to read current time from RTC\n"); now->tv_sec = now->tv_nsec = 0; return; diff --git a/drivers/base/power/trace.c b/drivers/base/power/trace.c index c2e925357474..cd6e559648b2 100644 --- a/drivers/base/power/trace.c +++ b/drivers/base/power/trace.c @@ -120,7 +120,7 @@ static unsigned int read_magic_time(void) struct rtc_time time; unsigned int val; - if (mc146818_get_time(&time, 10) < 0) { + if (mc146818_get_time(&time, 1000) < 0) { pr_err("Unable to read current time from RTC\n"); return 0; } diff --git a/drivers/rtc/rtc-cmos.c b/drivers/rtc/rtc-cmos.c index 16dcbd196ce2..345897dadb91 100644 --- a/drivers/rtc/rtc-cmos.c +++ b/drivers/rtc/rtc-cmos.c @@ -231,7 +231,7 @@ static int cmos_read_time(struct device *dev, struct rtc_time *t) if (!pm_trace_rtc_valid()) return -EIO; - ret = mc146818_get_time(t, 10); + ret = mc146818_get_time(t, 1000); if (ret < 0) { dev_err_ratelimited(dev, "unable to read current time\n"); return ret; diff --git a/drivers/rtc/rtc-mc146818-lib.c b/drivers/rtc/rtc-mc146818-lib.c index 75b2fc1791e6..c6f5db6521dd 100644 --- a/drivers/rtc/rtc-mc146818-lib.c +++ b/drivers/rtc/rtc-mc146818-lib.c @@ -87,7 +87,7 @@ EXPORT_SYMBOL_GPL(mc146818_avoid_UIP); */ bool mc146818_does_rtc_work(void) { - return mc146818_avoid_UIP(NULL, 10, NULL); + return mc146818_avoid_UIP(NULL, 1000, NULL); } EXPORT_SYMBOL_GPL(mc146818_does_rtc_work);
Specs don't say anything about UIP being cleared within 10ms. They only say that UIP won't occur for another 244uS. If a long NMI occurs while UIP is still updating it might not be possible to get valid data in 10ms. This has been observed in the wild that around s2idle some calls can take up to 480ms before UIP is clear. Adjust callers from outside an interrupt context to wait for up to a 1s instead of 10ms. Reported-by: xmb8dsv4@gmail.com Closes: https://bugzilla.kernel.org/show_bug.cgi?id=217626 Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> --- arch/x86/kernel/rtc.c | 2 +- drivers/base/power/trace.c | 2 +- drivers/rtc/rtc-cmos.c | 2 +- drivers/rtc/rtc-mc146818-lib.c | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-)