Re: [ANNOUNCE] 3.12.6-rt9
From: Muli Baron <hidden>
Date: 2014-01-21 06:39:23
On 21/1/2014 04:17, Steven Rostedt wrote:
quoted hunk ↗ jump to hunk
On Sat, 18 Jan 2014 04:15:29 +0100 Mike Galbraith [off-list ref] wrote:quoted
quoted
So you also have the timers-do-not-raise-softirq-unconditionally.patch?People have been complaining that the latest 3.12-rt does not boot on intel i7 boxes. And by reverting this patch, it boots fine. I happen to have a i7 box to test on, and sure enough, the latest 3.12-rt locks up on boot and reverting the timers-do-not-raise-softirq-unconditionally.patch, it boots fine. Looking into it, I made this small update, and the box boots. Seems checking "active_timers" is not enough to skip raising softirqs. I haven't looked at why yet, but I would like others to test this patch too. I'll leave why this lets i7 boxes boot as an exercise for Thomas ;-) -- Steve Signed-off-by: Steven Rostedt <rostedt@goodmis.org>diff --git a/kernel/timer.c b/kernel/timer.c index 46467be..8212c10 100644 --- a/kernel/timer.c +++ b/kernel/timer.c@@ -1464,13 +1464,11 @@ void run_local_timers(void) raise_softirq(TIMER_SOFTIRQ); return; } - if (!base->active_timers) - goto out; /* Check whether the next pending timer has expired */ if (time_before_eq(base->next_timer, jiffies)) raise_softirq(TIMER_SOFTIRQ); -out: + rt_spin_unlock_after_trylock_in_irq(&base->lock); } --To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
While this might fix booting on i7 machines it kinds of defeats the original purpose of this patch, which was to let NO_HZ_FULL work properly with threaded interrupts. With the active_timers check removed the timer interrupt keeps firing even though there is only one task running on a specific processor, since it can't shut down the tick because the ksoftirqd thread keeps getting scheduled (see the previous thread "CONFIG_NO_HZ_FULL + CONFIG_PREEMPT_RT_FULL = nogo" for the full discussion). -- Muli