triosoft_at_triosoft.com.ua wrote: > I found some odd behavior of ata device numbering. It seems, that there > is no effect of option ATA_STATIC_ID in CURRENT. > What I have: > supermicro server with 4 sata ports onto Intel ICH7 SATA300 controller > recent CURRENT > sata mode in BIOS is Enhanced > ahci support in BIOS in Enabled > option ATA_STATIC_ID in KERNCONF > > So, if I boot with 4 HDD connected to sata i found ad4,ad6,ad8,ad10 as > disks. but when I detach disk, which "was" ad8 in last case, and then > reboot - I see ad4,ad6,ad8! and not ad4,ad6,ad10! atacontrol list > doesn't show an empty ata channel. Only channels with HDDs connected. I > check 6.x 7.x on the same server with _the same configuration in bios_ - > and all works as suspected - there are empty ata channels, there are > really static device numbers. when I set AHCI to Disabled I have just > two ata channels (with AHCI - I have four, one for each sata disk) and > with or without HDDs connected I see empty channels and have really > static dev nums in the same CURRENT. > So my question is - is it my fault? does I miss something? Or it is a bug? > > Yes ;) I know about glabel, but my setup is complicated enough without > them ( gpart-ed disks with zfs-only setup) so I do not want to make it > more complicated. > And with such behavior I cannot add disks on the fly, if there is > no empty ata channels. This looks like odd behavior of Supermicro BIOS. It marks unconnected ports as unimplemented. I have also noticed such behavior on one of my Supermicro servers. It is not difficult to change ahci driver logic now, but I just not sure yet how we should better handle this situation. AHCI specification uses that register for reporting ports not implemented in hardware, not for unused. As quick hack, you can try to replace in ata-ahci.c line ctlr->ichannels = ATA_INL(ctlr->r_res2, ATA_AHCI_PI); with ctlr->ichannels = 0xFFFFFFFF; to just ignore what BIOS thinks about implemented ports. -- Alexander MotinReceived on Thu May 28 2009 - 16:34:21 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:48 UTC