e "changed" hw_max_sectors, dma_max_mapping_size of
dma_dev("dev") and dma_max_mapping_size of sysdev...?
On Mon, 30 Nov 2020 at 17:48, Hans de Goede wrote:
>
> Hi,
>
> On 11/28/20 4:48 PM, Tom Yan wrote:
> > Apparently the former (with the chosen dma_dev) m
For the record,
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/scsi/scsi_host.h?h=v5.10-rc6#n753
On Tue, 1 Dec 2020 at 02:57, Tom Yan wrote:
>
> This maybe?
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/scsi/scsi_lib.
:48PM +0100, Hans de Goede wrote:
> >>>> Hi,
> >>>>
> >>>> On 11/30/20 1:58 PM, Tom Yan wrote:
> >>>>> It's merely a moving of comment moving for/and a no-behavioral-change
> >>>>> adaptation for the reversion.&g
On Mon, 30 Nov 2020 at 21:23, Hans de Goede wrote:
>
> Hi,
>
> On 11/30/20 1:58 PM, Tom Yan wrote:
>
> IMHO the revert of the troublesome commit and the other/new changes really
> should be 2 separate commits. But I will let Alan and Greg have the final
> verdict on this.
It's merely a moving of comment moving for/and a no-behavioral-change
adaptation for the reversion. Similar has been done in the equivalent
patch for the UAS driver (and the reason is stated there).
On Mon, 30 Nov 2020 at 17:50, Hans de Goede wrote:
>
> Hi,
>
> On 11/28/20 4:48
While the change only seemed to have caused issue on uas drives, we
probably want to avoid it in the usb-storage driver as well, until
we are sure it is the right thing to do.
Signed-off-by: Tom Yan
---
drivers/usb/storage/scsiglue.c | 40 +-
drivers/usb/storage
dma_max_mapping_size.
Since the device/size for the clamp that is applied when the scsi request queue
is initialized/allocated is different than the one used here, we invalidate the
early clamping by making a fallback blk_queue_max_hw_sectors() call.
Signed-off-by: Tom Yan
---
drivers/usb/storage/uas.c
Should we still be clamping max_sectors to dma_max_mapping_size(dev)
(for now)? with dev being us->pusb_dev->bus->sysdev and
devinfo->udev->bus->sysdev respectively (i.e. revert only
scsi_add_host_with_dma() to scsi_add_host())?
On Sat, 28 Nov 2020 at 02:12, Hans de Goede wrote:
>
> Hi,
>
> On 11
On 25 August 2016 at 16:03, Shaun Tancheff wrote:
> On Thu, Aug 25, 2016 at 2:01 AM, Tom Yan wrote:
>> Really please just drop this patch. There is no rational reason for
>> you to associate the maximum payload size to the logical sector size.
>
> Been over this many, many
Really please just drop this patch. There is no rational reason for
you to associate the maximum payload size to the logical sector size.
And please stop using the ATA SCSI Response Buffer (ata_scsi_rbuf)
that is used for response to the SCSI layer for SCSI commands that
won't really interact with
&sctpg[6]);
+ put_unaligned_le32(0u, &sctpg[10]);
What I doubted is, if you don't memset (zero-fill) the buffer first,
will other bytes have indeterministic value that causes random
unexpected behavior?
On 25 August 2016 at 06:04, Shaun Tancheff wrote:
> On Wed, Aug
On 25 August 2016 at 05:28, Shaun Tancheff wrote:
> On Wed, Aug 24, 2016 at 12:31 AM, Tom Yan wrote:
>> On 24 August 2016 at 11:33, Martin K. Petersen
>> wrote:
>>>>>>>> "Tom" == Tom Yan writes:
>>>
>>> Tom> Nope, SCS
Btw, I wonder if you need to memset your buffer with 0 first, like
what is done in ata_scsi_rbuf_get.
On 24 August 2016 at 13:57, Tom Yan wrote:
> Never mind. I was a bit lightheaded.
>
> Anyway I don't think you should use ata_scsi_rbuf. It is a buffer
> created and used for
descr() and
ata_format_sct_write_same() of size(s) you need.
On 23 August 2016 at 18:56, Shaun Tancheff wrote:
> On Tue, Aug 23, 2016 at 5:37 AM, Tom Yan wrote:
>> On 22 August 2016 at 04:23, Shaun Tancheff wrote:
>>> +/**
>>> + * ata_format_dsm_trim_descr() - SATL
On 24 August 2016 at 11:33, Martin K. Petersen
wrote:
>>>>>> "Tom" == Tom Yan writes:
>
> Tom> Nope, SCSI Write Same commands does not have payload (or in SCSI
> Tom> terms, parameter list / data-out buffer).
>
> WRITE SAME has a a payload of 1 lo
On 22 August 2016 at 04:23, Shaun Tancheff wrote:
> SATA drives may support write same via SCT. This is useful
> for setting the drive contents to a specific pattern (0's).
>
> Translate a SCSI WRITE SAME 16 command to be either a DSM TRIM
> command or an SCT Write Same command.
>
> Based on the U
d NUMBER OF
BLOCK (to TRIM) field in the CDB and pack ranges according to that.
All we care is the actual TRIM limit of the ATA device (and
conservative concern on bogus ones).
On 23 August 2016 at 08:42, Shaun Tancheff wrote:
> On Tue, Aug 23, 2016 at 2:53 AM, Tom Yan wrote:
>> On 23 A
Hmm,
On 22 August 2016 at 18:00, Shaun Tancheff wrote:
>
> Timeout for WS is 120 seconds so we should be fine there.
>
> The number to look for is the:
>Max. Sustained Transfer Rate OD (MB/s): 190 8TB (180 5TB)
>
> Which means the above drives should complete a 2G write in
> about 10 to 11 se
On 23 August 2016 at 06:20, Shaun Tancheff wrote:
> On Tue, Aug 23, 2016 at 12:26 AM, Tom Yan wrote:
>
>> It is always 1 merely because we prefer sticking to that. Say we want
>> to enable multi-block payload now, it won't be 1 anymore.
>
> Sorry, I though that DSM
On 23 August 2016 at 00:36, Shaun Tancheff wrote:
> On Mon, Aug 22, 2016 at 6:09 PM, Tom Yan wrote:
>> I am not sure about what you mean here. Rejecting SCSI Write Same
>> commands that has its "number of blocks" field set to a value higher
>> than the device'
On 23 August 2016 at 01:01, Shaun Tancheff wrote:
> On Mon, Aug 22, 2016 at 6:49 PM, Tom Yan wrote:
>> The only 512 I can see in the old code is the one in:
>>
>>> - used_bytes = ALIGN(i * 8, 512);
>>
>> where the alignment is necessary because '
The only 512 I can see in the old code is the one in:
> - used_bytes = ALIGN(i * 8, 512);
where the alignment is necessary because 'used_bytes' will be returned
as 'size', which will be used for setting the number of 512-byte block
payload when we construct the ATA taskfile / command. It ma
August 2016 at 22:07, Shaun Tancheff wrote:
> On Mon, Aug 22, 2016 at 3:14 PM, Tom Yan wrote:
>> On 23 August 2016 at 03:43, Shaun Tancheff
>> wrote:
>>>
>>> Why would we enforce upper level limits on something that doesn't
>>> have any?
>>
>
On 22 August 2016 at 04:23, Shaun Tancheff wrote:
> Safely overwriting the attached page to ATA format from the SCSI formatted
> variant.
>
> Signed-off-by: Shaun Tancheff
> ---
> v6:
> - Fix bisect bug reported by Tom Yan
> - Change to use sg_copy_from_buffer as per
On 22 August 2016 at 18:52, Tom Yan wrote:
>
> For the "payload block size" that is "always" 512-byte as per the same
> spec, I don't think we need to concern about it. I think it only
> matters if we want to enable multi-block TRIM payload according to th
On 23 August 2016 at 03:43, Shaun Tancheff wrote:
>>> + if (unmap) {
>>> + /* If trim is not enabled the cmd is invalid. */
>>> + if ((dev->horkage & ATA_HORKAGE_NOTRIM) ||
>>> + !ata_id_has_trim(dev->id)) {
>>> + fp = 1;
>>
sense.
On 23 August 2016 at 03:51, Shaun Tancheff wrote:
> On Mon, Aug 22, 2016 at 2:27 PM, Tom Yan wrote:
>> On 22 August 2016 at 12:23, Shaun Tancheff wrote:
>>> Safely overwriting the attached page to ATA format from the SCSI formatted
>>> variant.
>>&g
On 22 August 2016 at 12:23, Shaun Tancheff wrote:
> Safely overwriting the attached page to ATA format from the SCSI formatted
> variant.
>
> Signed-off-by: Shaun Tancheff
> ---
> v6:
> - Fix bisect bug reported by Tom Yan
> - Change to use sg_copy_from_buffer as per
On 22 August 2016 at 12:23, Shaun Tancheff wrote:
> SATA drives may support write same via SCT. This is useful
> for setting the drive contents to a specific pattern (0's).
>
> Translate a SCSI WRITE SAME 16 command to be either a DSM TRIM
> command or an SCT Write Same command.
>
> Based on the U
ll always mean 64
TRIM entries, even on 4Kn drives, instead of 512.
On 23 August 2016 at 02:00, Shaun Tancheff wrote:
> On Mon, Aug 22, 2016 at 12:02 PM, Tom Yan wrote:
>> On 22 August 2016 at 15:04, Shaun Tancheff
>> wrote:
>>> On Mon, Aug 22, 2016 at 3:33 AM, Tom Yan
On 22 August 2016 at 15:04, Shaun Tancheff wrote:
> On Mon, Aug 22, 2016 at 3:33 AM, Tom Yan wrote:
>> On 22 August 2016 at 08:31, Tom Yan wrote:
>>> As mentioned before, as of the latest draft of ACS-4, nothing about a
>>> larger payload size is mentioned. Conserva
On 22 August 2016 at 08:31, Tom Yan wrote:
> As mentioned before, as of the latest draft of ACS-4, nothing about a
> larger payload size is mentioned. Conservatively speaking, it sort of
*payload block size
> means that we are allowing four 512-byte block payload on 4Kn device
*eight
As mentioned before, as of the latest draft of ACS-4, nothing about a
larger payload size is mentioned. Conservatively speaking, it sort of
means that we are allowing four 512-byte block payload on 4Kn device
regardless of the reported limit in the IDENTIFY DEVICE data. I am
really not sure if it's
On 14 August 2016 at 11:10, Pavel Machek wrote:
>
> It is the case in v4.6. We had change hda->sda for SATA drives long
> time ago, it was stable since that.
Not for me. It has been like forever (even if it wasn't the fact) that
the disk order is not consistent among boots. Only that would
logica
ore enumerating disks from the latter. Sociopaths like me that
put the root filesystem on an UAS drive should really be ignored.
Wait, there's NVMe! Problem solved.
On 14 August 2016 at 10:26, David Lang wrote:
> On Sun, 14 Aug 2016, Tom Yan wrote:
>
>> On 14 August 2016 at 18:07, Tom
On 14 August 2016 at 18:07, Tom Yan wrote:
> On 14 August 2016 at 18:01, Pavel Machek wrote:
>>
>> Since SATA support was merged, certainly since v2.4, and from way
>> before /dev/disk/by-id existed.
>
> I have no idea how "SATA before USB" had been done in
On 14 August 2016 at 18:01, Pavel Machek wrote:
>
> Since SATA support was merged, certainly since v2.4, and from way
> before /dev/disk/by-id existed.
I have no idea how "SATA before USB" had been done in the past (if it
was ever a thing in the kernel), but that has not been the case since
at le
Since when it is expected that SATA disks will always be probed before
USB disks? We can't guarantee that even if we make sure all ata
drivers are loaded before usb-storage/uas. That's why we need
consistent namings (e.g. /dev/disk/by-id/*).
On 14 August 2016 at 17:20, Pavel Machek wrote:
> Hi!
>
On 11 August 2016 at 09:47, Martin K. Petersen
wrote:
>
> Tom> so we can at most allow only a 2-block (well, or 3-block) payload.
>
> We tried turning on multi block payloads and it was a massive disaster.
> Many drives reported that they supported 8 block payloads but actually
> didn't. Instead o
On 11 August 2016 at 02:29, Shaun Tancheff wrote:
>>
>> You are talking about an AF 4Kn drive I suppose? For a 512e drive it
>> should be only ~2G.
>
> I stand corrected. Since all the kernel math is 512 byte sectors you are
> absolutely correct and this isn't an issue at all.
>
> We should report
On 10 August 2016 at 14:31, Tom Yan wrote:
> I don't really know about SCT Write Same but there is one concern I
> could I think of.
>
> libata's SATL would report a maximum write same length base on the
> number of sectors a one-block TRIM payload can describe at mo
On 10 August 2016 at 15:41, David Milburn wrote:
> Hi,
>
> The 168 makes AHCI_CMD_TBL_SZ equal to 2816
>
> AHCI_CMD_TBL_SZ = AHCI_CMD_TBL_HDR_SZ + (AHCI_MAX_SG * 16)
> AHCI_CMD_TBL_SZ = 128 + (168 * 16)
>
> I think if you add in AHCI_CMD_SLOT_SZ (1024) and AHCI_RX_FIS_SZ (256)
> the DMA is 4K alig
On 10 August 2016 at 09:00, Shaun Tancheff wrote:
> static unsigned int ata_scsi_write_same_xlat(struct ata_queued_cmd *qc)
> {
> struct ata_taskfile *tf = &qc->tf;
> struct scsi_cmnd *scmd = qc->scsicmd;
> struct ata_device *dev = qc->dev;
> const u8 *cdb = scmd-
On 10 August 2016 at 11:26, Tejun Heo wrote:
> Hmmm.. why not? The hardware limit is 64k and the driver is using a
Is that referring to the maximum number of entries allowed in the
PRDT, Physical Region Descriptor Table (which is, more precisely,
65535)?
> lower limit of 168 most likely because
I don't really know about SCT Write Same but there is one concern I
could I think of.
libata's SATL would report a maximum write same length base on the
number of sectors a one-block TRIM payload can describe at most, which
is 65535 * 64 = 4194240 (see ata_scsiop_inq_b0 in libata-scsi.c). If
the d
On 10 August 2016 at 14:34, Shaun Tancheff wrote:
>
> You are correct in that we can advertise the larger limit in
> ata_scsi_dev_config() when only SCT write same is supported
> rather than fall back to WS10.
ata_scsi_dev_config()? Not sure if I follow. We should only need to
report Maximum Writ
So the (not so) recent bump of BLK_DEF_MAX_SECTORS from 1024 to 2560
(commit d2be537c3ba3) seemed to have caused trouble to some of the ATA
devices, which were then worked around with ATA_HORKAGE_MAX_SEC_1024.
However, I am suspecting that the bump of BLK_DEF_MAX_SECTORS is not
the "real" cause of
Yes, because it touches an actual ATA drive setting, while D_SENSE is
merely a "software setting" stored in dev->flags to make the kernel
response differently when build sense data.
On 26 July 2016 at 02:30, Tejun Heo wrote:
> On Fri, Jul 22, 2016 at 05:50:18AM +0800, Tom Yan w
Strange. I merely changed the two "char" to "u8". I wonder how the tab
became spaces. Anyway, sorry about that, resending soon.
On 22 July 2016 at 17:59, Sergei Shtylyov
wrote:
> Hello.
>
>
> On 7/22/2016 2:29 AM, tom.t...@gmail.com wrote:
>
>> F
This is actually a bit clumsy. Sending a rewritten version.
On 22 July 2016 at 02:41, wrote:
> From: Tom Yan
>
> Commit 7780081c1f04 ("libata-scsi: Set information sense field for
> invalid parameter") changed how ata_mselect_*() make sure read-only
> bits
As I've mentioned in the comment/message, there is no ATA command
needed to be sent to the device, since it only toggles a bit in
dev->flags. See that there is no ata_taskfile constructed in
ata_mselect_control().
On 22 July 2016 at 05:26, Tejun Heo wrote:
> On Fri, Jul 22, 2016 at 02:41:54AM +08
2:41:52AM +0800, tom.t...@gmail.com wrote:
>> From: Tom Yan
>>
>> ata_mselect_*() would initialize a char array for storing a copy of
>> the current mode page. However, if char was actually signed char,
>> overflow could occur.
>
> Do you mean sign extension?
>
This patch should cause no behavioral change. Even the (removal of)
the redundant bit mask should be a nop. So it seems like a bit of an
overkill to split them.
On 22 July 2016 at 02:45, Sergei Shtylyov
wrote:
> Hello.
>
> On 07/21/2016 09:41 PM, tom.t...@gmail.com wrote:
>
>
The commit has been reverted. The parentheses are actually necessary
since `!=` is of higher precedence than `&`. My bad.
On 21 July 2016 at 15:40, Arnd Bergmann wrote:
> gcc-6.1 warns about possibly ambiguous code that was newly added
> to libata:
>
> drivers/ata/libata-scsi.c: In function 'ata_
by sd, they can use BLOCK LIMITS VPD to
> tell it to do so.
>
>
>> -Original Message-
>> From: Tom Yan [mailto:tom.t...@gmail.com]
>> Sent: Saturday, June 4, 2016 1:41 AM
>> To: Long Li
>> Cc: James E.J. Bottomley ; Martin K. Petersen
>> ; linux-s...@
The main point there is not to check q->limits.max_sectors against
BLK_DEF_MAX_SECTORS, but sdkp->opt_xfer_blocks against
SD_DEF_XFER_BLOCKS et al.? `rw_max = BLK_DEF_MAX_SECTORS;` there is
merely the fallback when sdkp->opt_xfer_blocks does not pass the
conditions. With your patch `rw_max` can be
There seems to be some sort of race condition between
blkdev_issue_zeroout() and the scsi disk driver (disabling write same
after an illegal request). On my UAS drive, sometimes `blkdiscard -z
/dev/sdX` will return right away, even though if I then check
`write_same_max_bytes` it has turned 0. Some
57 matches
Mail list logo
