Messages in this thread Patch in this message | | | Date | Fri, 25 Apr 2008 21:14:06 +0200 | From | bstroesser@fujitsu- ... | Subject | hrtimer: timeout too long when using HRTIMER_CB_SOFTIRQ |
| |
There seems to be a bug in hrtimer, when callback is handled in softirq. Sometimes clockevent is missing, so timers are defered. The patch is for 2.5.22.5, but the problem seems to persist in 2.6.25.
Please CC me, I'm not on the list.
Best regards Bodo
============================================================ When using hrtimer with timer->cb_mode == HRTIMER_CB_SOFTIRQ in some cases the clockevent is not programmed. This happens, if: - a timer is rearmed while it's state is HRTIMER_STATE_CALLBACK - hrtimer_reprogram() returns -ETIME, when it is called after CALLBACK is finished. This occurs if the new timer->expires is in the past when CALLBACK is done. In this case, the timer needs to be removed from the tree and put onto the pending list again.
The patch is against 2.6.22.5, but AFAICS, it is relevant for 2.6.25 also (in run_hrtimer_pending()).
Signed-off-by: Bodo Stroesser <bstroesser@fujitsu-siemens.com> --- kernel/hrtimer.c | 15 +++++++++++++-- 1 file changed, 13 insertions(+), 2 deletions(-)
Index: linux-2.6.22.5-31/kernel/hrtimer.c =================================================================== --- linux-2.6.22.5-31.orig/kernel/hrtimer.c +++ linux-2.6.22.5-31/kernel/hrtimer.c @@ -1124,8 +1124,19 @@ static void run_hrtimer_softirq(struct s * If the timer was rearmed on another CPU, reprogram * the event device. */ - if (timer->base->first == &timer->node) - hrtimer_reprogram(timer, timer->base); + struct hrtimer_clock_base *base = timer->base; + + if (base->first == &timer->node && + hrtimer_reprogram(timer, base)) { + /* + * Timer is expired. Thus move it from tree to + * pending list again. + */ + __remove_hrtimer(timer, base, + HRTIMER_STATE_PENDING, 0); + list_add_tail(&timer->cb_entry, + &base->cpu_base->cb_pending); + } } } spin_unlock_irq(&cpu_base->lock); | |