Date: Sun, 12 Jan 2014 17:36:16 -0800 (PST) From: Alex Goncharov <alex_goncharov_usa@yahoo.com> To: freebsd-usb@FreeBSD.org, Hans Petter Selasky <hps@bitfrost.no> Subject: Re: usb/185628: usbd_req_re_enumerate set address failed USB_ERR_STALLED for Seagate USB drives between r259425 and r260321 Message-ID: <1389576976.47441.YahooMailBasic@web162105.mail.bf1.yahoo.com> In-Reply-To: <1389565689.83194.YahooMailBasic@web162101.mail.bf1.yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
The PR problem is resolved after "svn up" with change r260575 in.
Thank you, Hans! =20
(I'd appreciate some action on my da0-out grievances. :)
-- Alex
--------------------------------------------
On Sun, 1/12/14, Alex Goncharov <alex_goncharov_usa@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" <hps@bitfrost.no>
Date: Sunday, January 12, 2014, 5:28 PM
=20
,-- From: Alex Goncharov <alex_goncharov_usa@yahoo.com>
> Date: Sunday, January 12, 2014, 5:01 PM
=20
> I just noticed your recent
>=20
> ----
> r260575 | hselasky | 2014-01-12
>
> and am beginning a full rebuild; the results will be
known in about
> three hours.
=20
Hans,
=20
While I am doing the rebuild, may I return to the topic I
touched
slightly in my original PR submission?
=20
A sporadic USB HDD device loss, sometimes with a system
crash:
=20
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.
=20
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.=A0 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.=A0
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.=A0 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.
=20
What WD and Sony exhibit on FreeBSD is plain horrible.=A0
It doesn't
make sense to quickly write the first 10G of 100G of data if
the
system goes down after those 10G.=A0 And losing "da0" on
reading or
after idling (the WD's behavior) is just as bad.
=20
As I mentioned, I didn't observe the Sony issue when using
it on Linux
(I didn't with WD -- just sent it back.)
=20
Can something be done about it along the Linux's lines,
which you
briefly mentioned and seemed to be critical about?=A0 As
a data user, I
strongly disagree that Linux's approach here is inferior to
the one
FreeBSD took, if I understand both correctly.
=20
Thank you,
=20
-- Alex
=20
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1389576976.47441.YahooMailBasic>