☰

这个错误是什么意思？

tag-icon • tag-icon kernel
这个错误是什么意思？

日志中不断出现以下错误：

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

答案1

我找到了一个针对内核版本 4.6.3 及更高版本的错误报告，该错误首次出现于此版本。它/var/log/syslog每 10 分钟发送一次。此错误最晚在内核版本 4.7.2 中被报告。显然，Ubuntu 更新到内核 4.4.0-38 已经引入了此错误。

也有人报告说这个错误与 USB 连接的驱动器有关。我猜你的也是这样sdb。

显然，除了它会向您的垃圾邮件发送之外，没有什么可担心的syslog。

我发现的错误报告可以在此处找到：https://bugzilla.redhat.com/show_bug.cgi?id=1351305

答案2

这很可能是由于这个提交造成的：

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.

我相信从我对此修复的理解以及所看到的错误来看，ATA 直通命令带有操作码 0x85“ATA 命令直通（16）”和 0xa1“ATA 命令直通（12）/空白”现在正在（可能错误地）发出，因此导致这些错误消息。

查看 ATA 直通命令数据，它看起来像是正在发出 SMART（自我监控、分析和报告技术）ATA 命令（命令代码 0xb0），我猜测也许这个 H/W 无法处理这个问题。

相关内容