Date: Fri, 20 Jan 2006 12:00:04 -0800 From: Nate Lawson <nate@root.org> To: Marcus Alves Grando <mnag@FreeBSD.org> Cc: freebsd-scsi@FreeBSD.org Subject: Re: cvs commit: src/sys/cam/scsi scsi_da.c Message-ID: <43D14144.3050808@root.org> In-Reply-To: <20060120192131.4B0D916A44F@hub.freebsd.org> References: <20060120192131.4B0D916A44F@hub.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <rdg@bzerk.org> [1], Radek Kozlowski <radek@raadradd.com> [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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?43D14144.3050808>