Messages in this thread | | | From | Daniel Drake <> | Date | Mon, 12 Aug 2019 14:16:02 +0800 | Subject | Re: [PATCH] x86/apic: Handle missing global clockevent gracefully |
| |
On Fri, Aug 9, 2019 at 8:54 PM Thomas Gleixner <tglx@linutronix.de> wrote: > Some newer machines do not advertise legacy timers. The kernel can handle > that situation if the TSC and the CPU frequency are enumerated by CPUID or > MSRs and the CPU supports TSC deadline timer. If the CPU does not support > TSC deadline timer the local APIC timer frequency has to be known as well. > > Some Ryzens machines do not advertize legacy timers, but there is no > reliable way to determine the bus frequency which feeds the local APIC > timer when the machine allows overclocking of that frequency. > > As there is no legacy timer the local APIC timer calibration crashes due to > a NULL pointer dereference when accessing the not installed global clock > event device. > > Switch the calibration loop to a non interrupt based one, which polls > either TSC (frequency known) or jiffies. The latter requires a global > clockevent. As the machines which do not have a global clockevent installed > have a known TSC frequency this is a non issue. For older machines where > TSC frequency is not known, there is no known case where the legacy timers > do not exist as that would have been reported long ago.
This solves the problem I described in the thread: setup_boot_APIC_clock() NULL dereference during early boot on reduced hardware platforms
Thanks for your quick support!
> Note: Only lightly tested, but of course not on an affected machine. > > If that works reliably, then this needs some exhaustive testing > on a wide range of systems so we can risk backports to stable > kernels.
I can do a bit of testing on other platforms too. Are there any specific tests I should run, other than checking that the system boots and doesn't have any timer watchdog complaints in the log?
Thanks Daniel
| |