Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 30 Nov 2009 21:17:40 +0100
From:      Stefan Esser <se@freebsd.org>
To:        Hans Petter Selasky <hselasky@c2i.net>
Cc:        bugs@freebsd.org, freebsd-stable@freebsd.org, Guojun Jin <gjin@ubicom.com>, freebsd-usb@freebsd.org
Subject:   Re: 8.0-RC USB/FS problem
Message-ID:  <4B142864.3000103@freebsd.org>
In-Reply-To: <200911221047.20362.hselasky@c2i.net>
References:  <CB2DD11991B27C4F99935E6229450D3203950A1C@STORK.scenix.com>	<CB2DD11991B27C4F99935E6229450D3203950A23@STORK.scenix.com>	<CB2DD11991B27C4F99935E6229450D3203950A26@STORK.scenix.com> <200911221047.20362.hselasky@c2i.net>

next in thread | previous in thread | raw e-mail | index | archive | help
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 
> FreeBSD we just try a software reset via the control endpoint. I guess that it 
> is a device problem you are seeing. The USB stack in FreeBSD is faster than 
> the old one, and maybe the faster queueing of mass storage requests trigger 
> some hidden bugs in your device.
> 
> When the problem happens try:
> 
> sysctl hw.usb.umass.debug=-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=6 makes the drive work at some 4MB/s for
any amount of data transfered, while hw.usb.debug=5 (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?4B142864.3000103>