On Fri, 17 Feb 2017, Frederic Weisbecker wrote: > On Thu, Feb 16, 2017 at 08:34:45PM +0100, Thomas Gleixner wrote: > > On Thu, 16 Feb 2017, Frederic Weisbecker wrote: > > > On Thu, Feb 16, 2017 at 10:20:14AM -0800, Linus Torvalds wrote: > > > > On Thu, Feb 16, 2017 at 10:13 AM, Frederic Weisbecker > > > > <fweisbec@xxxxxxxxx> wrote: > > > > > > > > > > I haven't followed the discussion but this patch has a known issue which is fixed > > > > > with: > > > > > 7bdb59f1ad474bd7161adc8f923cdef10f2638d1 > > > > > "tick/nohz: Fix possible missing clock reprog after tick soft restart" > > > > > > > > > > I hope this fixes your issue. > > > > > > > > No, Pavel saw the problem with rc8 too, which already has that fix. > > > > > > > > So I think we'll just need to revert that original patch (and that > > > > means that we have to revert the commit you point to as well, since > > > > that ->next_tick field was added by the original commit). > > > > > > Aw too bad, but indeed that late we don't have the choice. > > > > Hint: Look for CPU hotplug interaction of these patches. I bet something > > becomes stale when the CPU goes down and does not get reset when it comes > > back online. > > Indeed I should check that. But Pavel is seeing this on boot, where the I don't think so. He observed it on suspend resume and by doing hotplug operations in a loop. But I might be wrong as usual. > only hotplug operations that happen are CPU UP without preceding CPU DOWN > that may have retained stale values. I think the value of ts->next_tick should > be initially 0 for all CPUs. So perhaps that 0 value confuses stuff. But > looking at the code I don't see how. It maybe something more subtle. >
