BUG_ON() in ksoftirqd is a bit too agressive...
PATCH 1/1 BUG_ON() in ksoftirqd is a bit too agressive...
Ksoftirqd is created by init, long after the timer system is up and running. We have hit the BUG_ON(tasklet_... in this code, i.e. tasklets pending at ksoftirqd create time. Since, with the RT option to push all softirq code to a thread, any softirqs are defered to this time, it is easy to hit this bug. Clearly only a problem for cpu 0. Here is a patch:
kernel/softirq.c +6 -2
@@ -514,8 +514,12 @@switch (action) {case CPU_UP_PREPARE : -BUG_ON (per_cpu (tasklet_vec, hotcpu).list); -BUG_ON (per_cpu (tasklet_hi_vec, hotcpu).list); +/* We may have tasklets already scheduled on +processor 0, so don't check there. */ +if (hotcpu !=0 ) { +BUG_ON (per_cpu (tasklet_vec, hotcpu).list); +BUG_ON (per_cpu (tasklet_hi_vec, hotcpu).list); + } p =kthread_create (ksoftirqd, hcpu,"ksoftirqd/%d" , hotcpu);if (IS_ERR (p)) {printk ("ksoftirqd for %i failed\n" , hotcpu);
Signature · 2 lines
George Anzinger [email protected] High-res-timers: http://sourceforge.net/projects/high-res-timers/
Quoted 6 lines · George Anzinger
Ksoftirqd is created by init, long after the timer system is up and running. We have hit the BUG_ON(tasklet_... in this code, i.e. tasklets pending at ksoftirqd create time. Since, with the RT option to push all softirq code to a thread, any softirqs are defered to this time, it is easy to hit this bug. Clearly only a problem for cpu 0. Here is a patch:
thanks, i've applied this to my -RT tree (will show up in .47-05 and later trees).
Ingo