[comp.periphs.scsi] NCR-5386 behaviour

richard@moncam.co.uk (Richard Jordan) (10/03/90)

I am in the process of modifying a driver for the NCR 5386 SCSI
controller chip which I wrote a while ago. Among other things, I am
adding support for "disconnect/reconnect" operation. I have re-read
the "NCR 5386 SCSI Protocol Controller Data Sheet", but some details
of the behaviour are not clear to me.

The select command is only valid if the chip is in the disconnected
state. If the chip is reselected while it is actually executing a
select command, the select command is "forgotten" and a "reselected"
interrupt generated.  This I am quite happy with.

The way my driver is structured, there will always be a small window
between testing to see whether the chip is in the disconnected state,
and issuing the "select" command. This means that there is a small
chance that I will issue the command when the chip has just been
reselected.  Obviously I can mask the reselection interrupt so that it
doesn't occur in this window, but presumably this only changes when I
see the reselection interrupt, not when reselection actually occurs.

The manual contains apparently contradictory statements about this
situation.  The description of "Select w/ATN" states that...

    This command causes the chip to attempt to select a Target. It may
    only be used if the SPC is in the Disconnected state.  Any attempt
    to issue this command in another state will result in an invalid
    command interrupt.

However the section on "Invalid Commands" states the following...

    The microprocessor must never issue any interrupting type command
    when the chip is not expecting such a command. Unpredictable
    results will occur in this case.

The manual then lists a number of states in which the chip is not
expecting an interrupting command, one of which states...

    The chip is connected as an initiator, but the target has not yet
    requested an information transfer.

This is exactly the state which I would be in immediately after
reselection.  Does anybody know how the chip actually behaves under
these conditions?  An "invalid command interrupt" I can work with,
"unpredictable results" I can't!.