Linux SCSI subsystem development
 help / color / mirror / Atom feed
From: "Martin K. Petersen" <martin.petersen@oracle.com>
To: Bernhard Sulzer <micraft.b@gmail.com>
Cc: "Martin K. Petersen" <martin.petersen@oracle.com>,
	linux-scsi@vger.kernel.org
Subject: Re: Invalid optimal transfer size 33553920 accepted when physical_block_size 512
Date: Sun, 22 Mar 2020 18:45:27 -0400	[thread overview]
Message-ID: <yq14kugrou0.fsf@oracle.com> (raw)
In-Reply-To: <46035460-9d63-2a9a-d37b-514640f8732f@gmail.com> (Bernhard Sulzer's message of "Sun, 22 Mar 2020 22:53:11 +0100")


Bernhard,

> [  105.197403] sd 6:0:0:0: [sdc] Preferred minimum I/O size 512 bytes

In the sg_vpd -p bl output you sent this field was set to 8 blocks
(i.e. 4096 bytes). And in the sg_readcap -l output the physical block
size exponent was reported as 3 (i.e. also 4096 bytes).

But when we inspect these values during device discovery they appear to
be either 0 or 1. What is weird is that if the device somehow updated
them on the fly, I would also expect the optimal transfer length value
to be 0 as well. But it is consistently reported as 0xffff.

Do the reported values change if you do the following a while after you
plugged the drive in?

# lsblk -t
# echo 1 > /sys/block/sdc/device/rescan
# sleep 10
# lsblk -t

The only way I can replicate your results is by making scsi_debug return
zeroes during discovery and then switch to reporting the correct values
after a while. I did a quick hack where I returned zeroes for the
optimal transfer length granularity and the physical block size exponent
the first few times they were requested. That produces results similar
to yours.

I also attached a quick debug patch for capturing some more info.

-- 
Martin K. Petersen	Oracle Linux Engineering


diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c
index e41f8eb00787..e1e3213ab155 100644
--- a/drivers/scsi/sd.c
+++ b/drivers/scsi/sd.c
@@ -2333,6 +2333,11 @@ static int read_capacity_16(struct scsi_disk *sdkp, struct scsi_device *sdp,
 	/* Logical blocks per physical block exponent */
 	sdkp->physical_block_size = (1 << (buffer[13] & 0xf)) * sector_size;
 
+	sd_printk(KERN_ERR, sdkp, "%s: result %d, retries %u\n", __func__,
+		  the_result, retries);
+	sd_printk(KERN_ERR, sdkp, "%s: lbs %u, pbs %u, last LBA %llx\n", __func__,
+		  sector_size, sdkp->physical_block_size, lba);
+
 	/* RC basis */
 	sdkp->rc_basis = (buffer[12] >> 4) & 0x3;
 
@@ -2402,6 +2407,11 @@ static int read_capacity_10(struct scsi_disk *sdkp, struct scsi_device *sdp,
 	sector_size = get_unaligned_be32(&buffer[4]);
 	lba = get_unaligned_be32(&buffer[0]);
 
+	sd_printk(KERN_ERR, sdkp, "%s: result %d, retries %u\n", __func__,
+		  the_result, retries);
+	sd_printk(KERN_ERR, sdkp, "%s: lbs %u, last LBA %llx\n", __func__,
+		  sector_size, lba);
+
 	if (sdp->no_read_capacity_16 && (lba == 0xffffffff)) {
 		/* Some buggy (usb cardreader) devices return an lba of
 		   0xffffffff when the want to report a size of 0 (with
@@ -2438,6 +2448,9 @@ sd_read_capacity(struct scsi_disk *sdkp, unsigned char *buffer)
 	int sector_size;
 	struct scsi_device *sdp = sdkp->device;
 
+	sd_printk(KERN_ERR, sdkp, "%s: rc10_first %u, rc16_first: %u\n",
+		  __func__, sdp->try_rc_10_first, sd_try_rc16_first(sdp));
+
 	if (sd_try_rc16_first(sdp)) {
 		sector_size = read_capacity_16(sdkp, sdp, buffer);
 		if (sector_size == -EOVERFLOW)
@@ -2457,7 +2470,7 @@ sd_read_capacity(struct scsi_disk *sdkp, unsigned char *buffer)
 		if ((sizeof(sdkp->capacity) > 4) &&
 		    (sdkp->capacity > 0xffffffffULL)) {
 			int old_sector_size = sector_size;
-			sd_printk(KERN_NOTICE, sdkp, "Very big device. "
+			sd_printk(KERN_ERR, sdkp, "Very big device. "
 					"Trying to use READ CAPACITY(16).\n");
 			sector_size = read_capacity_16(sdkp, sdp, buffer);
 			if (sector_size < 0) {

  reply	other threads:[~2020-03-22 22:45 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-22 14:32 Invalid optimal transfer size 33553920 accepted when physical_block_size 512 Bernhard Sulzer
2020-03-22 15:45 ` Martin K. Petersen
     [not found]   ` <accd7d25-ee35-11b9-e49b-76e20d9550f2@gmail.com>
     [not found]     ` <yq1pnd4uxof.fsf@oracle.com>
2020-03-22 17:41       ` Bernhard Sulzer
     [not found]     ` <yq1pnd4tbxm.fsf@oracle.com>
2020-03-22 19:45       ` Bernhard Sulzer
2020-03-22 21:06         ` Martin K. Petersen
2020-03-22 21:20           ` Bernhard Sulzer
2020-03-22 21:53             ` Bernhard Sulzer
2020-03-22 22:45               ` Martin K. Petersen [this message]
2020-03-22 23:10                 ` Bernhard Sulzer
2020-03-22 23:22                 ` Bernhard Sulzer
2020-03-22 23:32                   ` Martin K. Petersen
2020-03-22 23:40                     ` Bernhard Sulzer
2020-03-23  1:41                       ` Martin K. Petersen
2020-03-24 13:49                         ` Bryan Gurney
2020-03-24 15:47                       ` [PATCH] scsi: sd: Fix optimal I/O size for devices that change reported values Martin K. Petersen
2020-03-24 15:52                       ` Invalid optimal transfer size 33553920 accepted when physical_block_size 512 Martin K. Petersen
2020-03-24 16:14                         ` Bernhard Sulzer
2020-03-27  0:54                           ` Martin K. Petersen
2020-03-22 20:57 ` [PATCH] scsi: sd: Optimal I/O size should be a multiple of reported granularity Martin K. Petersen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=yq14kugrou0.fsf@oracle.com \
    --to=martin.petersen@oracle.com \
    --cc=linux-scsi@vger.kernel.org \
    --cc=micraft.b@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox