** This is the quasi-official and semi-temporary T13 email list server. **
Actually, there is a very GOOD reason that you may see this happen.
This is a normal part of ATAPI behavior that hosts must 'just accept'.
-------------
Part of the ATAPI protocol (e.g. QIC-157 for tape, ??? for CD) involves the
<asynchronous> setting of the DSC status bit when a device has
'logically disconnnected' from the host during some
long operation (usually involving media). Please see examples below.
Assume that an ATAPI device has a status of RDY only (x40)
and a media-access command is still in process (e.g. LOAD or REWIND).
When the <media> is ready (again), the device is required to set the
DSC status bit.
- - - but according to ATA, when BSY=0, the device does not 'own' the bus.
Proper ATAPI controller chips and firmware implement and respect this.
Device firmware that wants to set DSC must first set BSY=1 in order to get
control of the bus, set the desired new status, and then clear BSY=0
AS FAST AS POSSIBLE. Some devices do this in hardware
(and it happens very quickly), and some do it in firmware (slowly).
-----------------
Now, part of the problem is that the processor speeds of devices and hosts
used to be closer to each other than now. Currently, hosts are many times
faster than the processors in many devices, so a host may read the STATUS
register many times during a transition. Transitions are not seen so much
on
slower hosts.
For our own ATAPI tape drives, I have seen this many, many times.
It happens less frequently when hardware does the transition, and
when the host is slow.
----------------------
Example:
Media access command that takes a long time:
Status Event
---------------------------
------------------------------------------------------------
RDY+DSC device is idle
RDY+DSC+BSY device receives command
(e.g. REWIND,
LOAD/UNLOAD, SPACE,
LOCATE,
etc.)
device decodes command
and starts
processing it.
RDY device logically disconnects
from bus
to allow host to
access other devices
during a long media
operation
(time passes)
device operation is
completed
RDY+BSY device 'steals' control of bus
RDY+DSC+BSY device changes status
RDY+DSC device is idle, and command is
complete
======================================================================
- Jim Hatfield
Sr. Firmware Engineer
Overland Data Inc.
----------------------------------------------------------------------------------------------------------------
On Wed, 11 Jul 2001 14:47:06 -0700, Larry Barras wrote:
>I've run into a number of devices (atapi usually) which transition
>from BSY=0 to BSY=1 on their own.
I have seen this problem on many ATAPI devices.
THIS IS ABSOLUTELY AND COMPLETELY ILLEGAL! Such devices should never
pass a vendor qualification test (period, no excuses)!
>This is a rather vexing situation
>for the host, who looks at the status register and sees the device is
>not busy, starts to issue a command based on that status which fails
>because the device decides to set busy on its own.
You are correct. Related to this are the ATAPI devices that decide
all on their own that a host is too slow during command execution and
just "reset" themselves. This too is absolutely and completely
illegal.
*** Hale Landis *** [EMAIL PROTECTED] ***
*** Niwot, CO USA *** www.ata-atapi.com ***
********************************************************************
Get it all in Overland's revolutionary new LibraryXpress Neo Series.
Visit us at CA World July 8 - 11, Orlando, FL booth #124 where you'll
find everything you always wanted in a tape library.
For more information on Neo:
http://www.overlanddata.com/mktg.nsf/lookup/lxn2000.pdf/$file/lxn2000.pdf
For more information on Overland:
http://www.overlanddata.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]
