lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Thu, 16 Jan 2020 23:04:50 +0100
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Vipul Kumar <vipulk0511@...il.com>
Cc:     linux-kernel@...r.kernel.org,
        Srikanth Krishnakar <Srikanth_Krishnakar@...tor.com>,
        Cedric Hombourger <Cedric_Hombourger@...tor.com>,
        Vipul Kumar <vipul_kumar@...tor.com>, x86@...nel.org,
        Bin Gao <bin.gao@...ux.intel.com>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Len Brown <len.brown@...el.com>
Subject: Re: [PATCH] x86/tsc: Unset TSC_KNOWN_FREQ and TSC_RELIABLE flags on Intel Bay Trail SoC

Vipul,

please always CC the relevant maintainers. Aside of that it's good
practice to CC the author of a particular commit you identified.

Vipul Kumar <vipulk0511@...il.com> writes:

> From: Vipul Kumar <vipul_kumar@...tor.com>
>
> 'commit f3a02ecebed7 ("x86/tsc: Set TSC_KNOWN_FREQ and TSC_RELIABLE
> flags on Intel Atom SoCs")', causing time drift for Bay trail SoC.
> These flags are set for SoCs having cpuid_level 0x15 or more.
> Bay trail is having cpuid_level 0xb.

Which is completely irrelevant. These CPUs read their frequency from
MSRs not from CPUID.

> So, unset both flags to make sure the clocksource calibration can
> be done.

That's going to break tons of ATOM SoC based systems which have neither
HPET not PIT.

Aside of that on some systems HPET/PIT based calibration is not really
more accurate than the MSR based frequency, quite the contrary.

Can you please provide detailed data about the problem you are trying to
solve? 'time drift' is pretty unspecific.

Thanks,

        tglx

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