summaryrefslogtreecommitdiffstats
path: root/sys/dev/isp/isp.c
Commit message (Collapse)AuthorAgeFilesLines
* Don't set ZIO for 23XX for target mode (use fast posting instead).mjacob2005-01-231-7/+37
| | | | | | | | | | | Use the correct number of handles for multihandle returns. Very, very, rarely on some SMP systems we've seen an 'unstable' type in the response queue. I dunno whether or not it's a bug in our handling, or whether there's a cache incoherency issue, but try to guard against it. MFC after: 2 weeks
* Start each of the license/copyright comments with /*-, minor shuffle of linesimp2005-01-061-1/+1
|
* Store the target handles in a separate list from normal commands. Add anjl2004-05-241-3/+5
| | | | | | CTIO fast post routine to handle CTIO completions. Submitted by: mjacob
* Add case to handle ISPCTL_GET_PDB.mjacob2004-02-071-0/+9
| | | | MFC after: 1 week
* If we have ISP_ROLE_INITIATOR set, make sure that we clear ICBOPT_INI_DISABLEmjacob2004-01-231-0/+6
| | | | | from the fwoptions. Likewise, we *set* ICBOPT_INI_DISABLE if we don't have initiator role.
* On reset, make sure that we have some parameters set correctly. Thismjacob2003-09-131-1/+18
| | | | | | | | | | | | fixes a longstanding issue WRT resetting the chip after startup- it would fail if we were connected as an F-port to a switch. If we were connected as an F-port, we got assigned a hard loop ID of 255, which is really a bogus loop id. Then when we turned around to reset ourselves, the firmware would reject the ICB_INIT request because the loop id was bogus. *sputter* Minor fixlet from somebody in NetBSD with too much time on their hands (dma -> DMA).
* Revert previous commit. Violates Maintainer (O'Brien knows how tomjacob2003-08-251-13/+24
| | | | | reach me directly), but more importantly, breaks compiles on non-FreeBSD platforms.
* Use __FBSDID().obrien2003-08-241-1/+3
| | | | Also some minor style cleanups.
* Restore parentheses removed inappropriately in last commit.mjacob2003-06-011-2/+3
|
* Remove unused variablesphk2003-05-311-6/+3
| | | | | | Add /* FALLTHROUGH */ Found by: FlexeLint
* Pick up some compilation warning fixes from NetBSD.mjacob2003-02-161-7/+7
| | | | | | If we don't have ISP_FW_CRASH_DUMP defined, we have to do a isp_reinit in the core code- not the platform code- so fix the ISP_CONN_FATAL case.
* Correct typos, mostly s/ a / an / where appropriate. Some whitespace cleanup,schweikh2003-01-011-1/+1
| | | | especially in troff files.
* Fix typos, mostly s/ an / a / where appropriate and a few s/an/and/schweikh2002-12-301-1/+1
| | | | Add FreeBSD Id tag where missing.
* This should enable 10160 support. As best as I can tell, the samemjacob2002-10-111-1/+4
| | | | | | | f/w as 12160 is used, and otherwise, this is just a single channel variant of the 10160. MFC after: 0 days
* If we have a 1240 or an ULTRA2 or better card, use MBOX_INIT_RES_QUEUE_A64mjacob2002-09-231-22/+49
| | | | (preparation for DAC/A64 support)
* The size argument to snprintf does not have to be backed off by onemjacob2002-09-071-17/+17
| | | | | | to account for a NULL byte. Submitted by: Jacques A. Vidrine <nectar@celabo.org>
* Remove STRNCAT (==>strncat) usage. Apparently I never read the manmjacob2002-09-061-18/+17
| | | | | | page correctly and it wasn't doing what I thought it was. Noticed by: Brooks Davis <brooks@one-eyed-alien.net>
* If we're using ancient (pre 1.17.0) 2100 f/w (for the cards that cannotmjacob2002-08-171-22/+63
| | | | | | | | | | | | | | | | | | | | load f/w images > 0x7fff words), set ISP_FW_ATTR_SCCLUN. We explicitly don't believe we can find attributes if f/w is < 1.17.0, so we have to set SCCLUN for the 1.15.37 f/w we're using manually- otherwise every target will replicate itself across all 16 supported luns for non-SCCLUN f/w. Correctly set things up for 23XX and either fast posting or ZIO. The 23XX, it turns out, does not support RIO. If you put a non-zero value in xfwoptions, this will disable fast posting. If you put ICBXOPT_ZIO in xfwoptions, then the 23XX will do interrupt delays but post to the response queue- apparently QLogic *now* believes that reading multiple handles from registers is less of a win than writing (and delaying) multiple 64 byte responses to the response queue. At the end of taking a a good f/w crash dump, send the ISPASYNC_FW_DUMPED event to the outer layers (who can then do things like wake a user daemon to *fetch* the crash image, etc.).
* Remove the 'bogus registrant' hack for fabric searches. It reallymjacob2002-07-081-12/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | turns out that there's something of a hole in our new fabric name server stuff. We ask the name server for entities that have registered as a specific type. That type is FC-SCSI. If the entity hasn't performed a REGISTER FC4 TYPES, the fabric nameserver won't return it. This brings this driver to a bit of a fork in the road as to what the right thing to do is. For servicing the needs of accessing FC-SCSI devices, this method is fine, and to be preferred. It is extremely unlikely we're interested in fabric devices that *don't* register correctly. If I ever get around to adding an FC-IP stack, then asking for devices that have registers as FC-IP types is also the right thing to do. So- asking the fabric nameserver for a specific type is fine, *as long as you are only interested in specific types*. If, on the other hand, you want to create (as for management tool support) a picture of everything on the fabric, this is *not* so fine. There are a large class of FC-SCSI *initiators* who *don't* correctly register, so we never will *see* them. Is this a problem? Yes, but only a little one. If we want to do such management tool support, we should probably run a *different* fabric nameserver query algorithm. Better yet, we should talk to the management nameserver in Brocade switches instead of the standard FC-GS-2 fabric nameserver (which can be unwieldy). Other changes: if we've overrrides marked, don't set some default values from reading NVRAM. This allows us to override things like EXEC throttle without having to ignore NVRAM entirely. MFC after: 1 week
* 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
* 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
* Scale back # of luns supported for SCC to 16384- oops- top 3 bits are amjacob2002-04-161-28/+91
| | | | | | | | | | | | 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).
* Fix bus dma segment count to be based off of MAXPHYS, not BUS_SPACE_MAXSIZE.mjacob2002-04-041-70/+381
| | | | | | | | | | | | | | | | | | | | | | | 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
* Limit fabric search to a default 256 entries. This will all go awaymjacob2002-03-211-20/+28
| | | | | | | | | | | | | | | | | | | 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
* 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
* 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-181-3/+3
| | | | | | and hints to enable for specific units) MFC after: 1 week
* Support for f/w crash dumps (2200 && 23XX).mjacob2002-02-171-19/+372
| | | | | | | | | | | | | 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
* + A variety of 23XX changes:mjacob2002-02-041-34/+153
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Implement REDUCED INTERRUPT OPERATION usage form FC cards- this allows themjacob2002-01-031-29/+88
| | | | | | | | | | | | | | | | | 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-111-4/+4
| | | | | | | 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-111-123/+134
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Misunderstanding documentation caused me to try and set 1Gbps/2Gps/Automjacob2001-10-061-11/+18
| | | | | | 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.
* Implement a call to get the actual link data rate (if 23XX) so we canmjacob2001-10-011-8/+28
| | | | | | 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
* 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 2 Gigabit Fibre Channel support (2300 && 2312 cards). This requiredmjacob2001-08-311-138/+172
| | | | | | | | | | some reworking (and consequent cleanup) of the interrupt service code. Also begin to start a cleanup of target mode support that will (eventually) not require more inforamtion routed with the ATIO to come back with the CTIO other than tag. MFC after: 4 weeks
* Clean up some ways in which we set defaults for SCSI cardsmjacob2001-08-201-136/+172
| | | | | | | | | that do not have valid NVRAM. In particular, we were leaving a retry count set (to retry selection timeouts) when thats not really what we want. Do some constant string additions so that LOGDEBUG0 info is useful across all cards. MFC after: 2 weeks
* oops- typo in a previous commitmjacob2001-08-161-1/+1
|
* Enable LIP F8, LIP Reset async events.mjacob2001-08-161-4/+45
| | | | | | | | | Be more chatty about SNS failures. Fix typo for skipped phase mesage. Correct MBOX_GET_PORT_QUEUE_PARAMS options in table. MFC after: 2 weeks
* Oops- don't set 'goal' twice when you mean to set 'nvrm' as well.mjacob2001-08-021-1/+1
| | | | | | This breaks bogus NVRAM boards. MFC after: 1 day
* Redo how we manage SCSI device settings- have a 3rd flags (nvram) that recordsmjacob2001-07-301-157/+143
| | | | | | | either what's in NVRAM or what the safe defaults would be if we lack NVRAM. Then we rename cur_XXXX to actv_XXXX (these are the currently active settings) and the dev_XXX settings to goal_XXXX (these are the settings which we want cur_XXXX to converge to).
* Hmm. Let's try this on for size...mjacob2001-07-111-5/+11
| | | | | | | | | | | | | | | | | | | | We originally had it such that if the connection topology was FL-loop (public loop), we never looked at any local loop addresses. The reason for not doing that was fear or concern that we'd see the same local loop disks reflected from the name server and we'd attach them twice. However, when I recently hooked up a JBOD and a system to an ANCOR SA-8 switch, the disks did *not* show up on the fabric. So at least the ANCOR is screening those disks from appearing on the fabric. Now, it's possible this is a 'feature' of the ANCOR. When I get a chance, I'll check the Brocade (it's hard to do this on a low budget). In any case, if they *do* also show up on the fabric, we should simply elect to not log into them because we already have an entry for the local loop. There is relatively unexercised code just for this case. MFC after: 2 weeks
* More 2300 support prep- the Request/Response in/out pointers aremjacob2001-07-041-36/+34
| | | | | | | | | | | | | | | | part of the PCI block for the 2300- not software convention usage of the mailbox registers- so we macrosize in/out pointer usage. Only report that a LIP destroyed commands if it actually destroyed commands. Get the chan/tgt/lun order correct. Fix a longstanding stupid bug that caused us to try and issue a command with a tag on Channel B because we were checking the tagged capability for the target against Channel A. A firmware crash is now vectored out to platform specific code as an async event. Some minor formatting tweaks.
* We've had problems with data corruption occuring onmjacob2001-06-141-0/+21
| | | | | | | | | | commands that complete (with no apparent error) after we receive a LIP. This has been observed mostly on Local Loop topologies. To be safe, let's just mark all active commands as dead if we get a LIP and we're on a private or public loop. MFC after: 4 weeks
* Fix botch for state levels. Role minor release. Start adding code for amjacob2001-06-051-2/+5
| | | | | | 'force logout' path. MFC after: 4 weeks
* Spring MegaChange #1.mjacob2001-05-281-7/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ---- Make a device for each ISP- really usable only with devfs and add an ioctl entry point (this can be used to (re)set debug levels, reset the HBA, rescan the fabric, issue lips, etc). ---- Add in a kernel thread for Fibre Channel cards. The purpose of this thread is to be woken up to clean up after Fibre Channel events block things. Basically, any FC event that casts doubt on the location or identify of FC devices blocks the queues. When, and if, we get the PORT DATABASE CHANGED or NAME SERVER DATABASE CHANGED async event, we activate the kthread which will then, in full thread context, re-evaluate the local loop and/or the fabric. When it's satisfied that things are stable, it can then release the blocked queues and let commands flow again. The prior mechanism was a lazy evaluation. That is, the next command to come down the pipe after change events would pay the full price for re-evaluation. And if this was done off of a softcall, it really could hang up the system. These changes brings the FreeBSD port more in line with the Solaris, Linux and NetBSD ports. It also, more importantly, gets us being more proactive about topology changes which could then be reflected upwards to CAM so that the periph driver can be informed sooner rather than later when things arrive or depart. --- Add in the (correct) usage of locking macros- we now have lock transition macros which allow us to transition from holding the CAM lock (Giant) and grabbing the softc lock and vice versa. Switch over to having this HBA do real locking. Some folks claim this won't be a win. They're right. But you have to start somewhere, and this will begin to teach us how to DTRT for HBAs, etc. -- Start putting in prototype 2300 support. Add back in LIP and Loop Reset as async events that each platform will handle. Add in another int_bogus instrumentation point. Do some more substantial target mode cleanups. MFC after: 8 weeks
* After loading f/w, for FC cards print out Firmware Attributes.mjacob2001-04-041-51/+72
| | | | | | | | | | | | | Redo establishment of default SCSI parameters whether or not we've been compiled for target mode. Unfortunately, the Qlogic f/w is confused so that if we set all targets to be 'safe' (i.e., narrow/async), it will also then report narrow, async if we're contacted in target mode from that target (acting in initiator role). D'oh! Fix ISPCTL_TOGGLE_TMODE to correctly enable the right channel for dual channel cards. Add some more opcodes. Fix a stupid NULL pointer bug.
OpenPOWER on IntegriCloud