Tejun Heo wrote:
Hello, Rus.
Rus V. Brushkoff wrote:
...
[Hors]:root:~ # hdparm -K 1 /dev/sda
/dev/sda:
setting drive keep features to 1 (on)
HDIO_DRIVE_CMD(keepsettings) failed: Input/output error
.....
Those two are different ones. These are to keep software setting over
soft resets and doesn't have much to do with SSP. Mark, maybe we need
to add a feature to hdparm to configure SSP?
..
MMmm.. yes, there are a bunch of newish things there, specificially for SATA.
I'll extend hdparm to give access to changing those things.
..
:To solve the problem, ATA added Software Setting Preservation
:featureset, which makes the drive remember configurations over
:hardresets but it's an optional feature and not all drives implement it.
: I think having SSP support in the drive is the only sane way to support
:password locking on SATA; otherwise, the drive can just go away while
:the system is running. That said, it would be nice to have a parameter
:to force SRST or no reset at all for odd cases.
Hmm, if someone enable SSP in the drive after password unlock - does this
mean that it will be unlocked forever ? Or drive can distinguish between
power-on and hard-reset states ?
SSP by default stays on, so once unlocked it will stay unlocked as long
as power stays applied. On power loss, it gets locked again. On
reboots, the BIOS can always lock it again if it wants to.
..
The problem here, is that SSP itself gets turned-OFF after COMMRESET.
It does preserve settings over the COMMRESET, but it then has to be
renewed (re-issued by the driver) for things to survive a subsequent
COMMRESET after the first one. This has to go into libata,
as it's not something we can control entirely from hdparm.
??
--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
