O que esse erro significa?

Question

O seguinte erro continua aparecendo nos registros:

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

    

Answer 1

Eu encontrei um relatório de bug para o Kernel versão 4.6.3 e maior onde esse bug apareceu pela primeira vez. Spams /var/log/syslog a cada 10 minutos. Esse bug foi reportado tão tarde quanto a versão 4.7.2 do Kernel. Aparentemente, as atualizações do Ubuntu para o kernel 4.4.0-38 introduziram o bug agora.

Além disso, esse bug é relatado com unidades conectadas via USB. Eu presumo que seu sdb seja.

Aparentemente, isso não é motivo para preocupação, a não ser o fato de que ele spams seu syslog .

O relatório de bug que encontrei pode ser seguido em: link

    

Answer 2

É bem possível que seja devido a este commit:

0dec8c0d67c64401d97122e4eba347ccc5850622 is the first bad commit
commit 0dec8c0d67c64401d97122e4eba347ccc5850622
Author: James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx>
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 retried 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.

Eu acredito que pelo que entendi desta correção e os erros sendo vistos é que os comandos de passagem ATA com opcodes 0x85 "passagem de comando ATA (16)" e 0xa1 "passagem de comando ATA (12) / em branco" são sendo agora (possivelmente erroneamente) emitido e, portanto, causando essas mensagens de erro.

Examinando os dados do comando de passagem ATA, parece que um comando ATA SMART (tecnologia de auto-monitoramento, análise e relatório) está sendo emitido (código de comando 0xb0), estou especulando que talvez este H / W não esteja capaz de lidar com isso.