Micke,
On Thu, Feb 25 2021 at 12:18, Mikael Beckius wrote:
>> The proposed change breaks the reprogramming logic. To keep it working
>> cpu_base::*expires_next is only updated by hrtimer_reprogram() and
>> hrtimer_interrupt(). I will send you a patch for testing in reply to this
>> thread. The pa
> The proposed change breaks the reprogramming logic. To keep it working
> cpu_base::*expires_next is only updated by hrtimer_reprogram() and
> hrtimer_interrupt(). I will send you a patch for testing in reply to this
> thread. The patch is compile tested only.
>
Ok. I kind of guessed that would b
Hi Micke,
On Fri, 12 Feb 2021, Beckius, Mikael wrote:
> Thanks for the update and sorry for the late reply. After long-term
> testing of the patch, storm detection improved, it turns out that a
> similar problem can occur if hrtimer_interrupt runs during
> clock_settime. In this case it seems the
Thanks for the update and sorry for the late reply. After long-term testing of
the patch, storm detection improved, it turns out that a similar problem can
occur if hrtimer_interrupt runs during clock_settime. In this case it seems the
offset can get updated and later read using hrtimer_update_b
On Thu, Jan 28 2021 at 15:02, Mikael Beckius wrote:
> During clock_settime absolute realtime timers may get updated to expire
> sooner in absolute monotonic time but if hrtimer_force_reprogram is
> called as part of a clock_settime and the next hard hrtimer expires
> before the next soft hrtimer s
During clock_settime absolute realtime timers may get updated to expire
sooner in absolute monotonic time but if hrtimer_force_reprogram is
called as part of a clock_settime and the next hard hrtimer expires
before the next soft hrtimer softirq_expires_next will not be updated
to reflect this chang
6 matches
Mail list logo
