** This is the quasi-official and semi-temporary T13 email list server. **
Larry,
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.
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!)
Take care,
MKE.
-----Original Message-----
From: Larry Barras [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, July 11, 2001 2:47 PM
To: [EMAIL PROTECTED]
Subject: [temp t13] Are devices allowed to go busy on their own?
** This is the quasi-official and semi-temporary T13 email list server. **
I've run into a number of devices (atapi usually) which transition
from BSY=0 to BSY=1 on their own. 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.
Literally a trace with an extra status register read in one case
looked like this:
{ following a reset which ended with a status=0 }
...
RD Alt. STATUS = 00 <-- host starting a command
WR Dev select = xx <-- whatever device
RD Alt. STATUS = 00 <-- not busy
..... write out the taskfile registers for packet command
.... fails to respond.
In order to debug the problem, an extra status read was inserted in
the code which revealed the device transitioning to busy on its own.
...
RD Alt. STATUS = 00 <-- host starting a command
WR Dev select = xx <-- whatever device
RD Alt. STATUS = 00 <-- not busy
{ rd alt status = BSY } <-- inserted for debugging purposes
In this case, the time delta was substantially longer than the
required 400ns after selecting a device, so it wasn't a matter of a
host looking too "soon" after writing the device selection register.
I've seen a number of atapi drives lately which transition between
busy and not busy states on their own, particular if media is
inserted or if media is present following a reset. As you might
imagine, this is troublesome for a host who may look and say the
drive is ready, only to find that really isn't a short time later,
even though no command was issued. This was the worse case, it's
usually caught by the first status check prior to writing the
selection register. That in itself is bad, because the command
attempt has failed due to a busy drive. A device driver that sees a
busy device when it has no reason to be busy will likely decide the
device has gone bad or hung and reset it. Often, the reset command
will set the whole thing back in motion again, unless it happens to
fall outside of the timing to get trapped on this "self-busy"
transition.
--
---------------------
"Anything you CAN control you MUST control."
Wendy Carlos
---------------------
Larry Barras
Apple Computer Inc.
1 Infinite Loop
MS: 306-2TC
Cupertino, CA 95014
(408) 974-3220
--
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]
--
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]
