summaryrefslogtreecommitdiffstats
path: root/sys/dev/isp/isp.c
Commit message (Collapse)AuthorAgeFilesLines
...
* MFC r290118: Change the way how target mode is enabled on 23xx chips.mav2015-11-301-1/+1
| | | | | Without docs I am not completely sure about this, but on my tests new method works better then previous, at least with our latest firmware.
* MFC r290104: Improve/fix loop scanning routine.mav2015-11-301-64/+117
| | | | | | | | | | | | For the most of chips (except anscient ones) port handlers have no relation to port IDs. In such situation old code scanning first 125 handlers was quite naive. Instead of doing that, send to chip single request to get full list of port handlers available on specific virtual port and scan only them. Old code had problems with case of several virtual ports enabled, when port handlers allocated from global address space could easily go above 125. This change was successfully tested on 23xx, 24xx and 25xx chips in loop mode with 4 virtual initiator ports, each seing 50 virtual target ports.
* MFC r290054: Reimplement next port handle generation.mav2015-11-131-57/+43
| | | | | For some reason port handles should be allocated from HBA-global space, while old code was not very specific, mixing per-HBA and per-VP logic.
* MFC r290018: Reimplement enable and implement disable of virtual ports.mav2015-11-131-4/+9
| | | | | | | | | | Now on 24xx and above chips it is really possible to simulate several virtual FC ports with single physical one. For example, it allows to configure several targets in ctl.conf, assign each of them to separate virtual port, and let user to control access to them with switch zoning. I still doubt that all problems are solved there, but at now it passes at least basic tests.
* MFC r289937: Try to keep Loop IDs persistent across chip reinits.mav2015-11-131-37/+31
|
* MFC r289933, r289939: Improve Port Database Changed handling and reporting.mav2015-11-131-7/+7
|
* MFC r289930: Formalize/unify chip (re-)inits.mav2015-11-131-26/+27
|
* MFC r289890: Skip reserved IP Broadcast handle from using.mav2015-11-131-3/+3
|
* MFC r289882: Add PIM_EXTLUNS support to isp(4) driver.mav2015-11-131-13/+49
| | | | | | Now 24xx and above chips support full 8-byte LUN address space. Older FC chips may support up to 16K LUNs when firmware allows. Tested in both initiator and target modes for 23xx, 24xx and 25xx.
* MFC r289875: Decode few more response info codes.mav2015-11-131-13/+21
| | | | Though CAM still does not send any requests that would require those.
* MFC r289812, r289852: Some polishing and unification in ISR code.mav2015-11-131-30/+13
|
* MFC r289681: Some more defines and polishing for INIT_FIRMWARE.mav2015-11-131-13/+22
|
* MFC r289622: Zero mbox[1] for INIT_FIRMWARE to fix version 7.3 firmware.mav2015-11-131-2/+4
| | | | While there, add new fields to isp_icb_2400_t structure.
* MFC r289620: Decode more firmware attributes.mav2015-11-131-2/+55
|
* MFC r285600: MULTI_ID supported does not mean it is used.mav2015-10-051-1/+1
|
* MFC r285459: Unify port database use for target and initiator roles.mav2015-10-051-143/+73
| | | | | Aside from cleaner and more consistent code, this allows ports to be both target and initiator same time, and easily switch from any role to any.
* MFC r285154: Remove extra level of target ID indirection (isp_dev_map).mav2015-10-051-52/+27
| | | | | | | FreeBSD never had limitation on number of target IDs, and there is no any other requirement to allocate them densely. Since slots of port database already populated just sequentially, there is no much need for another indirection to allocate sequentially too.
* MFC r285146: Drop discovered targets when initiator role is disabled.mav2015-10-051-1/+53
|
* MFC r284808: Remove limitations on setting WWNNs starting from 2.mav2015-06-281-2/+2
| | | | | | | It is odd that driver first tries to generate synthetic WWNN based on WWPN starting from 2, but then refuses to use it. If we don't trust generated WWNN, we should probably not generate it. Same time this limitation prevents potentially valid WWNN setting by user.
* MFC r284698: Dump additional config bytes for INIT_FIRMWARE_MULTI_ID.mav2015-06-251-0/+5
|
* MFC r284697: Add logging of executed mailbox command names.mav2015-06-251-5/+7
| | | | | Previously those commands were logged only as part of register dump, that is not very readable.
* MFC isp(4) driver changes:ken2015-02-031-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* MFC r275123: Fix incorrect check, blocking MULTIID functionality.mav2014-12-031-1/+1
|
* MFC r259860 (by mjacob):dim2014-03-191-1/+0
| | | | | | | | | | Harvest one no longer used constant string. Remove another and place it into play in the normally ifdef protected zone it would be used int. Noticed by: dim
* MFC r257930:mav2014-01-051-7/+6
| | | | | | | Some more registers access optimizations: - Process ATIO queue only if interrupt status tells so; - Do not update queue out pointers after each processed command, do it only once at the end of the loop.
* MFC r256705:mav2014-01-051-22/+20
| | | | | | | | | | 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.
* When fiddling with options of which registers to copy out formjacob2013-07-131-1/+8
| | | | | | | | | | | | | | a mailbox command and which registers to copy back in when the command completes, the bits being set need to not only specify what bits you want to add from the default from the table but also what bits you want *subtract* (mask) from the default from the table. A failing ISP2200 command pointed this out. Much appreciation to: marius, who persisted and narrowed down what the failure delta was, and shamed me into actually fixing it. MFC after: 1 week
* Turn off fast posting for the ISP2100- I'd forgotten that it actuallymjacob2013-02-251-1/+7
| | | | | | | | might have been enabled for them- now that we use all 32 bits of handle. Fast Posting doesn't pass the full 32 bits. Noticed by: Bugs in NetBSD. Only a NetBSD user might actually still use such old hardware. MFC after: 1 week
* Remove extraneous newline.mjacob2012-08-121-1/+1
| | | | MFC after: 1 month
* -----------mjacob2012-07-281-268/+299
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Fix typo in a message.brueffer2012-07-151-1/+1
| | | | | Obtained from: DragonFly BSD (change 7a817ab191e4898404a9037c55850e47d177308c) MFC after: 3 days
* Unbreak register tests for parallel SCSI.mjacob2012-06-251-2/+5
| | | | | You can't overwrite registers 7 and 8. MFC after: 3 days
* Clean up multi-id mode so it's driven by the f/w loaded,mjacob2012-06-241-29/+62
| | | | | | | | | | | | 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
* Prepare for FC-Tape support. This involved doing a lot of little cleanupsmjacob2012-06-171-325/+405
| | | | | | | | | | | | | | | | | | | | 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
* Clean up and complete the incomplete deferred enable code.mjacob2012-06-011-1/+6
| | | | | | | | | | | | 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
* Was chasing down a failure to load f/w on a 2400. It turns out that the cardmjacob2011-11-161-11/+56
| | | | | | is actually broken, or needs a BIOS upgrade for 64 bit loads, but this uncovered a couple of misplaced opcode definitions and some missing continual mbox command cases, so might as well update them here.
* Most of these changes to isp are to allow for isp.ko unloading.mjacob2011-08-131-2/+1
| | | | | | | | | | | 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
* Sync FreeBSD ISP with mercurial tree. Minor changes having to do withmjacob2011-02-281-5/+5
| | | | a macro for minima.
* - Use the correct DMA tag/map pair for synchronize the FC scratch area.marius2011-02-141-21/+21
| | | | | | | | | | | - 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
* Be more specific about which CDB length we're going to use. Not really a likelymjacob2010-06-051-4/+14
| | | | | | | | | bug but we might as well be clearer. Found with: Coverity Prevent(tm) CID: 3981 MFC after: 2 weeks
* Various minor and not so minor fixes suggested by Coverity.mjacob2010-06-021-24/+35
| | | | | | | In at least one case, it's amazing that target mode worked at all. Found by: Coverity. MFC after: 2 weeks
* Clean up some printing stuff so that we can have a bit finer controlmjacob2010-03-261-147/+74
| | | | | | | | | | on debug output. Add a new platform function requirement to allow for printing based upon the ITL nexus instead of the isp unit plus channel, target and lun. This allows some printouts and error messages from the core code to appear in the same format as the platform's subsystem (in FreeBSD's case, CAM path). MFC after: 1 week
* Revamp the pieces of some of the stuff I forgot to do when shifting tomjacob2010-02-271-216/+180
| | | | | | | | | | | | | | | | | | | | | | | | | | | 32 bit handles. The RIO (reduced interrupt operation) and fast posting for the parallel SCSI cards were all 16 bit handles. Furthermore, target mode parallel SCSI only can have 16 bit handles. Use part of a supplied patch to switch over to using 32 bit handles. Be a bit more conservative here and only do this for parallel SCSI for the 12160 (Ultra3) cards. There were a lot of marginal Ultra2 cards, and, frankly, few are findable now for testing. Fix the target handle routine to only do 16 bit handles for parallel SCSI cards. This is okay because the upper sixteen bits of the new 32 bit handles is a sequence number to help protect against duplicate completions. This would be very unlikely to happen with parallel SCSI target mode, and wasn't present before, so we're no worse off than we used to be. While we're at it, finally split the async mailbox completion handlers into FC and parallel SCSI functions. This makes it much cleaner and easier to figure out what is or isn't a legal async mailbox completion code for different card classes. PR: kern/144250 Submitted partially by: Charles D MFC after: 1 week
* Don't try and re-use a handle, even if the firmware tells you that's what is ↵mjacob2010-02-181-30/+33
| | | | | | | logged in. PR: kern/144026 MFC after: 1 week
* Redo how commands handles are created and managed and implement sequencemjacob2010-02-031-8/+11
| | | | | | | | | | | | numbers and handle types in rational way. This will better protect from (unwittingly) dealing with stale handles/commands. Fix the watchdog timeout code to better protect itself from mistakes. If we run an abort on a putatively timed out command, the command may in fact get completed, so check to make sure the command we're timing it out is still around. If the abort succeeds, btw, the command should get returned via a different path.
* Amazingly we've been freeing a handle and using that which it refers tomjacob2010-01-151-1/+1
| | | | | | for years. Bad! MFC after: 1 week
* Remove extraneous semicolons, no functional changes.mbr2010-01-071-3/+3
| | | | | Submitted by: Marc Balmer <marc@msys.ch> MFC after: 1 week
* Make sure that the WWNN is also created for 2100..2300 cards.mjacob2010-01-031-0/+2
| | | | MFC after: 1 day
* Create a Node WWN from the *Port* WWN, not vice versa, for 2400s.mjacob2009-12-311-5/+4
| | | | | | | If the NAA is type 2, the Node WWN is the Port WWN with the 12 bits of port (48..60) cleared. This iff a wwn fetched from NVRAM is zero. MFC after: 1 week
* (semiforced commit to add comment missed in last delta)mjacob2009-09-211-1/+0
| | | | | | | | | | 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).
OpenPOWER on IntegriCloud