Mike Christie wrote: >>> And actually are we not supposed to call the upper layers if there is an >>> abort in progress in csae we get a recovery qualifier. >>> >> The fc_exch.c does recovery qualifier processing but we should call >> fc_fcp.c for abort response to sync exch done issue describe above. >> I also suggested in point 2 below to add call to upper layer for >> abort response as I said before also. >> > > I did not mean to call it at all :) My fault it was not clear. My > question was that I thought fcp4 or fc-fs said that once we send an > abort we should not process any other sequences, and we have to wait for > the abort response to see if there was a recovery qual before we can > process the normal IO. So I just mean that for those normal IO sequences > are we supposed to be calling the ep->resp function when a abts is in > flight?
I think I merged the recovery qual dropping of data with fcp's. If we get a recovery qual we should drop seqeunces that the recovery qual told us too right? This has nothing to do with sequences that are sent before we got the abort response. For dropping frames before we get an abort response I found this in fcp4 12.3.2 it says: Following the transmission of transmission of ABTS, any Device_Data Frames received for this Exchange shall be discarded until the BA_ACC with “Last Sequence of Exchange” bit set to one is received from the target FCP_Port. In fc_fcp_recv_data we actually drop the data and do not read it in, but we are supposed to be dropping all date ones like FC_RCTL_DD_DATA_DESC and FC_RCTL_DD_CMD_STATUS related ones too right? We drop this until we get the BA_ACC from the abort correct? I also did a fix so that we no longer can return DID_OK if we aborted a command, and fc_fcp_recv_data dropped data. I will extend it so handles these other cases if needed. _______________________________________________ devel mailing list [email protected] http://www.open-fcoe.org/mailman/listinfo/devel
