On 12/11/2014 10:26 AM, Santosh Shukla wrote:
On 11 December 2014 at 10:14, Preeti U Murthy preeti@linux.vnet.ibm.com wrote:
On 12/10/2014 06:22 PM, Viresh Kumar wrote:
On 10 December 2014 at 18:03, Preeti U Murthy preeti@linux.vnet.ibm.com wrote:
Right. We get an interrupt when nobody had asked for it to be delivered or had asked for it to be delivered and later canceled the request. It is most often in the latter situation, that there can be race conditions. If these race conditions are not taken care of, they can result in spurious interrupts.
But the delta time will be very small then, right ?
I was talking of the case where we get an interrupt from the clockevent device but dont find the hrtimer to service and not really of an anomaly in timekeeping. For instance one of the issues that we had seen earlier wherein we cancel the tick-sched-timer before going tickless, but since we had programmed the clock event device to fire, we get a spurious interrupt.
I verified this case before reporting; In my case tick_sched_timer do get cancelled before expire duration but then clk_evt_device get reprogrammed for next time node in list. __remove_hrtimer() takes care of that.
Right. The scenario I described happens in the Low Resolution Mode. You are right, this does not happen in the High Resolution Mode.
Regards Preeti U Murthy