From owner-freebsd-scsi@FreeBSD.ORG Thu Feb 2 22:13:07 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 B6FAB16A420; Thu, 2 Feb 2006 22:13:07 +0000 (GMT) (envelope-from mj@feral.com) Received: from ns1.feral.com (ns1.feral.com [192.67.166.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2D54043D48; Thu, 2 Feb 2006 22:13:05 +0000 (GMT) (envelope-from mj@feral.com) Received: from ns1.feral.com (localhost [127.0.0.1]) by ns1.feral.com (8.13.4/8.13.4) with ESMTP id k12MD4DG099572; Thu, 2 Feb 2006 14:13:04 -0800 (PST) (envelope-from mj@feral.com) Received: from localhost (mjacob@localhost) by ns1.feral.com (8.13.4/8.13.4/Submit) with ESMTP id k12MD20Z099569; Thu, 2 Feb 2006 14:13:04 -0800 (PST) (envelope-from mj@feral.com) X-Authentication-Warning: ns1.feral.com: mjacob owned process doing -bs Date: Thu, 2 Feb 2006 14:13:02 -0800 (PST) From: Matthew Jacob X-X-Sender: mjacob@ns1.feral.com To: Scott Long In-Reply-To: <43E28272.30704@samsco.org> Message-ID: <20060202140733.J99168@ns1.feral.com> 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> <20060202095828.D97756@ns1.feral.com> <43E252EC.1050803@root.org> <43E25C4D.9020804@samsco.org> <43E2650D.1060109@root.org> <20060202130620.A99168@ns1.feral.com> <43E27E58.4020606@samsco.org> <20060202135123.K99168@ns1.feral.com> <43E28272.30704@samsco.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-scsi@freebsd.org, "Kenneth D. Merry" , Florent Thoumie , Matthew Jacob , Nate Lawson 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 Reply-To: Matthew Jacob List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2006 22:13:07 -0000 >> >> No. But a device could have it turned off and you wouldn't then infer that >> you *could*. > > I guess I don't follow. There was a suggestion to read page 8 during > the da device probe, cache the WCE value, and act on it accordingly > later on. There was also a suggestion to read the page on demand as > part of the immediate decision to do the SYNC CACHE. As much of a > hassle as it could be, the latter is likely the better approach as it > eliminates the messy state tracking that you'd have to do on the user. > Who wants to hack up the pass driver to trap mode page writes and then > try to correlate which da device to pass that info on to? And yeah, > if the device is able to change the state on its own, there is no way > the first approach can work. > Okay- I was a bit fatigued (up until 2AM last night worrying over core emails) The WCE bit from page 8 is either the current state, the persistent state, or whether you can change that bit (the PCF fields). All you can infer from this bit is whether WCE is currently enabled, or whether the default is for it to be enabled or not. You cannot infer whether the device correctly supports it or not. You could infer from the CHANGEABLE version as to whether you can change the state. I guess what is being suggested by inference here is that if the WCE bit is off at attach time, we don't issue a SYNC CACHE. If you want your drive to be cacheable, you run camcontrol on it (saving the page) and reboot. I suppose this isn't so bad, because you could then also begin to think about using FUA as well. -matt