Date: Thu, 2 Feb 2006 10:02:22 -0800 (PST) From: Matthew Jacob <mj@feral.com> To: "Kenneth D. Merry" <ken@freebsd.org> Cc: freebsd-scsi@freebsd.org, Florent Thoumie <flz@xbsd.org>, Matthew Jacob <mj@feral.com>, Nate Lawson <nate@root.org> Subject: Re: cvs commit: src/sys/cam/scsi scsi_da.c src/sys/dev/usb umass.c usbdevs Message-ID: <20060202095828.D97756@ns1.feral.com> In-Reply-To: <20060202175041.GA92109@nargothrond.kdm.org> References: <20060130202806.DCC7916A4CA@hub.freebsd.org> <43DEF43A.6090804@root.org> <20060130213338.H79194@ns1.feral.com> <200601311239.10248.flz@xbsd.org> <43E06B06.80405@root.org> <20060202175041.GA92109@nargothrond.kdm.org>
next in thread | previous in thread | raw e-mail | index | archive | help
>> I think the tape driver (sa) does MODE SENSE as part of normal operation
>> but da does not. (Working frm memory here).
>
> It seems like a reasonable idea to check the WCE bit before sending a sync
> cache command. In theory it shouldn't cause any more breakage than sync
> cache itself. The generic CAM probe code already sends a mode sense (for
> the control mode page) to detect whether the DQue bit is set.
>
> The way to implement it in the da(4) driver would be as another probe state
> in addition to the two read capacity states. One difference is that things
> shouldn't blow up if the mode sense fails. (In that case, we should
> probably disable sync cache.)
>
> One case this won't cover, though, is when the user changes the WCE bit
> after we probe. That's obviously not a very common case, but the only way
> to mostly cover it would be to do a mode sense just prior to every sync
> cache command. (We could set a bit, though, if that mode page isn't
> supported so that we don't constantly ask for a mode page that isn't
> supported.)
>
> We're also assuming that the device firmware is telling the truth about
> whether the write cache is enabled or disabled. (Hopefully so, but you
> never know.)
Changing the WCE bit is actually pretty common. I do it all the time
myself. Furthermore, a common scenario is the Windows enables WCE and
then uses FUA for synchronization.
I've missed something here- other than broken devices that die
spectacularly when the get one, why don't you just infer from a failed
SYNCHRONIZE CACHE (e.g., "Illegal Request") that the device doesn't
support it and stop doing it?
For example, the EMC/Clariion AX100 reports Illegal Request on
this command. You can't use quirks to identify this device because all
Clariions have essentially the same Vendor/Product ID ("DGC", "RAID5").
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060202095828.D97756>