Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
DescriptionAkshay Ratnaparkhe
2021-05-05 17:19:35 UTC
Description of problem:
(Below details were shared by the customer).
o Incorrect TSC calibration for overclocked BCLK
o In case of platforms overclocked by bumping BCLK (bus frequency) one ends up with TSC impacted as well.
o On one such hardware that we've evaluated we've seen TSC go up from the nominal 3.4GHz to 3.502GHz.
This was evidenced by the output of turbostat (see attachement).
o Due to the way the kernel performs TSC calibration, the discovered frequency is still the nominal 3.4GHz as shown by dmesg.
-----------------------------------------------------
> dmesg | grep "tsc: Detected"
[ 0.000000] tsc: Detected 3400.000 MHz processor
-----------------------------------------------------
o Modern kernels heavily rely on CPUID to obtain crystal frequency for the TSC (which for our Xeon 6246R SKU is 3.4GHz). With the actual frequency of TSC at 3502MHz the sfptp daemon will never be able to settle at stable freq adjust values and fail to synchronize the system clock against the NIC. Other kernel subsystems that rely on correctly identifying current frequency will also be impacted.
o This can be addressed by forcing the kernel to resort to using MSR rather than CPUID for obtaining TSC frequency in native_calibrate_cpu(void) (see attachement).
o Introducing additional kernel cmdline params to drive calibration method (ie. disabling cpuid as calibration source) would entirely solve this edge case without changing the default behaviour. Such change was successfully tested in customer's environments.
* Important Note:
o Customer has also given link of conversation in between Red Hat and Supermicro and wants to get follow up on the same.
https://lore.kernel.org/lkml/1543865843219.51523@supermicro.com/T/
OR https://marc.info/?t=153151085300010&r=1&w=2
* Request:
Is it possible to merge this patch in RHEL 8?
Version-Release number of selected component (if applicable):
RHEL 8.3.
How reproducible:
Customer has mentioned that it is always reproducible.
Steps to Reproduce:
Not known.
Actual results:
o overclocking impacts PTP clock synchronisation.
Expected results:
o Overclocking should not impact PTP clock synchronisation.
Additional info:
N/A.
Comment 1Akshay Ratnaparkhe
2021-05-05 17:21:59 UTC
Does the "tsc_early_khz=" parameter help?
tsc_early_khz= [X86] Skip early TSC calibration and use the given
value instead. Useful when the early TSC frequency discovery
procedure is not reliable, such as on overclocked systems
with CPUID.16h support and partial CPUID.15h support.
Format: <unsigned int>
P.
Comment 27RHEL Program Management
2021-11-29 16:00:27 UTC
Development Management has reviewed and declined this request. You may appeal this decision by reopening this request.
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory (Important: kernel security, bug fix, and enhancement update), and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.
https://access.redhat.com/errata/RHSA-2022:1988