Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
IronPort-SDR: 9aqHKmCrQKHvtOL42oRZW8N3I+i6/7Acy85xh8lgDd+dprZx1Sm8kEsgofRWpwS8Hd3qVWM+U3
 I+FHlO/6SW9WptLqM8RePkmvPk73RiuDFZGwQhJzDn4KbzOplpL+RjYAmL+EJGN4vAdzocFu6L
 miASWE0vpzxuR51TrukHmwcyCjVqhbeT8pYokkbLPSucKRlBCUEodHuYCZgVEZ2wdOYpKQBVh/
 bAcdRvaUsGMshJs2gLb1LJMVKV6IE4W5qXX84l+jJTEsrRqA+gc+LKrj0Z1fnBprR6P1n1cIZL
 J0k=
From:   Damien Le Moal <Damien.LeMoal@wdc.com>
To:     "Martin K. Petersen" <martin.petersen@oracle.com>,
        Justin Piszcz <jpiszcz@lucidpixels.com>
CC:     'LKML' <linux-kernel@vger.kernel.org>,
        "linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
        "linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>
Subject: Re: 5.2.x kernel: WD 8TB USB Drives: Unaligned partial completion
 (resid=78, sector_sz=512)
Thread-Topic: 5.2.x kernel: WD 8TB USB Drives: Unaligned partial completion
 (resid=78, sector_sz=512)
Thread-Index: AdVJ2z/+9mq0jIkOQpG4zabX2Rwi3A==
Date:   Tue, 13 Aug 2019 03:47:09 +0000
Message-ID: <BYAPR04MB5816F39A6F073D77499B8D85E7D20@BYAPR04MB5816.namprd04.prod.outlook.com>
References: <006d01d549db$54e42140$feac63c0$@lucidpixels.com>
 <yq1ftmcct1j.fsf@oracle.com>
 <002d01d54dc3$17c278c0$47476a40$@lucidpixels.com>
 <yq1r25p7qzp.fsf@oracle.com>
Accept-Language: en-US
Content-Language: en-US
wdcipoutbound: EOP-TRUE
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: dd25149d-f910-4736-1432-08d71fa0eb30
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Aug 2019 03:47:09.6310
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: b61c8803-16f3-4c35-9b17-6f65f441df86
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: jrfKNRv1mMJJOWG1csEVkXDkymI2yekgZPM/1YP6D/dttdWXpYZ1+cLmzlQ5GX9hMnxaBjLG8hIyGcyYOuow3Q==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR04MB3942
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 2019/08/12 19:12, Martin K. Petersen wrote:=0A=
> =0A=
> Justin,=0A=
> =0A=
>>> Attached 2 x brand new Western Digital 8TB USB 3.0 drives awhile back=
=0A=
>>> and ran some file copy tests and was getting these warnings-- is=0A=
>>> there any way to avoid these warnings?  I did confirm with parted=0A=
>>> that the partition was aligned but this appears to be something=0A=
>>> related to the firmware on the device according to [1] and [2]?=0A=
> =0A=
>> sg_vpd_bdc.txt=0A=
>> Block device characteristics VPD page (SBC):=0A=
>>   Nominal rotation rate: 5400 rpm=0A=
>>   Product type: Not specified=0A=
>>   WABEREQ=3D0=0A=
>>   WACEREQ=3D0=0A=
>>   Nominal form factor: 3.5 inch=0A=
>>   ZONED=3D0=0A=
> =0A=
> Damien: What can we do to limit the messages in cases like this? Would=0A=
> it make sense to make the residual warning conditional on sd_is_zoned()?=
=0A=
> =0A=
=0A=
These WD drives are regular disks, not SMR. Making the warning conditional =
on=0A=
sd_is_zoned() will not reduce the amount of messages. REPORT ZONES is the o=
nly=0A=
command that could result in a resid not being aligned to the block size si=
nce=0A=
by definition the command reply is composed of 64B zone descriptors. But th=
at=0A=
command is now processed through a device method and is not a REQ_OP_XXX=0A=
anymore, so as an internal req, it does not go through sd_done() for comple=
tion=0A=
right ? All other zone commands either have no buffer, or the exact same=0A=
requirement as regular disks, expecting a block aligned resid. So I think t=
hat=0A=
using sd_is_zoned() is not relevant to this problem.=0A=
=0A=
Bottom line: this USB adapter is weird and likely triggers all the unaligne=
d=0A=
resid. I do get regularly reports of similar problem with SAS HBAs, all alw=
ays=0A=
fixed with HBA FW updates. Not sure if there is a FW available for these dr=
ives.=0A=
I will ask internally.=0A=
=0A=
In the mean time, rate limiting or removing the sd_printk() call may be the=
 only=0A=
option. Failing all commands with an invalid resid would be safer I guess, =
but=0A=
will at best likely cause a lot of retry on these buggy devices, and break =
the=0A=
drive operation/perfomance completely in the worst case.=0A=
=0A=
Or the usb mass storage device driver could add some silent forced resid=0A=
alignment too.=0A=
=0A=
Best regards.=0A=
=0A=
-- =0A=
Damien Le Moal=0A=
Western Digital Research=0A=