6

The following error keeps coming up in logs:

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
5
  • Can you update your question with the output of uname -a? Is sdb a USB attached disk? Oct 3, 2016 at 0:53
  • Are you using Ubuntu? Oct 3, 2016 at 1:05
  • @Zacharee1 looking at his history of questions and answers he's been a Ubuntu user since 2011. This question isn't so great though as he doesn't state his Ubuntu version, nor his kernel version (even though his tag is kernel), nor did he reply to our comments :( I think I'll go ahead and answer anyway :D Oct 3, 2016 at 1:30
  • Done, updated the question. Oct 4, 2016 at 8:04
  • Take care of your data. That could also be a USB HDD with read/write errors because of bad sectors.
    – Gibbi
    Feb 4, 2017 at 16:28

2 Answers 2

6

I found a bug report for Kernel version 4.6.3 and greater where this bug first appeared. It spams /var/log/syslog every 10 minutes. This bug was reported as late as Kernel version 4.7.2. Apparently Ubuntu updates to kernel 4.4.0-38 have introduced the bug now.

Also this bug is reported with USB attached drives. Which I presume your sdb is.

Apparently it is not a cause for concern other than the fact it spams your syslog.

The bug report I found can be followed at: https://bugzilla.redhat.com/show_bug.cgi?id=1351305

2
  • I'm on Ubuntu 16.04, using kernel 4.4.0-38-generic. It does indeed seem to be a USB drive, so I'm pretty thankful that it wasn't a hardware issue. Oct 4, 2016 at 8:04
  • I've updated the answer to reflect Kernel 4.4.0-38 also containing the bug now. If you can mark the question solved and up-vote that will let others know it is correct if they have same error. Oct 4, 2016 at 10:15
4

It is quite possible it is due to this 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.

I believe from what I understand from this fix and the errors being seen is that ATA pass-through commands with opcodes 0x85 "ATA command pass through(16)" and 0xa1 "ATA command pass through(12)/Blank" are being now (possibly erroneously) issued and hence causing these error messages.

Looking at the ATA pass-through command data, it looks like a SMART (Self-Monitoring, Analysis and Reporting Technology) ATA command is being issued (command code 0xb0), I'm speculating perhaps this H/W is not able to handle this.

1
  • I think you're on the money. I started seeing the log spam for all my USB disks right after I started smartd on my Fedora box.
    – Navin
    Jun 30, 2017 at 0:50

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .