Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 16 Nov 2011 15:08:54 -0800
From:      Maksim Yevmenkin <emax@freebsd.org>
To:        Alexander Motin <mav@freebsd.org>
Cc:        current@freebsd.org
Subject:   Re: [RFC] ahci(4) patch
Message-ID:  <CAFPOs6qAXYQzeD6yP0cuayp8VDuZky%2BZAGyux=5__A0EqSH1Dg@mail.gmail.com>
In-Reply-To: <4EC4404B.4070008@FreeBSD.org>
References:  <CAFPOs6rU6AKeTNzKhaqxktDb9CN=g-EDMLf2%2Bcyvhq772SymjA@mail.gmail.com> <4EC43ABA.7060407@FreeBSD.org> <CAFPOs6qyC%2B_8CrxyoCpXBOTTXbgo=vozLNSzHhsH4Hw=jgvERg@mail.gmail.com> <4EC4404B.4070008@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Nov 16, 2011 at 2:59 PM, Alexander Motin <mav@freebsd.org> wrote:
> On 17.11.2011 00:44, Maksim Yevmenkin wrote:
>>
>> On Wed, Nov 16, 2011 at 2:35 PM, Alexander Motin<mav@freebsd.org> =A0wro=
te:
>>>
>>> On 16.11.2011 23:59, Maksim Yevmenkin wrote:
>>>>
>>>> would anyone object to the following ahci(4) patch?
>>>>
>>>> =3D=3D
>>>>
>>>> --- ahci.c.orig 2011-11-16 21:35:26.000000000 +0000
>>>> +++ ahci.c =A0 =A0 =A02011-11-16 21:35:41.000000000 +0000
>>>> @@ -500,7 +500,7 @@
>>>> =A0 =A0 =A0 =A0for (unit =3D 0; unit< =A0 =A0ctlr->channels; unit++) {
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if ((ctlr->ichannels& =A0 =A0(1<< =A0 =
=A0unit)) =3D=3D 0)
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0continue;
>>>> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 child =3D device_add_child(dev, "ahcich"=
, -1);
>>>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 child =3D device_add_child(dev, "ahcich"=
, unit);
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (child =3D=3D NULL)
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0device_printf(dev, "fai=
led to add channel
>>>> device\n");
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0else
>>>>
>>>> =3D=3D
>>>>
>>>> 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 usef=
ul
>>> 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. Destroy=
ing
> 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 repor=
t
> unconnected ports and not impliemented.. You should just wire CAM buses t=
o
> 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=3D"umass-sim0"
hint.scbus.1.at=3D"ahcich0"
hint.scbus.2.at=3D"ahcich1"
hint.scbus.3.at=3D"ahcich2"
hint.scbus.4.at=3D"ahcich3"
hint.scbus.5.at=3D"ahcich4"
hint.scbus.6.at=3D"ahcich5"

hint.da.0.at=3D"scbus0"
hint.ada.0.at=3D"scbus1"
hint.ada.1.at=3D"scbus2"
hint.ada.2.at=3D"scbus3"
hint.ada.3.at=3D"scbus4"
hint.ada.4.at=3D"scbus5"
hint.ada.5.at=3D"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?

thanks,
max



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAFPOs6qAXYQzeD6yP0cuayp8VDuZky%2BZAGyux=5__A0EqSH1Dg>