SCSI firmware question

John_F._Walsh.Wbst129 at xerox.com John_F._Walsh.Wbst129 at xerox.com
Tue Jun 20 12:24:28 PDT 1995


I am a SCSI firmware programmer developing an external SCSI-2 (16 bit, 10MHz)
peripheral.  A customer may intentionally or unintentionally cycle the power on
my device and I'm trying to figure out how to resume operation gracefully.

Based on the SCSI-2 spec., my plan was to send WDTR and SDTR messages after I
have been selected for the first time after my device was powered on (if the
host didn't send me WDTR and SDTR messages first).  My plan was to go to
MESSAGE IN phase after SELECTION and after the MESSAGE OUT phase if there is
one, but before the COMMAND phase.

My Zeos Pentium 90 with an AMD SCSI chip hangs waiting for the ACK of the first
byte of the WDTR during the MESSAGE IN phase if I go to MESSAGE IN before the
COMMAND phase.  This computer is also the first that I've seen that does a
select without attention, but I believe that's a legal exception case.

This leaves me with two questions:
1.	Is there a commonly accepted graceful exit from the above hang
condition?  I can detect the condition with timeouts, but it's not clear what I
should do then.  I could either go to a bus free phase and wait to be
reselected, or I could go to COMMAND phase and hope that the message byte I
sent wasn't latched into the initiator's fifo.  Either way, I'd have to make a
guess at what the last negotiated speed and width was and act accordingly.
That wouldn't be very robust.  I could also trip a SCSI bus reset, but that
seems very ill advised.
2.	Is there another way around this problem (a fast/wide SCSI peripheral's
power being cycled independantly of the host's power), short of telling users
simply not to turn off the device independently of the host?  That directive
seems reasonable when you talk about the external disk drive on a Unix system,
but it's sure to be a customer dissatisfier in my case.

Please respond back to me directly.  I am not on the reflector.  My address is:
	walsh.wbst129 at xerox.com

Thanks,
John Walsh




More information about the T10 mailing list