usb/185628: usbd_req_re_enumerate set address failed USB_ERR_STALLED for Seagate USB drives between r259425 and r260321
Number: 185628 Category: usb Synopsis: usbd_req_re_enumerate set address failed USB_ERR_STALLED for Seagate USB drives between r259425 and r260321 Confidential: no Severity: non-critical Priority: low Responsible:freebsd-usb State: open Quarter: Keywords: Date-Required: Class: sw-bug Submitter-Id: current-users Arrival-Date: Fri Jan 10 03:10:00 UTC 2014 Closed-Date: Last-Modified: Originator: Alex Goncharov Release:9.2-STABLE, built from svn source, r260321 Organization: Environment: FreeBSD 9.2-STABLE FreeBSD 9.2-STABLE #0 r260321 Sun Jan 5 13:06:01 EST 2014 Description: This is an extremely reproducible and very upsetting new problem. I have been using two identical Seagate Expansion 0219 drives for about a year, attaching them to three FreeBSD systems, all of which I update, building from the source, about every two-three weeks. No problem, good drives -- till the last Sunday. This past Sunday, I update two systems from r259425 to r260321, and suddenly both of them now show these 'dmesg'es on connecting either of the two drives: usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_STALLED, ignored) usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_STALLED usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_STALLED, ignored) usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_STALLED usb_alloc_device: Failure selecting configuration index 0:USB_ERR_STALLED, port 3, addr 2 (ignored) ugen5.2: Seagate at usbus5 ugen5.2: Seagate at usbus5 (disconnected) Fortunately, I didn't upgrade my third system and its still at FreeBSD 9.2-STABLE FreeBSD 9.2-STABLE #0 r259425: Sun Dec 15 16:52:59 EST 2013 I've been using one of these two Seagate drives on it without a single problem (didn't have to try the second one.) So between r259425 and r26032 something significant was changed in the code, but I couldn't spot it, having looked into lib/libusb etc/devd code differences. Other points of reference for the current situation: 1. Several other USB drives I have -- Buffalo, Toshiba, Sony -- function without this problem. 2. After I discovered this problem in r260321, I copied the full (close to 1TB) contents of my primary Seagate drive to two 1T Sony drives, using my Linux system. Not a single problem. 3. When I tried to copy (in r260321 only) the contents of my 500G Buffalo drives to the same Sony drive, my system went down twice, because the device written to, 'da0' was being lost while being written to; I first used gjournal and then the plain 'news -U /dev/da0' to create a file system -- the same result: the computer crashed after a few tens of GBs had been copied to the Sony. (A very poor comparison to my Linux experience, alas.) 4. To my astonishment, I could not boot into the old kernel boot /boot/kernel.old/kernel now, to experiment with the r259425 kernel. On both system where I tried that, the boot process was interrupted on some devd (devfs) problems. I've never had see such behavior before (but I haven't been booting with kernel.old for 2+ years.) Needless to say, this is a big disappointment, especially considering the wonderful behavior of both Seagate and Sony drives when used on a Linux machines -- with a wider range or the file systems I used. I'll try 10.0-STABLE in a couple of weeks, but for now the non-upgraded 9.2-STABLE #0 r259425 machine will stay non-upgraded (and I am thinking, again, if moving to Linux more resolutely than I have done so far, would make sense now.) Thank you, -- Alex How-To-Repeat: Fix: Release-Note: Audit-Trail: Unformatted: ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: usb/185628: usbd_req_re_enumerate set address failed USB_ERR_STALLED for Seagate USB drives between r259425 and r260321
The following reply was made to PR usb/185628; it has been noted by GNATS. From: Alex Goncharov alex_goncharov_...@yahoo.com To: Hans Petter Selasky h...@bitfrost.no, freebsd-gnats-sub...@freebsd.org freebsd-gnats-sub...@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=3DUTF8psc=3D1=0A=0A What USB speed are they connected at= ?=0A=0AA 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 h...@bitfrost.no 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 htmlbodydiv style=3Dcolor:#000; background-color:#fff; font-family:He= lveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif;fo= nt-size:12ptdivspanHello Hans,brbrThank you for your prompt repli= es; I'll make this a short note, beforebrrunning to work, and we can work= on this later.brbrgt; Here is a patch you can try, as an attachment.= brbrOK, re-building
Re: usb/185628: usbd_req_re_enumerate set address failed USB_ERR_STALLED for Seagate USB drives between r259425 and r260321
The following reply was made to PR usb/185628; it has been noted by GNATS. From: Alex Goncharov alex_goncharov_...@yahoo.com To: Hans Petter Selasky h...@bitfrost.no, freebsd-gnats-sub...@freebsd.org freebsd-gnats-sub...@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 06:05:04 -0800 (PST) --464114708-1921223609-1389362704=:6984 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable If you are running EHCI, there has been no changes in the USB stack, and= =0A you should look for CAM/SCSI related changes:=0A =0A Just grepping q= uickly, can this be related to what you are seeing?=0A =0A http://svnweb.= freebsd.org/changeset/base/259722=0A=0A=A0 Author: =A0=A0=A0 mav=0A=A0 Date= : =A0=A0=A0 Sun Dec 22 13:03:33 2013 UTC (2 weeks, 5 days ago)=0A=0AThank y= ou: this may be the trouble-causing change.=A0 Later, I'll see if=0Areverti= ng it results in being able to use the Seagate HDDs again.=0A=0AThe 'pcicon= f' for the desktop (upgraded, Seagate-problematic now):=0A=0A--= =0Apciconf -lv=0A= =3D=0Ahostb0@pci0:0:0:0:=A0=A0=A0=A0=A0 class=3D0x06 card=3D0x01271028= chip=3D0x25608086 rev=3D0x01 hdr=3D0x00=0A=A0=A0=A0 vendor=A0=A0=A0=A0 =3D= 'Intel Corporation'=0A=A0=A0=A0 device=A0=A0=A0=A0 =3D '82845G/GL[Brookdal= e-G]/GE/PE DRAM Controller/Host-Hub Interface'=0A=A0=A0=A0 class=A0=A0=A0= =A0=A0 =3D bridge=0A=A0=A0=A0 subclass=A0=A0 =3D HOST-PCI=0Avgapci0@pci0:0:= 2:0:=A0=A0=A0=A0 class=3D0x03 card=3D0x01271028 chip=3D0x25628086 rev= =3D0x01 hdr=3D0x00=0A=A0=A0=A0 vendor=A0=A0=A0=A0 =3D 'Intel Corporation'= =0A=A0=A0=A0 device=A0=A0=A0=A0 =3D '82845G/GL[Brookdale-G]/GE Chipset Inte= grated Graphics Device'=0A=A0=A0=A0 class=A0=A0=A0=A0=A0 =3D display=0A=A0= =A0=A0 subclass=A0=A0 =3D VGA=0Auhci0@pci0:0:29:0:=A0=A0=A0=A0=A0 class=3D0= x0c0300 card=3D0x01271028 chip=3D0x24c28086 rev=3D0x01 hdr=3D0x00=0A=A0=A0= =A0 vendor=A0=A0=A0=A0 =3D 'Intel Corporation'=0A=A0=A0=A0 device=A0=A0=A0= =A0 =3D '82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller'=0A=A0=A0= =A0 class=A0=A0=A0=A0=A0 =3D serial bus=0A=A0=A0=A0 subclass=A0=A0 =3D USB= =0Auhci1@pci0:0:29:1:=A0=A0=A0=A0=A0 class=3D0x0c0300 card=3D0x01271028 chi= p=3D0x24c48086 rev=3D0x01 hdr=3D0x00=0A=A0=A0=A0 vendor=A0=A0=A0=A0 =3D 'In= tel Corporation'=0A=A0=A0=A0 device=A0=A0=A0=A0 =3D '82801DB/DBL/DBM (ICH4/= ICH4-L/ICH4-M) USB UHCI Controller'=0A=A0=A0=A0 class=A0=A0=A0=A0=A0 =3D se= rial bus=0A=A0=A0=A0 subclass=A0=A0 =3D USB=0Auhci2@pci0:0:29:2:=A0=A0=A0= =A0=A0 class=3D0x0c0300 card=3D0x01271028 chip=3D0x24c78086 rev=3D0x01 hdr= =3D0x00=0A=A0=A0=A0 vendor=A0=A0=A0=A0 =3D 'Intel Corporation'=0A=A0=A0=A0 = device=A0=A0=A0=A0 =3D '82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Contr= oller'=0A=A0=A0=A0 class=A0=A0=A0=A0=A0 =3D serial bus=0A=A0=A0=A0 subclass= =A0=A0 =3D USB=0Aehci0@pci0:0:29:7:=A0=A0=A0=A0=A0 class=3D0x0c0320 card=3D= 0x01271028 chip=3D0x24cd8086 rev=3D0x01 hdr=3D0x00=0A=A0=A0=A0 vendor=A0=A0= =A0=A0 =3D 'Intel Corporation'=0A=A0=A0=A0 device=A0=A0=A0=A0 =3D '82801DB/= DBM (ICH4/ICH4-M) USB2 EHCI Controller'=0A=A0=A0=A0 class=A0=A0=A0=A0=A0 = =3D serial bus=0A=A0=A0=A0 subclass=A0=A0 =3D USB=0Apcib1@pci0:0:30:0:=A0= =A0=A0=A0=A0 class=3D0x060400 card=3D0x chip=3D0x244e8086 rev=3D0x8= 1 hdr=3D0x01=0A=A0=A0=A0 vendor=A0=A0=A0=A0 =3D 'Intel Corporation'=0A=A0= =A0=A0 device=A0=A0=A0=A0 =3D '82801 PCI Bridge'=0A=A0=A0=A0 class=A0=A0=A0= =A0=A0 =3D bridge=0A=A0=A0=A0 subclass=A0=A0 =3D PCI-PCI=0Aisab0@pci0:0:31:= 0:=A0=A0=A0=A0=A0 class=3D0x060100 card=3D0x chip=3D0x24c08086 rev= =3D0x01 hdr=3D0x00=0A=A0=A0=A0 vendor=A0=A0=A0=A0 =3D 'Intel Corporation'= =0A=A0=A0=A0 device=A0=A0=A0=A0 =3D '82801DB/DBL (ICH4/ICH4-L) LPC Interfac= e Bridge'=0A=A0=A0=A0 class=A0=A0=A0=A0=A0 =3D bridge=0A=A0=A0=A0 subclass= =A0=A0 =3D PCI-ISA=0Aatapci0@pci0:0:31:1:=A0=A0=A0 class=3D0x01018a card=3D= 0x01271028 chip=3D0x24cb8086 rev=3D0x01 hdr=3D0x00=0A=A0=A0=A0 vendor=A0=A0= =A0=A0 =3D 'Intel Corporation'=0A=A0=A0=A0 device=A0=A0=A0=A0 =3D '82801DB = (ICH4) IDE Controller'=0A=A0=A0=A0 class=A0=A0=A0=A0=A0 =3D mass storage=0A= =A0=A0=A0 subclass=A0=A0 =3D ATA=0Anone0@pci0:0:31:3:=A0=A0=A0=A0=A0 class= =3D0x0c0500 card=3D0x01271028 chip=3D0x24c38086 rev=3D0x01 hdr=3D0x00=0A=A0= =A0=A0 vendor=A0=A0=A0=A0 =3D 'Intel Corporation'=0A=A0=A0=A0 device=A0=A0= =A0=A0 =3D '82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) SMBus Controller'=0A=A0=A0= =A0 class=A0=A0=A0=A0=A0 =3D serial bus=0A=A0=A0=A0 subclass=A0=A0 =3D SMBu= s=0Adc0@pci0:1:7:0: class=3D0x02 card=3D0x05741317 chip=3D0x09851317 re= v=3D0x11 hdr=3D0x00=0A=A0=A0=A0 vendor=A0=A0=A0=A0 =3D 'ADMtek'=0A=A0=A0=A0= device=A0=A0=A0=A0 =3D 'NC100 Network Everywhere Fast Ethernet 10/100'=0A= =A0=A0=A0 class=A0=A0=A0=A0=A0
Re: usb/185628: usbd_req_re_enumerate set address failed USB_ERR_STALLED for Seagate USB drives between r259425 and r260321
The following reply was made to PR usb/185628; it has been noted by GNATS. From: Alex Goncharov alex_goncharov_...@yahoo.com To: Hans Petter Selasky h...@bitfrost.no, freebsd-gnats-sub...@freebsd.org freebsd-gnats-sub...@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 19:50:58 -0800 (PST) --464114708-874558429-1389412258=:8299 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable I rebuilt the kernel with change 259722 reverted:=0A=0A=A0 ident /boot/kern= el.scsi_all-back/kernel | grep /scsi_all.c=0A=A0 =3D=0A=A0=A0=A0=A0 $FreeB= SD: stable/9/sys/cam/scsi/scsi_all.c 257050 2013-10-24 10:34:13Z mav $=0A= =0AStill have the same dmesges:=0A=0A-=0Ausbd_req_re_enumerate: addr=3D= 2, set address failed! (USB_ERR_STALLED, ignored)=0Ausbd_setup_device_desc:= getting device descriptor at addr 2 failed, USB_ERR_STALLED=0Ausbd_req_re_= enumerate: addr=3D2, set address failed! (USB_ERR_STALLED, ignored)=0Ausbd_= setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_STAL= LED=0Ausb_alloc_device: Failure selecting configuration index 0:USB_ERR_STA= LLED, port 4, addr 2 (ignored)=0Augen5.2: Seagate at usbus5=0A=0A=0AI= 'll launch another rebuild for the night, after 'svn up' -- maybe something= will be discovered.=A0 If anybody has suggestions on debugging the issue, = please let me know.=0A=0A-- Alex=0A=0A=0A=0A=0AOn Friday, January 10, 2014 = 8:08 AM, Hans Petter Selasky h...@bitfrost.no wrote:=0A =0AOn 01/10/14 12:= 49, Alex Goncharov wrote:=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 May be; but think about the fact correlations: the fac= t of the two=0A system's upgrade, two identical Seagate units, and other H= DDs being=0A non-stalled.=0A=0A=0AHi,=0A=0AIf you are running EHCI, there= has been no changes in the USB stack, and =0Ayou should look for CAM/SCSI = related changes:=0A=0AJust grepping quickly, can this be related to what yo= u are seeing?=0A=0Ahttp://svnweb.freebsd.org/changeset/base/259722=0A=0A--H= PS --464114708-874558429-1389412258=:8299 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable htmlbodydiv style=3Dcolor:#000; background-color:#fff; font-family:He= lveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif;fo= nt-size:12ptI rebuilt the kernel with change 259722 revespan class=3Dta= brted:brbrnbsp; ident /boot/kernel.scsi_all-back/kernel | grep /scsi= _all.cbrnbsp; =3Dgt;brnbsp;nbsp;nbsp;nbsp; $FreeBSD: stable/9/sys= /cam/scsi/scsi_all.c 257050 2013-10-24 10:34:13Z mav $brbrStill have th= e same dmesges:brbr-brusbd_req_re_enumerate: addr=3D2, set addres= s failed! (USB_ERR_STALLED, ignored)brusbd_setup_device_desc: getting dev= ice descriptor at addr 2 failed, USB_ERR_STALLEDbrusbd_req_re_enumerate: = addr=3D2, set address failed! (USB_ERR_STALLED, ignored)brusbd_setup_devi= ce_desc: getting device descriptor at addr 2 failed, USB_ERR_STALLEDbrusb= _alloc_device: Failure selecting configuration index 0:USB_ERR_STALLED, por= t 4, addr 2 (ignored)brugen5.2: lt;Seagategt; at usbus5brbrbrI'll launch another rebuild for the night, after 'sv= n up' -- maybe something will be discovered.nbsp; If anybody has suggestio= ns on debugging the issue, please let me know.brbr-- Alexbrspan clas= s=3Dtab/span/spandiv style=3Ddisplay: block; class=3Dyahoo_quote= d br br div style=3Dfont-family: HelveticaNeue, Helvetica Neue, Hel= vetica, Arial, Lucida Grande, sans-serif; font-size: 12pt; div style=3D= font-family: HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande= , sans-serif; font-size: 12pt; div dir=3Dltr font face=3DArial siz= e=3D2 On Friday, January 10, 2014 8:08 AM, Hans Petter Selasky lt;hps@b= itfrost.nogt; wrote:br /font /div div class=3Dy_msg_containerOn= 01/10/14 12:49, Alex Goncharov wrote:brgt;gt; gt;If devices simply re= -attach either they are not respond and softwarebrgt;gt; gt;initiates = a reset, which can be disabled by settingbrgt;gt; gt;hw.usb.no_cs_fai= l or the software in the USB HDD died andbrgt;gt; gt;rebooted.brgt; May be;= but think about the fact correlations: the fact of the twobrgt; system'= s upgrade, two identical Seagate units, and other HDDs beingbrgt; non-st= alled.brgt;brbrHi,brbrIf you are running EHCI, there has been no= changes in the USB stack, and bryou should look for CAM/SCSI related cha= nges:brbrJust grepping quickly, can this be related to what you are see= ing?brbra href=3Dhttp://svnweb.freebsd.org/changeset/base/259722; tar= get=3D_blankhttp://svnweb.freebsd.org/changeset/base/259722/abrbr-= -HPSbrbrbr/div /div /div /div /div/body/html --464114708-874558429
Re: usb/185628: usbd_req_re_enumerate set address failed USB_ERR_STALLED for Seagate USB drives between r259425 and r260321
No improvement after:
* 'svn up' to r260531M
* scsi_all.c reverted to:
svn diff
Index: sys/cam/scsi/scsi_all.c
===
--- sys/cam/scsi/scsi_all.c (revision 260531)
+++ sys/cam/scsi/scsi_all.c (working copy)
@@ -6509,11 +6509,7 @@
while (rhs_id = rhs_last
(rhs_id-identifier + rhs_id-length) = rhs_end) {
- if ((rhs_id-id_type
-(SVPD_ID_ASSOC_MASK | SVPD_ID_TYPE_MASK)) ==
- (lhs_id-id_type
-(SVPD_ID_ASSOC_MASK | SVPD_ID_TYPE_MASK))
- rhs_id-length == lhs_id-length
+ if (rhs_id-length == lhs_id-length
memcmp(rhs_id-identifier, lhs_id-identifier,
rhs_id-length) == 0)
return (0);
More info:
sysctl kern.bootfile
=
kern.bootfile: /boot/kernel/kernel
strings /boot/kernel/kernel | grep '^FreeBSD 9'
=
FreeBSD 9.2-STABLE #0 r260531M: Sat Jan 11 00:55:07 EST 2014
ident /boot/kernel/kernel | grep sys/cam/scsi/scsi_all.c
=
$FreeBSD: stable/9/sys/cam/scsi/scsi_all.c 257050 2013-10-24 10:34:13Z mav
$
With hw.usb.no_cs_fail 0 or 1, the same dmesges on attaching the
Seagate drive:
kernel: usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_STALLED,
ignored)
kernel: usbd_setup_device_desc: getting device descriptor at addr 2 failed,
USB_ERR_STALLED
kernel: usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_STALLED,
ignored)
kernel: usbd_setup_device_desc: getting device descriptor at addr 2 failed,
USB_ERR_STALLED
kernel: usb_alloc_device: Failure selecting configuration index
0:USB_ERR_STALLED, port 3, addr 2 (ignored)
kernel: ugen5.2: Seagate at usbus5
Used this drive all right yesterday with the build done 2013-12-15.
-- Alex
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: usb/185628: usbd_req_re_enumerate set address failed USB_ERR_STALLED for Seagate USB drives between r259425 and r260321
The following reply was made to PR usb/185628; it has been noted by GNATS.
From: Alex Goncharov alex_goncharov_...@yahoo.com
To: freebsd-gnats-sub...@freebsd.org, freebsd-usb@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: Sat, 11 Jan 2014 03:10:41 -0800 (PST)
No improvement after:
* 'svn up' to r260531M
* scsi_all.c reverted to:
svn diff
Index: sys/cam/scsi/scsi_all.c
===
--- sys/cam/scsi/scsi_all.c (revision 260531)
+++ sys/cam/scsi/scsi_all.c (working copy)
@@ -6509,11 +6509,7 @@
while (rhs_id = rhs_last
(rhs_id-identifier + rhs_id-length) = rhs_end) {
- if ((rhs_id-id_type
-(SVPD_ID_ASSOC_MASK | SVPD_ID_TYPE_MASK)) ==
- (lhs_id-id_type
-(SVPD_ID_ASSOC_MASK | SVPD_ID_TYPE_MASK))
- rhs_id-length == lhs_id-length
+ if (rhs_id-length == lhs_id-length
memcmp(rhs_id-identifier, lhs_id-identifier,
rhs_id-length) == 0)
return (0);
More info:
sysctl kern.bootfile
=
kern.bootfile: /boot/kernel/kernel
strings /boot/kernel/kernel | grep '^FreeBSD 9'
=
FreeBSD 9.2-STABLE #0 r260531M: Sat Jan 11 00:55:07 EST 2014
ident /boot/kernel/kernel | grep sys/cam/scsi/scsi_all.c
=
$FreeBSD: stable/9/sys/cam/scsi/scsi_all.c 257050 2013-10-24 10:34:13Z
mav $
With hw.usb.no_cs_fail 0 or 1, the same dmesges on attaching the
Seagate drive:
kernel: usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_STALLED,
ignored)
kernel: usbd_setup_device_desc: getting device descriptor at addr 2 failed,
USB_ERR_STALLED
kernel: usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_STALLED,
ignored)
kernel: usbd_setup_device_desc: getting device descriptor at addr 2 failed,
USB_ERR_STALLED
kernel: usb_alloc_device: Failure selecting configuration index
0:USB_ERR_STALLED, port 3, addr 2 (ignored)
kernel: ugen5.2: Seagate at usbus5
Used this drive all right yesterday with the build done 2013-12-15.
-- Alex
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: usb/185628: usbd_req_re_enumerate set address failed USB_ERR_STALLED for Seagate USB drives between r259425 and r260321
,-- On Fri, 1/10/14, Hans Petter Selasky h...@bitfrost.no wrote:
,-- On 01/10/14 12:49, Alex Goncharov wrote:
Maybe; but think about the fact correlations: the fact of the two
system's upgrade, two identical Seagate units, and other HDDs being
non-stalled.
If you are running EHCI, there has been no changes in the USB stack,
Apparently, there have been; this is what causes the bogus error:
r259454 | hselasky | 2013-12-16 03:51:58 -0500 (Mon, 16 Dec 2013) | 11 lines
MFC r244503 and r246565:
Make sure all USB drivers allocate buffer memory
through the USB API and/or busdma.
The following assumptions have been made:
umass - buffers passed from CAM/SCSI layer are OK
network - mbufs are OK.
Some other nits while at it.
I am attaching the code difference for the two relevant files
M sys/dev/usb/storage/ustorage_fs.c
M sys/dev/usb/usb_msctest.c
in this change set, skipping the irrelevant 'sys/dev/usb/wlan' ones.
Can this be fixed reasonably soon, please? (I miss my HDDs :)
-- AlexIndex: sys/dev/usb/storage/ustorage_fs.c
===
--- sys/dev/usb/storage/ustorage_fs.c (revision 259449)
+++ sys/dev/usb/storage/ustorage_fs.c (revision 259494)
@@ -74,7 +74,7 @@
/* Define some limits */
#ifndef USTORAGE_FS_BULK_SIZE
-#define USTORAGE_FS_BULK_SIZE (1UL 17) /* bytes */
+#define USTORAGE_FS_BULK_SIZE (1U 17) /* bytes */
#endif
#ifndef USTORAGE_FS_MAX_LUN
@@ -85,8 +85,6 @@
#define USTORAGE_QDATA_MAX 40 /* bytes */
#endif
-#define sc_cmd_data sc_cbw.CBWCDB
-
/*
* The SCSI ID string must be exactly 28 characters long
* exluding the terminating zero.
@@ -176,8 +174,9 @@
struct ustorage_fs_softc {
- ustorage_fs_bbb_cbw_t sc_cbw; /* Command Wrapper Block */
- ustorage_fs_bbb_csw_t sc_csw; /* Command Status Block */
+ ustorage_fs_bbb_cbw_t *sc_cbw; /* Command Wrapper Block */
+ ustorage_fs_bbb_csw_t *sc_csw; /* Command Status Block */
+ void *sc_dma_ptr; /* Main data buffer */
struct mtx sc_mtx;
@@ -275,7 +274,6 @@
.endpoint = UE_ADDR_ANY,
.direction = UE_DIR_OUT,
.bufsize = sizeof(ustorage_fs_bbb_cbw_t),
- .flags = {.ext_buffer = 1,},
.callback = ustorage_fs_t_bbb_command_callback,
.usb_mode = USB_MODE_DEVICE,
},
@@ -295,7 +293,7 @@
.endpoint = UE_ADDR_ANY,
.direction = UE_DIR_OUT,
.bufsize = USTORAGE_FS_BULK_SIZE,
- .flags = {.proxy_buffer = 1,.short_xfer_ok = 1,.ext_buffer = 1},
+ .flags = {.proxy_buffer = 1,.short_xfer_ok = 1},
.callback = ustorage_fs_t_bbb_data_read_callback,
.usb_mode = USB_MODE_DEVICE,
},
@@ -315,7 +313,7 @@
.endpoint = UE_ADDR_ANY,
.direction = UE_DIR_IN,
.bufsize = sizeof(ustorage_fs_bbb_csw_t),
- .flags = {.short_xfer_ok = 1,.ext_buffer = 1,},
+ .flags = {.short_xfer_ok = 1},
.callback = ustorage_fs_t_bbb_status_callback,
.usb_mode = USB_MODE_DEVICE,
},
@@ -409,6 +407,14 @@
transfers, %s\n, usbd_errstr(err));
goto detach;
}
+
+ sc-sc_cbw = usbd_xfer_get_frame_buffer(sc-sc_xfer[
+ USTORAGE_FS_T_BBB_COMMAND], 0);
+ sc-sc_csw = usbd_xfer_get_frame_buffer(sc-sc_xfer[
+ USTORAGE_FS_T_BBB_STATUS], 0);
+ sc-sc_dma_ptr = usbd_xfer_get_frame_buffer(sc-sc_xfer[
+ USTORAGE_FS_T_BBB_DATA_READ], 0);
+
/* start Mass Storage State Machine */
mtx_lock(sc-sc_mtx);
@@ -518,7 +524,7 @@
switch (USB_GET_STATE(xfer)) {
case USB_ST_TRANSFERRED:
- tag = UGETDW(sc-sc_cbw.dCBWSignature);
+ tag = UGETDW(sc-sc_cbw-dCBWSignature);
if (tag != CBWSIGNATURE) {
/* do nothing */
@@ -525,29 +531,29 @@
DPRINTF(invalid signature 0x%08x\n, tag);
break;
}
- tag = UGETDW(sc-sc_cbw.dCBWTag);
+ tag = UGETDW(sc-sc_cbw-dCBWTag);
/* echo back tag */
- USETDW(sc-sc_csw.dCSWTag, tag);
+ USETDW(sc-sc_csw-dCSWTag, tag);
/* reset status */
- sc-sc_csw.bCSWStatus = 0;
+ sc-sc_csw-bCSWStatus = 0;
/* reset data offset, data length and data remainder */
sc-sc_transfer.offset = 0;
sc-sc_transfer.data_rem =
- UGETDW(sc-sc_cbw.dCBWDataTransferLength);
+ UGETDW(sc-sc_cbw-dCBWDataTransferLength);
/* reset data flags */
sc-sc_transfer.data_short = 0;
/* extract LUN */
- sc-sc_transfer.lun = sc-sc_cbw.bCBWLUN;
+ sc-sc_transfer.lun = sc-sc_cbw-bCBWLUN;
if (sc-sc_transfer.data_rem == 0) {
sc-sc_transfer.cbw_dir = DIR_NONE;
} else {
- if (sc-sc_cbw.bCBWFlags CBWFLAGS_IN) {
+ if (sc-sc_cbw-bCBWFlags CBWFLAGS_IN) {
sc-sc_transfer.cbw_dir = DIR_WRITE;
} else {
sc-sc_transfer.cbw_dir = DIR_READ;
@@ -554,8 +560,8 @@
}
}
- sc-sc_transfer.cmd_len = sc-sc_cbw.bCDBLength;
- if ((sc-sc_transfer.cmd_len sizeof(sc-sc_cbw.CBWCDB)) ||
+ sc-sc_transfer.cmd_len = sc-sc_cbw-bCDBLength;
+ if ((sc-sc_transfer.cmd_len sizeof(sc
Re: usb/185628: usbd_req_re_enumerate set address failed USB_ERR_STALLED for Seagate USB drives between r259425 and r260321
The following reply was made to PR usb/185628; it has been noted by GNATS. From: Alex Goncharov alex_goncharov_...@yahoo.com To: freebsd-gnats-sub...@freebsd.org freebsd-gnats-sub...@freebsd.org, Hans Petter Selasky h...@bitfrost.no, freebsd-usb@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: Sat, 11 Jan 2014 21:58:02 -0800 (PST) --2120775178-1643984294-1389506282=:33519 Content-Type: text/plain; charset=us-ascii ,-- On Fri, 1/10/14, Hans Petter Selasky h...@bitfrost.no wrote: ,-- On 01/10/14 12:49, Alex Goncharov wrote: Maybe; but think about the fact correlations: the fact of the two system's upgrade, two identical Seagate units, and other HDDs being non-stalled. If you are running EHCI, there has been no changes in the USB stack, Apparently, there have been; this is what causes the bogus error: r259454 | hselasky | 2013-12-16 03:51:58 -0500 (Mon, 16 Dec 2013) | 11 lines MFC r244503 and r246565: Make sure all USB drivers allocate buffer memory through the USB API and/or busdma. The following assumptions have been made: umass - buffers passed from CAM/SCSI layer are OK network - mbufs are OK. Some other nits while at it. I am attaching the code difference for the two relevant files M sys/dev/usb/storage/ustorage_fs.c M sys/dev/usb/usb_msctest.c in this change set, skipping the irrelevant 'sys/dev/usb/wlan' ones. Can this be fixed reasonably soon, please? (I miss my HDDs :) -- Alex --2120775178-1643984294-1389506282=:33519 Content-Type: text/x-patch; name=sys-dev-usb-2013-12-16-2013-12-17.diff Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=sys-dev-usb-2013-12-16-2013-12-17.diff SW5kZXg6IHN5cy9kZXYvdXNiL3N0b3JhZ2UvdXN0b3JhZ2VfZnMuYwo9PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09Ci0tLSBzeXMvZGV2L3VzYi9zdG9yYWdlL3Vz dG9yYWdlX2ZzLmMJKHJldmlzaW9uIDI1OTQ0OSkKKysrIHN5cy9kZXYvdXNi L3N0b3JhZ2UvdXN0b3JhZ2VfZnMuYwkocmV2aXNpb24gMjU5NDk0KQpAQCAt NzQsNyArNzQsNyBAQAogLyogRGVmaW5lIHNvbWUgbGltaXRzICovCiAKICNp Zm5kZWYgVVNUT1JBR0VfRlNfQlVMS19TSVpFIAotI2RlZmluZQlVU1RPUkFH RV9GU19CVUxLX1NJWkUgKDFVTCA8PCAxNykJLyogYnl0ZXMgKi8KKyNkZWZp bmUJVVNUT1JBR0VfRlNfQlVMS19TSVpFCSgxVSA8PCAxNykJLyogYnl0ZXMg Ki8KICNlbmRpZgogCiAjaWZuZGVmCVVTVE9SQUdFX0ZTX01BWF9MVU4KQEAg LTg1LDggKzg1LDYgQEAKICNkZWZpbmUJVVNUT1JBR0VfUURBVEFfTUFYCTQw CS8qIGJ5dGVzICovCiAjZW5kaWYKIAotI2RlZmluZSBzY19jbWRfZGF0YSBz Y19jYncuQ0JXQ0RCCi0KIC8qCiAgKiBUaGUgU0NTSSBJRCBzdHJpbmcgbXVz dCBiZSBleGFjdGx5IDI4IGNoYXJhY3RlcnMgbG9uZwogICogZXhsdWRpbmcg dGhlIHRlcm1pbmF0aW5nIHplcm8uCkBAIC0xNzYsOCArMTc0LDkgQEAKIAog c3RydWN0IHVzdG9yYWdlX2ZzX3NvZnRjIHsKIAotCXVzdG9yYWdlX2ZzX2Ji Yl9jYndfdCBzY19jYnc7CS8qIENvbW1hbmQgV3JhcHBlciBCbG9jayAqLwot CXVzdG9yYWdlX2ZzX2JiYl9jc3dfdCBzY19jc3c7CS8qIENvbW1hbmQgU3Rh dHVzIEJsb2NrICovCisJdXN0b3JhZ2VfZnNfYmJiX2Nid190ICpzY19jYnc7 CS8qIENvbW1hbmQgV3JhcHBlciBCbG9jayAqLworCXVzdG9yYWdlX2ZzX2Ji Yl9jc3dfdCAqc2NfY3N3OwkvKiBDb21tYW5kIFN0YXR1cyBCbG9jayAqLwor CXZvaWQgKnNjX2RtYV9wdHI7CQkvKiBNYWluIGRhdGEgYnVmZmVyICovCiAK IAlzdHJ1Y3QgbXR4IHNjX210eDsKIApAQCAtMjc1LDcgKzI3NCw2IEBACiAJ CS5lbmRwb2ludCA9IFVFX0FERFJfQU5ZLAogCQkuZGlyZWN0aW9uID0gVUVf RElSX09VVCwKIAkJLmJ1ZnNpemUgPSBzaXplb2YodXN0b3JhZ2VfZnNfYmJi X2Nid190KSwKLQkJLmZsYWdzID0gey5leHRfYnVmZmVyID0gMSx9LAogCQku Y2FsbGJhY2sgPSAmdXN0b3JhZ2VfZnNfdF9iYmJfY29tbWFuZF9jYWxsYmFj aywKIAkJLnVzYl9tb2RlID0gVVNCX01PREVfREVWSUNFLAogCX0sCkBAIC0y OTUsNyArMjkzLDcgQEAKIAkJLmVuZHBvaW50ID0gVUVfQUREUl9BTlksCiAJ CS5kaXJlY3Rpb24gPSBVRV9ESVJfT1VULAogCQkuYnVmc2l6ZSA9IFVTVE9S QUdFX0ZTX0JVTEtfU0laRSwKLQkJLmZsYWdzID0gey5wcm94eV9idWZmZXIg PSAxLC5zaG9ydF94ZmVyX29rID0gMSwuZXh0X2J1ZmZlciA9IDF9LAorCQku ZmxhZ3MgPSB7LnByb3h5X2J1ZmZlciA9IDEsLnNob3J0X3hmZXJfb2sgPSAx fSwKIAkJLmNhbGxiYWNrID0gJnVzdG9yYWdlX2ZzX3RfYmJiX2RhdGFfcmVh ZF9jYWxsYmFjaywKIAkJLnVzYl9tb2RlID0gVVNCX01PREVfREVWSUNFLAog CX0sCkBAIC0zMTUsNyArMzEzLDcgQEAKIAkJLmVuZHBvaW50ID0gVUVfQURE Ul9BTlksCiAJCS5kaXJlY3Rpb24gPSBVRV9ESVJfSU4sCiAJCS5idWZzaXpl ID0gc2l6ZW9mKHVzdG9yYWdlX2ZzX2JiYl9jc3dfdCksCi0JCS5mbGFncyA9 IHsuc2hvcnRfeGZlcl9vayA9IDEsLmV4dF9idWZmZXIgPSAxLH0sCisJCS5m bGFncyA9IHsuc2hvcnRfeGZlcl9vayA9IDF9LAogCQkuY2FsbGJhY2sgPSAm dXN0b3JhZ2VfZnNfdF9iYmJfc3RhdHVzX2NhbGxiYWNrLAogCQkudXNiX21v ZGUgPSBVU0JfTU9ERV9ERVZJQ0UsCiAJfSwKQEAgLTQwOSw2ICs0MDcsMTQg QEAKIAkJICAgICJ0cmFuc2ZlcnMsICVzXG4iLCB1c2JkX2VycnN0cihlcnIp KTsKIAkJZ290byBkZXRhY2g7CiAJfQorCisJc2MtPnNjX2NidyA9IHVzYmRf eGZlcl9nZXRfZnJhbWVfYnVmZmVyKHNjLT5zY194ZmVyWworCSAgICBVU1RP UkFHRV9GU19UX0JCQl9DT01NQU5EXSwgMCk7CisJc2MtPnNjX2NzdyA9IHVz YmRfeGZlcl9nZXRfZnJhbWVfYnVmZmVyKHNjLT5zY194ZmVyWworCSAgICBV
Re: usb/185628: usbd_req_re_enumerate set address failed USB_ERR_STALLED for Seagate USB drives between r259425 and r260321
Step 2 is here -- the stall with the 2014-01-05 (r260321) kernel. The attached log covers: the attach-detach-attach-detach sequence. On Sun, 1/12/14, Alex Goncharov alex_goncharov_...@yahoo.com wrote: Subject: Re: usb/185628: usbd_req_re_enumerate set address failed USB_ERR_STALLED for Seagate USB drives between r259425 and r260321 To: Hans Petter Selasky h...@bitfrost.no, freebsd-usb@FreeBSD.org freebsd-usb@FreeBSD.org, freebsd-gnats-sub...@freebsd.org freebsd-gnats-sub...@freebsd.org Date: Sunday, January 12, 2014, 12:02 PM I'll do it slightly differently first -- it'll be easier for me this way. I'll do it differently if you don't find what you are looking for here. Step 1: I booted into kernel-2013-12-16/kernel -- r259449. I can see and mount /dev/da0 when I connect the Seagate HDD. I am attaching the lo of the usbdump here, including the event of 'mount' and 'umount'. Next, I'll reboot into the current (2014-01-05) kernel and will collect similar information. It'll be in the next message. ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: usb/185628: usbd_req_re_enumerate set address failed USB_ERR_STALLED for Seagate USB drives between r259425 and r260321
Hans, Our messages crossed -- a few minutes back I sent you this, which is how it is: From: Alex Goncharov alex_goncharov_...@yahoo.com Subject: Re: usb/185628: usbd_req_re_enumerate set address failed USB_ERR_STALLED for Seagate USB drives between r259425 and r260321 To: Hans Petter Selasky h...@bitfrost.no Date: Sunday, January 12, 2014, 5:01 PM I just noticed your recent r260575 | hselasky | 2014-01-12 16:21:19 -0500 (Sun, 12 Jan 2014) | 5 lines MFC r244607 and r244650: Fix regression issues after r244503. PR: usb/185628 and am beginning a full rebuild; the results will be known in about three hours. Thank you! -- Alex On Sun, 1/12/14, Hans Petter Selasky h...@bitfrost.no wrote: Subject: Re: usb/185628: usbd_req_re_enumerate set address failed USB_ERR_STALLED for Seagate USB drives between r259425 and r260321 To: Alex Goncharov alex_goncharov_...@yahoo.com, freebsd-usb@FreeBSD.org Date: Sunday, January 12, 2014, 4:30 PM On 01/12/14 18:20, Alex Goncharov wrote: The following reply was made to PR usb/185628; it has been noted by GNATS. Hi, Thank you for the logs. I see now what is going on. Your Seagate USB enclosures are crashing hard upon a zero length command block :-( And cannot recover afterwards. The others are not. It is related to some patches which I forgot to MFC to 9-stable which are already in 10 and 11, and not in 8-stable. Can you svn up to 9-stable and try again after this: http://svnweb.freebsd.org/changeset/base/260575 Thank you! --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: usb/185628: usbd_req_re_enumerate set address failed USB_ERR_STALLED for Seagate USB drives between r259425 and r260321
,-- From: Alex Goncharov alex_goncharov_...@yahoo.com Date: Sunday, January 12, 2014, 5:01 PM I just noticed your recent r260575 | hselasky | 2014-01-12 and am beginning a full rebuild; the results will be known in about three hours. Hans, While I am doing the rebuild, may I return to the topic I touched slightly in my original PR submission? A sporadic USB HDD device loss, sometimes with a system crash: I had this with a WD drive, when da0 could disappear at any moment, a file system vnode could not be found for reading or writing and bad things would happen. Now the same story with the Sony USB drive. My observations of many USB HDD's led me to conclude that some are smarter than the others -- the smarter ones may be slower to react to just about anything but they don't get lost. My Seagates may have a huge operation queues for either writing or reading, but I've never lost those drives' devices (da0s) when using them. 500G Buffalo never has a long queue, and good for it, but I am fine with a longer queue of the 1T Seagates, as long as their da0s don't go down. 1.5T Toshiba is another story: it seems like it often needs a significant wake-up period after sitting idle, but 'da0' never goes away, either. What WD and Sony exhibit on FreeBSD is plain horrible. It doesn't make sense to quickly write the first 10G of 100G of data if the system goes down after those 10G. And losing da0 on reading or after idling (the WD's behavior) is just as bad. As I mentioned, I didn't observe the Sony issue when using it on Linux (I didn't with WD -- just sent it back.) Can something be done about it along the Linux's lines, which you briefly mentioned and seemed to be critical about? As a data user, I strongly disagree that Linux's approach here is inferior to the one FreeBSD took, if I understand both correctly. Thank you, -- Alex ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: usb/185628: usbd_req_re_enumerate set address failed USB_ERR_STALLED for Seagate USB drives between r259425 and r260321
The PR problem is resolved after svn up with change r260575 in. Thank you, Hans! (I'd appreciate some action on my da0-out grievances. :) -- Alex On Sun, 1/12/14, Alex Goncharov alex_goncharov_...@yahoo.com wrote: Subject: Re: usb/185628: usbd_req_re_enumerate set address failed USB_ERR_STALLED for Seagate USB drives between r259425 and r260321 To: freebsd-usb@FreeBSD.org, Hans Petter Selasky h...@bitfrost.no Date: Sunday, January 12, 2014, 5:28 PM ,-- From: Alex Goncharov alex_goncharov_...@yahoo.com Date: Sunday, January 12, 2014, 5:01 PM I just noticed your recent r260575 | hselasky | 2014-01-12 and am beginning a full rebuild; the results will be known in about three hours. Hans, While I am doing the rebuild, may I return to the topic I touched slightly in my original PR submission? A sporadic USB HDD device loss, sometimes with a system crash: I had this with a WD drive, when da0 could disappear at any moment, a file system vnode could not be found for reading or writing and bad things would happen. Now the same story with the Sony USB drive. My observations of many USB HDD's led me to conclude that some are smarter than the others -- the smarter ones may be slower to react to just about anything but they don't get lost. My Seagates may have a huge operation queues for either writing or reading, but I've never lost those drives' devices (da0s) when using them. 500G Buffalo never has a long queue, and good for it, but I am fine with a longer queue of the 1T Seagates, as long as their da0s don't go down. 1.5T Toshiba is another story: it seems like it often needs a significant wake-up period after sitting idle, but 'da0' never goes away, either. What WD and Sony exhibit on FreeBSD is plain horrible. It doesn't make sense to quickly write the first 10G of 100G of data if the system goes down after those 10G. And losing da0 on reading or after idling (the WD's behavior) is just as bad. As I mentioned, I didn't observe the Sony issue when using it on Linux (I didn't with WD -- just sent it back.) Can something be done about it along the Linux's lines, which you briefly mentioned and seemed to be critical about? As a data user, I strongly disagree that Linux's approach here is inferior to the one FreeBSD took, if I understand both correctly. Thank you, -- Alex ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: usb/185628: usbd_req_re_enumerate set address failed USB_ERR_STALLED for Seagate USB drives between r259425 and r260321
The following reply was made to PR usb/185628; it has been noted by GNATS. From: Alex Goncharov alex_goncharov_...@yahoo.com To: freebsd-gnats-sub...@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: Mon, 13 Jan 2014 09:13:41 -0800 (PST) The statted problem is resolved after svn up with change r260575 in. Thank you, -- Alex ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
