Re: Another (ESP?) scsi blk-mq problem on sparc64

[Jens Axboe <axboe@kernel.dk>]

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