On Thu, Nov 17, 2011 at 8:09 AM, Alexander Motin <mav_at_freebsd.org> wrote: > 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 >>>>>> _at__at_ -500,7 +500,7 _at__at_ >>>>>> 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? i not exactly sure. below is the relevant dmesg. as far as i can tell, channels are correct, however, ahcich numbering is sequential and that is why hints dont work. Nov 16 11:18:00 PREPROD-red1 kernel: ahci0: <Intel Cougar Point AHCI SATA controller> port 0xf070-0xf077,0xf060-0xf063,0xf050-0xf057,0xf040-0xf043,0xf000-0xf01f mem 0xfbb21000-0xfbb217ff irq 19 at device 31.2 on pci0 Nov 16 11:18:00 PREPROD-red1 kernel: ahci0: AHCI v1.30 with 6 6Gbps ports, Port Multiplier not supported Nov 16 11:18:00 PREPROD-red1 kernel: ahcich0: <AHCI channel> at channel 0 on ahci0 Nov 16 11:18:00 PREPROD-red1 kernel: ada0 at ahcich0 bus 0 scbus1 target 0 lun 0 Nov 17 09:22:51 PREPROD-red1 kernel: ahci0: <Intel Cougar Point AHCI SATA controller> port 0xf070-0xf077,0xf060-0xf063,0xf050-0xf057,0xf040-0xf043,0xf000-0xf01f mem 0xfbb21000-0xfbb217ff irq 19 at device 31.2 on pci0 Nov 17 09:22:51 PREPROD-red1 kernel: ahci0: attempting to allocate 1 MSI vectors (1 supported) Nov 17 09:22:51 PREPROD-red1 kernel: ahci0: using IRQ 270 for MSI Nov 17 09:22:51 PREPROD-red1 kernel: ahci0: AHCI v1.30 with 6 6Gbps ports, Port Multiplier not supported Nov 17 09:22:51 PREPROD-red1 kernel: ahci0: Caps: 64bit NCQ SNTF AL CLO 6Gbps PMD SSC PSC 32cmd EM 6ports Nov 17 09:22:51 PREPROD-red1 kernel: ahci0: Caps2: APST Nov 17 09:22:51 PREPROD-red1 kernel: ahci0: EM Caps: ALHD XMT SMB LED Nov 17 09:22:51 PREPROD-red1 kernel: ahcich0: <AHCI channel> at channel 0 on ahci0 Nov 17 09:22:51 PREPROD-red1 kernel: ahcich0: Caps: Nov 17 09:22:51 PREPROD-red1 kernel: ahcich1: <AHCI channel> at channel 2 on ahci0 Nov 17 09:22:51 PREPROD-red1 kernel: ahcich1: Caps: Nov 17 09:22:51 PREPROD-red1 kernel: ahcich2: <AHCI channel> at channel 5 on ahci0 Nov 17 09:22:51 PREPROD-red1 kernel: ahcich2: Caps: Nov 17 09:22:51 PREPROD-red1 kernel: ahcich0: AHCI reset... Nov 17 09:22:51 PREPROD-red1 kernel: ahcich0: SATA connect time=100us status=00000133 Nov 17 09:22:51 PREPROD-red1 kernel: ahcich0: AHCI reset: device found Nov 17 09:22:51 PREPROD-red1 kernel: ahcich0: AHCI reset: device ready after 0ms Nov 17 09:22:51 PREPROD-red1 kernel: (aprobe0:ahcich0:0:0:0): SIGNATURE: 0000 Nov 17 09:22:51 PREPROD-red1 kernel: ahcich1: AHCI reset... Nov 17 09:22:51 PREPROD-red1 kernel: ahcich1: SATA connect time=100us status=00000123 Nov 17 09:22:51 PREPROD-red1 kernel: ahcich1: AHCI reset: device found Nov 17 09:22:51 PREPROD-red1 kernel: ahcich1: AHCI reset: device ready after 0ms Nov 17 09:22:51 PREPROD-red1 kernel: (aprobe0:ahcich1:0:0:0): SIGNATURE: 0000 Nov 17 09:22:51 PREPROD-red1 kernel: ahcich2: AHCI reset... Nov 17 09:22:51 PREPROD-red1 kernel: ahcich2: SATA connect time=100us status=00000123 Nov 17 09:22:51 PREPROD-red1 kernel: ahcich2: AHCI reset: device found Nov 17 09:22:51 PREPROD-red1 kernel: ahcich2: AHCI reset: device ready after 0ms Nov 17 09:22:51 PREPROD-red1 kernel: (aprobe0:ahcich2:0:0:0): SIGNATURE: 0000 Nov 17 09:22:51 PREPROD-red1 kernel: ada0 at ahcich0 bus 0 scbus1 target 0 lun 0 Nov 17 09:22:51 PREPROD-red1 kernel: ada1 at ahcich1 bus 0 scbus2 target 0 lun 0 Nov 17 09:22:51 PREPROD-red1 kernel: ada2 at ahcich2 bus 0 scbus3 target 0 lun 0 Nov 17 09:22:51 PREPROD-red1 kernel: pass0 at ahcich0 bus 0 scbus1 target 0 lun 0 Nov 17 09:22:51 PREPROD-red1 kernel: pass1 at ahcich1 bus 0 scbus2 target 0 lun 0 Nov 17 09:22:51 PREPROD-red1 kernel: pass2 at ahcich2 bus 0 scbus3 target 0 lun 0 thanks, maxReceived on Thu Nov 17 2011 - 15:35:26 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:20 UTC