Que signifie cette erreur?

L’erreur suivante continue à apparaître dans les journaux:

Oct 3 09:51:36 gooseberry kernel: [15050.345601] sd 5:0:0:0: [sdb] tag#0 CDB: ATA command pass through(12)/Blank a1 06 20 da 00 00 4f c2 00 b0 00 00 Oct 3 10:01:35 gooseberry kernel: [15649.821810] sd 5:0:0:0: [sdb] tag#0 FAILED Result: hostbyte=DID_ERROR driverbyte=DRIVER_SENSE Oct 3 10:01:35 gooseberry kernel: [15649.821817] sd 5:0:0:0: [sdb] tag#0 Sense Key : Hardware Error [current] [descriptor] Oct 3 10:01:35 gooseberry kernel: [15649.821820] sd 5:0:0:0: [sdb] tag#0 Add. Sense: No additional sense information Oct 3 10:01:35 gooseberry kernel: [15649.821824] sd 5:0:0:0: [sdb] tag#0 CDB: ATA command pass through(16) 85 06 20 00 00 00 00 00 00 00 00 00 00 00 e5 00 Oct 3 10:01:36 gooseberry kernel: [15650.300873] sd 5:0:0:0: [sdb] tag#0 FAILED Result: hostbyte=DID_ERROR driverbyte=DRIVER_SENSE Oct 3 10:01:36 gooseberry kernel: [15650.300879] sd 5:0:0:0: [sdb] tag#0 Sense Key : Hardware Error [current] [descriptor] Oct 3 10:01:36 gooseberry kernel: [15650.300881] sd 5:0:0:0: [sdb] tag#0 Add. Sense: No additional sense information Oct 3 10:01:36 gooseberry kernel: [15650.300885] sd 5:0:0:0: [sdb] tag#0 CDB: ATA command pass through(12)/Blank a1 06 20 da 00 00 4f c2 00 b0 00 00 $ uname -a Linux gooseberry 4.4.0-38-generic #57-Ubuntu SMP Tue Sep 6 15:42:33 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux 

J’ai trouvé un rapport de bogue pour la version 4.6.3 et ultérieure du kernel où ce bogue est apparu pour la première fois. Il diffuse /var/log/syslog toutes les 10 minutes. Ce bogue a été signalé jusqu’à la version 4.7.2 du kernel. Apparemment, les mises à jour du kernel 4.4.0-38 d’Ubuntu ont introduit le bogue maintenant.

Ce bogue est également signalé avec les lecteurs USB connectés. Je suppose que votre firebase database est.

Apparemment, ce n’est pas un sujet de préoccupation, mis à part le fait qu’il spams votre syslog .

Le rapport de bogue que j’ai trouvé peut être suivi à: https://bugzilla.redhat.com/show_bug.cgi?id=1351305

Il est fort possible que cela soit dû à ce commit:

 0dec8c0d67c64401d97122e4eba347ccc5850622 is the first bad commit commit 0dec8c0d67c64401d97122e4eba347ccc5850622 Author: James Bottomley  Date: Fri May 13 12:04:06 2016 -0700 scsi_lib: correctly retry failed zero length REQ_TYPE_FS commands commit a621bac3044ed6f7ec5fa0326491b2d4838bfa93 upstream. When SCSI was written, all commands coming from the filesystem (REQ_TYPE_FS commands) had data. This meant that our signal for needing to complete the command was the number of bytes completed being equal to the number of bytes in the request. Unfortunately, with the advent of flush barriers, we can now get zero length REQ_TYPE_FS commands, which confuse this logic because they satisfy the condition every time. This means they never get resortinged even for retryable conditions, like UNIT ATTENTION because we complete them early assuming they're done. Fix this by special casing the early completion condition to recognise zero length commands with errors and let them drop through to the retry code. 

D’après ce que j’ai compris de ce correctif et des erreurs constatées, je pense que les commandes d’intercommunication ATA avec les opcodes 0x85 “Commande ATA passage (16)” et 0xa1 “Commande ATA passage (12) / Vierge” sont en cours ( peut-être à tort) a été émis et est donc à l’origine de ces messages d’erreur.

En regardant les données de la commande ATA directe, il semble qu’une commande ATA SMART (technologie d’auto-surveillance, d’parsing et de génération de rapports) est en cours d’émission (code de commande 0xb0). Je suppose que ce H / W n’est pas en mesure de gérer ce.