On Wed, 2011-02-02 at 01:24 -0800, Mike Christie wrote: > On 01/17/2011 06:37 PM, Bhanu Gollapudi wrote: > >> > >> Are you sending a abort when a lun or target reset has been successfully > >> completed? Does your hw need the reset? SCSI spec wise the lun or target > >> reset will take care of the scsi commands on its side, so there is no > >> need to send an abort. > > > > It is better to send ABTS on all the outstanding IOs after issuing > > lun/target reset. targets may take care of scsi commands on its side. > > But the commands on the flight may have to be aborted. This is as per > > the FCP-4 spec in "Table 8 - Clearing effects of initiator FCP-Port > > actions" :- > > "Exchanges are cleared internally within the target FCP_Port, but open > > FCP Sequences shall be individually aborted by the initiator FCP_Port > > using ABTS-LS that also has the effect of aborting the associated FCP > > Exchange. See 12.3." > > Ughh. I must have misread that before. I think libfc is broken then. > > > > >> > >>> +} > >>> + > >>> +static int bnx2fc_map_sg(struct bnx2fc_cmd *io_req) > >>> +{ > >>> + struct bnx2fc_hba *hba = io_req->port->hba; > >>> + struct scsi_cmnd *sc = io_req->sc_cmd; > >>> + struct fcoe_bd_ctx *bd = io_req->bd_tbl->bd_tbl; > >>> + struct scatterlist *sg; > >>> + int byte_count = 0; > >>> + int sg_count = 0; > >>> + int bd_count = 0; > >>> + int sg_frags; > >>> + unsigned int sg_len; > >>> + u64 addr; > >>> + int i; > >>> + > >>> + sg = scsi_sglist(sc); > >>> + sg_count = pci_map_sg(hba->pcidev, sg, scsi_sg_count(sc), > >>> + sc->sc_data_direction); > >> > >> > >> I think you could also use scsi_dma_map instead. > >> > >> And if not I think we are supposed to be using the dma functions instead > >> of the pci ones. > > > > OK. I can use dma_map_sg() intead. But this function inturn calls > > pci_map_sg(). Is there any reason why we cannot directly call it? > > > > People like abstractions. I guess we are trying to move to the dma > functions. If you had some other bus then the dma wrappers would hide that. We handles this anyway. > > > > > >> > >> > >> > >>> + > >>> +static int bnx2fc_post_io_req(struct bnx2fc_rport *tgt, > >>> + struct bnx2fc_cmd *io_req) > >>> +{ > >> > >> > >>> + > >>> + /* Time IO req */ > >>> + bnx2fc_cmd_timer_set(io_req, BNX2FC_IO_TIMEOUT); > >> > >> Hard coding this does not seem right becuase the scsi cmnd timer can be > >> set through sysfs. It could be set lower than this which makes it > >> useless. I think libfc is dropping their similar timer like this and > >> just relying on the scsi_cmnd timer now (I think they just do the rec > >> but not the abort now). > > > > if it is a lower value, eh_abort_handler() code kicks in. Default scsi > > cmd timer is 60 secs, which may be too long to wait to sends an ABTS. > > > Do not work around scsi-ml and the classes. If really useful it seems > this should be in libfc or the fc class so all drivers do the same thing > if capable. > > Also if the abort fails you still have to wait for the scsi eh to run. > > And if the the scsi timer is too long why don't you just set it lower? > > Also, it is 30 secs by default in the kernel, but some distro's have > udev's that set it to 60. On 02/02/2011 03:24 AM, Mike Christie wrote: > > > > Also if the abort fails you still have to wait for the scsi eh to > run. > > > > Actually you do not have to wait for the scsi eh to run, right. It > looks > like bnx2fc would log out the port, which ends up calling > fc_remote_port_delete and that would cause the fc timed out function > to > return BLK_EH_RESET_TIMER to prevent the scsi eh from running. Is > that > right? That type of eh strategy behavior seems like something you > want > to sync up with libfc or the fc class so all drivers do something > similar. As per FCP-4, if the ABTS times out, we will have to explicitly LOGO the target and relogin back. If we rely on 60 sec eh_abort_handler, and if ABTS times out, SCSI error handling will go to LUN RESET, TGT reset path, which is a generic error handling than transport specific error handling. -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html