From owner-freebsd-stable@FreeBSD.ORG Tue Feb 23 19:27:26 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 54AD6106566C for ; Tue, 23 Feb 2010 19:27:26 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-fx0-f223.google.com (mail-fx0-f223.google.com [209.85.220.223]) by mx1.freebsd.org (Postfix) with ESMTP id D17B08FC0C for ; Tue, 23 Feb 2010 19:27:25 +0000 (UTC) Received: by fxm23 with SMTP id 23so143357fxm.3 for ; Tue, 23 Feb 2010 11:27:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=4GSZHlFvtX10mZULhBDOXI2mS7FsG45+A4um08qn5Og=; b=EmCUZnskG4khGiZjaVUWzSMvMY6kQD2GeoUCxR5Lt6lcIy+REsPIAk6dMycOXhiBfv 2r8B87UeOVtDD76opFq4VfYcYU5CF8306BrXmrjCvqswpSa4h1UUedkrsMjwIOZzkwjz KJutfS4kcTyEqfwBAqIyCqwqHk2xijxJUpgvc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=tPI0C1CI0hF3uNMhiXPXt4Rr4oIf7RVWAQ8rtN7eS/jXHdZDcTZfie5eT5wr/QMY3+ VZA2cRfuBxYpUelpGKH0vx41NiO/eXnh1Uvi6caYq94+o3SyMrmHTfkkycqmL6dkEM/C WVjbzUtmNjT8PWF8MMdKFPrAThl0xJJwG6dVg= Received: by 10.223.100.129 with SMTP id y1mr9171332fan.15.1266953239241; Tue, 23 Feb 2010 11:27:19 -0800 (PST) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id 16sm2712007fxm.15.2010.02.23.11.27.18 (version=SSLv3 cipher=RC4-MD5); Tue, 23 Feb 2010 11:27:18 -0800 (PST) Sender: Alexander Motin Message-ID: <4B842C14.4030306@FreeBSD.org> Date: Tue, 23 Feb 2010 21:27:16 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Harald Schmalzbauer References: <1266934981.00222684.1266922202@10.7.7.3> <4B83EFD4.8050403@FreeBSD.org> <4B83FD62.2020407@omnilan.de> <4B83FFEF.7010509@FreeBSD.org> <4B840C54.3010304@omnilan.de> <4B8411EE.5030909@FreeBSD.org> <4B841409.5070603@omnilan.de> <4B841B19.3020106@FreeBSD.org> <4B842830.7030004@omnilan.de> In-Reply-To: <4B842830.7030004@omnilan.de> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@FreeBSD.org Subject: Re: ahcich timeouts, only with ahci, not with ataahci X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2010 19:27:26 -0000 Harald Schmalzbauer wrote: > Am 23.02.2010 19:14, schrieb Alexander Motin: >>> I'll restore the default vfs.zfs.txg.timeout=30, so the hang can be >>> easily reproduced and see if I can 'camcontrol stop' the drive. Do you >>> think I can get usefull information with that test? >> Stop won't work for ATA devices. It is SCSI command. And all it does - >> stops spindle. It won't destroy device. AFAIK there is no method in CAM >> now to manually disable some device on-flight. If some device half-died, >> the best way is to mechanically disconnect it. It will help CAM to >> recover as fast as possible. > > Thank you very much again. I wasn't aware of that. I thought 'camcontrol > stop' is similar to 'atacontrol detach'. > It's important for me te be able to manage my systems rmotely, so I need > to stay with the old ataahci driver. The detach feature has been > life-saver several times for me, especially with IDE disks. I often had > drives going nuts and detach/attach with gmirror/graid3 rebuild always > solved the problem. I expect to see also SATA drive oddities (maybe like > now) when they replace the old ide servers. gmirror and graid3 allow you to remove failed component from array, add new or resync without detaching devices from the system. I don't see problem there, sufficient to migrate back. > One last quick question: I read about a new feature adopting old ata to > cam. Do you have a link to useful information? Or will a mailman search > list all useful info. It's really simple. Add `options ATA_CAM` to the kernel and you are there. Everything the same as with loading ahci(4) (adX -> adaX, acdX -> cdX, ...), just without NCQ. Then you could remove all ata(4) peripheral device drivers from the kernel, as they become useless. atacontrol is also deprecated in this mode. -- Alexander Motin