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 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
