Paul, what's the best way to figure out these CPU stalls?
The second oops is in blk_mq_map_queue() which is a trivial
two level cpu lookup. I wonder if there's something odd about
cpu numbers on these big old sparc systems?
Something like the debug patch below might shed some light on where the
index goes wrong, but it'll be horribly verbose.
diff --git a/block/blk-mq.c b/block/blk-mq.c
index b5896d4..ef4b35b 100644
--- a/block/blk-mq.c
+++ b/block/blk-mq.c
@@ -1270,7 +1270,12 @@ run_queue:
*/
struct blk_mq_hw_ctx *blk_mq_map_queue(struct request_queue *q, const int cpu)
{
- return q->queue_hw_ctx[q->mq_map[cpu]];
+ int idx;
+
+ printk("cpu: %d\n", cpu);
+ idx = q->mq_map[cpu];
+ printk("queue: %d\n", idx);
+ return q->queue_hw_ctx[idx];
}
EXPORT_SYMBOL(blk_mq_map_queue);
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
