[PATCH] uas: Add US_FL_NO_ATA_1X quirk for one more Seagate device

[PATCH] uas: Add US_FL_NO_ATA_1X quirk for one more Seagate device

[Hans de Goede]

Just like all previous UAS capable Seagate disk enclosures, this
one needs a US_FL_NO_ATA_1X quirk.

Cc: stable@vger.kernel.org # 3.16
Signed-off-by: Andrey Astafyev <1@246060.ru>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
 drivers/usb/storage/unusual_uas.h | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/drivers/usb/storage/unusual_uas.h b/drivers/usb/storage/unusual_uas.h
index cde115359793..2fe4fd336446 100644
--- a/drivers/usb/storage/unusual_uas.h
+++ b/drivers/usb/storage/unusual_uas.h
@@ -121,6 +121,13 @@ UNUSUAL_DEV(0x0bc2, 0xab2a, 0x0000, 0x9999,
 		USB_SC_DEVICE, USB_PR_DEVICE, NULL,
 		US_FL_NO_ATA_1X),
 
+/* Reported-by: Andrey Astafyev <dev@246060.ru> */
+UNUSUAL_DEV(0x0bc2, 0xab30, 0x0000, 0x9999,
+		"Seagate",
+		"BUP BK",
+		USB_SC_DEVICE, USB_PR_DEVICE, NULL,
+		US_FL_NO_ATA_1X),
+
 /* Reported-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> */
 UNUSUAL_DEV(0x13fd, 0x3940, 0x0000, 0x9999,
 		"Initio Corporation",
-- 
2.14.3

Re: [PATCH] uas: Add US_FL_NO_ATA_1X quirk for one more Seagate device

[Jérôme Carretero]

On Fri, 10 Nov 2017 16:13:44 +0100
Hans de Goede <hdegoede@redhat.com> wrote:

> Just like all previous UAS capable Seagate disk enclosures, this
> one needs a US_FL_NO_ATA_1X quirk.
> [...]
> +/* Reported-by: Andrey Astafyev <dev@246060.ru> */

Hi Andrey,


I notice that you have an external Seagate SMR drive, I am encountering
some trouble and was wondering if you (or anyone in CC) could have some
feedback.

While the drives I have (PID 0xab45, "Backup+ Hub BK") are used
without problem with very light loads, I'm starting to get annoyed when
doing more serious work.
Here is a series of messages (v4.14) I have when simply trying to balance 1
chunk of BTRFS data, ie. write 5 GiB, and waiting a long time in-between:

	Nov 12 16:15:35 Bidule kernel: sd 22:0:0:0: [sdaa] tag#7 uas_eh_abort_handler 0 uas-tag 8 inflight: CMD OUT
	Nov 12 16:15:35 Bidule kernel: sd 22:0:0:0: [sdaa] tag#7 CDB: Write(16) 8a 00 00 00 00 00 00 00 11 00 00 00 00 80 00 00
	Nov 12 16:15:35 Bidule kernel: sd 22:0:0:0: [sdaa] tag#6 uas_eh_abort_handler 0 uas-tag 7 inflight: CMD OUT
	Nov 12 16:15:35 Bidule kernel: sd 22:0:0:0: [sdaa] tag#6 CDB: Write(16) 8a 00 00 00 00 00 00 00 11 80 00 00 00 80 00 00
	Nov 12 16:15:35 Bidule kernel: sd 22:0:0:0: [sdaa] tag#5 uas_eh_abort_handler 0 uas-tag 6 inflight: CMD OUT
	Nov 12 16:15:35 Bidule kernel: sd 22:0:0:0: [sdaa] tag#5 CDB: Write(16) 8a 00 00 00 00 00 00 bf fd 80 00 00 00 80 00 00
	Nov 12 16:15:35 Bidule kernel: sd 22:0:0:0: [sdaa] tag#4 uas_eh_abort_handler 0 uas-tag 5 inflight: CMD OUT
	Nov 12 16:15:35 Bidule kernel: sd 22:0:0:0: [sdaa] tag#4 CDB: Write(16) 8a 00 00 00 00 00 00 bf fd 00 00 00 00 80 00 00
	Nov 12 16:15:35 Bidule kernel: scsi host22: uas_eh_device_reset_handler start
	Nov 12 16:15:35 Bidule kernel: usb 6-4.3.2.1: reset SuperSpeed USB device number 9 using xhci_hcd
	Nov 12 16:15:35 Bidule kernel: scsi host22: uas_eh_device_reset_handler success


	Nov 12 16:20:28 Bidule kernel: sd 22:0:0:0: [sdaa] tag#3 uas_eh_abort_handler 0 uas-tag 4 inflight: CMD IN
	Nov 12 16:20:28 Bidule kernel: sd 22:0:0:0: [sdaa] tag#3 CDB: Read(16) 88 00 00 00 00 00 01 02 53 80 00 00 00 80 00 00
	Nov 12 16:20:28 Bidule kernel: sd 22:0:0:0: [sdaa] tag#13 uas_eh_abort_handler 0 uas-tag 14 inflight: CMD OUT
	Nov 12 16:20:28 Bidule kernel: sd 22:0:0:0: [sdaa] tag#13 CDB: Write(16) 8a 00 00 00 00 00 01 02 3b c0 00 00 00 20 00 00
	Nov 12 16:20:28 Bidule kernel: sd 22:0:0:0: [sdaa] tag#2 uas_eh_abort_handler 0 uas-tag 3 inflight: CMD OUT
	Nov 12 16:20:28 Bidule kernel: sd 22:0:0:0: [sdaa] tag#2 CDB: Write(16) 8a 00 00 00 00 00 01 02 41 00 00 00 01 00 00 00
	Nov 12 16:20:28 Bidule kernel: sd 22:0:0:0: [sdaa] tag#12 uas_eh_abort_handler 0 uas-tag 13 inflight: CMD OUT
	Nov 12 16:20:28 Bidule kernel: sd 22:0:0:0: [sdaa] tag#12 CDB: Write(16) 8a 00 00 00 00 00 01 02 3c a0 00 00 00 20 00 00
	Nov 12 16:20:28 Bidule kernel: sd 22:0:0:0: [sdaa] tag#11 uas_eh_abort_handler 0 uas-tag 12 inflight: CMD OUT
	Nov 12 16:20:28 Bidule kernel: sd 22:0:0:0: [sdaa] tag#11 CDB: Write(16) 8a 00 00 00 00 00 01 02 62 00 00 00 00 80 00 00
	Nov 12 16:20:28 Bidule kernel: sd 22:0:0:0: [sdaa] tag#1 uas_eh_abort_handler 0 uas-tag 2 inflight: CMD OUT
	Nov 12 16:20:28 Bidule kernel: sd 22:0:0:0: [sdaa] tag#1 CDB: Write(16) 8a 00 00 00 00 00 01 02 61 80 00 00 00 80 00 00
	Nov 12 16:20:28 Bidule kernel: sd 22:0:0:0: [sdaa] tag#10 uas_eh_abort_handler 0 uas-tag 11 inflight: CMD OUT
	Nov 12 16:20:28 Bidule kernel: sd 22:0:0:0: [sdaa] tag#10 CDB: Write(16) 8a 00 00 00 00 00 01 02 61 00 00 00 00 80 00 00
	Nov 12 16:20:28 Bidule kernel: sd 22:0:0:0: [sdaa] tag#9 uas_eh_abort_handler 0 uas-tag 10 inflight: CMD OUT
	Nov 12 16:20:28 Bidule kernel: sd 22:0:0:0: [sdaa] tag#9 CDB: Write(16) 8a 00 00 00 00 00 01 02 60 80 00 00 00 80 00 00
	Nov 12 16:20:28 Bidule kernel: sd 22:0:0:0: [sdaa] tag#8 uas_eh_abort_handler 0 uas-tag 9 inflight: CMD OUT
	Nov 12 16:20:28 Bidule kernel: sd 22:0:0:0: [sdaa] tag#8 CDB: Write(16) 8a 00 00 00 00 00 01 02 60 00 00 00 00 80 00 00
	Nov 12 16:20:28 Bidule kernel: sd 22:0:0:0: [sdaa] tag#7 uas_eh_abort_handler 0 uas-tag 8 inflight: CMD OUT
	Nov 12 16:20:28 Bidule kernel: sd 22:0:0:0: [sdaa] tag#7 CDB: Write(16) 8a 00 00 00 00 00 01 02 5f 80 00 00 00 80 00 00
	Nov 12 16:20:28 Bidule kernel: sd 22:0:0:0: [sdaa] tag#6 uas_eh_abort_handler 0 uas-tag 7 inflight: CMD OUT
	Nov 12 16:20:28 Bidule kernel: sd 22:0:0:0: [sdaa] tag#6 CDB: Write(16) 8a 00 00 00 00 00 01 02 5f 00 00 00 00 80 00 00
	Nov 12 16:20:28 Bidule kernel: sd 22:0:0:0: [sdaa] tag#5 uas_eh_abort_handler 0 uas-tag 6 inflight: CMD OUT
	Nov 12 16:20:28 Bidule kernel: sd 22:0:0:0: [sdaa] tag#5 CDB: Write(16) 8a 00 00 00 00 00 01 02 50 00 00 00 00 80 00 00
	Nov 12 16:20:28 Bidule kernel: scsi host22: uas_eh_device_reset_handler start
	Nov 12 16:20:28 Bidule kernel: usb 6-4.3.2.1: reset SuperSpeed USB device number 9 using xhci_hcd
	Nov 12 16:20:28 Bidule kernel: scsi host22: uas_eh_device_reset_handler success


	Nov 12 16:20:59 Bidule kernel: sd 22:0:0:0: [sdaa] tag#2 uas_eh_abort_handler 0 uas-tag 3 inflight: CMD OUT
	Nov 12 16:20:59 Bidule kernel: sd 22:0:0:0: [sdaa] tag#2 CDB: Write(16) 8a 00 00 00 00 00 20 00 08 00 00 00 00 08 00 00
	Nov 12 16:20:59 Bidule kernel: sd 22:0:0:0: [sdaa] tag#1 uas_eh_abort_handler 0 uas-tag 2 inflight: CMD OUT
	Nov 12 16:20:59 Bidule kernel: sd 22:0:0:0: [sdaa] tag#1 CDB: Write(16) 8a 00 00 00 00 00 00 02 08 00 00 00 00 08 00 00
	Nov 12 16:21:29 Bidule kernel: sd 22:0:0:0: [sdaa] tag#0 uas_eh_abort_handler 0 uas-tag 1 inflight: CMD
	Nov 12 16:21:29 Bidule kernel: sd 22:0:0:0: [sdaa] tag#0 CDB: Synchronize Cache(10) 35 00 00 00 00 00 00 00 00 00
	Nov 12 16:21:29 Bidule kernel: scsi host22: uas_eh_device_reset_handler start
	Nov 12 16:21:29 Bidule kernel: usb 6-4.3.2.1: reset SuperSpeed USB device number 9 using xhci_hcd
	Nov 12 16:21:29 Bidule kernel: scsi host22: uas_eh_device_reset_handler success


Do you see such things?

I understand that latencies can climb to several seconds as the disks can do GC,
and suspect that the issues (sometimes the USB reset doesn't work and a reboot
is needed...) are due to some unawareness of that, but I don't know.

There are several threads on distribution forums & bug trackers, but nothing
really helpful, and I didn't see much on LKML.


Regards,

-- 
Jérôme

Re: [PATCH] uas: Add US_FL_NO_ATA_1X quirk for one more Seagate device

[Andrey Astafyev]

13.11.2017 00:42, Jérôme Carretero пишет:
> Nov 12 16:20:59 Bidule kernel: sd 22:0:0:0: [sdaa] tag#2 
> uas_eh_abort_handler 0 uas-tag 3 inflight: CMD OUT
> 	Nov 12 16:20:59 Bidule kernel: sd 22:0:0:0: [sdaa] tag#2 CDB: Write(16) 8a 00 00 00 00 00 20 00 08 00 00 00 00 08 00 00
> 	Nov 12 16:20:59 Bidule kernel: sd 22:0:0:0: [sdaa] tag#1 uas_eh_abort_handler 0 uas-tag 2 inflight: CMD OUT
> 	Nov 12 16:20:59 Bidule kernel: sd 22:0:0:0: [sdaa] tag#1 CDB: Write(16) 8a 00 00 00 00 00 00 02 08 00 00 00 00 08 00 00
> 	Nov 12 16:21:29 Bidule kernel: sd 22:0:0:0: [sdaa] tag#0 uas_eh_abort_handler 0 uas-tag 1 inflight: CMD
> 	Nov 12 16:21:29 Bidule kernel: sd 22:0:0:0: [sdaa] tag#0 CDB: Synchronize Cache(10) 35 00 00 00 00 00 00 00 00 00
> 	Nov 12 16:21:29 Bidule kernel: scsi host22: uas_eh_device_reset_handler start
> 	Nov 12 16:21:29 Bidule kernel: usb 6-4.3.2.1: reset SuperSpeed USB device number 9 using xhci_hcd
> 	Nov 12 16:21:29 Bidule kernel: scsi host22: uas_eh_device_reset_handler success
>
>
> Do you see such things?
>
Hi, I've seen dmesg output like this so I've added my device to quirks 
list like any other Seagate USB drive.

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] uas: Add US_FL_NO_ATA_1X quirk for one more Seagate device

