From owner-freebsd-scsi@FreeBSD.ORG Fri Feb 3 02:20:11 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 45DF016A420; Fri, 3 Feb 2006 02:20:11 +0000 (GMT) (envelope-from nate@root.org) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9C98C43D4C; Fri, 3 Feb 2006 02:20:10 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.0.53] (adsl-67-119-74-222.dsl.sntc01.pacbell.net [67.119.74.222]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id k132K4Er013529 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 2 Feb 2006 18:20:04 -0800 Message-ID: <43E2BDE0.1070709@root.org> Date: Thu, 02 Feb 2006 18:20:16 -0800 From: Nate Lawson User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Scott Long 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> In-Reply-To: <43E28272.30704@samsco.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-scsi@freebsd.org, "Kenneth D. Merry" , 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: Fri, 03 Feb 2006 02:20:11 -0000 Scott Long wrote: > Matthew Jacob wrote: >>>> >>>> And how will you distinguish between "not currently enabled" and >>>> "not supported"? >>>> >>> >>> If WCE is not supported, will the device lie and report the WCE bit as >>> set? >>> >> >> 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. I agree -- we should just do the MODE SENSE inline with the SYNC CACHE each time for starters. If it causes problems, then re-evaluate this approach. Can someone with a bad USB device run the appropriate camcontrol command to see if WCE is set or not? It would help to know if they lie because if so, this approach is not likely to succeed. -- Nate