Il-y-a un quelques années, disons 5 ou 6 ans, basculer un ordinateur personnel sous Linux signifait d’abord vérifier la compatibilité du matériel. Cela est toujours vrai aujourd’hui, en témoigne Linux-Drivers.org, mais de manière générale ce n’est plus un passage obligé.
De manière générale.
Dans le but de mettre en place un NAS sur un Raspberry Pi flambant neuf, j’ai fait l’acquisition d’un boitier Sata USB 3 Icy Box IB-351StU3-B. Ni une ni deux je branche la chose sur le premier port USB disponible… et… mount /dev/sda1 /tmp/test… et rien. Un beau plantage du système.
Le pourquoi de la non chose
Pourquoi un simple périphérique de stockage n’est pas reconnu par ma machine ? Avant de creuser un peu plus, je teste rapidement le boitier sur Windows 7 : pas de problème, le disque et son boitier sont correctement reconnus.
De retour sur Linux, je regarde ce qui se passe du coté de dmesg :
[ 3434.890820] usb 1-1.3: new high-speed USB device number 4 using dwc_otg
[ 3434.998764] usb 1-1.3: New USB device found, idVendor=1234, idProduct=5678
[ 3434.998799] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 3434.998820] usb 1-1.3: Product: VLI Product String
[ 3434.998836] usb 1-1.3: Manufacturer: VLI manufacture String
[ 3434.998852] usb 1-1.3: SerialNumber: 0000000000006122
[ 3435.007870] scsi0 : usb-storage 1-1.3:1.0
[ 3439.167410] scsi 0:0:0:0: Direct-Access WDC WD25 00BEKT-75PVM 01.0 PQ: 0 ANSI: 2
[ 3439.173974] sd 0:0:0:0: [sda] 488397165 512-byte logical blocks: (250 GB/232 GiB)
[ 3439.175587] sd 0:0:0:0: [sda] Write Protect is off
[ 3439.175626] sd 0:0:0:0: [sda] Mode Sense: 00 06 00 00
[ 3439.177209] sd 0:0:0:0: [sda] No Caching mode page present
[ 3439.177243] sd 0:0:0:0: [sda] Assuming drive cache: write through
[ 3439.186049] sd 0:0:0:0: [sda] No Caching mode page present
[ 3439.186085] sd 0:0:0:0: [sda] Assuming drive cache: write through
[ 3439.199966] sda: sda1
[ 3439.200029] sda: p1 size 488395120 extends beyond EOD, enabling native capacity
[ 3439.206799] sd 0:0:0:0: [sda] No Caching mode page present
[ 3439.206836] sd 0:0:0:0: [sda] Assuming drive cache: write through
[ 3439.209317] sda: sda1
[ 3439.209375] sda: p1 size 488395120 extends beyond EOD, truncated
[ 3439.220922] sd 0:0:0:0: [sda] No Caching mode page present
[ 3439.220959] sd 0:0:0:0: [sda] Assuming drive cache: write through
[ 3439.220981] sd 0:0:0:0: [sda] Attached SCSI disk
[ 3440.467258] sd 0:0:0:0: [sda] Result: hostbyte=0x00 driverbyte=0x08
[ 3440.467301] sd 0:0:0:0: [sda] Sense Key : 0x5 [current]
[ 3440.467327] sd 0:0:0:0: [sda] ASC=0x24 ASCQ=0x0
[ 3440.467349] sd 0:0:0:0: [sda] CDB: cdb[0]=0x28: 28 00 00 00 00 38 00 00 08 00 00 00
[ 3440.467411] end_request: I/O error, dev sda, sector 56
[ 3440.467434] Buffer I/O error on device sda, logical block 56
[ 3440.467458] Buffer I/O error on device sda, logical block 57
[ 3440.467476] Buffer I/O error on device sda, logical block 58
[ 3440.467494] Buffer I/O error on device sda, logical block 59
[ 3440.467511] Buffer I/O error on device sda, logical block 60
[ 3440.467528] Buffer I/O error on device sda, logical block 61
[ 3440.467545] Buffer I/O error on device sda, logical block 62
[ 3440.467562] Buffer I/O error on device sda, logical block 63
Le mot clé ici est SCSI, en effet ce boitier permet un changement de disque-dur à chaud (c’est à dire sans arrêt/relance), ce n’est donc pas un simple périphérique USB comme je l’imaginais.
Pour confirmer le problème, je teste un hpparm /dev/sda1 :
/dev/sda1:
HDIO_DRIVE_CMD(identify) failed: Invalid argument
readonly = 0 (off)
readahead = 256 (on)
Pour comparer, la même commande sur un disque fonctionnel :
/dev/sda2:
multcount = 8 (on)
IO_support = 1 (32-bit)
readonly = 0 (off)
readahead = 256 (on)
geometry = 30401/255/63, sectors = 204800, start = 2048
Retour à l’envoyeur ou geekage intense ?
Coup de chance pour ce post, LDLC ne propose pas de politique d’échange ou remboursement, et comme le disque n’est pas explicitement compatible Linux point de salut auprès du SAV. Il faut donc que je trouve une solution.
Après quelques recherches, je trouve cet article qui semble correspondre à mon problème, et renvoit vers cet obscure publication.
En regardant de plus près, il s’avère que le boitier se présente comme un appareil de classe SFF-8020i (visible avec un lsusb -v) :
bInterfaceSubClass 2 SFF-8020i, MMC-2 (ATAPI)
Une recherche Google me permet de trouver une Datasheet, qui a pour titre “ATA Packet Interface for CD-ROMs”. Hu hum. CD-ROM ? Effectivement, cela doit être un moyen simplifié de permetre le hot-swap sur un disque-dur (car on peut changer le média dans un lecteur CD-ROM sans reboot).
Un peu plus loin dans la doc on peut lire “Support for command packets of at least 12 bytes in length.”, je n’ai pas trouvé cela par hasard, c’est écrit dans l’article mentionné plus haut (“This kicks-in code to force all commands to 12-byte, as (I think) required by 8020i”). Bien qu’il soit question de 12 octets minimum pour les commandes envoyées au périphérique, les développeurs du noyau Linux ont probablement interprété cela comme une limite à ne pas dépasser.
Quelqu’un qui doit connaître le noyau comme sa poche a trouvé la solution , il faut modifier le noyau pour qu’il ne force plus les instructions à une longeur de 12 octets. La publication n’est plus trop à jour, sur un noyau 3.6.2 il faut éditer le fichier linux-3.6.2/drivers/usb/storage/protocol.c et le modifier ainsi :
/* Ligne 66, on commente */
/*for (; srb->cmd_len < 12; srb->cmd_len++)
* srb->cmnd[srb->cmd_len] = 0;
*/
/* Ligne 90, on commente */
/* srb->cmd_len = 12; */
On recompile le noyau, et hop tout fonctionne, le disque est reconnu sans erreurs.
Alors pour de vrai, j’ai un peu triché, je n’ai pas encore compilé de noyau pour un Rapsberry Pi car cela un implique une compilation croisée (compiler du code pour un processeur ARM sur un processeur x86). Mais promis, j’ai testé et approuvé sur le Archlinux installé sur mon laptop et je me lancerain bientôt dans la cross-compilation pour le Rapsberry Pi :)