From owner-freebsd-scsi@FreeBSD.ORG Tue Feb 28 16:26:57 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 9162116A420; Tue, 28 Feb 2006 16:26:57 +0000 (GMT) (envelope-from ticso@cicely12.cicely.de) Received: from ant.bwct.de (ant.bwct.de [85.159.14.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id C9E6943D46; Tue, 28 Feb 2006 16:26:56 +0000 (GMT) (envelope-from ticso@cicely12.cicely.de) Received: from cicely5.cicely.de ([10.1.1.7]) by ant.bwct.de (8.12.11/8.12.11) with ESMTP id k1SGQsJX006110; Tue, 28 Feb 2006 17:26:54 +0100 (CET) Received: from cicely12.cicely.de (cicely12.cicely.de [10.1.1.14]) by cicely5.cicely.de (8.13.4/8.13.4) with ESMTP id k1SGQmU9046310 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Feb 2006 17:26:49 +0100 (CET) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (localhost [127.0.0.1]) by cicely12.cicely.de (8.13.4/8.13.3) with ESMTP id k1SGQm07071202; Tue, 28 Feb 2006 17:26:48 +0100 (CET) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.13.4/8.13.3/Submit) id k1SGQmUB071201; Tue, 28 Feb 2006 17:26:48 +0100 (CET) (envelope-from ticso) Date: Tue, 28 Feb 2006 17:26:47 +0100 From: Bernd Walter To: "Kenneth D. Merry" Message-ID: <20060228162647.GZ64548@cicely12.cicely.de> References: <20060227201644.GR64548@cicely12.cicely.de> <20060227202254.GA1016@nargothrond.kdm.org> <20060227204326.GS64548@cicely12.cicely.de> <20060228161004.GA9002@nargothrond.kdm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060228161004.GA9002@nargothrond.kdm.org> X-Operating-System: FreeBSD cicely12.cicely.de 5.4-STABLE alpha User-Agent: Mutt/1.5.9i X-Spam-Status: No, score=-5.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.4 X-Spam-Report: * -3.3 ALL_TRUSTED Did not pass through any untrusted hosts * -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% * [score: 0.0000] X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on cicely12.cicely.de Cc: Bernd Walter , freebsd-scsi@freebsd.org, ticso@cicely.de Subject: Re: Automatic unit start broken? X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2006 16:26:57 -0000 On Tue, Feb 28, 2006 at 09:10:04AM -0700, Kenneth D. Merry wrote: > On Mon, Feb 27, 2006 at 21:43:27 +0100, Bernd Walter wrote: > > On Mon, Feb 27, 2006 at 01:22:54PM -0700, Kenneth D. Merry wrote: > > > On Mon, Feb 27, 2006 at 21:16:45 +0100, Bernd Walter wrote: > > > What error code do your disks return? You will probably see some console > > > output if GEOM has tried to read metadata off the disk and that initial > > > read fails. > > > > > > If the drive returns 0x04,0x02 ("Logical unit not ready, initializing cmd. > > > required"), CAM will attempt to spin the disk up automatically and retry > > > the command. > > > > During the first tests I waited 90s in loader to let all delayed spin > > up drives spin up. > > This is with recent RELENG_6 and a drive which don't spin up themself: > > [...] > > da7 at esp1 bus 0 target 10 lun 0 > > da7: Fixed Direct Access SCSI-3 device > > da7: 20.000MB/s transfers (10.000MHz, offset 15, 16bit), Tagged Queueing Enabled > > da7: Attempt to query device size failed: NOT READY, Logical unit not ready, initial > > That's rather odd, since it looks like you've got an 0x04,0x02 response, > but the device must have rejected the start unit command if we failed to > get capacity information. At least the drive won't fail a start unit when done via camcontrol. > > [...] > > No GEOM message about this driver until rc sends a start command and > > GEOM is retriggered to reread the drive: > > Unit started successfully > > GEOM_LABEL: Label for provider da7 is ufs/dump1. > > The following commands were used in rc: > > camcontrol start -n da -u 7 > > cat /dev/null > /dev/da7 > > > > Without the loader delay other disks are having problems as well: > > da9 at esp1 bus 0 target 14 lun 0 > > da9: Fixed Direct Access SCSI-3 device > > da9: 20.000MB/s transfers (10.000MHz, offset 15, 16bit), Tagged Queueing Enabled > > da9: Attempt to query device size failed: NOT READY, Logical unit is in process of b > > > > That's a different error. We won't send a start unit in that case. The > error recovery action for 0x04,0x01 is to send a test unit ready every half > second for a minute until the device becomes ready. > Evidently it didn't become ready after that period of time. Possible that this works, but a minute is hardly enough for a drive with ID 14 - considered 6s per ID this means the given drive requires 84s after power-up. But I doubt that the kernel waits - I should have noticed waiting a whole minute. Where is the minute defined? If it is not solved by raising the wait to 120s it likely won't work. > > On Shell: > > [30]cicely19# dd if=/dev/da7 bs=1k count=1 of=/dev/null > > 1+0 records in > > 1+0 records out > > 1024 bytes transferred in 0.008765 secs (116829 bytes/sec) > > [31]cicely19# camcontrol stop -n da -u 7 > > Unit stopped successfully > > [32]cicely19# dd if=/dev/da7 bs=1k count=1 of=/dev/null > > dd: /dev/da7: Input/output error > > 0+0 records in > > 0+0 records out > > 0 bytes transferred in 0.004810 secs (0 bytes/sec) > > Exit 1 > > What errors do you see on the console at that point? In order for CAM to > automatically spin up the disk, it needs to send back 0x04,0x02 when it is > spun down, and it needs to actually spin up the disk in response to a start > unit. I don't see anything on console. > What happens when you: > > camcontrol stop da7 > camcontrol tur da7 -v > camcontrol start da7 -v [52]raven# camcontrol stop da7 Unit stopped successfully [53]raven# camcontrol tur da7 -v Unit is not ready (pass8:esp1:0:10:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 (pass8:esp1:0:10:0): CAM Status: CCB request is in progress Exit 1 [54]raven# camcontrol start da7 -v Unit started successfully -- B.Walter BWCT http://www.bwct.de bernd@bwct.de info@bwct.de