On Fri, 22 Jul 2016, Chris Metcalf wrote: > > It already as a stable clocksource. Sorry but that was one of the criteria > > for the server when we ordered them. Could this be clock adjustments? > > We probably need to get clock folks to jump in on this thread! Guess so. I will have a look at this when I get some time again. > Maybe it's disabling some built-in unstable clock just as part of > falling back to using the better, stable clock that you also have? > So maybe there's a way of just disabling that clocksource from the > get-go instead of having it be marked unstable later. This is a standard Dell server. No clocksources are marked as unstable as far as I can tell. > If you run the test again after this storm of unstable marking, does > it all happen again? Or is it a persistent state in the kernel? This happens anytime we try to run with prctl(). I hope to get some more detail once I get some time to look at this. But this is likely an x86 specific problem. -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
