#
347894 |
|
16-May-2019 |
ken |
MFC r345008: ------------------------------------------------------------------------ r345008 | ken | 2019-03-11 10:21:14 -0400 (Mon, 11 Mar 2019) | 59 lines
Fix CRN resets in the isp(4) driver in certain situations.
The Command Reference Number (CRN) is part of the FC-Tape features that we enable when talking to tape drives. It starts at 1, and goes to 255 and wraps around to 1. There are a number of reset type conditions that result in the CRN getting reset to 1. These are detailed in section 4.10 (table 8) of the FCP-4r02b specification.
One of the conditions is when a PRLI (Process Login) is sent by the initiator, and the Establish Image Pair bit is set in Word 0 of the PRLI.
Previously, the isp(4) driver core sent a notification via isp_async() that the target had changed or stayed in place, but there was no indication of whether a PRLI was sent and whether the Establish Image Pair bit was set.
The result of this was that in some situations, notably switching back and forth between a direct connection and a switch connection to a tape drive, the isp(4) driver would fail to reset the CRN in situations that require it according to the spec. When the CRN isn't reset in a situation that requires it, the tape drive then rejects every subsequent command that is sent to the drive. It is assuming that the commands are being sent out of order.
So, modify the isp(4) driver to include Word 0 of the PRLI command when it sends isp_async() notifications of target changes. Look at the Establish Image Pair bit, and reset the CRN if that bit is set.
With this change, I am able to switch a tape drive back and forth between a direct connection and a switch connection, and the isp(4) driver resets the CRN when it should.
sys/dev/isp_stds.h: Add bit definitions for PRLI Word 0.
sys/dev/ispmbox.h: Add PRLI Word 0 to the port database type, isp_pdb_t.
sys/dev/ispvar.h Add PRLI Word 0 to fcportdb_t.
sys/dev/isp.c: Populate the new prli_word0 parameter in the port database.
In isp_pdb_add_update(), add a check to see if the Establish Image Pair bit is set in PRLI Word 0. If it is, then that is an additional reason to create a change notification.
sys/dev/isp_freebsd.c: In isp_async(), if the device changed or stayed, look at PRLI Word 0 to see if the Establish Image Pair bit is set. If it is, reset the CRN if we haven't already.
Sponsored by: Spectra Logic Differential Revision: https://reviews.freebsd.org/D19472
------------------------------------------------------------------------
|
#
331722 |
|
29-Mar-2018 |
eadler |
Revert r330897:
This was intended to be a non-functional change. It wasn't. The commit message was thus wrong. In addition it broke arm, and merged crypto related code.
Revert with prejudice.
This revert skips files touched in r316370 since that commit was since MFCed. This revert also skips files that require $FreeBSD$ property changes.
Thank you to those who helped me get out of this mess including but not limited to gonzo, kevans, rgrimes.
Requested by: gjb (re)
|
#
330897 |
|
14-Mar-2018 |
eadler |
Partial merge of the SPDX changes
These changes are incomplete but are making it difficult to determine what other changes can/should be merged.
No objections from: pfg
|
#
302408 |
|
07-Jul-2016 |
gjb |
Copy head@r302406 to stable/11 as part of the 11.0-RELEASE cycle. Prune svn:mergeinfo from the new branch, as nothing has been merged here.
Additional commits post-branch will follow.
Approved by: re (implicit) Sponsored by: The FreeBSD Foundation |
#
297751 |
|
09-Apr-2016 |
mav |
Register symbolic port/node names in FC name server.
This is cosmetics that simplifies identification of new ports on FC switch.
It would be good to use target name from CTL here instead of hostname, but it is not passed here through CAM now.
MFC after: 2 weeks
|
#
291000 |
|
17-Nov-2015 |
mav |
Register our FC4 Features in SNS.
|
#
289843 |
|
23-Oct-2015 |
mav |
Add partial support for QUERY TMF to CAM and isp(4).
This change allows to decode respective functions in isp(4) in target mode and pass them through CAM to CTL. Unfortunately neither CAM nor isp(4) support returning response info for those task management functions now.
On the other side I just have no initiator to test this functionality.
|
#
238869 |
|
28-Jul-2012 |
mjacob |
----------- MISC CHANGES
Add a new async event- ISP_TARGET_NOTIFY_ACK, that will guarantee eventual delivery of a NOTIFY ACK. This is tons better than just ignoring the return from isp_notify_ack and hoping for the best.
Clean up the lower level lun enable code to be a bit more sensible.
Fix a botch in isp_endcmd which was messing up the sense data.
Fix notify ack for SRR to use a sensible error code in the case of a reject.
Clean up and make clear what kind of firmware we've loaded and what capabilities it has. ----------- FULL (252 byte) SENSE DATA
In CTIOs for the ISP, there's only a limimted amount of space to load SENSE DATA for associated CHECK CONDITIONS (24 or 26 bytes). This makes it difficult to send full SENSE DATA that can be up to 252 bytes.
Implement MODE 2 responses which have us build the FCP Response in system memory which the ISP will put onto the wire directly.
On the initiator side, the same problem occurs in that a command status response only has a limited amount of space for SENSE DATA. This data is supplemented by status continuation responses that the ISP pushes onto the response queue after the status response. We now pull them all together so that full sense data can be returned to the periph driver.
This is supported on 23XX, 24XX and 25XX cards.
This is also preparation for doing >16 byte CDBs.
----------- FC TAPE
Implement full FC-TAPE on both initiator and target mode side. This capability is driven by firmware loaded, board type, board NVRAM settings, or hint configuration options to enable or disable. This is supported for 23XX, 24XX and 25XX cards.
On the initiator side, we pretty much just have to generate a command reference number for each command we send out. This is FCP-4 compliant in that we do this per ITL nexus to generate the allowed 1 thru 255 CRN.
In order to support the target side of FC-TAPE, we now pay attention to more of the PRLI word 3 parameters which will tell us whether an initiator wants confirmed responses. While we're at it, we'll pay attention to the initiator view too and report it.
On sending back CTIOs, we will notice whether the initiator wants confirmed responses and we'll set up flags to do so.
If a response or data frame is lost the initiator sends us an SRR (Sequence Retransmit Request) ELS which shows up as an SRR notify and all outstanding CTIOs are nuked with SRR Received status. The SRR notify contains the offset that the initiator wants us to restart the data transfer from or to retransmit the response frame.
If the ISP driver still has the CCB around for which the data segment or response applies, it will retransmit.
However, we typically don't know about a lost data frame until we send the FCP Response and the initiator totes up counters for data moved and notices missing segments. In this case we've already completed the data CCBs already and sent themn back up to the periph driver. Because there's no really clean mechanism yet in CAM to handle this, a hack has been put into place to complete the CTIO CCB with the CAM_MESSAGE_RECV status which will have a MODIFY DATA POINTER extended message in it. The internal ISP target groks this and ctl(8) will be modified to deal with this as well.
At any rate, the data is retransmitted and an an FCP response is sent. The whole point here is to successfully complete a command so that you don't have to depend on ULP (SCSI) to have to recover, which in the case of tape is not really possible (hence the name FC-TAPE).
Sponsored by: Spectralogic MFC after: 1 month
|
#
197373 |
|
20-Sep-2009 |
mjacob |
(semiforced commit to add comment missed in last delta) Add a maximum response length for FCP RSPNS IUs.
Clarify some of the FC option words for setting parameters and try and disable automatic PRLI when in target mode- this should correct some cases of N-port topologies with 23XX cards where we put out an illegal PRLI (in target mode only we're not supposed to put out a PRLI).
|
#
197372 |
|
20-Sep-2009 |
mjacob |
Remove file unused in freebsd.
|
#
196008 |
|
31-Jul-2009 |
mjacob |
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs.
Target mode support has received some serious attention to make it more usable and stable.
Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place.
Further refinement and better support for NP-IV (N-port Virtualization) is now in place.
Code for release prior to RELENG_7 has been stripped away for code clarity.
Sponsored by: Copan Systems
Reviewed by: scottl, ken, jung-uk kim Approved by: re
|
#
167403 |
|
10-Mar-2007 |
mjacob |
Fix some stupid copyright mistakes that have been there for quite some time.
|
#
164370 |
|
18-Nov-2006 |
mjacob |
Make the SAN login/logout stuff more common between different chipsets and provied an isp_control entry point so that the outer layers can do PLOGI/LOGO explicitly. Add MS IOCB support. This completes the cycle for base support for SMI-S.
|
#
164272 |
|
14-Nov-2006 |
mjacob |
Push things closer to path failover by implementing loop down and gone device timers and zombie state entries. There are tunables that can be used to select a number of parameters.
loop_down_limit - how long to wait for loop to come back up before declaring all devices dead (default 300 seconds)
gone_device_time- how long to wait for a device that has appeared to leave the loop or fabric to reappear (default 30 seconds)
Internal tunables include (which should be externalized):
quick_boot_time- how long to wait when booting for loop to come up
change_is_bad- whether or not to accept devices with the same WWNN/WWPN that reappear at a different PortID as being the 'same' device.
Keen students of some of the subtle issues here will ask how one can keep devices from being re-accepted at all (the answer is to set a gone_device_time to zero- that effectively would be the same thing).
|
#
163899 |
|
02-Nov-2006 |
mjacob |
Add 4Gb (24XX) support and lay the foundation for a lot of new stuff.
|