On 12 May 2016 at 12:04, Fam Zheng <f...@redhat.com> wrote: > > Following is: > > else > rw_max = BLK_DEF_MAX_SECTORS; > > Which seems in sector unit, and is already making above change suspicious, and
Yes BLK_DEF_MAX_SECTORS is in sector unit. It has been bumped from 1024 to 2560 not long ago btw: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/include/linux/blkdev.h?id=d2be537c3ba3568acd79cd178327b842e60d035e I suppose the code should be changed to something like this: ... { rw_max = sdkp->opt_xfer_blocks; q->limits.io_opt = rw_max * sdp->sector_size; } > further down: > > /* Combine with controller limits */ > q->limits.max_sectors = min(rw_max, queue_max_hw_sectors(q)); > > looks like a unit mismatch to me. IIUC q->limits.max_sectors _is_ in sector > unit, similar to queue_max_hw_sectors(). > > Is the error reported by Christian fixed just because we are setting an > incorrect high max? However in the worst case max_sectors should still be limited by max_hw_sectors, which apparently depends on the host. For example uas devices (without any quirks) have max_hw_sectors set to 1024 (SCSI_DEFAULT_MAX_SECTORS defined in include/scsi/scsi_host.h). Speaking of this, shouldn't SCSI_DEFAULT_MAX_SECTORS be increased? For example at least to the new BLK_DEF_MAX_SECTORS (2560), or maybe even SD_DEF_XFER_BLOCKS (65535)? -- 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
