From owner-freebsd-scsi@FreeBSD.ORG Fri Jan 20 20:00:01 2006 Return-Path: X-Original-To: freebsd-scsi@FreeBSD.org Delivered-To: freebsd-scsi@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 417C416A420; Fri, 20 Jan 2006 20:00:01 +0000 (GMT) (envelope-from nate@root.org) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id D655E43D68; Fri, 20 Jan 2006 19:59:59 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.0.53] (adsl-67-119-74-222.dsl.sntc01.pacbell.net [67.119.74.222]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id k0KJxeVK028564 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 20 Jan 2006 11:59:41 -0800 Message-ID: <43D14144.3050808@root.org> Date: Fri, 20 Jan 2006 12:00:04 -0800 From: Nate Lawson User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Marcus Alves Grando References: <20060120192131.4B0D916A44F@hub.freebsd.org> In-Reply-To: <20060120192131.4B0D916A44F@hub.freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-scsi@FreeBSD.org Subject: Re: cvs commit: src/sys/cam/scsi scsi_da.c X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2006 20:00:01 -0000 Marcus Alves Grando wrote: > mnag 2006-01-20 19:21:15 UTC > > FreeBSD src repository (ports committer) > > Modified files: (Branch: RELENG_6) > sys/cam/scsi scsi_da.c > Log: > MFC: src/sys/cam/scsi/scsi_da.c 1.184 > > Allow to use Time DPA20B 1GB MP3 Player [1] > Allow to use Qware BeatZkey! Pro [2] > > PR: usb/81846 [1], usb/79164 [2] > Submitted by: Ruben de Groot [1], Radek Kozlowski [2] > Approved by: njl (implict) > > Revision Changes Path > 1.180.2.3 +16 -0 src/sys/cam/scsi/scsi_da.c It looks like we have another quirk proliferation problem that should be solved at the architectural level. Does anyone have an idea if we can do something simpler than just disabling SYNC_CACHE completely? I have a theory that Windows only does SYNC_CACHE in the final close of a USB device. So a very simple implementation in the USB device firmware: switch (cmd) case SYNC_CACHE: write_nonvolatile(); while (1) ; The problem may be that we are calling SYNC_CACHE at a time before final close. If someone could test that a broken device works if we change this behavior, we could come up with an architectural fix. Perhaps, change umass to filter out SYNC_CACHE but send it at final device close. Although, since we don't have the device_eject() method currently, there may be no way to send it at final close. If this is the case, we should just make umass disable SYNC_CACHE for all devices. -- Nate