Message ID | yq1egenwons.fsf@sermon.lab.mkp.net (mailing list archive) |
---|---|
State | Not Applicable, archived |
Headers | show |
On Wed, Dec 16, 2015 at 2:29 AM, Martin K. Petersen <martin.petersen@oracle.com> wrote: >>>>>> "Eryu" == Eryu Guan <guaneryu@gmail.com> writes: > > Eryu, > > Does the patch below fix the issue? No, it can't. As the debug log shows, it is because you use 'OPTIMAL TRANSFER LENGTH' to set queue's max_sectors. Thanks, > > -- > Martin K. Petersen Oracle Linux Engineering > > diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c > index 3d22fc3e3c1a..d1eb7aa78b8d 100644 > --- a/drivers/scsi/sd.c > +++ b/drivers/scsi/sd.c > @@ -2667,8 +2667,9 @@ static void sd_read_block_limits(struct scsi_disk *sdkp) > > if (buffer[3] == 0x3c) { > unsigned int lba_count, desc_count; > + u64 max_ws = get_unaligned_be64(&buffer[36]); > > - sdkp->max_ws_blocks = (u32)get_unaligned_be64(&buffer[36]); > + sdkp->max_ws_blocks = (u32)max_ws; > > if (!sdkp->lbpme) > goto out;
>>>>> "Ming" == Ming Lei <tom.leiming@gmail.com> writes:
Ming,
Ming> No, it can't.
Well, it fixes a problem on one of my test systems where max_ws_blocks,
by virtue of being 64 bits, clobbers opt_xfer_blocks causing rw_len and
thus max_sectors to be set incorrectly.
We haven't run into that issue on real hardware. Probably because
scsi_debug is the only driver reporting $LUDICROUS_NUMBER as the max hw
transfer.
Ming> As the debug log shows, it is because you use 'OPTIMAL TRANSFER
Ming> LENGTH' to set queue's max_sectors.
But that is intentional.
I agree that the value chosen by scsi_debug in this case is very low and
we should fix that.
On Tue, Dec 15, 2015 at 01:29:59PM -0500, Martin K. Petersen wrote: > >>>>> "Eryu" == Eryu Guan <guaneryu@gmail.com> writes: > > Eryu, > > Does the patch below fix the issue? Unfortunately no, still BUG_ON. Thanks, Eryu > > -- > Martin K. Petersen Oracle Linux Engineering > > diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c > index 3d22fc3e3c1a..d1eb7aa78b8d 100644 > --- a/drivers/scsi/sd.c > +++ b/drivers/scsi/sd.c > @@ -2667,8 +2667,9 @@ static void sd_read_block_limits(struct scsi_disk *sdkp) > > if (buffer[3] == 0x3c) { > unsigned int lba_count, desc_count; > + u64 max_ws = get_unaligned_be64(&buffer[36]); > > - sdkp->max_ws_blocks = (u32)get_unaligned_be64(&buffer[36]); > + sdkp->max_ws_blocks = (u32)max_ws; > > if (!sdkp->lbpme) > goto out; -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c index 3d22fc3e3c1a..d1eb7aa78b8d 100644 --- a/drivers/scsi/sd.c +++ b/drivers/scsi/sd.c @@ -2667,8 +2667,9 @@ static void sd_read_block_limits(struct scsi_disk *sdkp) if (buffer[3] == 0x3c) { unsigned int lba_count, desc_count; + u64 max_ws = get_unaligned_be64(&buffer[36]); - sdkp->max_ws_blocks = (u32)get_unaligned_be64(&buffer[36]); + sdkp->max_ws_blocks = (u32)max_ws; if (!sdkp->lbpme) goto out;
>>>>> "Eryu" == Eryu Guan <guaneryu@gmail.com> writes: Eryu, Does the patch below fix the issue?