From owner-freebsd-usb@FreeBSD.ORG Fri Jan 10 11:50:02 2014 Return-Path: Delivered-To: freebsd-usb@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0043CDA7 for ; Fri, 10 Jan 2014 11:50:01 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DE83A149D for ; Fri, 10 Jan 2014 11:50:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id s0ABo17r054763 for ; Fri, 10 Jan 2014 11:50:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id s0ABo1t7054762; Fri, 10 Jan 2014 11:50:01 GMT (envelope-from gnats) Date: Fri, 10 Jan 2014 11:50:01 GMT Message-Id: <201401101150.s0ABo1t7054762@freefall.freebsd.org> To: freebsd-usb@FreeBSD.org Cc: From: Alex Goncharov Subject: Re: usb/185628: usbd_req_re_enumerate set address failed USB_ERR_STALLED for Seagate USB drives between r259425 and r260321 X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Alex Goncharov List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 11:50:02 -0000 The following reply was made to PR usb/185628; it has been noted by GNATS. From: Alex Goncharov To: Hans Petter Selasky , "freebsd-gnats-submit@FreeBSD.org" Cc: Subject: Re: usb/185628: usbd_req_re_enumerate set address failed USB_ERR_STALLED for Seagate USB drives between r259425 and r260321 Date: Fri, 10 Jan 2014 03:49:00 -0800 (PST) --464114708-973494774-1389354540=:24518 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hello Hans,=0A=0AThank you for your prompt replies; I'll make this a short = note, before=0Arunning to work, and we can work on this later.=0A=0A> Here = is a patch you can try, as an attachment.=0A=0AOK, re-building now.=0A=0A> = Can you give some more details? Are these in some kind of enclosure?=0A=0AT= his model:=0A=0A=A0=A0 http://www.amazon.com/gp/product/B008R7FC74/ref=3Dwm= s_ohs_product?ie=3DUTF8&psc=3D1=0A=0A> What USB speed are they connected at= ?=0A=0A"A normal" one -- I speak as a layman here; later I can give you all= =0A'usbconfig' information.=0A=0A> If you are using an XHCI controller and = the drives are connected at=0A> Super Speed (5.0 GBit),=0A=0ADon't think so= .=0A=0A> Do other USB devices connected to the same USB host controller=0A>= continue to work?=0A=0ADidn't try many but, Buffalo and Sony USB drives di= dn't show anything=0Alike the Seagate's behavior -- see my original posting= .=0A=0ANow: the two upgraded computers, both of which get these=0AUSB_ERR_S= TALLED events, are totally different: one is a self-built=0Adesktop, the ot= her -- a Compaq laptop.=A0 The OS upgrade is the common=0Afactor.=0A=0A> Ca= n you tell which USB controllers you have in your system (PCI=0A> devices) = and tell to which of these your HDD's are attaching to.=0A=0A(Later).=0A=0A= > If devices simply re-attach either they are not respond and software=0A> = initiates a reset, which can be disabled by setting=0A> "hw.usb.no_cs_fail"= or the software in the USB HDD died and=0A> rebooted.=0A=0AMay be; but thi= nk about the fact correlations: the fact of the two=0Asystem's upgrade, two= identical Seagate units, and other HDDs being=0Anon-stalled.=0A=0A> Linux = hide these problems, but they are visible through the fact that=0A> you'll = see some requests delaying for some seconds to complete instead=0A> of some= milliseconds.=0A=0AI copied the 1 TB of data from Seagate UFS to Sony Ext4= and Sony NTFS,=0Amuch faster than I expected it to happen based on my past= FreeBSD=0Aperceptions.=A0 This is just a perception, not a measured fact, = but I=0Areally don't care about a 25% slower if I can use an HDD.=A0 In the= =0Apast, I had to return a 1 TB Western Digital HDD, because it was=0Apredi= ctably lost while even being read on my FreeBSD systems.=A0 Seagate=0Aand T= oshiba apparently do some retries which WD didn't.=0A=0A> Beware that many = USB HDD's contain reprogramable software and that there=0A> might be timing= reasons for HDD's breaking down on one system and not on=0A> another. For = example Linux buffer at lot more using 64K reads, while=0A> under FreeBSD y= ou'll see more different block sizes being read and written.=0A> =0A> Do yo= u have dmesg from around the spurious detach?=0A=0ALater -- I have to go *n= ow*.=0A=0A=0A-- Alex=0A=0A=0A=0A=0AOn Friday, January 10, 2014 2:47 AM, Han= s Petter Selasky wrote:=0A =0AOn 01/10/14 04:02, Alex Gon= charov wrote:=0A>=0A>> Number:=A0 =A0 =A0 =A0 185628=0A>> Category:=A0 =A0= =A0 usb=0A>> Synopsis:=A0 =A0 =A0 usbd_req_re_enumerate set address fail= ed USB_ERR_STALLED for Seagate USB drives between r259425 and r260321=0A>> = Confidential:=A0 no=0A>> Severity:=A0 =A0 =A0 non-critical=0A>> Priority:= =A0 =A0 =A0 low=0A>> Responsible:=A0 =A0 freebsd-usb=0A>> State:=A0 =A0 = =A0 =A0 =A0 open=0A>> Quarter:=0A>> Keywords:=0A>> Date-Required:=0A>> Clas= s:=A0 =A0 =A0 =A0 =A0 sw-bug=0A>> Submitter-Id:=A0 current-users=0A>> Arri= val-Date:=A0 Fri Jan 10 03:10:00 UTC 2014=0A>> Closed-Date:=0A>> Last-Modi= fied:=0A>> Originator:=A0 =A0 Alex Goncharov=0A>> Release:=A0 =A0 =A0 =A0 = 9.2-STABLE, built from svn source, r260321=0A>> Organization:=0A>> Environm= ent:=0A> FreeBSD 9.2-STABLE FreeBSD 9.2-STABLE #0 r260321 Sun Jan=A0 5 13:0= 6:01 EST 2014=0A>> Description:=0A> This is an extremely reproducible and v= ery upsetting new problem.=0A=0AHere is a patch you can try, as an attachme= nt.=0A=0A--HPS --464114708-973494774-1389354540=:24518 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Hello Hans,

