Date: Thu, 2 Feb 2006 10:50:41 -0700 From: "Kenneth D. Merry" <ken@freebsd.org> To: Nate Lawson <nate@root.org> Cc: freebsd-scsi@freebsd.org, Matthew Jacob <mj@feral.com>, Florent Thoumie <flz@xbsd.org> Subject: Re: cvs commit: src/sys/cam/scsi scsi_da.c src/sys/dev/usb umass.c usbdevs Message-ID: <20060202175041.GA92109@nargothrond.kdm.org> In-Reply-To: <43E06B06.80405@root.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>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Feb 01, 2006 at 00:02:14 -0800, Nate Lawson wrote:
> Florent Thoumie wrote:
> >On Tuesday 31 January 2006 06:33, Matthew Jacob wrote:
> >
> >>>>Linux only sends the SYNCHRONIZE_CACHE command if the WCE (Write Cache
> >>>>Enable) bit of the disk is set. I can't seem to find something
> >>>>equivalent to this in our CAM framework. I have no particular SCSI
> >>>>knowledge but I guess I can have a look at this tomorrow.
> >>>>
> >>>>I'm forwarding this to freebsd-scsi@ (keep me CC'ed, as I'm not
> >>>>subscribed to this list, yet).
> >>>
> >>>Hmm, is WCE part of the inquiry response? [moving to scsi@ list]
> >>
> >>Yes.
> >
> >
> >Hum, reading Linux source and SCSI standard [1], I'm not so sure, but I
> >might be wrong. We need to request the caching page in
> >scsi_mode_sense_{6,10}.
> >
> >I'll try to write something today, but I guess someone having already
> >worked on scsi will only need 10 minutes to DTRT.
> >
> >[1] http://www.danbbs.dk/~dino/SCSI/SCSI2-09.html (table 156)
> >
>
> You might also want to check if we or Linux set the Immediate bit as
> part of the SYNCHRONIZE CACHE command. It's possible that USB devices
> don't properly parse that bit.
>
> 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.)
Ken
--
Kenneth Merry
ken@FreeBSD.ORG
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060202175041.GA92109>