(Keeping as much as the thread since I've just added Lennart to the Cc) On Wed, 2010-03-31 at 12:12 -0400, Douglas Gilbert wrote: > 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? As I said above, I don't think it's ata_id that is the problem - I think it's udisks-probe-ata-smart, via libatasmart, that is responsible for submitting the SET FEATURES command: http://git.0pointer.de/?p=libatasmart.git;a=blob;f=atasmart.c;h=a4b60c0eedf8e4f1ebafd932b7070c030459ef16;hb=HEAD#l2561 when it finds out that the SMART feature is available, yet not turned on. I actually don't think libatasmart has any business making such decisions on behalf of the user... Lennart, any chance we can stop libatasmart from doing this? Thanks. > 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
