From owner-freebsd-scsi@FreeBSD.ORG Wed May 26 18:21:11 2010 Return-Path: Delivered-To: freebsd-scsi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 01360106566B; Wed, 26 May 2010 18:21:11 +0000 (UTC) (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 CF43A8FC16; Wed, 26 May 2010 18:21:10 +0000 (UTC) Received: from [192.168.0.102] (m206-63.dsl.tsoft.com [198.144.206.63]) by ns1.feral.com (8.14.3/8.14.3) with ESMTP id o4QILArj026862; Wed, 26 May 2010 11:21:10 -0700 (PDT) (envelope-from mj@feral.com) Message-ID: <4BFD6698.9040100@feral.com> Date: Wed, 26 May 2010 11:21:12 -0700 From: Matthew Jacob User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Alexander Motin References: <4BFB3985.1030301@FreeBSD.org> <4BFC1C57.4080703@FreeBSD.org> In-Reply-To: <4BFC1C57.4080703@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Default is to whitelist mail, not delayed by milter-greylist-4.2.3 (ns1.feral.com [192.67.166.1]); Wed, 26 May 2010 11:21:10 -0700 (PDT) Cc: freebsd-scsi@FreeBSD.org Subject: Re: patches for CAM SCSI probing, etc. 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: Wed, 26 May 2010 18:21:11 -0000 Okay, I see your point. I would assert that for SCSI there should only be one probe active at any time for any given nexus *or* I should adopt your approach and restart the state machine if additional commands show up. It's also true that scans ought to be limited from user space. There's nothing to stop one from running 1000 camcontrol rescans from user space, and that effectively hangs the system as it's spending all of its time running stuff for them, so I might put a bit of serialization in here. Thoughts? > Matthew Jacob wrote: > >> Part of the reason I went the way you had done for ATA is to try and >> guarantee one and one only probe action at a time per nexus. >> > But in ATA I am restarting probe from the begining when new request > arrive. Look on "softc->restart". > > >>> you are slightly changing semantics of device probe. Previously, probe >>> call means warranty that device will be probed from the beginning after >>> the moment of request. It is very important for ATA, as probe function >>> also initializes device, that is mandatory if probe is called as result >>> of device reset. SCSI devices probably don't need that initialization, >>> but what if probe was called due to inquiry change status received >>> during probe sequence running? Are you sure you won't loose events here? >>> >