Hello, Rus V. Brushkoff wrote: > :This is weird. The drive should have stayed unlocked over > :initialization sequence as SSP is in effect. Either the BIOS is turning > :off SSP during POST or the drive isn't preserving security mode state > :although SSP is in effect. Testing who's to blame can be a bit > :cumbersome and involves removing power from the drive while the rest of > :the system is running. Can you do that? > > Sure - I can simply hot-unplug/hot-plug hdd from laptop. For now I've > attached good dmesg (normal boot without hdd password set), and bad one - > with a kernel panic. Please clarify what exact power-on/power-off hdd log > do you need - with hdd password set (do not know if the kernel panic state > can be interrupted by sata events) or without hdd password set ? Okay, here's the sequence. 1. Boot w/o password set. hdparm -I will show that security feature is not enabled. 2. Execute "hdparm --user-master u --security-set-pass PASSWORD /dev/sda". hdparm -I will show that security is enabled but not locked. 3. Remove power from the drive and reapply. Now hdparm -I will show that security is enabled and locked and dd'ing from the drive will fail. 4. Execute "hdparm --user-master -u --security-unlock PASSWORD /dev/sda". hdparm -I will show security enabled but unlocked and you'll be able to access the drive again. 5. Unload and reload ahci. This will trigger controller initialization causing hardresets on the ports. Execute hdparm -I and see whether the drive is still unlocked and verify that you can read from the drive. If the drive stays unlocked over #5, it means that the BIOS is explicitly disabling SSP during POST. If the drive locks up again, it means its SSP implementation isn't preserving security mode state over hardreset. Thanks. -- tejun -- 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
