David Zeuthen wrote:
On Wed, 2010-03-31 at 10:56 -0400, Alan Stern wrote:
On Wed, 31 Mar 2010, Jonas Schwertfeger wrote:
Since this seems to have become a udev issue I'm brining the
hotplug/udev list into the loop.
A brief recap for the hotplug list readers: I'm experiencing issues
with a USB 3.0 hard drive (Buffalo HD-HXU3) on kernel 2.6.32.9 with
udev 151. When connected the device seems to be recognized and
registered with xHCI and USB core correctly but then responds to a
bulk transfer with a stall. We narrowed the issue down to udev by
stopping the udev daemon, connecting the device and mounting it
manually. If done this way the drive works fine. However, if udevd is
running the device stalls. Below is an excerpt of the conversation
involving the USB core, the USB storage and the SCSI list.
Any idea what command (most likely coming from udev) could cause the
drive to stall and what could be done about it?
More specifically, what program issues ATA-passthrough commands? And
what can be done to prevent it from doing so in cases where these
commands cause the device to crash?
Stock udev comes with ata_id which I think may be invoked for this
device (but I'm not sure). Try moving it out of the way?
On most distros, udisks (also known as DeviceKit-disks before the name
was changed) is installed which runs a small program that uses
libatasmart to determine if the device is SMART capable:
http://cgit.freedesktop.org/udisks/tree/src/probers/udisks-probe-ata-smart.c
and this definitely runs for this USB device assuming removable is 0 in
sysfs. Perhaps http://bugs.freedesktop.org/show_bug.cgi?id=25673 is
related? Maybe try with the latest libatasmart?
Since the sequence of commands was IDENTIFY DEVICE,
SET FEATURES then IDENTIFY DEVICE again my guess is
that SET FEATURES caused the problem. Why would a
program called ata_id try to change the state of
the device?
The SCSI subsystem has been very careful to call
the minimum number of "safe" commands when setting
up storage devices. Bitter experience has taught us
that when one strays beyond what another OS from
Oregon does, nasty things could happen.
I also suspect udev (more likely one of its helpers)
is behind a bizarre sequence of commands sent to a
storage device when it is closed. These commands
make smartmontools and other tools that attempt
to spin down an ATA disk useless.
[As an extra note, if the device is opened O_RDONLY
the "extra" commands on close() don't arrive.]
Doug Gilbert
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
