On Wed, 31 Mar 2010, Douglas Gilbert wrote: > > 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? Jonas, these sound like good things to try. Find the ata_id and udisks programs on your computer and rename them so they can't be run automatically. Then see if the problem still occurs. > Since the sequence of commands was IDENTIFY DEVICE, > SET FEATURES then IDENTIFY DEVICE again my guess is > that SET FEATURES caused the problem. More precisely, the commands were IDENTIFY DEVICE (ATA-12), SET FEATURES (ATA-16), IDENTIFY DEVICE (ATA-16). The third command was not the same as the first, so one shouldn't assume that the third should have worked merely because the first did. In fact, I would guess that the second IDENTIFY DEVICE is what caused the problem, since the first two commands both succeeded and the third failed. If the second command was responsible for the problem, I would have expected _it_ to fail. > Why would a > program called ata_id try to change the state of > the device? In fact, those three commands may have been sent by different programs. It certainly is possible that the problem is related to libatasmart. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
