usb/185628: usbd_req_re_enumerate set address failed USB_ERR_STALLED for Seagate USB drives between r259425 and r260321

[Alex Goncharov]

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_usa at 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 at FreeBSD.org, "Hans Petter Selasky" <hps at bitfrost.no>
 Date: Sunday, January 12, 2014, 5:28 PM
 
 ,-- From: Alex Goncharov <alex_goncharov_usa at 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 ("da0"s) 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 "da0"s 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