[Jérôme Carretero]

On Mon, 13 Nov 2017 07:01:30 +0300
Andrey Astafyev <1@246060.ru> wrote:

> 13.11.2017 00:42, Jérôme Carretero пишет:
> > Nov 12 16:20:59 Bidule kernel: sd 22:0:0:0: [sdaa] tag#2 
> > uas_eh_abort_handler 0 uas-tag 3 inflight: CMD OUT
> > [...]
> > Do you see such things?
> >  
> Hi, I've seen dmesg output like this so I've added my device to
> quirks list like any other Seagate USB drive.

Hi Andrey, Hans,


For my devices, adding US_FL_NO_ATA_1X to unusual_uas.h didn't
change anything, and while adding US_FL_IGNORE_UAS (using
quirks=0bc2:ab34:u,0bc2:ab38:u) there are still device resets,
but they cause shorter hangs in system activity (~1 second when
UAS was more like ~20).

Is the US_FL_NO_ATA_1X supposed to get rid of the R/W errors?
The first entry I saw about this quirk was so that the device can
be used at all (wouldn't be able to mount without it).


I'll follow up: when scrubbing the devices after a sequence of
experiments, there were checksum errors, so I'll retry with a more
reproducible sequence to try and get something more solid.
I wouldn't want to disable UAS just to see that reliability has
been reduced (one Arch bug report mentions something like that
https://bugs.archlinux.org/task/48362).


Regards,

-- 
Jérôme

PS: The controllers I tested do the same:

09:00.0 USB controller: Fresco Logic FL1100 USB 3.0 Host Controller (rev 10)
0c:00.0 USB controller: NEC Corporation uPD720200 USB 3.0 Host Controller (rev 03)

Re: [PATCH] uas: Add US_FL_NO_ATA_1X quirk for one more Seagate device

[Andrey Astafyev]

13.11.2017 09:14, Jérôme Carretero пишет:
> For my devices, adding US_FL_NO_ATA_1X to unusual_uas.h didn't
> change anything, and while adding US_FL_IGNORE_UAS (using
> quirks=0bc2:ab34:u,0bc2:ab38:u) there are still device resets,
> but they cause shorter hangs in system activity (~1 second when
> UAS was more like ~20).

Maybe you should try like this: quirks=0bc2:ab34:ut,0bc2:ab38:ut ?

Re: [PATCH] uas: Add US_FL_NO_ATA_1X quirk for one more Seagate device

[Jérôme Carretero]

On Mon, 13 Nov 2017 09:16:39 +0300
Andrey Astafyev <1@246060.ru> wrote:

> 13.11.2017 09:14, Jérôme Carretero пишет:
> > For my devices, adding US_FL_NO_ATA_1X to unusual_uas.h didn't
> > change anything, and while adding US_FL_IGNORE_UAS (using
> > quirks=0bc2:ab34:u,0bc2:ab38:u) there are still device resets,
> > but they cause shorter hangs in system activity (~1 second when
> > UAS was more like ~20).  
> 
> Maybe you should try like this: quirks=0bc2:ab34:ut,0bc2:ab38:ut ?

It looks like "ut" would do the same as "u" alone, as US_FL_NO_ATA_1X
is only used inside uas.ko.
For some reason, first I wanted to go in the .h, and it's only after,
when the trial and error went more intense, that I used the command-line
parameters.

Will follow up later... I hope the drives won't end up costing more
than 12Gb/s SAS drives on an expensive HBA... as they are definitely
not hassle-free so far.
I had gotten the first 8 TB model in 2015 and had issues, but my
simple, background workload (attic/borg) could afford to use a
workaround of throttling writes*.

-- 
Jérôme

* https://bugzilla.kernel.org/show_bug.cgi?id=93581#c129

Re: [PATCH] uas: Add US_FL_NO_ATA_1X quirk for one more Seagate device

[Hans de Goede]

Hi,

On 13-11-17 07:14, Jérôme Carretero wrote:
> On Mon, 13 Nov 2017 07:01:30 +0300
> Andrey Astafyev <1@246060.ru> wrote:
> 
>> 13.11.2017 00:42, Jérôme Carretero пишет:
>>> Nov 12 16:20:59 Bidule kernel: sd 22:0:0:0: [sdaa] tag#2
>>> uas_eh_abort_handler 0 uas-tag 3 inflight: CMD OUT
>>> [...]
>>> Do you see such things?
>>>   
>> Hi, I've seen dmesg output like this so I've added my device to
>> quirks list like any other Seagate USB drive.
> 
> Hi Andrey, Hans,
> 
> 
> For my devices, adding US_FL_NO_ATA_1X to unusual_uas.h didn't
> change anything, and while adding US_FL_IGNORE_UAS (using
> quirks=0bc2:ab34:u,0bc2:ab38:u) there are still device resets,
> but they cause shorter hangs in system activity (~1 second when
> UAS was more like ~20).

The errors you are seeing are write errors. If you're seeing these
errors with both the usb-storage and uas drivers then there likely
is something wrong with your setup / hardware.

Does the drive in question use an external power-supply or is it
USB bus-powered? If it is the latter then that is likely the problem.

Anyways things I would check and try to swap are both the cable
used, the power-supply used (if any), the USB-port used as well
as trying the disk on a completely different computer.

I've the feeling something is busted with your hardware, it
could be the disk itself. Did you mention that this was the first
release of a new higher capacity ? Those often have some kinks
which are worked out in later revisions.

Regards,

Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] uas: Add US_FL_NO_ATA_1X quirk for one more Seagate device

[Jérôme Carretero]

Hi Hans,

On Mon, 13 Nov 2017 10:04:53 +0100
Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:

> Hi,
> 
> On 13-11-17 07:14, Jérôme Carretero wrote:
> > On Mon, 13 Nov 2017 07:01:30 +0300
> > Andrey Astafyev <1@246060.ru> wrote:
> >   
> >> 13.11.2017 00:42, Jérôme Carretero пишет:  
> >>> Nov 12 16:20:59 Bidule kernel: sd 22:0:0:0: [sdaa] tag#2
> >>> uas_eh_abort_handler 0 uas-tag 3 inflight: CMD OUT
> >>> [...]
> >>> Do you see such things?

> > For my devices, adding US_FL_NO_ATA_1X to unusual_uas.h didn't
> > change anything, and while adding US_FL_IGNORE_UAS (using
> > quirks=0bc2:ab34:u,0bc2:ab38:u) there are still device resets,
> > but they cause shorter hangs in system activity (~1 second when
> > UAS was more like ~20).  
> 
> The errors you are seeing are write errors. If you're seeing these
> errors with both the usb-storage and uas drivers then there likely
> is something wrong with your setup / hardware.

My latest drives are Seagate Backup+ Hub 8TB and have ~ 50 hours of
uptime. I have connected them to different controllers and they do the
same as the first generation of the same capacity from 2015.

SMART says that everything is OK on these disks (I have another that
was RMA'ed and the symptoms of failure are something else), and if there
were USB errors, the messages wouldn't be at the higher SCSI level, I
guess I would see "xact failed" USB errors... no?

> Does the drive in question use an external power-supply or is it
> USB bus-powered? If it is the latter then that is likely the problem.

External power supply & ~2-ft cable provided by Seagate.

> Anyways things I would check and try to swap are both the cable
> used, the power-supply used (if any), the USB-port used as well
> as trying the disk on a completely different computer.

I did that. The same thing happens.

> I've the feeling something is busted with your hardware, it
> could be the disk itself. Did you mention that this was the first
> release of a new higher capacity ? Those often have some kinks
> which are worked out in later revisions.

No, that's about the 3rd release I think.


I really suspect this has to do with GC activity of these SMR drives,
as if the write activity is throttled or in more spaced bursts (same
USB-level intensity), then there is no problem.

I will do longer tests and see if only some of them do that, after
they have been subjected to similar usage history.


Best regards,

-- 
Jérôme
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] uas: Add US_FL_NO_ATA_1X quirk for one more Seagate device

[Hans de Goede]

Just like all previous UAS capable Seagate disk enclosures, this
one needs a US_FL_NO_ATA_1X quirk.

Cc: stable-u79uwXL29TY76Z2rM5mHXA@public.gmane.org # 3.16
Reported-by: Wido <wido.gg-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Signed-off-by: Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
---
 drivers/usb/storage/unusual_uas.h | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/drivers/usb/storage/unusual_uas.h b/drivers/usb/storage/unusual_uas.h
index 2fe4fd336446..a1ddcbfb7323 100644
--- a/drivers/usb/storage/unusual_uas.h
+++ b/drivers/usb/storage/unusual_uas.h
@@ -114,6 +114,13 @@ UNUSUAL_DEV(0x0bc2, 0xab21, 0x0000, 0x9999,
 		USB_SC_DEVICE, USB_PR_DEVICE, NULL,
 		US_FL_NO_ATA_1X),
 
+/* Reported-by: Wido <wido.gg-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> */
+UNUSUAL_DEV(0x0bc2, 0xab24, 0x0000, 0x9999,
+		"Seagate",
+		"BUP Slim BK",
+		USB_SC_DEVICE, USB_PR_DEVICE, NULL,
+		US_FL_NO_ATA_1X),
+
 /* Reported-by: G. Richard Bellamy <rbellamy-1/AleqyZJC8ybS5Ee8rs3A@public.gmane.org> */
 UNUSUAL_DEV(0x0bc2, 0xab2a, 0x0000, 0x9999,
 		"Seagate",
-- 
2.14.3

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] uas: Add US_FL_NO_ATA_1X quirk for one more Seagate device

[Hans de Goede]

Hi,

On 14-11-17 15:00, Hans de Goede wrote:
> Just like all previous UAS capable Seagate disk enclosures, this
> one needs a US_FL_NO_ATA_1X quirk.
> 
> Cc: stable-u79uwXL29TY76Z2rM5mHXA@public.gmane.org # 3.16
> Reported-by: Wido <wido.gg-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Signed-off-by: Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>


So far we've been adding quirks for Seagate drives on a one by one
basis (I started this myself) hoping that one day they will fix
their ATA_1X pass-through support. But that does not seem to
be happening.

Maybe we need to do something like this instead ?   :

--- a/drivers/usb/storage/uas-detect.h
+++ b/drivers/usb/storage/uas-detect.h
@@ -111,6 +111,10 @@ static int uas_use_uas_driver(struct usb_interface *intf,
                 }
         }

