euh si, si… on en trouve… mais bon 400/500 euros la carte quoi !!!
je visais un modèle à moins de 50 euros en occasion moi huhuhu
AH… Effectivement. Là du coup, tu n’échappera ps à la compilation 
tu peux m’aiguiller un peu sur comment on fait cela ?
je viens de regarder le paquets fourni, il n’y a pas les sources, donc pas possible là non plus.
Tu peux toujours essayer d’installer le paquet deb de la Debian 8.1 pour voir, mais je ne vois pas d’autres solutions.
Je viens d’essayer d’installer le paquet sur une debian 1à que j’ai et l’installation du .deb via dpkg -i s’est bien passé, mais je n’ai aps de carte raid pour vérifier que ca marche.
bon c’est tjrs une info utile… je te remercie de ton temps, déjà !
de rien 
Deux raisons possibles : soit le fabricant s’est complètement désintéressé de ce modèle, soit le pilote a été inclus dans le noyau standard donc il n’est plus utile de fournir un pilote séparé.
Inutile, c’est tout vu. Tout ce que ce que le .deb pour Debian 8.1 contient, c’est un module aacraid.ko de version 1.2.1 pour le noyau 3.16.0-4 qui ne fonctionnera pas avec n’importe quelle autre version de noyau, y compris le dernier 3.16.0-11 de Jessie. A noter que ce noyau contient déjà un module aacraid de version 1.2.0 qui a exactement les mêmes alias PCI que le module du paquet, donc devrait supporter les mêmes contrôleurs. Le module aacraid inclus dans le noyau 4.19.0-11 de buster est en version 1.2.1 et a un alias de plus. Les paramètres disponibles sont légèrement différents.
Note : le pilote n’est pas suffisant, en principe il faut aussi un logiciel de supervision pour surveiller l’état du RAID, enoyer des mails d’alerte… Mais je n’ai pas trouvé de paquet pour ce type de contrôleur dans l’archive Debian 10.
1 J'aime
En fait le modèle n’est plus fabriqué semble-t-il, il n’y a plus moyen d’en trouver du neuf.
Ce n’est pas une raison suffisante pour ne plus fournir de pilote. Il en va de la réputation du fabricant. La durée de vie utile de la plupart des matériels va bien au-delà de l’arrêt de la fabrication, et les utilisateurs s’attendent à disposer de pilotes encore pendant longtemps. Qui achèterait un matériel sachant que son pilote ne sera plus disponible après l’arrêt de sa fabrication ?
1 J'aime
Tu veux des noms de fabriquant? C’est facile, quasiment tous. C’était justement une des raisons de la création du logiciel libre et de la FSF.
J’avais des cartes d’acquisitions industrielles des années 90 (début), dont l’utilisation était encore valable au début des années 2000, et dont les pilotes n’existaient plus du tout. Pour mon projet d’ingénieur j’ai du ré-écrire un pilote en faisant de la rétro-ingénierie sur l’ancien.
On peut citer Intel par exemple qui fait ça aussi, du moins à une certaine époque. Qui a voulu ré-installer un matériel avec une autre version en a fait déjà les frais.
j’avais quand meme visé ADAPTEC qui fait des cartes de ce type depuis longtemps et qui, en général, est plutot carré… mais bon, la… c’est la deumer…
Pourquoi ? Je viens d’écrire que le noyau de Debian 10 inclut un pilote aacraid qui a de grande chances de prendre en charge la carte de tes rêves. On serait dans le second cas que j’ai évoqué, favorable : Adaptec ne founit plus de pilote parce qu’il n’en a plus besoin, il est inclus dans le noyau.
1 J'aime
Apparemment Adaptec ne fournit pas de pilotes libres :
et ne propose plus de mise à jour depuis 2016…
S’il y a un pilote inclut dans le noyau ce n’est probablement pas grâce au fabricant de ces cartes.
Personnellement, je pense qu’un Raid logiciel est préférable à l’utilisation d’une carte plus ou moins privatrice.
Ce sera plus performant et cela élimine une source de panne (celle de la carte).
ah oui, pascal, sorry… j’ai lu à l’envers… je devais plus fatigué que je ne le croyais hier -_____-’ mea culpa.
Bon, je vais peut etre tenter avec une carte pas trop chère… je me tate.
et le raid logiciel, en pratique, j’ai lu bien trop de souci de stabilité… sans compter que ca prends bcp de ressources quand meme.
Peu importe. Il y a un tas de pilotes du noyau qui ne proviennent pas des fabricants, et qui marchent très bien quand même.
Pas forcément. Ça dépend du modèle de contrôleur RAID, du niveau de RAID utilisé, de la rapidité du CPU et de sa charge nécessaire aux autres tâches de la machine.
Bon… déjà merci à tous de vos infos…
En résumé, j’aurais presque intérêt à acheter une petite carte « en occasion » pour tester… vu qu’il y a ces drivers …
Il est possible de regarder si un carte est a priori prise en charge par un pilote du noyau. Ce n’est pas une garantie absolue, mais une bonne indication.
Par exemple je prends le cas de la carte Adaptec ASR-6805T mentionnée dans le message initial. On commence par chercher ses identifiants PCI à partir de sa désignation dans le fichier /usr/share/misc/pci.ids qui est la base de données utilisée par lspci pour nommer les périphériques PCI.
9005 Adaptec
...
028b Series 6 - 6G SAS/PCIe 2
...
9005 0311 Series 6 Connectors on Top - ASR-6805T - 8 internal 6G SAS
Explication sur le format du fichier pci.ids :
La ligne du bas commençant par deux tabulations est l’identifiant sous-fabricant (sub-vendor) et sous-périphérique (sub-device) 9005 0311. Il n’y en a pas toujours, ça dépend des périphériques. Quand il y en a une, il faut remonter à la ligne précédente du fichier qui commence par une tabulation. Elle contient l’identifiant du périphérique (device) 028b.
Pour finir il faut remonter à la ligne précédente sans tabulation qui contient l’identifiant du fabricant (vendor) 9005 pour Adaptec.
Parfois, la désignation dans le fichier n’est pas exactement la même que celle qu’on connaît et il faut tâtonner. Il peut aussi y avoir plusieurs identifiants avec la même désignation. Cette fois, c’est facile, rien de tout cela.
On obtient donc :
- vendor = 9005
- device = 028B
- sub-vendor = 9005
- sub-device = 0311
Avec cela on peut construire un début de chaîne d’alias (les lettres hexadécimales A-F doivent être en majuscule) :
pci:v00009005d0000028Bsv00009005sd00000311
Un alias PCI complet contient d’autres identifiants (bc=base class, sc = sub-class, i=je ne sais pas) mais ils ne figurent pas dans pci.ids. Ces identifiants peuvent être utilisés par les pilotes génériques pour une classe de périphérique donnée plutôt que pour un modèle particulier (exemple : contrôleur SATA en mode AHCI)
Il faut ensuite chercher si un module du noyau a un alias compatible. Si on connaît le nom du module, il suffit d’afficher ses alias avec modinfo :
/sbin/modinfo -F alias aacraid
Parmi les alias on trouve une correspondance :
pci:v00009005d0000028Bsv*sd*bc*sc*i*
Le caractère * est un « wildcard » qui remplace n’importe quelle suite de caractères. Ici, l’alias accepte n’importe quels sub-vendor, sub-device, base class, etc.
Quand on ne sait pas quel module est censé prendre en charge le périphérique, il faut chercher dans le fichier des alias du noyau /lib/modules/<version>/modules.alias qui recense tous les alias de tous les modules de cette version du noyau. Par exemple avec le noyau actif :
grep pci:v00009005d0000028B /lib/modules/$(uname -r)/modules.alias
qui renvoie :
alias pci:v00009005d0000028Bsv*sd*bc*sc*i* aacraid
Il s’agit donc du module aacraid.
Comme je l’écrivais, l’existence d’un alias n’est pas une garantie absolue. Il sert à charger automatiquement le module lorsque le périphérique est détecté, mais c’est le module lui-même qui va décider s’il prend en charge ce périphérique ou pas. Il se peut que l’alias accepte tous les subvendor et subdevice mais que le pilote lui-même ne les gère pas tous. Pour le savoir, il faudrait examiner le code source du module.
1 J'aime
On peut aussi aller voir sur la doc sur kernel.org :
https://www.kernel.org/doc/html/latest/scsi/aacraid.html
où la carte ASR-6805T n’apparaît malheureusement pas dans la liste des cartes prises en charge.
Cette liste a été mise à jour pour la dernière fois en 2009.
C’est possible mais je n’ai pas vu cette date sur la page en question.
Si c’est le cas c’est sans doute qu’aucune nouvelle carte n’a été ajoutée depuis 2009.