summaryrefslogtreecommitdiffstats
path: root/sys/dev/isp
Commit message (Collapse)AuthorAgeFilesLines
* If the HBA is already 'touched', still set maxluns. Othewise formjacob2002-06-161-67/+126
| | | | | | | | | | | | | | | | | CAM_QUIRK_HILUN devices we loop thru 32bits of lun. Oops. Switch to using USEC_DELAY rather than USEC_SLEEP at isp_reset time. Try to paper around a defect in clients that don't correctly registers themeselves with the fabric nameserver. Minor updates for Mirapoint support- they still use code that is not HANDLE_LOOPSTATE_IN_OUTER_LAYERS, and, surprise surprise, this old stuff had some bugs in it. Clean up some target mode stuff. MFC after: 1 week
* Add support for ISP_FC_GETHINFO, which returns current connectionmjacob2002-06-161-38/+158
| | | | | | | | | | | | | | | | | | | | | | | | topology, speed, loopid, WWPN/WWNN, etc. Beef up target mode. Add isp_handle_platform_notify_scsi and isp_handle_platform_notify_fc platform handlers to handle immediate notifies (isp_handle_platform_notify_scsi is still stubbed out). In implementation of isp_handle_platform_notify_fc, for IN_ABORT_TASK, peel off a pending XPT_IMMED_NOTIFY and call xpt_done on it and hope that somebody upstream is listening. Make sure on final CTIO2s that we set residual correctly. These are absolutely crucial. Make sure we set relative offset for each CTIO2 based upon bytes we've already xferred. This is what the private adjunct datat to the original ATIO is. Note state of command so we can figure out where to find it if we get an ABORT from the firmware. Make sure we *always* set CAM_TAG_ACTION_VALID for ATIO2s. Make sure we keep track of the original lun. If se sent status (or we're otherwise done with the command), don't forget to free the adjunct structure.
* Extend private adjunct to ATIO to have both tag lun, and extended statemjacob2002-06-161-1/+10
| | | | | | | | | | (so we can, when things get lost, find out who currently is processing on behalf of this open exchange. Invariably, when things are lost and wedged, it's CAM). Keep an atio resource counter locally. MFC after: 1 week
* Force commit (last CVS comment was wrong).mjacob2002-06-161-1/+0
| | | | | Go back to *not* fully evaluating loop/fabric state if our role is ISP_ROLE_NONE.
* Add ISP_FC_GETHINFO ioctl.mjacob2002-06-162-1/+30
| | | | MFC after: 1 week
* Set all 23XX cards as 'touched' (we have trouble, unpredictably, aboutmjacob2002-06-161-241/+73
| | | | | | | | | | running ABOUT FIRMWARE with some that were started by BIOS downloads). Redo CTIO2 dma mapping- use continuation segments instead of multiple CTIO2s. Thanks to Veritas for sponsoring this work (in a different context). MFC after: 1 week
* Change isp_target_async to a function returning an integer.mjacob2002-06-161-20/+8
| | | | Roll most immediate notifies into something the platform has to handle.
* Set default command count to 0xfe. This tells the f/w essentiallymjacob2002-06-161-3/+5
| | | | | | | to *not* do flow control based upon resource counts for the firmware. Increase default immediate notify count to 16. Change isp_target_async to a function returning an integer.
* Add MBOX_DRIVER_HEARTBEAT/MBOX_FW_HEARTBEAT/FC4_FC_SVC defines.mjacob2002-06-161-0/+4
| | | | MFC after: 1 week
* Roll minor version. Add ISPASYNC_FW_RESTARTED async event. Addmjacob2002-06-161-4/+11
| | | | | | DEFAULT_FRAMESIZE && DEFAULT_EXEC_THROTTLE references. MFC after: 1 week
* If we get a DATA UNDERRUN error from QLogic FC cards, but the RQCS_RU bitmjacob2002-05-011-6/+23
| | | | | | | | | | is not set in the scsi completion status, or if the residual is clearly nonsense, then this was a command that suffered the loss of one or more FC frames in the middle of the exchange. Set HBA_BOTCH and hope it will get retried. It's the only thing we can do. MFC after: 1 day
* Move the new byte order function prototypes from <sys/param.h> tomike2002-04-261-1/+1
| | | | <sys/endian.h>. This puts us in line with NetBSD and OpenBSD.
* Scale back # of luns supported for SCC to 16384- oops- top 3 bits are amjacob2002-04-163-28/+112
| | | | | | | | | | | | lun address modifier of sorts. Only an HP XP-512 seems to have cared. Fix a few misplaced pointers for the new fabric goop, which has been demonstrated to work on newer Brocades and McData switches now. Put in commented out code which would run GFF_ID if the QLogic f/w allowed it. Don't whine about not being able to find a handle for a command if it was a command aborted (by us).
* Send 32 bytes out for fc4_types... Interestingly enough the Solaris/Sparcmjacob2002-04-051-1/+1
| | | | | | version worked fine, but Linux/Sparc && FreeBSD/Sparc choked. MFC after: 1 week
* Fix bus dma segment count to be based off of MAXPHYS, not BUS_SPACE_MAXSIZE.mjacob2002-04-047-156/+675
| | | | | | | | | | | | | | | | | | | | | | | Grumble. I've seen better documented architectures out of Redmond. Redo fabric evaluation to not use GET ALL NEXT (GA_NXT). Switches seem to be trying to wriggle out of supporting this well. Instead, use GID_FT to get a list of Port IDs and then use GPN_ID/GNN_ID to find the port and node wwn. This should make working on fabrics a bit cleaner and more stable. This also caused some cleanup of SNS subcommand canonicalization so that we can actually check for FS_ACC and FS_RJT, and if we get an FS_RJT, print out the reason and explanation codes. We'll keep the old GA_NXT method around if people want to uncomment a controlling definition in ispvar.h. This also had us clean up ISPASYNC_FABRICDEV to use a local lportdb argument and to have the caller explicitly say that a device is at the end of the fabric list. MFC after: 1 week
* Change callers of mtx_init() to pass in an appropriate lock type name. Injhb2002-04-041-1/+1
| | | | | | | most cases NULL is passed, but in some cases such as network driver locks (which use the MTX_NETWORK_LOCK macro) and UMA zone locks, a name is used. Tested on: i386, alpha, sparc64
* Redo stuff for sparc64- primarily fix bus dma implementation. The endianmjacob2002-04-023-142/+132
| | | | | | | | | stuff was right, but the busdma stuff was massively not right. Didn't really test on ia64 or i386- don't have the former h/w and my FreeBSD-current disk is unwell right now. Hope that this is okay. MFC after: 1 week
* Limit fabric search to a default 256 entries. This will all go awaymjacob2002-03-213-24/+34
| | | | | | | | | | | | | | | | | | | soon because it's just getting harder and harder to find switches that correctly implement the GET ALL NEXT subcommands for the SNS protocol. Latch up result out pointer and set a busy flag when we're looking at the response queue. This allows for a cleaner way to make sure we don't get multiple CPUs trying to read the same response queue entries. Change how isp_handle_other_response returns values (clarity). Make PORT UNAVAILABLE the same as PORT LOGOUT (force a LIP). Do some formatting changes. MFC after: 0 days
* Remove __P.alfred2002-03-201-1/+1
|
* Disable RIO (reduced interrupt operation) for 2200 boards- it seemed likemjacob2002-03-071-4/+25
| | | | | | | | | | | | | it worked- but I ran into a case with a 2204 where commands were being lost right and left. Best be safe. For target mode, or things called if we call isp_handle_other response- note that we might have dropped locks by changing the output pointer so we bail from the loop. It's the responsibility of the entity dropping the lock to make sure that we let the f/w know we've read thus far into the response queue (else we begin processing the same entries again- blech!). MFC after: 1 day
* Reorder some of the ioctls and add a few new ones.mjacob2002-02-212-17/+37
| | | | MFC after: 1 day
* Fix a problem where a local loop disk logs out- and we get a PORT LOGGEDmjacob2002-02-211-8/+38
| | | | | | | | | | | | OUT status. We are, apparently, required to force the f/w to log back in if we want to try and talk to that disk again. This means either issuing a LOGIN LOCAL LOOP PORT mailbox command, or by issuing a LIP. I've elected to issue a LIP because this has a better chance of waking up the disk which clearly just crashed and burned. These should not occur at all. If they do, they should be darned rare. MFC after: 1 week
* More for f/w crash dumps (bug fixing and adding ioctl entry pointsmjacob2002-02-184-4/+63
| | | | | | and hints to enable for specific units) MFC after: 1 week
* Support for f/w crash dumps (2200 && 23XX).mjacob2002-02-174-20/+401
| | | | | | | | | | | | | If you want QLogic to look at a potential f/w problem for FC cards, you really have to provide them info in the format they expect. This involves dumping a lot of hardware registers (> 300 16 bit registers) and a lot of SRAM (> 128KB minimum). Thus all of this code is #ifdef protected which will become an option so that the memory allocation of where to dump the crash image is pretty expensive. It's worth it if you have a reproducible problem because they have some tools that can tell them, given the f/w version, the precise state of everything. MFC after: 1 week
* Hints for WWN are now WWNN and/or WWPN.mjacob2002-02-171-2/+2
| | | | MFC after: 1 week
* Add in support firmware crash dumps. Change CFG options to splitmjacob2002-02-171-2/+13
| | | | | | WWN into WWNN and WWPN. MFC after: 1 week
* + A variety of 23XX changes:mjacob2002-02-0410-56/+219
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | disable MWI on 2300 based on function code, set an 'isp_port' for the 2312- it's a separate instance, but the NVRAM is shared, and the second port's NVRAM is at offset 256. + Enable RIO operation for LVD SCSI cards. This makes a *big* difference as even under reasonable load we get batched completions of about 30 commands at a time on, say, an ISP1080. + Do 'continuation' mailbox commands- this allows us to specify a work area within the softc and 'continue' repeated mailbox commands. This is more or less on an ad hoc basis and is currently only used for firmware loading (which f/w now loads substantially faster becuase the calling thread is only woken when all the f/w words are loaded- not for each one of the 40000 f/w words that gets loaded). + If we're about to return from isp_intr with a 'bogus interrupt' indication, and we're not a 23XX card, check to see whether the semaphore register is currently *2* (not *1* as it should be) and whether there's an async completion sitting in outgoing mailbox0. This seems to capture cases of lost fast posting and RIO interrupts that the 12160 && 1080 have been known to pump out under extreme load (extreme, as in > 250 active commands). + FC_SCRATCH_ACQUIRE/FC_SCRATCH_RELEASE macros. + Endian correct swizzle/unswizzle of an ATIO2 that has a WWPN in it. MFC after: 1 week
* Add missing move of relative offset for CTIO2 updates.mjacob2002-01-111-0/+1
|
* Implement REDUCED INTERRUPT OPERATION usage form FC cards- this allows themjacob2002-01-036-35/+185
| | | | | | | | | | | | | | | | | firmware to delay completion of commands so that it can attempt to batch a bunch of completions at once- either returning 16 bit handles in mailbox registers, or in a resposne queue entry that has a whole wad of 16 bit handles. Distinguish between 2300 and 2312 chipsets- if only because the revisions on the chips have different meanings. Add more instrumentation plus ISP_GET_STATS and ISP_CLR_STATS ioctls. Run up the maximum number of response queue entities we'll look at per interrupt. If we haven't set HBA role yet, always return success from isp_fc_runstate. MFC after: 2 weeks
* Explicitly decode GetAllNext SNS Response back *as*mjacob2001-12-112-4/+59
| | | | | | | a GetAllNext response. Otherwise, we won't unswizzle it correctly. This was found on linux/PPC. This mandated creating another inline: isp_get_gan_response.
* Major restructuring for swizzling to the request queue and unswizzling frommjacob2001-12-119-579/+1500
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | the response queue. Instead of the ad hoc ISP_SWIZZLE_REQUEST, we now have a complete set of inline functions in isp_inline.h. Each platform is responsible for providing just one of a set of ISP_IOX_{GET,PUT}{8,16,32} macros. The reason this needs to be done is that we need to have a single set of functions that will work correctly on multiple architectures for both little and big endian machines. It also needs to work correctly in the case that we have the request or response queues in memory that has to be treated specially (e.g., have ddi_dma_sync called on it for Solaris after we update it or before we read from it). It also has to handle the SBus cards (for platforms that have them) which, while on a Big Endian machine, do *not* require *most* of the request/response queue entry fields to be swizzled or unswizzled. One thing that falls out of this is that we no longer build requests in the request queue itself. Instead, we build the request locally (e.g., on the stack) and then as part of the swizzling operation, copy it to the request queue entry we've allocated. I thought long and hard about whether this was too expensive a change to make as it in a lot of cases requires an extra copy. On balance, the flexbility is worth it. With any luck, the entry that we build locally stays in a processor writeback cache (after all, it's only 64 bytes) so that the cost of actually flushing it to the memory area that is the shared queue with the PCI device is not all that expensive. We may examine this again and try to get clever in the future to try and avoid copies. Another change that falls out of this is that MEMORYBARRIER should be taken a lot more seriously. The macro ISP_ADD_REQUEST does a MEMORYBARRIER on the entry being added. But there had been many other places this had been missing. It's now very important that it be done. Additional changes: Fix a longstanding buglet of sorts. When we get an entry via isp_getrqentry, the iptr value that gets returned is the value we intend to eventually plug into the ISP registers as the entry *one past* the last one we've written- *not* the current entry we're updating. All along we've been calling sync functions on the wrong index value. Argh. The 'fix' here is to rename all 'iptr' variables as 'nxti' to remember that this is the 'next' pointer- not the current pointer. Devote a single bit to mboxbsy- and set aside bits for output mbox registers that we need to pick up- we can have at least one command which does not have any defined output registers (MBOX_EXECUTE_FIRMWARE). MFC after: 2 weeks
* Tra-La, another QLogic f/w funny- this time with the 2300.mjacob2001-10-231-8/+25
| | | | | | | | If we get a completion status of RQCS_QUEUE_FULL, it means that the internal queues are full. Other QLogic boards set the QFULL SCSI status. But *nooooooooooo*, not the 2300. MFC after: 1 day
* Protect against deranged fabric nameservers that spit out 10000 identicalmjacob2001-10-181-3/+16
| | | | | | port numbers. MFC after: 1 day
* Add some somewhat vague documentation for this driver and a listmjacob2001-10-072-0/+938
| | | | of Hardware that might, in fact, work.
* Some patches from Doug for ia64 support- the principle one being themjacob2001-10-072-2/+6
| | | | | | | | appropriate cache flush that provides MEMORY_BARRIER in between handoffs between host && RISC processor for the shared memory request/response queues. Submitted by: dfr@nlsystems.com
* Misunderstanding documentation caused me to try and set 1Gbps/2Gps/Automjacob2001-10-062-14/+21
| | | | | | connection speed for the 2300 in the wrong offset in the ICB. Oops. Respect some QLogic errat wrt PCI errors on certain shared host/RISC registers.
* Whups- remember to zero the isr pointer arg.mjacob2001-10-061-1/+3
|
* Respect QLogic's errata- read BIU_ISR even on the 2300mjacob2001-10-061-0/+2
| | | | | | | | | to see if there's an interrupt (avoids PCI parity errors which can occur on the 2312 if you access some registers from the host at the same time the RISC on the 2312 is C accessing them). MFC after: 1 day
* Begin to implement target mode that for Fibre Channel has a privatemjacob2001-10-012-29/+68
| | | | | | | | | | | | | | per-command component that we *don't* try and pass thru CAM. CAM just is too risky and too much of a pain- structures get copied, but not all info of interest can be considered safely transported thru all consumers (including user space) from the incoming ATIO to the outgoing CTIO- it's just much safer to have a buddy structure, identified by the command's tag which *does* make it thru safely. Pay attention to link speed and report 200MB/s xfer speed for a 23XX card in 2GPs mode. MFC after: 1 week
* Implement a call to get the actual link data rate (if 23XX) so we canmjacob2001-10-013-40/+70
| | | | | | set whether it's a 2Gps or 1Gps link. MFC after: 1 week
* When calling isp_reset, set the request/response in/out pointers all atmjacob2001-09-291-9/+13
| | | | | | | | once so there isn't a window with the ones for the 23XX cards being wrong. When being verbose, print out some more FC NVRAM values (like framesize). MFC after: 1 week
* KSE Milestone 2julian2001-09-121-1/+1
| | | | | | | | | | | | | | Note ALL MODULES MUST BE RECOMPILED make the kernel aware that there are smaller units of scheduling than the process. (but only allow one thread per process at this time). This is functionally equivalent to teh previousl -current except that there is a thread associated with each process. Sorry john! (your next MFC will be a doosie!) Reviewed by: peter@freebsd.org, dillon@freebsd.org X-MFC after: ha ha ha ha
* I don't know what I was thinking- if I have two separate busses on onmjacob2001-09-041-174/+136
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | SIM (as is true for the 1280 and the 12160), then I have to have separate flags && status for *both* busses. *Whap*. Implement condition variables for coordination with some target mode events. It's nice to use these and not panic in obscure little places in the kernel like 'propagate_priority' just because we went to sleep holding a mutex, or some other absurd thing. Remove some bogus ISP_UNLOCK calls. *Whap*. No longer require that somebody do a lun enable on the wildcard device to enable target mode. They are, in fact, orthogonal. A wildcard open is a statement that somebody upstream is willing to accept commands which are otherwise unrouteable. Now, for QLogic regular SCSI target mode, this won't matter for a damn because we'll never see ATIOs for luns we haven't enabled (are listening for, if you will). But for SCCLUN fibre channel SCSI, we get all kinds of ATIOs. We can either reflect them back here with minimal info (which is isp_target.c:isp_endcmd() is for), or the wildcard device (nominally targbh) can handle them. Do further checking against firmware attributes to see whether we can, in fact, support target mode in Fibre Channel. For now, require SCCLUN f/w to supoprt FC target mode. This is an awful lot of change, but target mode *still* isn't quite right. MFC after: 4 weeks
* Note for ATIOs returned because of BDRs or Bus Resets for which bus thismjacob2001-09-041-20/+34
| | | | | | | | | | applies to. Do more bus # foo things. Acknowledge Immediate Notifies right away prior to throwing events upstream (where they're currently being ignored, *groan*) Capture ASYNC_LIP_F8 as with ASYNC_LIP_OCCURRED. Don't percolate them upstream as if they were BUS RESETS- they're not.
* If we're on an interrupt stack, mark things so that we don't trymjacob2001-09-041-10/+11
| | | | | | | | | | and cv_wait for mailbox commands to complete if we start them from here. Fix residuals for target mode such that we only check the residual and set it in the CTIO if this is the last CTIO (when we're sending status). MFC after: 4 weeks
* I don't know what I was thinking- if I have two separate busses on onmjacob2001-09-041-4/+6
| | | | | | | | | | | | SIM (as is true for the 1280 and the 12160), then I have to have separate flags && status for *both* busses. *Whap*. Implement condition variables for coordination with some target mode events. It's nice to use these and not panic in obscure little places in the kernel like 'propagate_priority' just because we went to sleep holding a mutex, or some other absurd thing. MFC after: 4 weeks
* Fix SET_IID_VAL/SET_BUS_VAL macros to usable.mjacob2001-09-041-2/+2
| | | | MFC after: 4 weeks
* Because we now store SCCLUN capabilities in firmware attributes, getmjacob2001-09-031-16/+19
| | | | | | rid of the silly test of isp_maxluns > 16 and use the attibutes directly. MFC after: 4 weeks
* Clarify issues about whether we have SCCLUN (65535 luns) or non-SCCLUN (16mjacob2001-09-031-31/+62
| | | | | | | | | | | | | | | | | | | | | | | | | | | | luns) firmware for the Fibre Channel cards. We used to assume that if we didn't download firmware, we couldn't know what the firmware capability with respect to SCCLUNs is- and it's important because the lun field changes in the request queue entry based upon which firmware it is. At any rate, we *do* get back firmware attributes in mailbox register 6 when we do ABOUT FIRMWARE for all 2200/2300 cards- and for 2100 cards with at least 1.17.0 firmware. So- we now assume non-SCCLUN behaviour for 2100 cards with firmware < 1.17.0- and we check the firmware attributes for other cards (loaded firmware or not). This also allows us to get rid of the crappy test of isp_maxluns > 16- we simply can check firmware attributes for SCCLUN behaviour. This required an 'oops' fix to the outgoing mailbox count field for ABOUT FIRMWARE for FC cards. Also- while here, hardwire firmware revisions for loaded code for SBus cards. Apparently the 1.35 or 1.37 f/w we've been loading into isp1000 just doesn't report firmware revisions out to mailbox regs 1, 2 and 3 like everyone else. Grumble. Not that this fix hardly matters for FreeBSD. MFC after: 4 weeks
* Add some more firmware revision macros. Add firmware attributes fieldmjacob2001-09-031-1/+7
| | | | | to fcparam structure. MFC after: 4 weeks
OpenPOWER on IntegriCloud