On 2014-11-14 23:48, Meelis Roos wrote:
[ 247.424529] sd 0:0:2:0: [sdc] READ CAPACITY failed [ 247.479803] sd 0:0:2:0: [sdc] [ 247.517288] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [ 247.583978] sd 0:0:2:0: [sdc] [ 247.621487] Sense Key : Not Ready [current] [ 247.672493] sd 0:0:2:0: [sdc] [ 247.710046] Add. Sense: Logical unit not ready, cause not reportable [ 247.788409] sd 0:0:2:0: [sdc] Test WP failed, assume Write Enabled [ 247.861176] sd 0:0:2:0: [sdc] Asking for cache data failed [ 247.926063] sd 0:0:2:0: [sdc] Assuming drive cache: write through [ 248.001337] blk-mq: cpu 14 got queue 1828716544 [ 248.053686] cpu10 -> queue index 809119744 [ 248.104595] cpu11 -> queue index 0 [ 248.147313] cpu14 -> queue index 1828716544 [ 248.199394] cpu15 -> queue index 0 [ 248.244954] sd 0:0:2:0: [sdc] Spinning up disk...
So the issue definitely seems to be related to the fact that this disk misbehaves. The hw queue values aren't random either, in fact they CPU14 mapping is identical to your previous boot, which is0x6d000000. And CPU10's mapping is 0x303a3000.
My next move would be to add more debug to the CPU map setup and teardown, so that we can verify that the map that is being used above has indeed been setup. Unless Christoph has any ideas on what is going on here?
-- Jens Axboe -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
