FreeBSD source tree https://cgit-dev.freebsd.org/src/atom?h=releng%2F10.2 2015-02-03T22:49:12Z 2015-02-03T22:49:12Z Kenneth D. Merry ken@FreeBSD.org 2015-02-03T22:49:12Z urn:sha1:1ae13775fa45090afda2d0242d363b8d011565fd r276839, r276842, r277513, r277514, r277515 ------------------------------------------------------------------------ r276839 | ken | 2015-01-08 10:41:28 -0700 (Thu, 08 Jan 2015) | 49 lines Fix Fibre Channel Command Reference Number handling in the isp(4) driver. The Command Reference Number is used for precise delivery of commands, and is part of the FC-Tape functionality set. (This is only enabled for devices that support precise delivery of commands.) It is an 8-bit unsigned number that increments from 1 to 255. The commands sent by the initiator must be processed by the target in CRN order if the CRN is non-zero. There are certain scenarios where the Command Reference Number sequence needs to be reset. When the target is power cycled, for instance, the initiator needs to reset the CRN to 1. The initiator will know this because it will see a LIP (when directly connected) or get a logout/login event (when connected to a switch). The isp(4) driver was not resetting the CRN when a target went away and came back. When it saw the target again after a power cycle, it would continue the CRN sequence where it left off. The target would ignore the command because the CRN sequence is supposed to be reset to 1 after a power cycle or other similar event. The symptom that the user would see is that there would be lots of aborted INQUIRY commands after a tape library was power cycled, and the library would fail to probe. The INQUIRY commands were being ignored by the tape drive due to the CRN issue mentioned above. isp_freebsd.c: Add a new function, isp_fcp_reset_crn(). This will reset all of the CRNs for a given port, or the CRNs for all LUNs on a target. Reset the CRNs for all targets on a port when we get a LIP, loop reset, or loop down event. Reset the CRN for a particular target when it arrives, is changed or departs. This is less precise behavior than the clearing behavior specified in the FCP-4 spec (which says that it should be reset for PRLI, PRLO, PLOGI and LOGO), but this is the level of information we have here. If this is insufficient, then we will need to add more precise notification from the lower level isp(4) code. isp_freebsd.h: Add a prototype for isp_fcp_reset_crn(). Sponsored by: Spectra Logic MFC after: 1 week ------------------------------------------------------------------------ r276842 | ken | 2015-01-08 10:51:12 -0700 (Thu, 08 Jan 2015) | 44 lines Close a race in the isp(4) driver that caused devices to disappear and not automatically come back if they were gone for a short period of time. The isp(4) driver has a 30 second gone device timer that gets activated whenever a device goes away. If the device comes back before the timer expires, we don't send a notification to CAM that it has gone away. If, however, there is a command sent to the device while it is gone and before it comes back, the isp(4) driver sends the command back with CAM_SEL_TIMEOUT status. CAM responds to the CAM_SEL_TIMEOUT status by removing the device. In the case where a device comes back within the 30 second gone device timer window, though, we weren't telling CAM the device came back. So, fix this by tracking whether we have told CAM the device is gone, and if we have, send a rescan if it comes back within the 30 second window. ispvar.h: In the fcportdb_t structure, add a new bitfield, reported_gone. This gets set whenever we return a command with CAM_SEL_TIMEOUT status on a Fibre Channel device. isp_freebsd.c: In isp_done(), if we're sending CAM_SEL_TIMEOUT for for a command sent to a FC device, set the reported_gone bit. In isp_async(), in the ISPASYNC_DEV_STAYED case, rescan the device in question if it is mapped to a target ID and has been reported gone. In isp_make_here(), take a port database entry argument, and clear the reported_gone bit when we send a rescan to CAM. In isp_make_gone(), take a port database entry as an argument, and set the reported_gone bit when we send an async event telling CAM consumers that the device is gone. Sponsored by: Spectra Logic MFC after: 1 week ------------------------------------------------------------------------ r277514 | will | 2015-01-21 13:27:11 -0700 (Wed, 21 Jan 2015) | 18 lines Force commit to record the correct log for r277513. If the user sends an XPT_RESET_DEV CCB, make sure to reset the Fibre Channel Command Reference Number if we're running on a FC controller. We send a SCSI Target Reset when we get this CCB, and as a result need to reset the CRN to 1 on the next command. isp_freebsd.c: In the XPT_RESET_DEV implementation in isp_action(), reset the CRN if we're on a FC controller. Submitted by: ken MFC after: 1 week Sponsored by: Spectra Logic MFSpectraBSD: 1112787 on 2015/01/15 ------------------------------------------------------------------------ r277515 | will | 2015-01-21 13:32:36 -0700 (Wed, 21 Jan 2015) | 25 lines Fix SCSI status byte reporting on 4Gb and 8Gb Qlogic boards. The newer boards don't have the response field that indicates whether the SCSI status byte is present. You have to just look to see whether it is non-zero. The code was looking to see whether the sense length was valid before propagating the SCSI status byte (and sense information) up the stack. With a status like Reservation Conflict, there is no sense information, only the SCSI status byte. So it wasn't getting correctly returned. isp.c: In isp_intr(), if we are on a 2400 or 2500 type board and get a response, look at the actual contents of the SCSI status value and set the RQSF_GOT_STATUS flag accordingly so that return any SCSI status value we get. The RQSF_GOT_SENSE flag will get set later on if there is actual sense information returned. Submitted by: ken MFC after: 1 week Sponsored by: Spectra Logic MFSpectraBSD: 1112791 on 2015/01/15 ------------------------------------------------------------------------ Sponsored by: Spectra Logic 2014-01-05T22:38:44Z Alexander Motin mav@FreeBSD.org 2014-01-05T22:38:44Z urn:sha1:ad9159995abf53c1ed7c25db29d7d4a26424158c Optimize isp(4) to reduce CPU usage, especially in target mode: - Remove two excessive and slow register reads from isp_intr(). Instead of rereading value every time, assume that registers contain what we have written there. - Avoid sequential search through 4096 array elements when looking for command tag. Use hash of lists to store active tags separately from free ones and so greatly speedup the searches. 2012-07-28T20:06:29Z Matt Jacob mjacob@FreeBSD.org 2012-07-28T20:06:29Z urn:sha1:387d8239fb5e7a6023d4627b3bc0e3afbf22af03 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 2012-06-24T17:30:54Z Matt Jacob mjacob@FreeBSD.org 2012-06-24T17:30:54Z urn:sha1:9e7d423d23c6e3ed8d9b55ff602843eb79fc1825 not by some hint setting. Do more preparations for FC-Tape. Clean up resource counting for 24XX or later chipsets so we find out after EXEC_FIRMWARE what is actually supported. Set target mode exchange count based upon whether or not we are supporting simultaneous target/initiator mode. Clean up some old (pre-24XX) xfwoption and zfwoption issues. Sponsored by: Spectralogic MFC after: 3 days 2012-06-17T21:39:40Z Matt Jacob mjacob@FreeBSD.org 2012-06-17T21:39:40Z urn:sha1:ad0ab753798293823ae6224a8c08d6707ee25c55 and crosschecks against firmware documentation. We now check and report FC firmware attributes and at least are now prepared for the upper 48 bits of f/w attributes (which are probably for the 8100 or later cards). This involed changing how inbits and outbits are calculated for varios commands, hopefully clearer and cleaner. This also caused me to clean up the actual mailbox register usage. Finally, we are now unconditionally using a CRN for initiator mode. A longstanding issue with the 2400/2500 is that they do *not* support a "Prefer PTP followed by loop", which explains why enabling that caused the f/w to crash. A slightly more invasive change is to let the firmware load entirely drive whether multi_id support is enabled or not. Sponsored by: Spectralogic MFC after: 1 week 2012-06-01T23:29:48Z Matt Jacob mjacob@FreeBSD.org 2012-06-01T23:29:48Z urn:sha1:e2873b76a677769b047c86f6acbfbb58ef346c67 Make the default role NONE if target mode is selected. This allows ctl(8) to switch to/from target mode via knob settings. If we default to role 'none', this causes a reset of the 24XX f/w which then causes initiators to wake up and notice when we come online. Reviewed by: kdm MFC after: 2 weeks Sponsored by: Spectralogic 2011-08-13T23:34:17Z Matt Jacob mjacob@FreeBSD.org 2011-08-13T23:34:17Z urn:sha1:e95725cb76c16fd743dbe8dc1c237aa678f9ba96 We also revive loop down freezes. We also externaliz within isp isp_prt_endcmd so something outside the core module can print something about a command completing. Also some work in progress to assist in handling timed out commands better. Partially Sponsored by: Panasas Approved by: re (kib) MFC after: 1 month 2011-02-28T15:58:30Z Matt Jacob mjacob@FreeBSD.org 2011-02-28T15:58:30Z urn:sha1:898899d9ddbd15925a9d3c6b1da0d426dbc6351b a macro for minima. 2011-02-14T21:50:51Z Marius Strobl marius@FreeBSD.org 2011-02-14T21:50:51Z urn:sha1:37bb79f1737be635aaa02e0401993e70718a3925 - Allocate coherent DMA memory for the request/response queue area and and the FC scratch area. These changes allow isp(4) to work properly on sparc64 with usage of the IOMMU streaming buffers enabled. Approved by: mjacob MFC after: 2 weeks 2010-05-15T20:26:10Z Matt Jacob mjacob@FreeBSD.org 2010-05-15T20:26:10Z urn:sha1:427fa8f9fe169e7fb827dc835710a250d0c775a4 the zombie device timeout code and the loop down time code and the fabric hysteresis code. MFC after: 1 week Sponsored By: Panasas