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
- Follow-Ups:
- Re: 2.6.19.1-rt15: BUG in __tasklet_action at kernel/softirq.c:568
- From: Ingo Molnar <[email protected]>
- Re: 2.6.19.1-rt15: BUG in __tasklet_action at kernel/softirq.c:568
- Prev by Date: [PATCH] Add a new section to CodingStyle, promoting include/linux/kernel.h.
- Next by Date: Re: [PATCH] Add a new section to CodingStyle, promoting include/linux/kernel.h.
- Previous by thread: [PATCH] Add a new section to CodingStyle, promoting include/linux/kernel.h.
- Next by thread: Re: 2.6.19.1-rt15: BUG in __tasklet_action at kernel/softirq.c:568
- Index(es):