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 17:06:21 -0400	[thread overview]
Message-ID: <yq1eetkrtf6.fsf@oracle.com> (raw)
In-Reply-To: <1eb896cd-2be1-4225-88d8-5ee590fe063b@gmail.com> (Bernhard Sulzer's message of "Sun, 22 Mar 2020 20:45:31 +0100")


Bernhard,

> # sg_readcap /dev/sdc
> READ CAPACITY (10) indicates device capacity too large
>   now trying 16 byte cdb variant
> Read Capacity results:
>    Protection: prot_en=0, p_type=0, p_i_exponent=0
>    Logical block provisioning: lbpme=0, lbprz=0
>    Last LBA=15628053166 (0x3a3812aae), Number of logical blocks=15628053167
>    Logical block length=512 bytes
>    Logical blocks per physical block exponent=3 [so physical block
> length=4096 bytes]
>    Lowest aligned LBA=0
> Hence:
>    Device size: 8001563221504 bytes, 7630885.3 MiB, 8001.56 GB, 8.00 TB

I sent a patch that I would like you to test. It adds some additional
sanity checking to the block limits handling. Given the VPD output you
sent earlier, I am hoping it will work around the issue.

I still can't explain how the physical block size can be unset given
that it is reported by the device and the capacity is > 0xffffffff. I
even tried to tweak scsi_debug to see if somehow the no_read_capacity_16
flag for card readers happened to be set in your case and caused us to
go down the wrong path. But no. I'm stumped.

Do you have any READ CAPACITY errors or messages in your log? There were
none in the output you sent.

-- 
Martin K. Petersen	Oracle Linux Engineering

  reply	other threads:[~2020-03-22 21:06 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 [this message]
2020-03-22 21:20           ` Bernhard Sulzer
2020-03-22 21:53             ` Bernhard Sulzer
2020-03-22 22:45               ` Martin K. Petersen
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=yq1eetkrtf6.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