>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
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Fri Jan 10 03:10:00 UTC 2014
>Originator:     Alex Goncharov
>Release:        9.2-STABLE, built from svn source, r260321
FreeBSD 9.2-STABLE FreeBSD 9.2-STABLE #0 r260321 Sun Jan  5 13:06:01 EST 2014
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, 
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_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



freebsd-usb@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"

Reply via email to