If the crystal frequency cannot be determined via CPUID(15).crystal_khz or
the built-in table then native_calibrate_tsc() will still set the
X86_FEATURE_TSC_KNOWN_FREQ flag which prevents the refined TSC calibration.
As a consequence such systems use cpu_khz for the TSC frequency which is
incorrect when cpu_khz != tsc_khz resulting in time drift.
Return early when the crystal frequency cannot be retrieved without setting
the X86_FEATURE_TSC_KNOWN_FREQ flag. This ensures that the refined TSC
calibration is invoked.
[ tglx: Steam-blastered changelog. Sigh ]
Fixes: 4ca4df0b7eb0 ("x86/tsc: Mark TSC frequency determined by CPUID as known")
Signed-off-by: Len Brown <email address hidden>
Signed-off-by: Thomas Gleixner <email address hidden>
Cc: <email address hidden>
Cc: Bin Gao <email address hidden>
Cc: <email address hidden>
Link: https://lkml.kernel.org/r/0fe2503aa7d7fc69137141fc705541a78101d2b9<email address hidden>
(cherry picked from commit da4ae6c4a0b8dee5a5377a385545d2250fa8cddb)
Signed-off-by: Joseph Salisbury <email address hidden>
Acked-by: Colin Ian King <email address hidden>
Acked-by: Khalid Elmously <email address hidden>
Signed-off-by: Khalid Elmously <email address hidden>
The INTEL_FAM6_SKYLAKE_X hardcoded crystal_khz value of 25MHZ is
problematic:
- SKX workstations (with same model # as server variants) use a 24 MHz
crystal. This results in a -4.0% time drift rate on SKX workstations.
- SKX servers subject the crystal to an EMI reduction circuit that reduces its
actual frequency by (approximately) -0.25%. This results in -1 second per
10 minute time drift as compared to network time.
This issue can also trigger a timer and power problem, on configurations
that use the LAPIC timer (versus the TSC deadline timer). Clock ticks
scheduled with the LAPIC timer arrive a few usec before the time they are
expected (according to the slow TSC). This causes Linux to poll-idle, when
it should be in an idle power saving state. The idle and clock code do not
graciously recover from this error, sometimes resulting in significant
polling and measurable power impact.
Stop using native_calibrate_tsc() for INTEL_FAM6_SKYLAKE_X.
native_calibrate_tsc() will return 0, boot will run with tsc_khz = cpu_khz,
and the TSC refined calibration will update tsc_khz to correct for the
difference.
[ tglx: Sanitized change log ]
Fixes: 6baf3d61821f ("x86/tsc: Add additional Intel CPU models to the crystal quirk list")
Signed-off-by: Len Brown <email address hidden>
Signed-off-by: Thomas Gleixner <email address hidden>
Cc: <email address hidden>
Cc: Prarit Bhargava <email address hidden>
Cc: <email address hidden>
Link: https://lkml.kernel.org/r/ff6dcea166e8ff8f2f6a03c17beab2cb436aa779<email address hidden>
(cherry picked from commit b511203093489eb1829cb4de86e8214752205ac6)
Signed-off-by: Joseph Salisbury <email address hidden>
Acked-by: Colin Ian King <email address hidden>
Acked-by: Khalid Elmously <email address hidden>
Signed-off-by: Khalid Elmously <email address hidden>
Free up the IRQs we request on the suspend path and reallocate them on the
resume path.
Fixes this error:
CPU 111 disable failed: CPU has 9 vectors assigned and there are only 0 available.
Error taking CPU111 down: -34
Non-boot CPUs are not disabled
Enabling non-boot CPUs ...
Signed-off-by: Scott Bauer <email address hidden>
Signed-off-by: Bjorn Helgaas <email address hidden>
Acked-by: Keith Busch <email address hidden>
(cherry picked from commit e2b1820bd5d0962d6f271b0d47c3a0e38647df2f)
Signed-off-by: Joseph Salisbury <email address hidden>
Acked-by: Kleber Souza <email address hidden>
Acked-by: Colin Ian King <email address hidden>
Signed-off-by: Khalid Elmously <email address hidden>
a0ec89d...
by
Kevin Cernekee <email address hidden>
The capability check in nfnetlink_rcv() verifies that the caller
has CAP_NET_ADMIN in the namespace that "owns" the netlink socket.
However, nfnl_cthelper_list is shared by all net namespaces on the
system. An unprivileged user can create user and net namespaces
in which he holds CAP_NET_ADMIN to bypass the netlink_net_capable()
check:
UBUNTU: [debian] use SRCPKGNAME in linux-headers Depends
Use the SRCPKGNAME macro instead of hardcoded "linux" in the Depends for
linux-headers-PKGVER-ABINUM-FLAVOUR, to provide the correct package name
for derivative kernels with a different SRCPKGNAME.
Commit 7d06d5895c15 ("Revert "Bluetooth: btusb: fix QCA...suspend/resume"")
removed the setting of the BTUSB_RESET_RESUME quirk for QCA Rome devices,
instead favoring adding USB_QUIRK_RESET_RESUME quirks in usb/core/quirks.c.
This was done because the DIY BTUSB_RESET_RESUME reset-resume handling
has several issues (see the original commit message). An added advantage
of moving over to the USB-core reset-resume handling is that it also
disables autosuspend for these devices, which is similarly broken on these.
But there are 2 issues with this approach:
1) It leaves the broken DIY BTUSB_RESET_RESUME code in place for Realtek
devices.
2) Sofar only 2 of the 10 QCA devices known to the btusb code have been
added to usb/core/quirks.c and if we fix the Realtek case the same way
we need to add an additional 14 entries. So in essence we need to
duplicate a large part of the usb_device_id table in btusb.c in
usb/core/quirks.c and manually keep them in sync.
This commit instead restores setting a reset-resume quirk for QCA devices
in the btusb.c code, avoiding the duplicate usb_device_id table problem.
This commit avoids the problems with the original DIY BTUSB_RESET_RESUME
code by simply setting the USB_QUIRK_RESET_RESUME quirk directly on the
usb_device.
This commit also moves the BTUSB_REALTEK case over to directly setting the
USB_QUIRK_RESET_RESUME on the usb_device and removes the now unused
BTUSB_RESET_RESUME code.
Lenovo introduced trackpoint compatible sticks with minimum PS/2 commands.
They supposed to reply with 0x02, 0x03, or 0x04 in response to the
"Read Extended ID" command, so we would know not to try certain extended
commands. Unfortunately even some trackpoints reporting the original IBM
version (0x01 firmware 0x0e) now respond with incorrect data to the "Get
Extended Buttons" command:
This change is suggested by Realtek. They guess that the XHCI controller
doesn't have enough buffer, and their guesswork is correct, once the RX
aggregation gets disabled, the issue is gone.
ASMedia is currently working on a real sulotion for this issue.
Dell and ODM confirm the bcdDevice and iSerialNumber is unique for TB16.
Note that TB15 has different bcdDevice and iSerialNumber, which are not
unique values. If you still have TB15, please contact Dell to replace it
with TB16.
BugLink: https://bugs.launchpad.net/bugs/1729674
Cc: Mario Limonciello <email address hidden>
Signed-off-by: Kai-Heng Feng <email address hidden>
Signed-off-by: David S. Miller <email address hidden>
(cherry picked from commit 0b1655143df00ac5349f27b765b2ed13a3ac40ca)
Signed-off-by: Kai-Heng Feng <email address hidden>
Acked-by: Seth Forshee <email address hidden>
Acked-by: Khalid Elmously <email address hidden>
Signed-off-by: Khalid Elmously <email address hidden>
