summaryrefslogtreecommitdiffstats
path: root/sys/dev/isp/isp_library.c
Commit message (Collapse)AuthorAgeFilesLines
* MFC r292739: Make virtual ports control asynchronous.mav2015-12-301-4/+12
| | | | | | | | | | | | Before this change virtual ports control IOCBs were executed synchronously via Execute IOCB mailbox command. It required exclusive use of scratch space of driver and mailbox registers of the hardware. Because of that shared resources use this code could not really sleep, having to spin for completion, blocking any other operation. This change introduces new asynchronous design, sending the IOCBs directly on request queue and gracefully waiting for their return on response queue. Returned IOCBs are identified with unified handle space from r292725.
* MFC r292725: Unify handles allocation for initiator and target IOCBs.mav2015-12-301-121/+40
| | | | | | I am not sure why this was split long ago, but I see no reason for it. At this point this unification just slightly reduces memory usage, but as next step I plan to reuse shared handle space for other IOCB types.
* MFC r292715: Clear virtual port's port database when disabling it.mav2015-12-301-162/+0
| | | | | Previously it was done only on full chip reinit, that caused old ports resurrect in case of virtual port reenabling.
* MFC r291730: Update isp_put_icb_2400() for new structure fields.mav2015-12-221-3/+10
|
* MFC r291365, r291369: One more round of port scanner rewrite.mav2015-11-301-25/+24
| | | | | | | - Make scan aborted by event restart immediately and infinitely. - Improve handling of some loop events from firmware. - Remove loop down timer, adding its functionality to scanner thread. - Some more unification and simplification.
* MFC r291209: Fix target mode support for Qlogic 2200 FC adapters.mav2015-11-301-2/+4
| | | | | Now target mode works for all supported FC adapters except ancient 2100, which is not tested.
* MFC r291188: Rip off target mode support for parallel SCSI QLogic adapters.mav2015-11-301-281/+1
| | | | | | | Hacks to enable target mode there complicated code, while didn't really work. And for outdated hardware fixing it is not really interesting. Initiator mode tested with Qlogic 1080 adapter is still working fine.
* MFC r291144: Fix target mode with fabric for pre-24xx chips.mav2015-11-301-5/+5
| | | | | | | For those chips we are not receiving login events, adding initiators based on ATIO requests. But there is no port ID in that structure, so in fabric mode we have to explicitly fetch it from firmware to be able to do normal scan after that.
* MFC r291080: Another round of port scanner rewrite.mav2015-11-301-30/+37
| | | | | | This change simplifies and unifies port adding/updating for loop and fabric scanners. It also fixes problems with scanning restarts due to concurrent port databases changes. It also fixes many cosmetic issues.
* MFC r291013: Remove some confusions between loopid and nphdl.mav2015-11-301-1/+1
| | | | | | | | Modern cards in most cases operate abstract port handles, that have no any relation to real loop IDs. Leave loopid used only where it really goes about local loop IDs. While there, fix few more cases where LUNs were still printed in decimal.
* MFC r291000: Register our FC4 Features in SNS.mav2015-11-301-0/+14
|
* MFC r290993, r290994: Unify and cleanup FC ports scan.mav2015-11-301-22/+16
|
* MFC r290980: Make firmware handle virtual ports SNS logins for us.mav2015-11-301-1/+2
|
* MFC r290978: Add real initial support for RQSTYPE_RPT_ID_ACQ.mav2015-11-301-11/+4
|
* MFC r290104: Improve/fix loop scanning routine.mav2015-11-301-0/+38
| | | | | | | | | | | | 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 r290018: Reimplement enable and implement disable of virtual ports.mav2015-11-131-62/+148
| | | | | | | | | | 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 r289886: Add new field to Abort IOCB.mav2015-11-131-0/+2
|
* MFC r289855: Minor additions to Status Type 0 IOCB.mav2015-11-131-1/+1
|
* MFC r289838: Improve INOTs handling for 24xx and above chips.mav2015-11-131-20/+40
|
* MFC r285459: Unify port database use for target and initiator roles.mav2015-10-051-164/+106
| | | | | 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 r285146: Drop discovered targets when initiator role is disabled.mav2015-10-051-11/+0
|
* MFC r284681: Rewrite port database handling for target mode.mav2015-06-281-111/+127
| | | | | | | | Previous implementation was too fragile to initiator parameters changes. In case of port role change it could not survive different handle assigned to the same initiator by firmware, even though initiator was logged out. The new implementation should be more resillient to this kind of problems, trying to work in any situation and only warn user about suspisious events.
* MFC r275112:mav2014-12-261-3/+3
| | | | | | | Make isp_find_pdb_by_*() search for targets in portdb in reverse order. Records with target_mode == 1 are allocated from the end of portdb, so it seems logical to start search from the end not traverse whole array.
* MFC r272937: Fix r272936 build with old GCC.mav2014-12-051-1/+2
|
* MFC r272936:mav2014-11-111-0/+5
| | | | | Update isp_tgt_map and send new arrival notification if target that departed earlier has returned. Previously that code worked only once, confusing CTL.
* MFC r261515:mav2014-02-101-2/+6
| | | | | | | | Fix I/O freezes in some cases, caused by r257916. Delaying isp_reqodx update, we should be ready to update it every time we read it. Otherwise requests using several indexes may be requeued ndefinitely without ever updating the variable.
* MFC r257916:mav2014-01-051-3/+7
| | | | | | | Save one more register read per command by not reading rqstoutrp register every time. The purpose of that register is unlikely output queue overflow detection, so read it only when its last known (and probably stale now) value signals overflow.
* -----------mjacob2012-07-281-161/+236
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* - Use the correct DMA tag/map pair for synchronize the FC scratch area.marius2011-02-141-2/+2
| | | | | | | | | | | - 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
* Don't pass a buffer directly as a printflike format string.mjacob2010-06-101-1/+1
| | | | | Found by: clang MFC after: 1 month
* Various minor and not so minor fixes suggested by Coverity.mjacob2010-06-021-1/+1
| | | | | | | In at least one case, it's amazing that target mode worked at all. Found by: Coverity. MFC after: 2 weeks
* D'oh- isp_handle_index' logic was reversed (not used in FreeBSD).mjacob2010-03-261-2/+2
| | | | MFC after: 1 week
* Revamp the pieces of some of the stuff I forgot to do when shifting tomjacob2010-02-271-5/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Yet another target mode compilation error.mjacob2010-02-041-1/+1
|
* Fix target mode compilation problem with previous deltamjacob2010-02-041-2/+2
|
* Redo how commands handles are created and managed and implement sequencemjacob2010-02-031-74/+73
| | | | | | | | | | | | 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.
* Remove extraneous semicolons, no functional changes.mbr2010-01-071-1/+1
| | | | | Submitted by: Marc Balmer <marc@msys.ch> MFC after: 1 week
* Add 8Gb support (isp_2500). Fix a fair number of configuration andmjacob2009-08-011-701/+1607
| | | | | | | | | | | | | | | | | | | | | 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
* Recover from some major omissions/problems with the 24XX port.mjacob2007-07-021-8/+11
| | | | | | | | | | | | | | | | | | | | | | | | First, we were never correctly checking for a 24XX Status Type 0 response- that cased us to fall through to evaluate status for commands as if this were a 2100/2200/2300 Status Type 0 response. This is *close*, but not quite the same. This has been reported to be apparent with some wierd lun configuration problems with some arrays. It became glaringly apparent on sparc64 where none of the correct byte swap things were done. Fixing this omission then caused a whole universe shifting debug cycle of endian issues for the 2400. The manual for 24XX f/w turns out to be wrong about the endianness of a couple of entities. The lun and cdb fields for the type 7 request are *not* unconditionally big endian- they happen to be opposite of whatever the endian of the current machine type is. Same with the sense data for the 24XX type 0 response. While we're at it investigate and resolve some NVRAM endian issues. Approved by: re (ken) MFC after: 3 days
* Temporarily desupport simultaneous target and initiator mode.mjacob2007-04-021-7/+7
| | | | | | | | | | | | | | | | | | | | | | | When the linux port changes were imported which split the target command list to be separate from the initiator command list and the handle format changed to encode a type in the handle the implications to the function isp_handle_index (which only the NetBSD/OpenBSD/FreeBSD ports use) were overlooked. The fault is twofold: first, the index into the DMA maps in isp_pci is wrong because a target command handle with the type bit left in place caused a bad index (and panic) into dma map. Secondly, the assumption of the array of DMA maps in either PCS or SBUS attachment structures is that there is a linear mapping between handle index and DMA map index. This can no longer be true if there are overlapping index spaces for initiator mode and target mode commands. These changes bandaid around the problem by forcing us to not have simultaneous dual roles and doing the appropriate masking to make sure things are indexed correctly. A longer term fix is being devloped.
* MFP4: a) Some constification from NetBSD (gcc 4.1.2)mjacob2007-03-221-1/+1
| | | | | | | b) Split default param fetching/setting into scsi and fibre functions and retry the fibre fetch more than once. MFC after: 1 week
* Fix some stupid copyright mistakes that have been there for quite some time.mjacob2007-03-101-24/+26
|
* Make the SAN login/logout stuff more common between different chipsetsmjacob2006-11-181-0/+60
| | | | | | 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.
* Increase the timeout for some SAN commands.mjacob2006-11-161-3/+3
| | | | | | | | | Only complain about FC Reponse errors if they're nonzero. Shorten some PortID printouts for local loop. Add an internal isp_xcmd_t data structure which we'll use for some CT-Passthru support as part of adding SMI-S.
* minor change to reduce some diff noisemjacob2006-11-161-1/+1
|
* Push things closer to path failover by implementing loop down andmjacob2006-11-141-6/+53
| | | | | | | | | | | | | | | | | | | | | | | | | 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).
* Add 4Gb (24XX) support and lay the foundation for a lot of new stuff.mjacob2006-11-021-778/+1845
|
* Fix na_fcentry_t to not have a lun field. Fix indentation in handlymjacob2006-08-041-6/+6
| | | | | | | | | the notify structs. Fix messages in isp_got_msg_fc to print out the loop id of the sender- not the wwpn which will be synthesized later, if possible, in the outer layers. Put in debug printouts to pair a notify ack to a notify so one can see the start/close of an immediate notify event. Put in spsace for TASK MANAGEMENT response flags (which we don't do yet).
* Some rearrangement of headers to minimize diffs with outside ofmjacob2006-07-161-7/+5
| | | | | | | | FreeBSD repository and to clean up the license header so as to not pollute the license with file function. Zero all mailbox structures prior to use (just in case). Change the outgoing mailbox count for INIT_FIRMWARE to be correct.
* Redo some code based upon issues found by Coverity.mjacob2006-04-211-1/+1
|
OpenPOWER on IntegriCloud