The following reply was made to PR usb/185628; it has been noted by GNATS. From: Hans Petter Selasky <h...@bitfrost.no> To: Alex Goncharov <alex_goncharov_...@yahoo.com>, 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 08:02:25 +0100
On 01/10/14 04:02, Alex Goncharov wrote: > >> 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.) > Hi, There has been very few changes changes in the USB code recently. Can you tell which USB controllers you have in your system (PCI devices) and tell to which of these your HDD's are attaching to. 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 the USB HDD died and rebooted. Linux hide these problems, but they are visible through the fact that you'll see some requests delaying for some seconds to complete instead of some milliseconds. 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 using 64K reads, while under FreeBSD you'll see more different block sizes being read and written. Do you have dmesg from around the spurious detach? Thank you, --HPS _______________________________________________ firstname.lastname@example.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"