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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Hans,

On Mon, 13 Nov 2017 10:04:53 +0100
Hans de Goede <hdegoede@xxxxxxxxxx> 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@xxxxxxxxx> 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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [SCSI Target Devel]     [Linux SCSI Target Infrastructure]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Samba]     [Device Mapper]

  Powered by Linux