This message is from the T13 list server.
Issue 1) It does work if you follow the rules in the SPEC.
Issue 2) Use your wallet to make a statement, because this (T13) is not an
organization that runs around playing policeman, and if you check
it is an optional feature set. The only people who will talk
about specific products is the OEM.
Cheers,
Andre Hedrick
LAD Storage Consulting Group
On Tue, 27 Aug 2002, sraposo wrote:
> This message is from the T13 list server.
>
>
> Folks,
>
> Maybe some of the subscribers think that they are implementation related
> problems, but since this is a forum where implementation people also
> participate, I guess that some will find it useful. I suggest that any reply
> be done off t13 list, if prefered.
>
> These facts were observed via application running on DOS 6.22 and directly
> programming I/O ports.
>
> First annoying phenomenon:
> An AT/A-6 complatible hdd (Maxtor model 2B020H1, controller version
> WAH21PB0), thru Identify Device command, reports host protected area feature
> available. It is really possible to set a maximum address below native max
> address and this setting continue valid while hdd is kept powered on. No
> matter if either volatile or non-volatile option is chosen. When
> non-volatile bit is set on set max address command and hdd is powered off
> and on, the max address becomes the native max address, as if set max
> address command were not issued. Other hdds does not perferm this way, i.
> e., they really set permanently the new max address.
>
> Second annooying phenomenon:
> A hdd with security feature available attached to an IBM Netvista computer
> returns ok when user password is set. The computer is turned off and powered
> on again and hdd keep fully accessible, as if that security command were
> never used. It seems that there is some hook that intercepts the AT/A I/O
> ports and fools application. Just to make it clearer, this strange behaviour
> does not happens on computer of other brands, as it was expected.
>
> Sure t13 is not responsible for any eventual implementation error, abuse,
> non-compliance etc. If someone could give some information about these
> facts, I will be very glad.
>
> Best regards,
>
> S�rgio.
>