+ /* All Seagate disk enclosures have broken ATA pass-through support */
+ if (le16_to_cpu(udev->descriptor.idVendor) == 0x0bc2)
+         flags |= US_FL_NO_ATA_1X;
+
         usb_stor_adjust_quirks(udev, &flags);

         if (flags & US_FL_IGNORE_UAS) {


Then we can remove a whole lot of quirks and we avoid future
churn when new Seagate device ids show up.

Regards,

Hans



> ---
>   drivers/usb/storage/unusual_uas.h | 7 +++++++
>   1 file changed, 7 insertions(+)
> 
> diff --git a/drivers/usb/storage/unusual_uas.h b/drivers/usb/storage/unusual_uas.h
> index 2fe4fd336446..a1ddcbfb7323 100644
> --- a/drivers/usb/storage/unusual_uas.h
> +++ b/drivers/usb/storage/unusual_uas.h
> @@ -114,6 +114,13 @@ UNUSUAL_DEV(0x0bc2, 0xab21, 0x0000, 0x9999,
>   		USB_SC_DEVICE, USB_PR_DEVICE, NULL,
>   		US_FL_NO_ATA_1X),
>   
> +/* Reported-by: Wido <wido.gg-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> */
> +UNUSUAL_DEV(0x0bc2, 0xab24, 0x0000, 0x9999,
> +		"Seagate",
> +		"BUP Slim BK",
> +		USB_SC_DEVICE, USB_PR_DEVICE, NULL,
> +		US_FL_NO_ATA_1X),
> +
>   /* Reported-by: G. Richard Bellamy <rbellamy-1/AleqyZJC8ybS5Ee8rs3A@public.gmane.org> */
>   UNUSUAL_DEV(0x0bc2, 0xab2a, 0x0000, 0x9999,
>   		"Seagate",
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] uas: Add US_FL_NO_ATA_1X quirk for one more Seagate device

[Alan Stern]

On Tue, 14 Nov 2017, Hans de Goede wrote:

> Hi,
> 
> On 14-11-17 15:00, Hans de Goede wrote:
> > Just like all previous UAS capable Seagate disk enclosures, this
> > one needs a US_FL_NO_ATA_1X quirk.
> > 
> > Cc: stable@vger.kernel.org # 3.16
> > Reported-by: Wido <wido.gg@gmail.com>
> > Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> 
> 
> So far we've been adding quirks for Seagate drives on a one by one
> basis (I started this myself) hoping that one day they will fix
> their ATA_1X pass-through support. But that does not seem to
> be happening.
> 
> Maybe we need to do something like this instead ?   :
> 
> --- a/drivers/usb/storage/uas-detect.h
> +++ b/drivers/usb/storage/uas-detect.h
> @@ -111,6 +111,10 @@ static int uas_use_uas_driver(struct usb_interface *intf,
>                  }
>          }
> 
> + /* All Seagate disk enclosures have broken ATA pass-through support */
> + if (le16_to_cpu(udev->descriptor.idVendor) == 0x0bc2)
> +         flags |= US_FL_NO_ATA_1X;
> +
>          usb_stor_adjust_quirks(udev, &flags);
> 
>          if (flags & US_FL_IGNORE_UAS) {
> 
> 
> Then we can remove a whole lot of quirks and we avoid future
> churn when new Seagate device ids show up.

That is a reasonable approach.  For what it's worth, usb-storage has 
had similar code for many years, affecting devices from Nokia, Nikon, 
Pentax, and Motorola.

Alan Stern

Re: [PATCH] uas: Add US_FL_NO_ATA_1X quirk for one more Seagate device

[Hans de Goede]

Hi,

On 11/14/2017 04:25 PM, Alan Stern wrote:
> On Tue, 14 Nov 2017, Hans de Goede wrote:
> 
>> Hi,
>>
>> On 14-11-17 15:00, Hans de Goede wrote:
>>> Just like all previous UAS capable Seagate disk enclosures, this
>>> one needs a US_FL_NO_ATA_1X quirk.
>>>
>>> Cc: stable@vger.kernel.org # 3.16
>>> Reported-by: Wido <wido.gg@gmail.com>
>>> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
>>
>>
>> So far we've been adding quirks for Seagate drives on a one by one
>> basis (I started this myself) hoping that one day they will fix
>> their ATA_1X pass-through support. But that does not seem to
>> be happening.
>>
>> Maybe we need to do something like this instead ?   :
>>
>> --- a/drivers/usb/storage/uas-detect.h
>> +++ b/drivers/usb/storage/uas-detect.h
>> @@ -111,6 +111,10 @@ static int uas_use_uas_driver(struct usb_interface *intf,
>>                   }
>>           }
>>
>> + /* All Seagate disk enclosures have broken ATA pass-through support */
>> + if (le16_to_cpu(udev->descriptor.idVendor) == 0x0bc2)
>> +         flags |= US_FL_NO_ATA_1X;
>> +
>>           usb_stor_adjust_quirks(udev, &flags);
>>
>>           if (flags & US_FL_IGNORE_UAS) {
>>
>>
>> Then we can remove a whole lot of quirks and we avoid future
>> churn when new Seagate device ids show up.
> 
> That is a reasonable approach.  For what it's worth, usb-storage has
> had similar code for many years, affecting devices from Nokia, Nikon,
> Pentax, and Motorola.


Ok.

Greg, please do no merge the 2 recent uas seagate quirks I send
then. I will submit a patch with the new approach right away.

Once the patch with the new approach is merged I will
submit a patch to remove all the seagate quirks.

Regards,

Hans

Re: [PATCH] uas: Add US_FL_NO_ATA_1X quirk for one more Seagate device

[Oliver Neukum]

Am Dienstag, den 14.11.2017, 18:44 +0100 schrieb Hans de Goede:
> 
> Greg, please do no merge the 2 recent uas seagate quirks I send
> then. I will submit a patch with the new approach right away.

Hi,

I am afraid in that case we will need a way to override a
quirk in the other direction, that is, to not apply it.

	Regards
		Oliver
 

Re: [PATCH] uas: Add US_FL_NO_ATA_1X quirk for one more Seagate device

[Hans de Goede]

Hi,

On 15-11-17 10:06, Oliver Neukum wrote:
> Am Dienstag, den 14.11.2017, 18:44 +0100 schrieb Hans de Goede:
>>
>> Greg, please do no merge the 2 recent uas seagate quirks I send
>> then. I will submit a patch with the new approach right away.
> 
> Hi,
> 
> I am afraid in that case we will need a way to override a
> quirk in the other direction, that is, to not apply it.

We already have that usb_stor_adjust_quirks when a match to the
device's vend:prod ids is found in usb_storage.quirks,
usb_stor_adjust_quirks will clear all quirks it allows to be set
through the usb_storage.quirks module option.

Regards,

Hans