Re: System hangs when using USB 3.0 HD with on Ubuntu

[Douglas Gilbert <dgilbert@interlog.com>]

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%673 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