From owner-freebsd-current@FreeBSD.ORG Thu Nov 17 16:09:18 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 E2110106567E; Thu, 17 Nov 2011 16:09:18 +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 44B468FC1F; Thu, 17 Nov 2011 16:09:12 +0000 (UTC) Received: by bkbzs8 with SMTP id zs8so2966922bkb.13 for ; Thu, 17 Nov 2011 08:09:11 -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=WWMKWCCGaJmqJGB+ybwJuftI650Ir/+ihyrbRY1zI9s=; b=qd2u9mG5oy0vXz3hubO1hlJAWClZ5pXypUwzyC2vJJCweR3FCaUiMR1tYrF1BPHY0c gvhS0NqstC72J63pQ/35oO0w9tRKkqhnI/GpG0WqgdUrHl2kF/aRxVV72zAm1dSPkMGJ O+Vh4cRzYeL43r0i+GLIe9Q1wcVfzxLZu/V/g= Received: by 10.204.156.218 with SMTP id y26mr26223733bkw.103.1321546151121; Thu, 17 Nov 2011 08:09:11 -0800 (PST) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua. [212.86.226.226]) by mx.google.com with ESMTPS id i3sm2491894faf.0.2011.11.17.08.09.09 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 17 Nov 2011 08:09:10 -0800 (PST) Sender: Alexander Motin Message-ID: <4EC531A4.4000803@FreeBSD.org> Date: Thu, 17 Nov 2011 18:09:08 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111003 Thunderbird/7.0.1 MIME-Version: 1.0 To: Maksim Yevmenkin References: <4EC43ABA.7060407@FreeBSD.org> <4EC4404B.4070008@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 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: Thu, 17 Nov 2011 16:09:19 -0000 On 11/17/11 01:08, Maksim Yevmenkin wrote: > On Wed, Nov 16, 2011 at 2:59 PM, Alexander Motin wrote: >> 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. > > ok. then i must be missing something, here is what i have in device.hints > > hint.scbus.0.at="umass-sim0" > hint.scbus.1.at="ahcich0" > hint.scbus.2.at="ahcich1" > hint.scbus.3.at="ahcich2" > hint.scbus.4.at="ahcich3" > hint.scbus.5.at="ahcich4" > hint.scbus.6.at="ahcich5" > > hint.da.0.at="scbus0" > hint.ada.0.at="scbus1" > hint.ada.1.at="scbus2" > hint.ada.2.at="scbus3" > hint.ada.3.at="scbus4" > hint.ada.4.at="scbus5" > hint.ada.5.at="scbus6" > > this is for 6-port ahci(4) compatible controller (intel) on the > motherboard. no matter which achi(4) ports are connected, resulted > adaX devices are always sequential starting from ada0. so, the > question is: what am i doing wrong here? Just put your lines into my loader.conf and got this: %camcontrol devlist -v scbus1 on ahcich0 bus 0: at scbus1 target 0 lun 0 (pass0,ada0) <> at scbus1 target -1 lun -1 () scbus2 on ahcich1 bus 0: <> at scbus2 target -1 lun -1 () scbus3 on ahcich2 bus 0: at scbus3 target 0 lun 0 (pass1,ada2) <> at scbus3 target -1 lun -1 () scbus4 on ahcich3 bus 0: <> at scbus4 target -1 lun -1 () scbus5 on ahcich4 bus 0: <> at scbus5 target -1 lun -1 () scbus6 on ahcich5 bus 0: <> at scbus6 target -1 lun -1 () ... I see no problem. What am I doing wrong? Let me repeat question not asked directly: Does your BIOS reports unused AHCI channels as implemented? Do you always have all 6 ahcich devices or not? -- Alexander Motin