[temp t13] Re: Are devices allowed to go busy on their own?

[Gary Laatsch]

Title: RE: [temp t13] Re: Are devices allowed to go busy on their own?

I remember long ago in a previous life with a hard drive company we were discussing going busy at certain intervals to do thermal recalibrations.  We got the same interpretation of the spec then.  The bottom line was although the spec clearly states when BSY can be set, it didn't blatantly exclude any other times.  However, the general opinion from the world was "please don't do that".  I think that was back in ATA-2 timeframe.  Maybe the committee should consider clearing this up.  Just a thought.....

 

gary laatsch

 

-----Original Message-----
From: Curtis Stevens [mailto:[EMAIL PROTECTED]]
Sent: Thursday, July 12, 2001 10:08 AM
To: '[EMAIL PROTECTED]'
Subject: [temp t13] Re: Are devices allowed to go busy on their own?

Jim

 

    This section lists conditions where BSY shall be set.  It does NOT state that BSY can not be set at other times.  "The BSY bit shall be set to one by the device:"  The word ONLY is sadly lacking from this statement...  Is there another section?

-----Original Message-----
From: Mcgrath, Jim [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, July 11, 2001 6:14 PM
To: '[EMAIL PROTECTED]'
Subject: [temp t13] Re: Are devices allowed to go busy on their own?

 

Section 7.15.6.1 (revision 5), where it explicitly lists the conditions under which BSY can be set to 1 by the device:

 

Reset: "after either the negation of RESET- or the setting of the SRST bit to one in the Device Control register;"

Start of some commands: "after writing the Command register if the DRQ bit is not set to one;"

Pacing of PIO data transfer: "between blocks of a data transfer during PIO data-in commands before the DRQ bit is cleared to zero;"

Special case in PIO data transfer: "after the transfer of a data block during PIO data-out commands before the DRQ bit is cleared to zero;"

Multiword DMA (cannot access registers in Ultra DMA mode, as per table 10): "during the data transfer of DMA commands either the BSY bit , the DRQ bit, or both shall be set to one;"

Start of ATAPI command execution: "after the command packet is received during the execution of a PACKET command."

As Hale points out, the discussed action is illegal unless it is occurring during one of the above.  Specifically, there is no general purpose rule that you set BSY=1 when changing the value of a bit in the Status register.  Indeed, why would there be a need for it in this case anyway?  (i.e. nothing breaks if you do not set BSY=1).

 

Jim

 

 -----Original Message-----
From: Curtis Stevens [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, July 11, 2001 5:12 PM
To: '[EMAIL PROTECTED]'
Subject: [temp t13] Re: Are devices allowed to go busy on their own?

Hale

        What section in ATA/ATAPI6 says that you shall not asynchronously set the BSY bit?

-----Original Message-----
From: Hale Landis [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, July 11, 2001 4:18 PM
To: [EMAIL PROTECTED]
Subject: [temp t13] Re: Are devices allowed to go busy on their own?

  ** This is the quasi-official and semi-temporary T13 email list server. **

On Wed, 11 Jul 2001 15:59:22 -0700, Eschmann, Michael K wrote:
>What I believe you may be seeing is the device selection delay problem,
>where you must wait 400nS for the device to have it's registers valid before
>you can read them.  You may be getting the first device's status, then you
>read status again and get the newly-selected device's status.  Please verify
>you are waiting 400nS or more before reading status.

What I have seen is devices that just toggle BSY for no apparently
good reason.

>This could be a case that device selection causes the drive in question to
>go busy until it can get it's state machine in order because it cannot be
>ready in 400nS.  I've seen this in the past, but cannot enumerate/name the
>device for you (losing my memory, me thinks!)

But even setting BSY=1 because the DEV bit changed value is
absolutely and completely illegal. But I hear rumors there is some
ATAPI interface chip core floating around the Far East that does
this.

As I said before, devices that do this sort of stuff should never
pass any device evaluation test and should never be seen in computers
from well known system vendors. All these problems with ATAPI devices
go back to the failure of the systems manufacturers to require
confomance to the published standards for ATAPI devices. Anyone
building an ATA device that did this sort of stuff would sell zero
devices but for some reason the ATAPI device designers can just do
anything they want in violation of the published standards and they
will have no trouble selling their crappy devices. What gives?

***  Hale Landis  *** [EMAIL PROTECTED] ***
*** Niwot, CO USA ***   www.ata-atapi.com   ***

--
  If you have any questions or wish to unsubscribe send a
  message to Hale Landis, [EMAIL PROTECTED] To post to
  this list server send your message to [EMAIL PROTECTED]
 
  For questions concerning Thistle Grove Industries or TGI's
  list services please send email to [EMAIL PROTECTED]