[smartmontools-support] Seagate Backup external USB drive (ID 0bc2:ac30 Seagate RSS LLC BUP Slim)

[Nathan Stratton Treadway]

On Sun, Apr 10, 2022 at 22:06:57 +0000, James wrote:
> 
> Apr. 10, 2022 17:08:35 Nathan Stratton Treadway <nathanst at ontko.com>:
> 
> > On Sun, Apr 10, 2022 at 16:00:04 -0400, James wrote:
> >> GRUB_CMDLINE_LINUX="iommu=soft audit=0 usb_storage.quirks=0bc2:ac30:"
> >> I think it is using UAS but how do I know it is not using NO_ATA_1X?
> >> It seems to work for smart
> > 
> > (You can confirm that UAS is being used with the "lsusb -t" command or
> > looking at the kern.log messages.)
> > 
> > As far as I know there is still no way to directly verify the NO_ATA_1X
> > flag status under UAS -- but if smartctl works on the drive while the
> > UAS driver is in use, then NO_ATA_1X must have been successfully
> > disabled...
> What potential bugs could I hit if I leave UAS enabled with NO_ATA_1X disabled?

I don't have much personal experience with those bugs, but you can see
some examples of what people have run into with other Seagate USB bridge
chips by looking at the pages linked down at the bottom of the
SAT-with-UAS-Linux wiki page.
 
In general, if the bug is present in your bridge it seems that you'll
see errors in your kern.log/dmesg either immediately after plugging in
the drive or after trying to transfer some data.  The exact errors seem
to vary from situation to situation; a few examples I have seen
mentioned are:

====
[ 2081.759381] sd 0:0:0:0: tag#0 uas_eh_abort_handler 0 uas-tag 1 inflight: IN
[ 2081.759388] sd 0:0:0:0: tag#0 CDB: Report supported operation codes a3 0c 01 12 00 00 00 00 02 00 00 00
[ 2081.759576] scsi host0: uas_eh_bus_reset_handler start
[ 2081.879432] usb 2-1: reset SuperSpeed USB device number 8 using xhci_hcd
[ 2081.902123] scsi host0: uas_eh_bus_reset_handler success
====

====
[ 2381.032039] sd 8:0:0:0: [sdc] tag#1 uas_eh_abort_handler 0 uas-tag 2 inflight: CMD
[ 2381.032045] sd 8:0:0:0: [sdc] tag#1 CDB: Read(10) 28 00 95 5a 11 00 00 00 08 00
[ 2381.032049] sd 8:0:0:0: [sdc] tag#0 uas_eh_abort_handler 0 uas-tag 1 inflight: CMD
[ 2381.032052] sd 8:0:0:0: [sdc] tag#0 CDB: Read(10) 28 00 00 00 00 00 00 00 20 00
[ 2381.032079] scsi host8: uas_eh_bus_reset_handler start
====

====
[ 9134.211695] sd 8:0:0:0: sense urb submission failure
====


Anyway, I think you should be safe plugging the drive in with that empty
quirks string and then reading some large files off the drive and
finally copying some large test files onto the drive, watching the
kern.log as you run the tests.

If you get any of those sort sorts of errors in the log, then you'll
know the bridge chip has this bug, and you can go ahead and unmount te
filesystem and unplug the drive at that point.  Then you'll have to
decide whether you want to have your general setup running in
usb-storage mode (which would allow smartctl to work) or with UAS
enabled but the NO_ATA_1X flag on (which disables smartctl but may allow
faster data transfers to the drive).


But there are reports of at least one Seagate bridge chip working okay
in UAS mode (but no reports I found so far regarding this 0bc2:ac30 chip
one way or the other), so it seems like it could be worth spending a
little while giving it a try in hopes that you are lucky and can have
the best of both worlds at the same time....  :)


						Nathan


----------------------------------------------------------------------------
Nathan Stratton Treadway  -  nathanst at ontko.com  -  Mid-Atlantic region
Ray Ontko & Co.  -  Software consulting services  -   http://www.ontko.com/
 GPG Key: http://www.ontko.com/~nathanst/gpg_key.txt   ID: 1023D/ECFB6239
 Key fingerprint = 6AD8 485E 20B9 5C71 231C  0C32 15F3 ADCD ECFB 6239