Re: [PATCH 1/2] uas: revert from scsi_add_host_with_dma() to scsi_add_host()

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

Re: [PATCH 2/2] usb-storage: revert from scsi_add_host_with_dma() to scsi_add_host()

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.

Re: [PATCH 2/2] usb-storage: revert from scsi_add_host_with_dma() to scsi_add_host()

: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

Re: [PATCH 2/2] usb-storage: revert from scsi_add_host_with_dma() to scsi_add_host()

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.

Re: [PATCH 2/2] usb-storage: revert from scsi_add_host_with_dma() to scsi_add_host()

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 PM, T

[PATCH 2/2] usb-storage: revert from scsi_add_host_with_dma() to scsi_add_host()

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

[PATCH 1/2] uas: revert from scsi_add_host_with_dma() to scsi_add_host()

the 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

Re: 5.10 regression caused by: "uas: fix sdev->host->dma_dev": many XHCI swiotlb buffer is full / DMAR: Device bounce map failed errors on thunderbolt connected XHCI controller

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

Re: [PATCH v6 3/4 RESEND] SCT Write Same / DSM Trim

On 25 August 2016 at 16:03, Shaun Tancheff <shaun.tanch...@seagate.com> wrote: > On Thu, Aug 25, 2016 at 2:01 AM, Tom Yan <tom.t...@gmail.com> wrote: >> Really please just drop this patch. There is no rational reason for >> you to associate the maximum payload size

Re: [PATCH v6 3/4 RESEND] SCT Write Same / DSM Trim

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, m

Re: [PATCH v6 3/4 RESEND] SCT Write Same / DSM Trim

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

Re: [PATCH v6 3/4 RESEND] SCT Write Same / DSM Trim

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

