dual port reset and mode parameters

Sheldon Kolansky sk at cringle.westford.ccur.com
Fri Aug 19 06:37:04 PDT 1994


Tom,

I work at Concurrent Computer and have a vested interest in dual port
as we use it in our systems.

> For mode parameters, a very literal reading would appear to require
> that the port not reset revert to saved (or default) mode parameters
> since it's allowed to return a UNIT ATTENTION but I can also argue
> that the port which was reset should return to current mode
> parameters so that the port not reset isn't affected by the reset.

I think the intention is to not change the mode parameters on either
port, but especially not on the port being reset.  That system has now
picked up the load of the first system failing, and any extra commands
it would have to do to reset the parameters would affect the system performance.

> 1.  Does the port being reset remain in its current operating mode (to
> leave the other port unchanged) as SIP appears to state?  If so, after
> a reset should the port also report "changed operating definition"
> since the port is not in its power on operating definition?

Yes and yes.

> 2.  How should mode parameters be handled?  Go back to power on values
> or leave current parameters in the port being reset?  If current
> parameters are retained should the port being reset generate a "mode
> parameters changed" unit attention to tell the initiator it hasn't
> gone back to any power on values the initiator may be aware of?

I think it would be preferable to go to power-on reset values, but in
any case it is imperative that the mode pages on the port not reset 
not be changed.

> I think some changed wording in SIP is in order, especially since
> operating modes and mode parameters are handled differently, while I
> think they should be handled consistently.

Given the current industry (lack of) dual port support and the necessary
capabilities being available in fibre channel and ssa, I don't think that 
lots of time should be spent on fine tuning the spec wording.

Sheldon Kolansky




More information about the T10 mailing list