From owner-freebsd-current@FreeBSD.ORG Mon Jan 5 09:18:54 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 344ED16A4D1 for ; Mon, 5 Jan 2004 09:18:54 -0800 (PST) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5E5CA43D41 for ; Mon, 5 Jan 2004 09:18:52 -0800 (PST) (envelope-from bde@zeta.org.au) Received: from gamplex.bde.org (katana.zip.com.au [61.8.7.246]) by mailman.zeta.org.au (8.9.3p2/8.8.7) with ESMTP id EAA16099; Tue, 6 Jan 2004 04:18:42 +1100 Date: Tue, 6 Jan 2004 04:18:41 +1100 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org In-Reply-To: <20040106030133.U6241@gamplex.bde.org> Message-ID: <20040106041140.A6673@gamplex.bde.org> References: <200401050914.i059EYfW036079@spider.deepcore.dk> <20040106030133.U6241@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Divacky Roman cc: current@freebsd.org Subject: Re: slow probe for ata channel with only an atapi master on it X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2004 17:18:54 -0000 [Private reply] [I wrote] > The other drive is undead. It seems to fail to spin up sometimes, but > works perfectly if its probe succeeds and I start accessing it immediately, > but tends to fail if I don't access it for a while. It now always fails > overnight. I'm wondering if it spins down and then the spin up doesn't > work, and plan to try putting it in sleep modes intentionally. The I tried your "atacontrol sleep" command. It broke the drive in much the same way as not using it overnight, except the BIOS was able to wake it up correctly :-). "atacontrol standby" doesn't break it. > driver handles its failure poorly. The failure is usually hard (takes > several power cycles to recover from), to it gets "removed from > configuration" after several seconds or minutes of the system being > unusable because it is blocked on Giant. Then removal usually causes > a null pointer panic. "atacontrol detach" also puts the drive too sleep, and it works much better than shooting an active drive. It also works to help wake up the drive: the drive works right after "atacontrol sleep; atacontrol detach; atacontrol attach", except it takes about 5 seconds to wake up after the first i/o command (attach apparently doesn't wake it up). Bruce