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:
Index: linux-2.6.10/kernel/softirq.c
===================================================================
--- linux-2.6.10.orig/kernel/softirq.c
+++ linux-2.6.10/kernel/softirq.c
@@ -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);
--
George Anzinger [email protected]
High-res-timers: http://sourceforge.net/projects/high-res-timers/
* George Anzinger <[email protected]> wrote:
> 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