Re: Seagate External SMR drive USB resets (XHCI transfer error, not timeout)

Hi, On Thu, 16 Nov 2017 14:42:51 -0500 (EST) Alan Stern <st...@rowland.harvard.edu> wrote: > On Wed, 15 Nov 2017, Jérôme Carretero wrote: > > > I performed an usbmon capture extract, centered around the event > > (there was a few hundred MBs written for this to happen)

Re: Seagate External SMR drive USB resets (XHCI transfer error, not timeout)

Hi, On Wed, 15 Nov 2017 18:17:08 -0500 Jérôme Carretero <cj...@zougloub.eu> wrote: > Hi, > > > On Thu, 16 Nov 2017 07:40:08 +0900 > James Bottomley <james.bottom...@hansenpartnership.com> wrote: > > > On Wed, 2017-11-15 at 17:02 -0500, Alan Stern wrote:

Re: Seagate External SMR drive USB resets... why? / USB storage debugging

On Wed, 15 Nov 2017 17:02:39 -0500 (EST) Alan Stern wrote: > > > - It looks like (haven't tested it yet) the CONFIG_DYNAMIC_DEBUG > > > isn't used with the USB mass storage debugging infrastructure, > > > please confirm? If unused, are we interested to have a patch

Re: Seagate External SMR drive USB resets (was: Re: [PATCH] uas: Add US_FL_NO_ATA_1X quirk for one more Seagate device)

Hi, On Thu, 16 Nov 2017 07:40:08 +0900 James Bottomley <james.bottom...@hansenpartnership.com> wrote: > On Wed, 2017-11-15 at 17:02 -0500, Alan Stern wrote: > > On Wed, 15 Nov 2017, Jérôme Carretero wrote: > > > >   Because with several of these drives / lots of

Re: Seagate External SMR drive USB resets (was: Re: [PATCH] uas: Add US_FL_NO_ATA_1X quirk for one more Seagate device)

(Adding Tejun Heo who was assigned on still-open bugzilla #93581 which is about SATA but seems terribly related.) On Wed, 15 Nov 2017 16:43:14 -0500 Jérôme Carretero <cj...@zougloub.eu> wrote: > Hi Hans, > > > Tests are currently undergoing with drives operating in plain

Seagate External SMR drive USB resets (was: Re: [PATCH] uas: Add US_FL_NO_ATA_1X quirk for one more Seagate device)

7 12:38:14 -0500 Jérôme Carretero <cj...@zougloub.eu> wrote: > Hi Hans, > > On Mon, 13 Nov 2017 10:04:53 +0100 > Hans de Goede <hdego...@redhat.com> wrote: > > > Hi, > > > > On 13-11-17 07:14, Jérôme Carretero wrote: > > > On Mon, 13 Nov

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

Hi Hans, On Mon, 13 Nov 2017 10:04:53 +0100 Hans de Goede <hdego...@redhat.com> 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

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

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

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

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 s

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

On Fri, 10 Nov 2017 16:13:44 +0100 Hans de Goede wrote: > Just like all previous UAS capable Seagate disk enclosures, this > one needs a US_FL_NO_ATA_1X quirk. > [...] > +/* Reported-by: Andrey Astafyev */ Hi Andrey, I notice that you have an external

Max. libusb bulk send/receive values lowered with xhci?

Hi Sarah, I was happily using big (10MB) buffers before, and with recent kernels, when using USB3, I had to reduce the size of my buffers a lot. By the way, I couldn't find any information on a maximum size for the bulk transfers using libusb, maybe you know about that also ? So, using v3.13,

Re: [PATCH] usbcore: fix BABBLE failed enumeration of legacy USB2 devices on USB3 bus

Hi, I encountered the same problem with another device. If possible, it would be nice to pick Marius's patch for stable kernels (tested here on v3.12.6). There are chances that MacOSX is affected by a similar issue, so if anybody has friends there... Thanks, -- Jérôme On Wed, 8 Jan 2014

xhci_hcd: Signal/Timeout while waiting for evaluate context command then Assuming host is dying, halting host

Hi, I am seeing that with an acquisition board: [27044.406737] usb 4-4.4: usb_probe_device [27044.406739] usb 4-4.4: configuration #1 chosen from 1 choice [27044.406803] usb 4-4.4: Successful Endpoint Configure command [27044.418946] usb 4-4.4: Successful evaluate context command [27044.421725]