bad: scheduling while atomic! (00000250 0 8 mtdblockd)
[<c02372d0>] (schedule+0x0/0x490) from [<c0335fd0>] (mtd_blktrans_thread+0x220/0x258)
r7 = 00000000 r6 = C0109FBC r5 = C0108000 r4 = C0109FB8
[<c0335db0>] (mtd_blktrans_thread+0x0/0x258) from [<c0224554>] (kernel_thread+0x40/0x48)
bad: scheduling while atomic! (00000251 0 8 mtdblockd)
[<c02372d0>] (schedule+0x0/0x490) from [<c0335fd0>] (mtd_blktrans_thread+0x220/0x258)
r7 = 00000000 r6 = C0109FBC r5 = C0108000 r4 = C0109FB8
[<c0335db0>] (mtd_blktrans_thread+0x0/0x258) from [<c0224554>] (kernel_thread+0x40/0x48)
bad: scheduling while atomic! (00000252 0 8 mtdblockd)
[<c02372d0>] (schedule+0x0/0x490) from [<c0335fd0>] (mtd_blktrans_thread+0x220/0x258)
r7 = 00000000 r6 = C0109FBC r5 = C0108000 r4 = C0109FB8
[<c0335db0>] (mtd_blktrans_thread+0x0/0x258) from [<c0224554>] (kernel_thread+0x40/0x48)
(The extra numbers are: preempt_count, kernel_locked, pid and comm).
This instance seems to be caused by the following code in
drivers/mtd/mtd_blkdevs.c:
while (!tr->blkcore_priv->exiting) {
spin_lock_irq(rq->queue_lock);
...
spin_unlock_irq(rq->queue_lock);
...
spin_lock_irq(rq->queue_lock);
...
}
It would be useful if we could balance the spin_locks with the
spin_unlocks. 8)
-- Russell King (rmk@arm.linux.org.uk) The developer of ARM Linux http://www.arm.linux.org.uk/personal/aboutme.html- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/