Thank you for your prompt repli= es; I'll make this a short note, before
running to work, and we can work= on this later.

> Here is a patch you can try, as an attachment.<= br>
OK, re-building now.

> Can you give some more details? Are= these in some kind of enclosure?

This model:

   ht= tp://www.amazon.com/gp/product/B008R7FC74/ref=3Dwms_ohs_product?ie=3DUTF8&a= mp;psc=3D1

> What USB speed are they connected at?

"A norm= al" one -- I speak as a layman here; later I can give you all
'usbconfig= ' information.

> If you are using an XHCI controller and the driv= es are connected at
> Super Speed (5.0 GBit),

Don't think so.<= br>
> Do other USB devices connected to the same USB host controller
> continue to work?

Didn't try many but, Buffalo a= nd Sony USB drives didn't show anything
like the Seagate's behavior -- s= ee my original posting.

Now: the two upgraded computers, both of whi= ch get these
USB_ERR_STALLED events, are totally different: one is a sel= f-built
desktop, the other -- a Compaq laptop.  The OS upgrade is t= he common
factor.

> Can you tell which USB controllers you hav= e in your system (PCI
> devices) and tell to which of these your HDD'= s are attaching to.

(Later).

> If devices simply re-attach= either they are not respond and software
> initiates a reset, which = can be disabled by setting
> "hw.usb.no_cs_fail" or the software in t= he USB HDD died and
> rebooted.

May be; but think about the fa= ct correlations: the fact of the two
system's upgrade, two identical Sea= gate units, and other HDDs being
non-stalled.

> Linux hide these problems, but they are visible through the fact that
> yo= u'll see some requests delaying for some seconds to complete instead
>= ; of some milliseconds.

I copied the 1 TB of data from Seagate UFS t= o Sony Ext4 and Sony NTFS,
much faster than I expected it to happen base= d on my past FreeBSD
perceptions.  This is just a perception, not a= measured fact, but I
really don't care about a 25% slower if I can use = an HDD.  In the
past, I had to return a 1 TB Western Digital HDD, b= ecause it was
predictably lost while even being read on my FreeBSD syste= ms.  Seagate
and Toshiba apparently do some retries which WD didn't= .

> Beware that many USB HDD's contain reprogramable software and= that there
> might be timing reasons for HDD's breaking down on one = system and not on
> another. For example Linux buffer at lot more usi= ng 64K reads, while
> under FreeBSD you'll see more different block sizes being read and written.
>
> Do you have dmesg fro= m around the spurious detach?

Later -- I have to go *now*.

-- Alex


On Friday, January 10, 2014 2= :47 AM, Hans Petter Selasky <hps@bitfrost.no> wrote:
On 01/10/14 04:02, Alex Goncharov wrote:
>= ;
>> Number:        185628
>> Catego= ry:      usb
>> Synopsis:      usb= d_req_re_enumerate set address failed USB_ERR_STALLED for Seagate USB drive= s between r259425 and r260321
>> Confidential:  no
>&g= t; Severity:      non-critical
>> Priority:  =     low
>> Responsible:    freebsd-usb
>= ;> State:          open
>> Quarter:>> Keywords:
>> Date-Required:
>> Class:  &nb= sp;       sw-bug
>> Submitter-Id:  current-us= ers
>> Arrival-Date:  Fri Jan 10 03:10:00 UTC 2014
>&g= t; Closed-Date:
>> Last-Modified:
>> Originator:    Alex Goncharov
>> Release:   =     9.2-STABLE, built from svn source, r260321
>> Organ= ization:
>> Environment:
> FreeBSD 9.2-STABLE FreeBSD 9.2-ST= ABLE #0 r260321 Sun Jan  5 13:06:01 EST 2014
>> Description:<= br>> This is an extremely reproducible and very upsetting new problem.
Here is a patch you can try, as an attachment.

--HPS


--464114708-973494774-1389354540=:24518--