summaryrefslogtreecommitdiffstats
path: root/sys/dev/isp
Commit message (Collapse)AuthorAgeFilesLines
* 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
* Add 2 Gigabit Fibre Channel support (2300 && 2312 cards). This requiredmjacob2001-08-317-294/+599
| | | | | | | | | | 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
* Add MBOX_GET_PCI_PARAMS alias.mjacob2001-08-201-0/+1
| | | | MFC after: 2 weeks
* oops- typo in a previous commitmjacob2001-08-161-1/+1
|
* Fix a spelling error in a comment.mjacob2001-08-161-1/+1
|
* Add more MBOX and ASYNC event defines.mjacob2001-08-161-0/+4
| | | | MFC after: 2 weeks
* Thanks to PHK for spotting: ISPASYNC_UNHANDLED_RESPONSE notmjacob2001-08-161-1/+2
| | | | handle in isp_async.
* 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-52/+47
| | | | | | | | | | | 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). This probably isn't entirely final as yet- but it's a lot closer to now being what it should be, including allowing camcontrol to actually set specific settings.
* Redo how we manage SCSI device settings- have a 3rd flags (nvram) that recordsmjacob2001-07-301-9/+13
| | | | | | | | | 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). Roll core minor.
* 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).
* Remove ISP_SMPLOCK stuff- we're just using locking now.mjacob2001-07-251-53/+40
| | | | | | | | | | Correctly reintroduce loop_seen_once semantics- that is, if we've never seen good link, start bouncing commands with CAM_SEL_TIMEOUT. But we have to be careful to have let ourselves try (in isp_kthread) to check for loop up at least once. PR: 28992 MFC after: 1 week
* Roll minor version. Remove ISP_SMPLOCK nonsense. We're using full locking,mjacob2001-07-251-19/+2
| | | | | | and that's final. MFC after: 1 week
* 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
* Oops- missed a CAMLOCK_2_ISP case.mjacob2001-07-051-0/+1
|
* Things have become cinched down more tightly about assertions for Giant.mjacob2001-07-051-4/+22
| | | | | This uncovered some missing spots where I trade off between isp's lock and Giant as I enter CAM.
* Add CAM_NEW_TRAN_CODE support. Use correct CAMLOCK_2_ISPLOCK macros.mjacob2001-07-041-31/+234
| | | | | | | | | For fibre channel, start going for the gusto and using AC_FOUND_DEVICE and AC_LOST_DEVICE calls to xpt_async when devices appear and disappear as the loop or fabric changes. ISPASYNC_FW_CRASH is the async event code where the platform layer deals with a firmware crash.
* Macroize request/response in/out queue pointer access.mjacob2001-07-041-1/+1
|
* Some possibly helpful casts.mjacob2001-07-041-3/+3
|
* Add a microcomment about how you'd use ispds64_t or ispdlist_tmjacob2001-07-041-0/+8
| | | | for CTIO3/CTIO4 entries.
* Add a bunch of additional defines for completion codes. Definemjacob2001-07-041-16/+75
| | | | | | | | | | some of the RIO (reduced interrupt operation) stuff. Add 64 bit data list (DSD type 1) and arbitrary data list (DSD type 2) data structure defines. Add macros that parameterize usage of the Request/Response in/out queue pointers. When we finish 2300 support, different registers will be accessed for the 2300.
* Firmware crashes handled in platform specific code (isp_async call).mjacob2001-07-041-3/+5
| | | | Fix longstanding silly buglet that left a hole in the debug log defines.
* 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.
* Fix warnings:peter2001-06-151-1/+1
| | | | | | 554: passing arg 4 of `resource_string_value' from incompatible pointer type 576: passing arg 4 of `resource_string_value' from incompatible pointer type 593: passing arg 4 of `resource_string_value' from incompatible pointer type
* 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-053-10/+14
| | | | | | 'force logout' path. MFC after: 4 weeks
* Spring MegaChange #1.mjacob2001-05-289-255/+565
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ---- 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
* Redo a lot of the target mode infrastructure to be cognizant of Dual Busmjacob2001-04-041-188/+215
| | | | | | cards like the 1280 && the 12160. Cleanup isp_target_putback_atio. Make sure bus and correct tag ids and firmware handles get propagated as needed.
* Roll platform minor.mjacob2001-04-041-15/+11
| | | | | Change target mode state definitions to be aware of 'channel' (for the dualbus 1280/12160 cards).
* Complete some Ansification. Check to make sure, in tdma_mk, that we won'tmjacob2001-04-041-17/+37
| | | | | | | | | | | | | | | | | overflow the request queue. The reason we want to do this is that we now push out completed CTIOs as we complete them- this gets the QLogic working on them quicker. So we need to know whether we can put the entire burrito out before we start. We now support conjoint status with data for the last CTIO for both Fibre Channel and SCSI. Leave the old code in place in case we need to go back (minor 3 line ifdef). Ultra-ultra important- *don't* set rq->req_seg_count for non-data target mode requests in isp_pci_dmasetup. D'oh- this is actually the tag value area for a CTIO. What *was* I thinking? Boy howdy does both aic7xxx and sym get awfully unhappy when on reconnect you give them a constant '1' for a tag value.
OpenPOWER on IntegriCloud