If someone has set a password on an ATA/SATA hard drive and someone later connects the drive to a Linux system (before or after booting that Linux system), libata reacts in an unbearably stupid manner. Someone might have connected the drive with the intention of running the hdparm command to unlock the drive, or maybe even to remove the password. Or maybe they didn't know that the drive was passworded. But either way, there's no reason for libata to make a mess. It is possible to look at the drive's inquiry data to find out if the drive has a password set and currently locked. It is possible to know that READ DMA QUEUED and READ DMA etc. are all going to fail. It is possible to know that no purpose in resetting the drive, resetting the port multiplier, retyring the reads, retrying the reads, retrying the resets, retrying the reads, retrying the resets, retrying the reads, retrying the resets, retrying the reads, retrying the resets, wow this stuff sure is trying. Now, is it really insane to retry the same command over and over again hoping for a different result? Not always. If a glitch is transient, it might be helpful to observe the error return, maybe try a reset if necessary, and wait 30 seconds before retrying the read. In fact if four drives are connected to the same port multiplier or two drives are connected to the same SATA controller then transient glitches are frequent and retries (after patient delays) are meaningful. But retrying automatically, over and over again, when the user hasn't had time to type an hdparm command? Come on. Just look to see if the drive is passworded. Don't bother trying to do the read. Some time later, if the user runs some program that tries to do a read, try it and see if maybe the password is gone. Try it when the user asks for it. But even then, if it fails because the drive is passworded, don't reset the drive, don't reset the port multiplier, and don't retry. OK? -- 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