Re: [PATCH v6 2/4] Add support for SCT Write Same

]); + put_unaligned_le32(0u, [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 <sh...@tancheff.com> wrote: > On Wed, Aug 24, 2016 at 1:10 AM, Tom Y

Re: [PATCH v6 2/4] Add support for SCT Write Same

]); + put_unaligned_le32(0u, [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 24, 2016 at 1:10 AM, Tom Yan wrote: >> Btw, I wond

Re: [PATCH v6 1/4] libata: Safely overwrite attached page in WRITE SAME xlat

On 25 August 2016 at 05:28, Shaun Tancheff <shaun.tanch...@seagate.com> wrote: > On Wed, Aug 24, 2016 at 12:31 AM, Tom Yan <tom.t...@gmail.com> wrote: >> On 24 August 2016 at 11:33, Martin K. Petersen >> <martin.peter...@oracle.com> wrote: >>>>>

Re: [PATCH v6 1/4] libata: Safely overwrite attached page in WRITE SAME xlat

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

Re: [PATCH v6 2/4] Add support for SCT Write Same

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 <tom.t...@gmail.com> wrote: > Never mind. I was a bit lightheaded. > > Anyway I don't think you should use ata_scsi_rbuf. It is a buffer >

Re: [PATCH v6 2/4] Add support for SCT Write Same

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 ata_s

Re: [PATCH v6 2/4] Add support for SCT Write Same

() and ata_format_sct_write_same() of size(s) you need. On 23 August 2016 at 18:56, Shaun Tancheff <shaun.tanch...@seagate.com> wrote: > On Tue, Aug 23, 2016 at 5:37 AM, Tom Yan <tom.t...@gmail.com> wrote: >> On 22 August 2016 at 04:23, Shaun Tancheff <s

Re: [PATCH v6 2/4] Add support for SCT Write Same

() 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 Write

Re: [PATCH v6 1/4] libata: Safely overwrite attached page in WRITE SAME xlat

On 24 August 2016 at 11:33, Martin K. Petersen <martin.peter...@oracle.com> wrote: >>>>>> "Tom" == Tom Yan <tom.t...@gmail.com> writes: > > Tom> Nope, SCSI Write Same commands does not have payload (or in SCSI > Tom> terms, parameter list

Re: [PATCH v6 1/4] libata: Safely overwrite attached page in WRITE SAME xlat

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

Re: [PATCH v6 2/4] Add support for SCT Write Same

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

Re: [PATCH v6 2/4] Add support for SCT Write Same

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

Re: [PATCH v6 1/4] libata: Safely overwrite attached page in WRITE SAME xlat

F 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 <shaun.tanch...@seagate.com> wrote: > On Tue, Aug 23, 2016 at 2:53 AM, Tom Yan &

Re: [PATCH v6 1/4] libata: Safely overwrite attached page in WRITE SAME xlat

F 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 August 2016

Re: [PATCH v6 2/4] Add support for SCT Write Same

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

Re: [PATCH v6 2/4] Add support for SCT Write Same

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

Re: [PATCH v6 1/4] libata: Safely overwrite attached page in WRITE SAME xlat

On 23 August 2016 at 06:20, Shaun Tancheff <shaun.tanch...@seagate.com> wrote: > On Tue, Aug 23, 2016 at 12:26 AM, Tom Yan <tom.t...@gmail.com> wrote: > >> It is always 1 merely because we prefer sticking to that. Say we want >> to enable multi-block payload now, it

Re: [PATCH v6 1/4] libata: Safely overwrite attached page in WRITE SAME xlat

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 TRIM

Re: [PATCH v6 2/4] Add support for SCT Write Same

On 23 August 2016 at 00:36, Shaun Tancheff <shaun.tanch...@seagate.com> wrote: > On Mon, Aug 22, 2016 at 6:09 PM, Tom Yan <tom.t...@gmail.com> wrote: >> I am not sure about what you mean here. Rejecting SCSI Write Same >> commands that has its "number of blocks"

Re: [PATCH v6 2/4] Add support for SCT Write Same

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's rep

Re: [PATCH v6 1/4] libata: Safely overwrite attached page in WRITE SAME xlat

On 23 August 2016 at 01:01, Shaun Tancheff <shaun.tanch...@seagate.com> wrote: > On Mon, Aug 22, 2016 at 6:49 PM, Tom Yan <tom.t...@gmail.com> wrote: >> The only 512 I can see in the old code is the one in: >> >>> - used_bytes = ALIGN(i * 8, 512); &g

Re: [PATCH v6 1/4] libata: Safely overwrite attached page in WRITE SAME xlat

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 'used

Re: [PATCH v6 1/4] libata: Safely overwrite attached page in WRITE SAME xlat

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

Re: [PATCH v6 1/4] libata: Safely overwrite attached page in WRITE SAME xlat

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

Re: [PATCH v6 2/4] Add support for SCT Write Same

6 at 22:07, Shaun Tancheff <shaun.tanch...@seagate.com> wrote: > On Mon, Aug 22, 2016 at 3:14 PM, Tom Yan <tom.t...@gmail.com> wrote: >> On 23 August 2016 at 03:43, Shaun Tancheff <shaun.tanch...@seagate.com> >> wrote: >>> >>> Why would we enfo

Re: [PATCH v6 2/4] Add support for SCT Write Same

6 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? >> >> If we adve

Re: [PATCH v6 1/4] libata: Safely overwrite attached page in WRITE SAME xlat

On 22 August 2016 at 04:23, Shaun Tancheff <sh...@tancheff.com> wrote: > Safely overwriting the attached page to ATA format from the SCSI formatted > variant. > > Signed-off-by: Shaun Tancheff <shaun.tanch...@seagate.com> > --- > v6: > - Fix bisect bug report

Re: [PATCH v6 1/4] libata: Safely overwrite attached page in WRITE SAME xlat

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

Re: [PATCH v6 3/4] SCT Write Same / DSM Trim

On 22 August 2016 at 18:52, Tom Yan <tom.t...@gmail.com> 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 pay

Re: [PATCH v6 3/4] SCT Write Same / DSM Trim

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 the >

Re: [PATCH v6 2/4] Add support for SCT Write Same

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)) { >>> +

Re: [PATCH v6 2/4] Add support for SCT Write Same

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;

Re: [PATCH v6 1/4] libata: Safely overwrite attached page in WRITE SAME xlat

sense. On 23 August 2016 at 03:51, Shaun Tancheff <shaun.tanch...@seagate.com> wrote: > On Mon, Aug 22, 2016 at 2:27 PM, Tom Yan <tom.t...@gmail.com> wrote: >> On 22 August 2016 at 12:23, Shaun Tancheff <sh...@tancheff.com> wrote: >>> Safely overwriting the attac

Re: [PATCH v6 1/4] libata: Safely overwrite attached page in WRITE SAME xlat

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

Re: [PATCH v6 1/4] libata: Safely overwrite attached page in WRITE SAME xlat

On 22 August 2016 at 12:23, Shaun Tancheff <sh...@tancheff.com> wrote: > Safely overwriting the attached page to ATA format from the SCSI formatted > variant. > > Signed-off-by: Shaun Tancheff <shaun.tanch...@seagate.com> > --- > v6: > - Fix bisect bug report

Re: [PATCH v6 1/4] libata: Safely overwrite attached page in WRITE SAME xlat

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

Re: [PATCH v6 2/4] Add support for SCT Write Same

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

Re: [PATCH v6 2/4] Add support for SCT Write Same

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

Re: [PATCH v6 3/4] SCT Write Same / DSM Trim

mean 64 TRIM entries, even on 4Kn drives, instead of 512. On 23 August 2016 at 02:00, Shaun Tancheff <shaun.tanch...@seagate.com> wrote: > On Mon, Aug 22, 2016 at 12:02 PM, Tom Yan <tom.t...@gmail.com> wrote: >> On 22 August 2016 at 15:04, Shaun Tancheff <shaun.tanch...@seag

Re: [PATCH v6 3/4] SCT Write Same / DSM Trim

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 wrote: &g

Re: [PATCH v6 3/4] SCT Write Same / DSM Trim

On 22 August 2016 at 15:04, Shaun Tancheff <shaun.tanch...@seagate.com> wrote: > On Mon, Aug 22, 2016 at 3:33 AM, Tom Yan <tom.t...@gmail.com> wrote: >> On 22 August 2016 at 08:31, Tom Yan <tom.t...@gmail.com> wrote: >>> As mentioned before, as of the

Re: [PATCH v6 3/4] SCT Write Same / DSM Trim

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. Conse

Re: [PATCH v6 3/4] SCT Write Same / DSM Trim

On 22 August 2016 at 08:31, Tom Yan <tom.t...@gmail.com> 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

Re: [PATCH v6 3/4] SCT Write Same / DSM Trim

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

Re: [PATCH v6 3/4] SCT Write Same / DSM Trim

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

Re: [PATCH v6 3/4] SCT Write Same / DSM Trim

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

Re: Regression - SATA disks behind USB ones on v4.8-rc1, breaking boot. [Re: Who reordered my disks (probably v4.8-rc1 problem)]

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

Re: Regression - SATA disks behind USB ones on v4.8-rc1, breaking boot. [Re: Who reordered my disks (probably v4.8-rc1 problem)]

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

Re: Regression - SATA disks behind USB ones on v4.8-rc1, breaking boot. [Re: Who reordered my disks (probably v4.8-rc1 problem)]

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 <da...@lang.hm> wrote: > On Sun, 14 Aug 2016, Tom Yan wrote: > >> On 14 August 2016 at 18:

Re: Regression - SATA disks behind USB ones on v4.8-rc1, breaking boot. [Re: Who reordered my disks (probably v4.8-rc1 problem)]

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 Yan wrote: >>

Re: Regression - SATA disks behind USB ones on v4.8-rc1, breaking boot. [Re: Who reordered my disks (probably v4.8-rc1 problem)]

On 14 August 2016 at 18:07, Tom Yan <tom.t...@gmail.com> wrote: > On 14 August 2016 at 18:01, Pavel Machek <pa...@ucw.cz> wrote: >> >> Since SATA support was merged, certainly since v2.4, and from way >> before /dev/disk/by-id existed. > > I have no i

Re: Regression - SATA disks behind USB ones on v4.8-rc1, breaking boot. [Re: Who reordered my disks (probably v4.8-rc1 problem)]

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

Re: Regression - SATA disks behind USB ones on v4.8-rc1, breaking boot. [Re: Who reordered my disks (probably v4.8-rc1 problem)]

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

Re: Regression - SATA disks behind USB ones on v4.8-rc1, breaking boot. [Re: Who reordered my disks (probably v4.8-rc1 problem)]

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

Re: Regression - SATA disks behind USB ones on v4.8-rc1, breaking boot. [Re: Who reordered my disks (probably v4.8-rc1 problem)]

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

Re: Regression - SATA disks behind USB ones on v4.8-rc1, breaking boot. [Re: Who reordered my disks (probably v4.8-rc1 problem)]

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!

Re: [PATCH v5 2/2] Add support for SCT Write Same

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

Re: [PATCH v5 2/2] Add support for SCT Write Same

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

Re: [PATCH v5 2/2] Add support for SCT Write Same

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

Re: [PATCH v5 2/2] Add support for SCT Write Same

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

Re: [PATCH v5 2/2] Add support for SCT Write Same

On 10 August 2016 at 14:31, Tom Yan <tom.t...@gmail.com> 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 de

Re: [PATCH v5 2/2] Add support for SCT Write Same

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 most, which

Re: Regarding AHCI_MAX_SG and (ATA_HORKAGE_MAX_SEC_1024)

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

Re: Regarding AHCI_MAX_SG and (ATA_HORKAGE_MAX_SEC_1024)

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

Re: [PATCH v5 1/2] Use kmap_atomic when rewriting attached page

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 = >tf; > struct scsi_cmnd *scmd = qc->scsicmd; > struct ata_device *dev = qc->dev; >

Re: [PATCH v5 1/2] Use kmap_atomic when rewriting attached page

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 = >tf; > struct scsi_cmnd *scmd = qc->scsicmd; > struct ata_device *dev = qc->dev; > const u8 *cdb =

Re: Regarding AHCI_MAX_SG and (ATA_HORKAGE_MAX_SEC_1024)

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

Re: Regarding AHCI_MAX_SG and (ATA_HORKAGE_MAX_SEC_1024)

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

Re: [PATCH v5 2/2] Add support for SCT Write Same

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

Re: [PATCH v5 2/2] Add support for SCT Write Same

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

Re: [PATCH v5 2/2] Add support for SCT Write Same

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

Re: [PATCH v5 2/2] Add support for SCT Write Same

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

Regarding AHCI_MAX_SG and (ATA_HORKAGE_MAX_SEC_1024)

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

Regarding AHCI_MAX_SG and (ATA_HORKAGE_MAX_SEC_1024)

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

Re: [PATCH resend 5/5] libata-scsi: fix MODE SELECT translation for Control mode page

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 <t...@kernel.org> wrote: > On Fri, Jul 22, 2016 at 05:

Re: [PATCH resend 5/5] libata-scsi: fix MODE SELECT translation for Control mode page

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

Re: [PATCH resend v2 3/5] libata-scsi: use u8 array to store mode page copy

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 <sergei.shtyl...@cogentembedded.com> wrote: > Hello. > > > On 7/22/2016 2:29 AM, tom.t.

Re: [PATCH resend v2 3/5] libata-scsi: use u8 array to store mode page copy

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

Re: [PATCH resend 2/5] libata-scsi: fix read-only bits checking in ata_mselect_*()

This is actually a bit clumsy. Sending a rewritten version. On 22 July 2016 at 02:41, <tom.t...@gmail.com> wrote: > From: Tom Yan <tom.t...@gmail.com> > > Commit 7780081c1f04 ("libata-scsi: Set information sense field for > invalid parameter") changed how a

Re: [PATCH resend 2/5] libata-scsi: fix read-only bits checking in ata_mselect_*()

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

Re: [PATCH resend 5/5] libata-scsi: fix MODE SELECT translation for Control mode page

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

Re: [PATCH resend 5/5] libata-scsi: fix MODE SELECT translation for Control mode page

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

Re: [PATCH resend 3/5] libata-scsi: fix overflow in mode page copy

On Fri, Jul 22, 2016 at 02:41:52AM +0800, tom.t...@gmail.com wrote: >> From: Tom Yan <tom.t...@gmail.com> >> >> ata_mselect_*() would initialize a char array for storing a copy of >> the current mode page. However, if char was actually signed char, >> overfl

Re: [PATCH resend 3/5] libata-scsi: fix overflow in mode page copy

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

Re: [PATCH resend 1/5] libata-scsi: minor cleanup in ata_mselect_*()

09:41 PM, tom.t...@gmail.com wrote: > >> From: Tom Yan <tom.t...@gmail.com> >> >> 1. Removed a repeated bit masking in ata_mselect_control() >> 2. Moved `wce`/`d_sense` assignment below the page validity checks >> 3. Added/Removed empty lines where approp

Re: [PATCH resend 1/5] libata-scsi: minor cleanup in ata_mselect_*()

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: > >

Re: [PATCH] libata: add parentheses to avoid a gcc warning

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:

Re: [PATCH] libata: add parentheses to avoid a gcc warning

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

  1   2   >