# SCSI Sense Key error messages with USB disk

## platojones

I've had these dmesg errors at least since the 2.6.36 series of gentoo-sources kernel.  I just upgraded to the 2.6.38 gentoo-sources kernels and they are still there.  They are referring to an external USB hard disk I keep attached for backups.  It's not the disk that's bad either...I originally had a WD My Book 500 Gb drive attached and replaced it with a Seagate 2 TB USB drive and still get the same errors.  These error messages are constant and happen whether the drive is mounted or not.  Googled around a lot, but never found anything that seems to fix these.  Anybody have any idea what (if anything) is causing these.  BTW, the drives seem to work fine:

```

[ 1869.086862] sd 10:0:0:0: [sdg]  Sense Key : Recovered Error [current] [descriptor]

[ 1869.086866] Descriptor sense data with sense descriptors (in hex):

[ 1869.086868]         72 01 04 1d 00 00 00 0e 09 0c 00 00 00 00 00 00 

[ 1869.086874]         00 4f 00 c2 40 50 

[ 1869.086878] sd 10:0:0:0: [sdg]  ASC=0x4 ASCQ=0x1d

[ 1869.165487] sd 10:0:0:0: [sdg]  Sense Key : Recovered Error [current] [descriptor]

[ 1869.165491] Descriptor sense data with sense descriptors (in hex):

[ 1869.165492]         72 01 04 1d 00 00 00 0e 09 0c 00 00 00 00 00 00 

[ 1869.165498]         00 4f 00 c2 40 50 

[ 1869.165502] sd 10:0:0:0: [sdg]  ASC=0x4 ASCQ=0x1d

[ 3669.004350] sd 10:0:0:0: [sdg]  Sense Key : Recovered Error [current] [descriptor]

[ 3669.004355] Descriptor sense data with sense descriptors (in hex):

[ 3669.004357]         72 01 04 1d 00 00 00 0e 09 0c 00 00 00 00 00 00 

[ 3669.004363]         00 4f 00 c2 40 50 

[ 3669.004367] sd 10:0:0:0: [sdg]  ASC=0x4 ASCQ=0x1d

[ 3669.085981] sd 10:0:0:0: [sdg]  Sense Key : Recovered Error [current] [descriptor]

[ 3669.085985] Descriptor sense data with sense descriptors (in hex):

[ 3669.085986]         72 01 04 1d 00 00 00 0e 09 0c 00 00 00 00 00 00 

[ 3669.085991]         00 4f 00 c2 40 50 

[ 3669.085994] sd 10:0:0:0: [sdg]  ASC=0x4 ASCQ=0x1d

```

Last edited by platojones on Sun Mar 20, 2011 3:18 pm; edited 1 time in total

----------

## Bones McCracker

Bottom line:   I don't know much about this, but I'll try to help.  I suspect this is a bug in the Linux storage drivers, but a benign one you can ignore.  You may be able to get rid of the error messages by disabling an application trying to access the disk in a particular way, or by invoking a driver option.  You might getter better input than mine with an improved thread subject: something like "SCSI Sense Key error messages with USB disk".

Here is a guide to SCSI Sense Key error codes (I just picked the first one I came across -- you should find a more complete, newer one, preferably from the manufacturer of your disk): 

http://download.oracle.com/docs/cd/E19105-01/storedge.6320/817-5918-10/817-5918-10.pdf

"Recovered Error" means the drive is ok.  I think that falls under sense key 0x1, but I don't see the asc / ascq pair that's showing up in your log (0x4 / 0x1d) listed under sense key 0x1.  

The asc and ascq reported in your log

```
ASC=0x4 ASCQ=0x1d 
```

are not listed in this guide.  Maybe you can find a more complete or more recent one that has it.  However, they do list 0x4; 0x1 (same thing with no d -- don't know if it's related or not).  This is listed as a 0x2 sense key error ("the drive is in a not-ready state and cannot be accessed").  Specifically those two codes are listed on page 4 to mean "the drive is okay but not ready, it is spinning up".

I have seen sense key errors before in Linux.  In my limited understanding, when they are spurious they are typically related to the SCSI emulation performed by the Linux drivers for various storage devices.  Basically, something is trying to communicate with the device as though it were an actual SCSI disk, and it is not getting the right feedback.

If you are using smartmontools (i.e. smartd) you might try disabling it and seeing if the log spewage ceases.  It has been known to trigger spurious SCSI sense key errors.

The only time I personally have seen something similar was with an old firewire iPod (basically an external disk connected via ieee1394 instead of usb).  The solution to my problem may be completely irrelevant to yours, but it might give you some ideas about where to look and what kind of solution might be available.

I googled for the error message I was getting, and saw a reference to using a "workaround option" of the driver.  I couldn't find any reference to it in any documentation for the driver, but I found mention of it when I did 'modinfo <drivername>'.  Based on that, I learned that there were some options that could invoked when loading the driver, to work around various device bugs.  So I created a modprobe.d file for the driver, specifying the relevant option.  

```
# /etc/modprobe.d/firewire_sbp2.conf

# BoneKracker

# 29 January 2010

# Purpose: allow use of new firewire stack with old (generation 2) iPod.

# This reduces the data transfer rate to 128kB. Run update-modules after

# making any changes to this file.

# Re: UPDATE-MODULES(8), MODPROBE.CONF(5), MODINFO(8)

# From 'modinfo firewire_sbp2':

# "workarounds:Work around device bugs (default = 0, 128kB max transfer = 0x1,

# 36 byte inquiry = 0x2, skip mode page 8 = 0x4, fix capacity = 0x8,

# delay inquiry = 0x10, override internal blacklist = 0x100, or a combination)

# (int)"

# This will be applied to any firewire disk device.  It may be possible to 

# selectively configure the driver for a single device, but I don't know how.

# (Maybe using udev?)

options firewire_sbp2 workarounds=0x1
```

Hopefully somebody who knows more will offer better information.

----------

## platojones

 *BoneKracker wrote:*   

> Bottom line:   I don't know much about this, but I'll try to help.  I suspect this is a bug in the Linux storage drivers, but a benign one you can ignore.  

 

For somebody who doesn't know much about it, that looks like a pretty thorough and accurate analysis to me   :Very Happy: 

I'd read several things in my Google searches similar to what you mentioned, but I was just curious if this was an obvious kernel config thing.  I don't think it is.  The config for USB mass storage is straightforward and I don't have anything unusual set there...and I haven't changed that config in ages.

I think you are on to something when you mentioned smartmon.  It's possible that I turned on smartd somewhere around the time I started noticing these messages.  I actually checked my smartd.conf file though, and I don't have this drive listed as one that smartd should check.  

BTW, I actually did find a kernel patch posted on the kernel mailing list that made these go away.  It worked up thru the 2.6.37 series kernels, but caused umount to hang when I applied it to the 2.6.38 kernel.  The dev who submitted it talked about incorrect SCSI command responses coming from the USB driver or something.  I don't think it was accepted into the main kernel tree though, possibly because of the issue I ran in to on the 2.6.38 kernel.

Any way, that was some really great info.  

I'll keep testing to see if I can narrow it down.

Cheers!

[UPDATE]I changed to the title of the thread as you suggested.  Thank you for that suggestion[/UPDATE]

----------

