From owner-freebsd-current@FreeBSD.ORG Wed Nov 16 22:59:26 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 29865106564A; Wed, 16 Nov 2011 22:59:26 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 6ECCC8FC14; Wed, 16 Nov 2011 22:59:25 +0000 (UTC) Received: by bkbzs8 with SMTP id zs8so1634515bkb.13 for ; Wed, 16 Nov 2011 14:59:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=FAepnCfv8uznzNllpsBrrklCJnYVgNxyPPdrOnTvguI=; b=x9yb21lUeYYhl50KCvsUN7azK+A39QfXe6II4OvoGr2umdopSMZ55DKsvG5eVvx9hx 0WU1wNK2y+xJq2WBevZ4l8ahMh6+GlrA8WrNe3v6U0STnm4DJaga2QGECyR76ZgcP3JU bWbPXf3Qi6qTI8nzKcrBqsFhmQ9XVITWc95G8= Received: by 10.205.128.138 with SMTP id he10mr30851198bkc.13.1321484364079; Wed, 16 Nov 2011 14:59:24 -0800 (PST) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua. [212.86.226.226]) by mx.google.com with ESMTPS id e20sm142135fab.2.2011.11.16.14.59.22 (version=SSLv3 cipher=OTHER); Wed, 16 Nov 2011 14:59:23 -0800 (PST) Sender: Alexander Motin Message-ID: <4EC4404B.4070008@FreeBSD.org> Date: Thu, 17 Nov 2011 00:59:23 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111112 Thunderbird/8.0 MIME-Version: 1.0 To: Maksim Yevmenkin References: <4EC43ABA.7060407@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: [RFC] ahci(4) patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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: Wed, 16 Nov 2011 22:59:26 -0000 On 17.11.2011 00:44, Maksim Yevmenkin wrote: > On Wed, Nov 16, 2011 at 2:35 PM, Alexander Motin wrote: >> On 16.11.2011 23:59, Maksim Yevmenkin wrote: >>> >>> would anyone object to the following ahci(4) patch? >>> >>> == >>> >>> --- ahci.c.orig 2011-11-16 21:35:26.000000000 +0000 >>> +++ ahci.c 2011-11-16 21:35:41.000000000 +0000 >>> @@ -500,7 +500,7 @@ >>> for (unit = 0; unit< ctlr->channels; unit++) { >>> if ((ctlr->ichannels& (1<< unit)) == 0) >>> continue; >>> - child = device_add_child(dev, "ahcich", -1); >>> + child = device_add_child(dev, "ahcich", unit); >>> if (child == NULL) >>> device_printf(dev, "failed to add channel >>> device\n"); >>> else >>> >>> == >>> >>> the idea is to have "static" numbering for ada(4) disks. >> >> I do. The only way I see this useful is if you have BIOS configured for >> non-hot-swappable disks, in which case you have some AHCI channels disabled, >> but want to keep numbers of the rest. While I don't like this mode in >> general, especially when it can't be disabled, that patch could be useful in >> these cases. But in other cases, when you have several AHCI controllers, it >> just wont not work. You will receive error on attempt to create second >> ahcich0. > > shouldn't achcichX be destroyed when disk is detached/removed/etc.? List of implemented AHCI channels to expose as ahcichX set by BIOS in vendor-specific way, but only during boot and not by many BIOSes. Destroying them on disk detach theoretically possible, but IMHO not right, as bus doesn't disappear on disk disconnect. > the particular problem i'm trying to address is disk re-numbering when > one of the disks fails/removed/etc. i'm trying to use hints to wire > disks to controllers/busses. it works perfectly fine with da(4) disks > (even hot swappable ones) , but i can not make it to work with ada(4) > disks. i'm perfectly fine to hid this under some sort of option > (something similar to ATA_STATIC_ID, AHCI_STATIC_ID for example) Wiring works for adaX also, unless your BIOS is so "intelligent" to report unconnected ports and not impliemented.. You should just wire CAM buses to ahcichX, not to ahciX. It could be done in other way changing just by one line around xpt_bus_register(), but now it is done so. -- Alexander Motin