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/E191 ... 918-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
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.
Code: Select all
# /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.
