This message is from the T13 list server.
They are being used for more than testing errors in software. 3/20/02 11:45:11 AM, Curtis Stevens <[EMAIL PROTECTED]> wrote: > > > From: Curtis Stevens <[EMAIL PROTECTED]> > > To: ata reflector <[EMAIL PROTECTED]> > Subject:RE: [t13] Re: ^ 18 R/W Long commands > Date: Wed, 20 Mar 2002 10:45:11 -0800 > > > > > Thom > > > I take exception to your statement that "At the same time, in the > ATA specification it states that these commands, are no longer part of > > ATA." You know as well as I do that this is not true. Marking commands > obsolete such as read/write long simply casts them in stone and states for > the record that there will be no more committee innovation on these > commands. Obsolesence is also a recommandation that host software vendors > > stop using them. These commands do however remain a permanent part of ATA. > If the ATA/ATAPI standard documented everything in the interface then a case > could probably be made for carrying these definitions forward in the text. > However, some OEMs require functionality that does not come to committee. > > The OEM may have a patent on it, or drive manufacturers can not agree on a > common implementation for the feature. SMART thresholds come to mind... > This means that there is already a body of undocumented features, unlike > obsoleted commands where the feature is fully documented. > > > If I follow these threads correctly, Read/Write long are mainly > being used for testing error conditions in host software. I think there are > > better ways to do this error testing, for instance a command that when > issued has parameters that set status and error registers to specific > values(i.e. LBA Low = Error, LBA Mid = Status). I think this thread started > because somebody misunderstood how read/write long works, and somebody else > > was looking for completeness with the new 48bit command set. If the only > thing that Read/Write long is good for is generating errors, I still don't > see a need to update them for 48bit LBA. > > > ----------------------- > Curtis E. Stevens > Pacific Digital Corp. > > 2052 Alton Parkway > Irvine, CA 92606 > > > Phone (949) 477-5713 > Fax (949) 252-9397 > > > E-Mail: [EMAIL PROTECTED] > WEB: www.PacificDigital.com > > > Since light travels faster than sound, isn't that why some people appear > bright until you hear them speak? > > > -----Original Message----- > From: Thomas Colligan [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, March 20, 2002 9:57 AM > To: McGrath, Jim; 'don clay'; ata reflector > > Subject: Re: [t13] Re: ^ 18 R/W Long commands > > > > > This message is from the T13 list server. > > > > > Jim; > > > This is ridiculous, OEMs still require these commands be supported for a > number of reasons. The drive suppliers comply to the OEM wishes. At the same > > time, in the ATA specification it states that these commands, are no longer > > part of ATA. > > There are two faces, the face that is presented by HDD suppliers while at > > T13 and the one in front of a customer. They say state they will still > support these commands. > > > So here we have the dilemma. We have individuals making decisions, that > ultimately impact their own customers or even those whom have nil as > customers. > > > Those whom actual have customers, reassure them, they will still support > them. > > > So why the two positions? > > > So, Why not have a single command, with the options, as Jeff summarized in > his email. I can see it now every drive supplier would be against any > proposal. Its not a cake walk trying to get anything into ATA unless it > benefits the drive suppliers. I can here stories now! > > > > > > Everyone, happy except for drive suppliers because they would have to do as > their customers ask. What a novel Idea? > > > As Harlan stated it is getting harder and harder to test today's ATA hard > drives for a number of reasons. I expect HDD supplier factories are under > the same constraints. How do you completely test a 120GB in the time > required by upper management, and state that the drive is good. We should > > be adding new test technologies that allow for a quicker analysis of drive > issues. As the capacity of today's HDD increase the more difficult it will > be for all of us. > > > Tom Colligan > > > > > > > On 3/19/02 6:56 PM, "McGrath, Jim" <[EMAIL PROTECTED]> wrote: > > > > This message is from the T13 list server. > > > > > > > > > Don, > > > > I was wrong in thinking that READ LONG/WRITE LONG was tied into the recent > > > > addressing changes (I got the timing confused in my mind with the SEEK > > command, which has just been proposed to become obsolete). In reality > READ > > LONG/WRITE LONG were made obsolete in ATA-4 back in August of 1997 > > (actually > > in revision 5 of that document in June of 1996). > > > > So they have not appeared in ATA-4, ATA-5, or ATA-6 (or the upcoming ATA- > > 7). > > It has not been in a draft document for more than 5 years. Every one of > > those standards have advised hosts not to use that command anymore, since > > devices are compliant while only returning a command aborted in response > > to > > the command. > > > > Indeed, they only appear in ATA-1, ATA-2, and ATA-3. ATA-1 and ATA-2 are > > > withdrawn standards (i.e. they no longer exist except as historical > > footnotes), so the only standard they are mentioned in is ATA-3. > > > > So the issue is rather academic (unless, once again, people have a new > > > proposal on some new functionality to make). > > > > The current issues are obsoleting the SEEK command and CHS addressing > mode. > > > > > Jim > > > > > > > -----Original Message----- > > From: don clay [mailto:[EMAIL PROTECTED]] > > Sent: Tuesday, March 19, 2002 2:27 PM > > To: ata reflector > > > Subject: [t13] Re: ^ 18 R/W Long commands > > > > > > This message is from the T13 list server. > > > > > > > Jim, > > > > > I have over 26 years of experience with multiple disk drive companies, > both > > big > > box and in ATA drives with long runs of service with two different > > > companies. I > > have designed ATA ASIC's and written the code for them. I have been > > involved > > in the development of ATA drives since mid 1986. > > > > > So I have designed the R/W Long command in several ASIC's and then written > > > the code for those commands. Both the code and the ASIC's have shipped > > successfully in very large volumes. > > > > > I have been intimately involved in the testing and development of all of > > these > > drives in very many different ways. I have worked closely with many > > > different > > customers and understand how they used to want drives tested and how they > > want them tested in the present. > > > > > Furthermore, I have worked very closely with other OEM's in the > development > > of > > their ASIC's for the ATA Interface. That technology also shipped in very > > > > large > > volumes. > > > > It has been my experience that you are wrong in this matter both on the > > > hardware and firmware side of this discussion. I have provided examples > > supporting my position and could supply more if necessary. These > assertions > > are based on actually designing and testing ASIC's, doing the code for > > them, > > and then designing tests for them. > > > > I entered this thread because the ATA committee is continually short > > > sighted in > > it's approach to backward compatibility. It has repeatedly acted without > > considering the whole of the ATA interface community. This has been true > > since the inception of this standards effort, which I also witnessed first > > > > hand. > > > > This thread began with several people complaining about the obsolescence > of > > > the R/W Long commands. The committee obviously did not poll the > > constituency of the ATA community prior to making the decision to obsolete > > > the > > R/W Long commands as several people have noted. Obsoleting a command, > > > as I've stated many times prior to this, subjects companies that are using > > > such > > commands to the whims and politics of this committee. > > > > > People should not have to come to these meetings out of self defense. > > People > > who are on the committee should have the responsibility to look at the big > > > picture and all of the members on it when considering changes. That would > > > > be > > a good use of this reflector. > > > > Your last paragraph is an example of that. Burden of proof???? The ATA > > > committee should be comprised of members who are going to exercise due > > dilligence prior to making a change. > > > > It is totally irrevalent how the R/W Long command is being used. People > > are > > using it. And that is burden of proof enough. > > > > don clay > > > > > 3/19/02 1:23:57 PM, "McGrath, Jim" <[EMAIL PROTECTED]> wrote: > > > >> > > >> Don, > >> > >> First, not all opinions are equal. I've worked at a disk drive company > for > > >> 15 years, and I know whereof I speak. Perhaps more importantly, a lot of > > >> folks on T13 are equally well educated on these sorts of issues. You > keep > >> on asserting no there are costs, despite the facts that they're been > > >> outlined to you. You are just not listening - so I'll stop talking. > >> > >> Second, the burden of proof is always on people advocating change - in > this > > >> case to add READ/WRITE LONG back into the standard. My (constructive) > >> suggestion has been to put together a proposal that accomplishes what > > people > >> want (whether that's really testing ECC, error injection, marking > > sectors, > >> etc...) and submit it to T13. Or even wait until it is published and > offer > >> a public comment. If you are not willing to make the effort, then it's > > >> obviously not a very important topic for you. > >> > >> Jim > >>>> > > >
