From owner-freebsd-scsi@FreeBSD.ORG Thu Feb 2 17:50:47 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 DC73916A420 for ; Thu, 2 Feb 2006 17:50:47 +0000 (GMT) (envelope-from ken@nargothrond.kdm.org) Received: from nargothrond.kdm.org (nargothrond.kdm.org [70.56.43.81]) by mx1.FreeBSD.org (Postfix) with ESMTP id 08FCE43D49 for ; Thu, 2 Feb 2006 17:50:46 +0000 (GMT) (envelope-from ken@nargothrond.kdm.org) Received: from nargothrond.kdm.org (localhost [127.0.0.1]) by nargothrond.kdm.org (8.13.4/8.12.11) with ESMTP id k12HogeM092343; Thu, 2 Feb 2006 10:50:42 -0700 (MST) (envelope-from ken@nargothrond.kdm.org) Received: (from ken@localhost) by nargothrond.kdm.org (8.13.4/8.12.5/Submit) id k12HofeC092342; Thu, 2 Feb 2006 10:50:41 -0700 (MST) (envelope-from ken) Date: Thu, 2 Feb 2006 10:50:41 -0700 From: "Kenneth D. Merry" To: Nate Lawson Message-ID: <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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43E06B06.80405@root.org> User-Agent: Mutt/1.4.2i X-Virus-Scanned: ClamAV 0.87.1/1270/Thu Feb 2 05:47:37 2006 on nargothrond.kdm.org X-Virus-Status: Clean Cc: freebsd-scsi@freebsd.org, Matthew Jacob , Florent Thoumie Subject: Re: cvs commit: src/sys/cam/scsi scsi_da.c src/sys/dev/usb umass.c usbdevs 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: Thu, 02 Feb 2006 17:50:48 -0000 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