linux/drivers/scsi/libfc, branch v3.6

[SCSI] libfc: fix sending REC after FCP_RESP is received

2012-07-20T07:58:56Z

This is exposed in the case the FCP_DATA frames somehow got lost and fc_fcp got the FCP_RSP, in fc_fcp_recv_resp(), since xfer_len is less than the expected_len it resets the the timer to wait to 2 more jiffies in case the data frames are already queued locally. However, for target does not support REC, it would just send RJT w/ ELS_RJT_UNSUP. The rec response handler thus only clears the rport flag for not doing REC later, but does not do fcp_io_complete() on the associated fsp. The fix is just check status of FCP_RSP being received already, i.e. using the FC_SRB_RCV_STATUS flag, in fc_fcp_timeout before start sending REC. We should have waited long enough if there is truely data frames queued locally. Signed-off-by: Yi Zou Tested-by: Ross Brattain Signed-off-by: Robert Love Signed-off-by: James Bottomley

[SCSI] libfc: fix retries with FDMI lport states

2012-07-20T07:58:56Z

The FC-GS-3 sepc requires to wait for least 3 times R_A_TOV per sec 4.6.1 "If the Requesting_CT does not receive a Response CT_IU from the Responding_CT within three times R_A_TOV, it shall consider this to be a protocol error." This means added four new states with management server could add significant delay with multiple retries on default 12 second timeout(3 * R_A_TOV), so instead just skip these states on very first timeout on any of these states to not stuck with states for such longer period. Signed-off-by: Vasu Dev Tested-by: Marcus Dennis Signed-off-by: Robert Love Signed-off-by: James Bottomley

[SCSI] libfc: don't exch_done() on invalid sequence ptr

2012-07-20T07:58:56Z

The lport_recv(), i.e., fc_lport_recv_req() may get called w/o the sequence ptr being set in fr_seq(), particularly in the case of vn2vn mode, this may happen if the passive fcp provider, e.g., tcm_fc, has not been registered yet. Signed-off-by: Yi Zou Tested-by: Ross Brattain Signed-off-by: Robert Love Signed-off-by: James Bottomley

[SCSI] libfc: add exch timer debug info

2012-07-20T07:58:55Z

Add exch timeout info to have debug log with exch timeout value to match with retries, also add debug info on exch timer cancel. Added common fc_exch_timer_cancel() func and grouped this along with fc_exch_timer_set() function, so that added debug code is not repeated. Signed-off-by: Vasu Dev Signed-off-by: Robert Love Signed-off-by: James Bottomley

[SCSI] libfc: update fcp and exch stats

2012-07-20T07:31:48Z

Updates newly added stats from fc_get_host_stats, added new function fc_exch_update_stats to update exches related stats from fc_exch.c by going thru internal ema_list elements. Signed-off-by: Vasu Dev Acked-by : Robert Love Tested-by: Ross Brattain Signed-off-by: James Bottomley

[SCSI] libfc: adds FCP failures stats

2012-07-20T07:31:48Z

Adds stats to track FCP pkt and frame alloc failure. Signed-off-by: Vasu Dev Acked-by : Robert Love Tested-by: Ross Brattain Signed-off-by: James Bottomley

[SCSI] libfc, fcoe, bnx2fc: cleanup fcoe_dev_stats

2012-07-20T07:31:47Z

The libfc is used by fcoe but fcoe agnostic, and therefore should not have any fcoe references. So renaming fcoe_dev_stats from libfc as its for fc_stats. After that libfc is fcoe string free except some strings for Open-FCoE.org. Signed-off-by: Vasu Dev Acked-by : Robert Love Tested-by: Ross Brattain Acked-by: Bhanu Prakash Gollapudi Signed-off-by: James Bottomley

Merge tag 'isci-for-3.5' into misc

2012-05-21T11:17:30Z

