On Wed, 31.03.10 12:37, David Zeuthen (david@xxxxxxxx) wrote: > > > 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. Uh. I think it definitely needs to call this. I am pretty sure most USB HDDs you plug in have SMART disabled by default until libatasmart enables it. So, libatasmart would stop enabling it automatically you'd end up with no SMART at all for these devices. Also, on my desktop here, when you reset the BIOS settings to the defaults, SMART is off. So, that means that somebody needs to enable SMART from Linux, and who should do that if not libatasmart? if that device chokes on SETFEATURES then we might need to blacklist that, not disabled SMART for all devices right-away... Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 -- 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
