Re: [PATCH resend] clocksource: Defer override invalidation unless clock is unstable

On Wed, Jul 27, 2016 at 6:50 AM, Kyle Walker wrote: > On Tue, Jul 26, 2016 at 5:36 PM, John Stultz wrote: >> The logic here is confusing as well. So.. if the override is not HRT >> compatible, we check if its stable or not? Once we're in HRT there's >> not much likelyhood of us going into non HR

Re: [PATCH resend] clocksource: Defer override invalidation unless clock is unstable

Good evening John, On Wed, Jul 27, 2016 at 10:29 AM, Kyle Walker wrote: > The issue I'm running into is that the override is not HRT compatible yet. > Though it will be later in the boot process, unless the clocksource watchdog > marks the clocksource as unstable. > > The issue with the current i

Re: [PATCH resend] clocksource: Defer override invalidation unless clock is unstable

I'm so sorry for the duplicate, gmail managed to sneak in some HTML. Resending due to the mailing list correctly blocking the initial send. On Tue, Jul 26, 2016 at 5:36 PM, John Stultz wrote: > Sorry for not getting back to you. This has been in my to-look-at list. No problem at all. Thanks for

Re: [PATCH resend] clocksource: Defer override invalidation unless clock is unstable

Sorry for not getting back to you. This has been in my to-look-at list. On Tue, Jul 26, 2016 at 2:24 PM, Kyle Walker wrote: > The clock_select() operation will attempt to use the clocksource override > to apply the desired clocksource when the "clocksource=" boot parameter is > supplied. However,

[PATCH resend] clocksource: Defer override invalidation unless clock is unstable

The clock_select() operation will attempt to use the clocksource override to apply the desired clocksource when the "clocksource=" boot parameter is supplied. However, in the event that "clocksource=tsc" is used on a system where there is a more desireable clocksource available, the boot parameter