Matériel: Quelle carte Raid5 pour Debian 10?

Tags: #<Tag:0x00007faa2ee38f48> #<Tag:0x00007faa2ee38e58>

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.

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.

Si puisque le module aacraid du noyau 3.16 de Jessie, postérieur, a plusieurs alias qui ne sont pas mentionnés dans cette liste. D’autre part, un alias a été ajouté au module aacraid entre le noyau 3.16 de Jessie et le noyau 4.19 de Buster, comme je l’ai écrit précédemment. Il est plus probable que celle liste n’a tout simplement plus été maintenue après 2009.

Pour infor j’ai trouvé la date dans l’historique du dépôt git du noyau sur git.kernel.org.