The nice thing about iscsi is that the RFC is only a 200 pages (less if
you do not count the indexes and graphs). For libfc, I have been trying
to figure out what is going wrong with the abort transmission and I
think I found in the depths of fc-fs.
In fc_fcp.c, we seem to only call exch_done if sp->seq_ptr is set.
However in fc_seq_exch_abort we seem to want to start a new sequence for
the abort. I think if there is an open sequence are we supposed to send
the abort with the SEQ_ID and SEQ_CNT like in 13.3.2.3.2 of fc-ls:
If the last Sequence is open and the Sequence Initiator of the last
Sequence transmits the ABTS frame,
the SEQ_ID of this ABTS frame shall match the SEQ_ID of the last
Sequence transmitted by the last
Sequence Initiator. The SEQ_CNT of the ABTS frame shall be one greater
than the SEQ_CNT of the last
Data frame transmitted for this last Sequence.
Instead it looks like we use the next SEQ_ID and the SEQ_CNT looks like
it will be 0.
So I think the protocol bits are messed up, but I think we have a bug in
the code in the implementation. Because we are trying to use a new
sequence by reusing ep->seq, it seems like if ep->seq was being used for
a seq then we are going to hit the warn on because the state is not yet
completed:
struct fc_seq *fc_seq_start_next(struct fc_seq *sp)
{
struct fc_exch *ep = fc_seq_exch(sp);
spin_lock_bh(&ep->ex_lock);
WARN_ON((ep->esb_stat & ESB_ST_COMPLETE) != 0);
Is that right?
Do we want to:
1. if the seqeunce is open then send the abort on the same sequence?
2. if the sequence is not open then we can reuse the ep->seq like how we
are today by calling fc_seq_start_next?
_______________________________________________
devel mailing list
[email protected]
http://www.open-fcoe.org/mailman/listinfo/devel
