lkml.org 
[lkml]   [2024]   [Apr]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH RESEND] x86/tsc: print some log if calibrated tsc freq deviates from original too much

* Lei Chen <lei.chen@smartx.com> wrote:

> In most cases, tsc_khz is refined by hpet on boot. But in a few
> production-level nodes, the refinement fails because calibrated
> freq diviates from origin tsc freq more than 1%. Printing some
> logs will help get this info.
>
> Signed-off-by: Lei Chen <lei.chen@smartx.com>
> ---
> arch/x86/kernel/tsc.c | 9 ++++++++-
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/arch/x86/kernel/tsc.c b/arch/x86/kernel/tsc.c
> index 15f97c0abc9d..a68b16e72df1 100644
> --- a/arch/x86/kernel/tsc.c
> +++ b/arch/x86/kernel/tsc.c
> @@ -1435,8 +1435,15 @@ static void tsc_refine_calibration_work(struct work_struct *work)
> }
>
> /* Make sure we're within 1% */
> - if (abs(tsc_khz - freq) > tsc_khz/100)
> + if (abs(tsc_khz - freq) > tsc_khz/100) {
> + pr_warn("Warning: TSC freq calibrated by [%s]: %lu.%03lu MHz deviates too much from original freq: %lu.%03lu MHz\n",

Yeah, so it wouldn't cost us anything to more precisely define 'too much':

s/deviates too much from
/deviates by more than 1% from

Right?

> + hpet ? "HPET" : "PM_TIMER",
> + (unsigned long)freq / 1000,
> + (unsigned long)freq % 1000,
> + (unsigned long)tsc_khz / 1000,
> + (unsigned long)tsc_khz % 1000);
> goto out;
> + }

The warning makes sense I suppose, if it's one per system and once per
bootup [right?], but I think pr_info() would be plenty enough priority for
this condition - especially as we didn't have the warning before and don't
know how frequent it is?

Thanks,

Ingo

\
 
 \ /
  Last update: 2024-05-27 16:30    [W:0.048 / U:1.004 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site