From owner-freebsd-current@FreeBSD.ORG Sun Jan 25 23:45:05 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E8FA21065673; Sun, 25 Jan 2009 23:45:05 +0000 (UTC) (envelope-from andy@siliconlandmark.com) Received: from lexi.siliconlandmark.com (lexi.siliconlandmark.com [66.184.117.4]) by mx1.freebsd.org (Postfix) with ESMTP id 831A28FC0A; Sun, 25 Jan 2009 23:45:05 +0000 (UTC) (envelope-from andy@siliconlandmark.com) Received: from [10.0.1.102] (c-76-112-231-135.hsd1.mi.comcast.net [76.112.231.135]) (authenticated bits=0) by lexi.siliconlandmark.com (8.14.2/8.14.2) with ESMTP id n0PN8xiV009761 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 25 Jan 2009 23:09:00 GMT (envelope-from andy@siliconlandmark.com) Message-Id: From: Andre Guibert de Bruet To: Maxim Sobolev In-Reply-To: <497CC3C4.1070708@FreeBSD.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sun, 25 Jan 2009 18:08:54 -0500 References: <200901241638.18591.hselasky@c2i.net> <497B7A80.4060002@FreeBSD.org> <20090125063441.GC1755@server.vk2pj.dyndns.org> <497CC3C4.1070708@FreeBSD.org> X-Mailer: Apple Mail (2.930.3) X-Virus-Scanned: ClamAV 0.94.1/8901/Sun Jan 25 10:10:36 2009 on lexi.siliconlandmark.com X-Virus-Status: Clean Cc: Peter Jeremy , freebsd-current@freebsd.org Subject: Re: Prblem whit USB in FreeBSD 8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jan 2009 23:45:06 -0000 On Jan 25, 2009, at 2:55 PM, Maxim Sobolev wrote: > Peter Jeremy wrote: >> On 2009-Jan-24 12:30:56 -0800, Maxim Sobolev >> wrote: >>> I wonder if this situation can be handled automatically. To my >>> ignorant view, our USB mass storage driver can try sending >>> "synchronize cache" command and if that fails then failback to the >>> NO_SYNCHRONIZE_CACHE behavior. >> This has been discussed in the past. The problem is that some drives >> lock up when you send a "synchronize cache" command so this isn't a >> general solution. > > So what? The drive that is not in the quirks won't work anyway, so > that if by auto-detection you can make at least fraction of those > drivers working out of the box it would be an improvement. I wonder > how other operating systems (Windows, Linux) cope with this issue. > Not sure about a Linux, but I really doubt Windows has anything like > our quirks, yet all drives work with it. Windows has write caching disabled by default. You need to turn it on per-device from the Device Manager by right-clicking on the device, selecting properties, going to the "Policies" tab and selecting "Optimize for performance" (The default is set to "Optimize for quick removal"). Cheers, Andy /* Andre Guibert de Bruet * 436f 6465 2070 6f65 742e 2042 6974 206a */ /* Managing Partner * 6f63 6b65 792e 2053 7973 4164 6d69 6e2e */ /* GSM: +1 734 846 8758 * 2055 4e49 5820 736c 6575 7468 2e00 0000 */ /* WWW: siliconlandmark.com * C/C++, Java, Perl, PHP, SQL, XHTML, XML */