summaryrefslogtreecommitdiffstats
path: root/sys/dev/isp/isp.c
Commit message (Collapse)AuthorAgeFilesLines
...
* 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.
* In order to save ourselves grief with the SUNPRO compiler undermjacob2001-03-141-98/+40
| | | | | | Solaris (which, for reasons unknown to me, chokes on u_int16_t as a typedef of unsigned short if used in a transitional (mixed K&R and ANSI) way), we'll go the extra mile and fully ANSIfy things.
* Remove a superfluous newline in a string (isp_prt adds this).mjacob2001-03-041-2/+2
| | | | Fix a missed conversion of 32 to 16 bit handles.
* Switch to using 16 bit handles instead of 32 bit handles.mjacob2001-03-021-16/+51
| | | | | | | | | | | | | | | | | | | | | | | | | This is a pretty invasive change, but there are three good reasons to do this: 1. We'll never have > 16 bits of handle. 2. We can (eventually) enable the RIO (Reduced Interrupt Operation) bits which return multiple completing 16 bit handles in mailbox registers. 3. The !)$*)$*~)@$*~)$* Qlogic target mode for parallel SCSI spec changed such that at_reserved (which was 32 bits) was split into two pieces- and one of which was a 16 bit handle id that functions like the at_rxid for Fibre Channel (a tag for the f/w to correlate CTIOs with a particular command). Since we had to muck with that and this changed the whole handler architecture, we might as well... Propagate new at_handle on through int ct_fwhandle. Follow implications of changing to 16 bit handles. These above changes at least get Qlogic 1040 cards working in target mode again. 1080/12160 cards don't work yet. In isp.c: Prepare for doing all loop management in outer layers.
* Fix a longstanding bug- we had the sense of what bit 14mjacob2001-02-231-10/+17
| | | | | | | | | | | | | | | for the ICB firmware options meant- *I* had taken it to mean that if you set it, Node Name would be ignored and derived from Port Name. Actually, it meant the opposite. As a consequence- change ICBOPT_USE_PORTNAME to the define ICBOPT_BOTH_WWNS- makes more sense. Fix wrong input bitmap for MBOX_DUMP_RAM command. Call ISP_DUMPREGS if we get a f/w crash. Add ISPCTL_RUN_MBOXCMD control command (so outer layers can run a mailbox command directly) and add a ISPASYNC_UNHANDLED_RESPONSE hook so outer layers can understand response queue entries we might not know about.
* Minor stuff:mjacob2001-02-111-370/+593
| | | | | | | | | | | | | | | | | | | | | | | Remove ISP2100_FABRIC defines- we always handle fabric now. Insert isp_getmap helper function (for getting Loop Position map). Make sure we (for our own benefit) mark req_state_flags with RQSF_GOT_SENSE for Fibre Channel if we got sense data- the !*$)!*$)~*$)*$ Qlogic f/w doesn't do so. Add ISPCTL_SCAN_FABRIC, ISPCTL_SCAN_LOOP, ISPCTL_SEND_LIP, and ISPCTL_GET_POSMAP isp_control functions. Correctly send async notifications upstream for changes in the name server, changes in the port database, and f/w crashes. Correctly set topology when we get a ASYNC_PTPMODE event. Major stuff: Quite massively redo how we handle Loop events- we've now added several intermediate states between LOOP_PDB_RCVD and LOOP_READY. This allows us a lot finer control about how we scan fabric, whether we go further than scanning fabric, how we look at the local loop, and whether we merge entries at the level or not. This is the next to last step for moving managing loop state out of the core module entirely (whereupon loop && fabric events will simply freeze the command queue and a thread will run to figure out what's changed and *it* will re-enable the queu). This fine amount of control also gets us closer to having an external policy engine decide which fabric devices we really want to log into.
* When resetting the Qlogic 2X00 units, reset the FPM (Fibre Protocolmjacob2001-01-151-75/+134
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Module) and FBM (Fibre Buffer Modules). Also remember to clear the semaphore registers. Tell the RISC processor to not halt on FPM parity errors. Throw out the ISP_CFG_NOINIT silliness and instead go to the use of adapter 'roles' to see whether one completes initialization or not (mostly for Fibre Channel). The ultimate intent, btw, of all of this is to have a warm standby adapter for failover reasons. Because we do roles now, setting of Target Capable Class 3 service parameters in the ICB for the 2x00 cards reflects from role. Also, in isp_start, if we're not supporting an initiator role, we bounce outgoing commands with a Selection Timeout error. Also clean out the TOGGLE_TMODE goop for FC- there is no toggling of target mode like there is for parallel SCSI cards. Do more cleanup with respect to using target ids 0..125 in F-port topologies. Also keep track of things which *were* fabric devices so that when you rescan the fabric you can notify the outer layers when fabric devices go away. Only force a LOGOUT for fabric devices if they're still logged in (i.e., you cat their Port Database entry. Clean up the Get All Next scanning. Finally, use a new tag in the softc to store the opcode for the last mailbox command used so we can report which opcode timed out.
* Add a isp_register_fc4_type function so that we work with McData switchesmjacob2001-01-091-39/+108
| | | | | | | | that require us to register our FC4 types of interest. Allow ourselves, in F-port topologies, to start logging in fabric devices in the target 0..125 range. Change ISPASYNC_PDB_CHANGED (misnamed) to ISPASYNC_LOGGED_INOUT. Fix (*SMACK*) again some default WWN stuff. This is *really* hard to get right across all the range of platforms.
* Change the modification of what could be a const string. Apparently themjacob2000-12-301-3/+2
| | | | | | | | | | | | | construct: char *foo; ... foo = "XXX"; ... foo[1] = 'Y'; is wrong. IT blew up on NetBSD-sparc64 because that platform write-protects constant strings.
* Add in Bill Sommerfelds -Wformat changes. Set up default node && portmjacob2000-12-291-31/+35
| | | | | | | | | WWNs correctly (Again!) - this time for the case that we're not going to fully init the adapter if isp_init is called (with ISP_CFG_NOINIT set in options). The pupose for this is to bring the adapter up to almost ready to go, get info out of NVRAM, but to not start it up- leaving it until later to actually start things up if wanted (and possibly with different roles selected).
* Make the Not RESPONSE in RESPONSE QUEUE message have a bit more infomjacob2000-12-021-14/+36
| | | | | | | | (specifically, how many entries we've looked at so far). Maintain interrupt instrumentation. Use USEC_SLEEP instead of USEC_DELAY in a number of places (this allows us to drop locks and sleep instead of spin). Track changes to configuration options for topology preference. Fix botched order of printout for Channel, Target, Lun.
OpenPOWER on IntegriCloud