Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 2 Dec 2009 11:26:54 -0800
From:      "Guojun Jin" <gjin@ubicom.com>
To:        "Stefan Esser" <se@freebsd.org>, "Hans Petter Selasky" <hselasky@c2i.net>
Cc:        bugs@freebsd.org, freebsd-stable@freebsd.org, freebsd-usb@freebsd.org
Subject:   RE: 8.0-RC USB/FS problem
Message-ID:  <CB2DD11991B27C4F99935E6229450D3204E5CB55@STORK.scenix.com>
In-Reply-To: <4B142864.3000103@freebsd.org>
References:  <CB2DD11991B27C4F99935E6229450D3203950A1C@STORK.scenix.com>	<CB2DD11991B27C4F99935E6229450D3203950A23@STORK.scenix.com>	<CB2DD11991B27C4F99935E6229450D3203950A26@STORK.scenix.com> <200911221047.20362.hselasky@c2i.net> <4B142864.3000103@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
I noticed that your machine also has an AMD CPU. Hopefully this may NOT
imply something to the hardware.

I will find more systems especially Intel CPUs to do further test.

-----Original Message-----
From: Stefan Esser [mailto:se@freebsd.org]=20
Sent: Monday, November 30, 2009 12:18 PM
To: Hans Petter Selasky
Cc: freebsd-usb@freebsd.org; bugs@freebsd.org;
freebsd-stable@freebsd.org; Guojun Jin
Subject: Re: 8.0-RC USB/FS problem

On 22.11.2009 10:47 Hans Petter Selasky wrote:
> Other operating systems do a port bus reset when the device has a
problem. On=20
> FreeBSD we just try a software reset via the control endpoint. I guess
that it=20
> is a device problem you are seeing. The USB stack in FreeBSD is faster
than=20
> the old one, and maybe the faster queueing of mass storage requests
trigger=20
> some hidden bugs in your device.
>=20
> When the problem happens try:
>=20
> sysctl hw.usb.umass.debug=3D-1

I have observed USB lock-ups with several external drive enclosures
that used to work with the old USB stack (and continue to work when
connected to a Windows notebook, for example). (BTW: System is AMD X2
with Nvidia chip-set and i386 kernel.)

In my case, hw.usb.debug=3D6 makes the drive work at some 4MB/s for
any amount of data transfered, while hw.usb.debug=3D5 (and an ylower
value) lets the drive pause for about 1 Minute per 100MB transfered.
I wanted to test whether short delays inserted in the places with
DPRINTFN(6, ...) make a difference, but will not get to it before
the weekend.

Regards, STefan



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CB2DD11991B27C4F99935E6229450D3204E5CB55>