2.6.19.1-rt15: BUG in __tasklet_action at kernel/softirq.c:568

From: Robert Crocombe
Date: Mon Dec 18 2006 - 12:49:32 EST


Almost exactly 24 hours after booting 2.6.19.1-rt15, I encountered the
following:

softirq-tasklet/49[CPU#3]: BUG in __tasklet_action at kernel/softirq.c:568

Call Trace:
[<ffffffff8027aca3>] __WARN_ON+0x5c/0x74
[<ffffffff8027c6e6>] __tasklet_action+0xae/0xf2
[<ffffffff8027cccd>] ksoftirqd+0xfc/0x198
[<ffffffff8027cbd1>] ksoftirqd+0x0/0x198
[<ffffffff8022ed5b>] kthread+0xd1/0x101
[<ffffffff80257bb8>] child_rip+0xa/0x12
[<ffffffff8022ec8a>] kthread+0x0/0x101
[<ffffffff80257bae>] child_rip+0x0/0x12

softirq-tasklet/36[CPU#2]: BUG in __tasklet_action at kernel/softirq.c:568

Call Trace:
[<ffffffff8027aca3>] __WARN_ON+0x5c/0x74
[<ffffffff8027c6e6>] __tasklet_action+0xae/0xf2
[<ffffffff8027cccd>] ksoftirqd+0xfc/0x198
[<ffffffff8027cbd1>] ksoftirqd+0x0/0x198
[<ffffffff8022ed5b>] kthread+0xd1/0x101
[<ffffffff80257bb8>] child_rip+0xa/0x12
[<ffffffff8022ec8a>] kthread+0x0/0x101
[<ffffffff80257bae>] child_rip+0x0/0x12

softirq-tasklet/49[CPU#3]: BUG in __tasklet_action at kernel/softirq.c:568

Call Trace:
[<ffffffff8027aca3>] __WARN_ON+0x5c/0x74
[<ffffffff8027c6e6>] __tasklet_action+0xae/0xf2
[<ffffffff8027cccd>] ksoftirqd+0xfc/0x198
[<ffffffff8027cbd1>] ksoftirqd+0x0/0x198
[<ffffffff8022ed5b>] kthread+0xd1/0x101
[<ffffffff80257bb8>] child_rip+0xa/0x12
[<ffffffff8022ec8a>] kthread+0x0/0x101
[<ffffffff80257bae>] child_rip+0x0/0x12

softirq-tasklet/49[CPU#3]: BUG in __tasklet_action at kernel/softirq.c:568

Call Trace:
[<ffffffff8027aca3>] __WARN_ON+0x5c/0x74
[<ffffffff8027c6e6>] __tasklet_action+0xae/0xf2
[<ffffffff8027cccd>] ksoftirqd+0xfc/0x198
[<ffffffff8027cbd1>] ksoftirqd+0x0/0x198
[<ffffffff8022ed5b>] kthread+0xd1/0x101
[<ffffffff80257bb8>] child_rip+0xa/0x12
[<ffffffff8022ec8a>] kthread+0x0/0x101
[<ffffffff80257bae>] child_rip+0x0/0x12

I had set the machine to do 1,000 kernel compiles the day before, but
it might have been finished by then (the BUG triggered on a Saturday).
I did this because it was kernel compiles that previously triggered a
hard lockup on -rt kernels. The machine seems to still be usable, and
the compiles all completed.

The referenced line is:
/*
* After this point on the tasklet might be rescheduled
* on another CPU, but it can only be added to another
* CPU's tasklet list if we unlock the tasklet (which we
* dont do yet).
*/
if (!test_and_clear_bit(TASKLET_STATE_SCHED, &t->state))
WARN_ON(1);

This is a quad Opteron. Config attached.

--
Robert Crocombe

Attachment: config_2.6.19.1-rt15
Description: Binary data