isci update for 3.5 1/ Rework remote-node-context (RNC) handling for proper management of the silicon state machine in error handling and hot-plug conditions. Further details below, suffice to say if the RNC is mismanaged the silicon state machines may lock up. 2/ Refactor the initialization code to be reused for suspend/resume support 3/ Miscellaneous bug fixes to address discovery issues and hardware compatibility. RNC rework details from Jeff Skirvin: In the controller, devices as they appear on a SAS domain (or direct-attached SATA devices) are represented by memory structures known as "Remote Node Contexts" (RNCs). These structures are transferred from main memory to the controller using a set of register commands; these commands include setting up the context ("posting"), removing the context ("invalidating"), and commands to control the scheduling of commands and connections to that remote device ("suspensions" and "resumptions"). There is a similar path to control RNC scheduling from the protocol engine, which interprets the results of command and data transmission and reception. In general, the controller chooses among non-suspended RNCs to find one that has work requiring scheduling the transmission of command and data frames to a target. Likewise, when a target tries to return data back to the initiator, the state of the RNC is used by the controller to determine how to treat the incoming request. As an example, if the RNC is in the state "TX/RX Suspended", incoming SSP connection requests from the target will be rejected by the controller hardware. When an RNC is "TX Suspended", it will not be selected by the controller hardware to start outgoing command or data operations (with certain priority-based exceptions). As mentioned above, there are two sources for management of the RNC states: commands from driver software, and the result of transmission and reception conditions of commands and data signaled by the controller hardware. As an example of the latter, if an outgoing SSP command ends with a OPEN_REJECT(BAD_DESTINATION) status, the RNC state will transition to the "TX Suspended" state, and this is signaled by the controller hardware in the status to the completion of the pending command as well as signaled in a controller hardware event. Examples of the former are included in the patch changelogs. Driver software is required to suspend the RNC in a "TX/RX Suspended" condition before any outstanding commands can be terminated. Failure to guarantee this can lead to a complete hardware hang condition. Earlier versions of the driver software did not guarantee that an RNC was correctly managed before I/O termination, and so operated in an unsafe way. Further, the driver performed unnecessary contortions to preserve the remote device command state and so was more complicated than it needed to be. A simplifying driver assumption is that once an I/O has entered the error handler path without having completed in the target, the requirement on the driver is that all use of the sas_task must end. Beyond that, recovery of operation is dependent on libsas and other components to reset, rediscover and reconfigure the device before normal operation can restart. In the driver, this simplifying assumption meant that the RNC management could be reduced to entry into the suspended state, terminating the targeted I/O request, and resuming the RNC as needed for device-specific management such as an SSP Abort Task or LUN Reset Management request.

[SCSI] libfc: flush lport worker after its disabled

2012-05-10T07:59:25Z

The lport could get timeout armed while its getting disabled, so flush lport worker after its disabled and ignore lport retry in that case instead of WARN_ON. [13192.936858] WARNING: at drivers/scsi/libfc/fc_lport.c:1573 fc_lport_timeout+0x53/0xa9 [libfc]() [13192.938026] Hardware name: Bochs [13192.938620] Modules linked in: fcoe libfcoe libfc scsi_transport_fc scsi_tgt fuse 8021q garp stp llc sunrpc ipv6 uinput microcode joydev pcspkr ixgbe e1000 i2c_piix4 i2c_core virtio_balloon dca mdio virtio_blk virtio_pci virtio_ring virtio floppy [last unloaded: speedstep_lib] [13192.942589] Pid: 23605, comm: kworker/0:6 Tainted: G W 3.2.0+ #71 [13192.943587] Call Trace: [13192.944052] [] warn_slowpath_common+0x85/0x9d [13192.944940] [] warn_slowpath_null+0x1a/0x1c [13192.945734] [] fc_lport_timeout+0x53/0xa9 [libfc] [13192.946665] [] process_one_work+0x20c/0x3ad [13192.947541] [] ? process_one_work+0x142/0x3ad [13192.948423] [] ? fc_lport_enter_ns+0x178/0x178 [libfc] [13192.949363] [] worker_thread+0xfd/0x181 [13192.950191] [] ? manage_workers.clone.15+0x173/0x173 [13192.951100] [] kthread+0xa4/0xac [13192.951755] [] kernel_thread_helper+0x4/0x10 [13192.952520] [] ? retint_restore_args+0x13/0x13 [13192.953398] [] ? __init_kthread_worker+0x5b/0x5b [13192.954278] [] ? gs_change+0x13/0x13 [13192.954911] ---[ end trace 9763213b95bbd803 ]--- Signed-off-by: Vasu Dev Acked-by: Neil Horman Tested-by: Ross Brattain Signed-off-by: Robert Love Signed-off-by: James Bottomley

[SCSI] libfc: update mfs boundry checking

2012-04-25T07:46:29Z

A previous commit changed the mfs checking to ensure the new mfs is less or equal to the mfs supported by the FCF. This doesn't work for BRDCM cards as they set an mfs of 2048 regardless of whether the switch returns a larger mfs. This patch validates the new mfs against the upper and lower spec defined boundries for a FCoE mfs. Signed-off-by: Vasu Dev Signed-off-by: Bhanu Prakash Gollapudi Signed-off-by: Robert Love Signed-off-by: James Bottomley