[RFC] ahci(4) patch
Alexander Motin
mav at FreeBSD.org
Thu Nov 17 16:09:19 UTC 2011
On 11/17/11 01:08, Maksim Yevmenkin wrote:
> On Wed, Nov 16, 2011 at 2:59 PM, Alexander Motin <mav at freebsd.org> wrote:
>> On 17.11.2011 00:44, Maksim Yevmenkin wrote:
>>>
>>> On Wed, Nov 16, 2011 at 2:35 PM, Alexander Motin<mav at freebsd.org> 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:
<INTEL SSDSA2M080G2GC 2CV102M3> 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:
<INTEL SSDSA2M080G2GC 2CV102M3> 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
More information about the freebsd-current
mailing list