Commit Graph

390 Commits

Author SHA1 Message Date
Matt Jacob
f553351ed2 Reorder some of the ioctls and add a few new ones.
MFC after:	1 day
2002-02-21 23:30:05 +00:00
Matt Jacob
014e78d18c Fix a problem where a local loop disk logs out- and we get a PORT LOGGED
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
2002-02-21 01:56:08 +00:00
Matt Jacob
d134aa0b20 More for f/w crash dumps (bug fixing and adding ioctl entry points
and hints to enable for specific units)

MFC after:	1 week
2002-02-18 00:00:34 +00:00
Matt Jacob
b894188248 Support for f/w crash dumps (2200 && 23XX).
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
2002-02-17 06:38:22 +00:00
Matt Jacob
3f02619fb8 Hints for WWN are now WWNN and/or WWPN.
MFC after:	1 week
2002-02-17 06:34:21 +00:00
Matt Jacob
01ff579d86 Add in support firmware crash dumps. Change CFG options to split
WWN into WWNN and WWPN.

MFC after:	1 week
2002-02-17 06:32:58 +00:00
Matt Jacob
75c1e828c0 + A variety of 23XX changes:
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
2002-02-04 21:04:25 +00:00
Matt Jacob
975284da32 Add missing move of relative offset for CTIO2 updates. 2002-01-11 23:48:25 +00:00
Matt Jacob
2903b27203 Implement REDUCED INTERRUPT OPERATION usage form FC cards- this allows the
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
2002-01-03 20:43:22 +00:00
Matt Jacob
c748b5e634 Explicitly decode GetAllNext SNS Response back *as*
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.
2001-12-11 21:58:04 +00:00
Matt Jacob
4fd13c1ba2 Major restructuring for swizzling to the request queue and unswizzling from
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
2001-12-11 00:18:45 +00:00
Matt Jacob
fc16d270b7 Tra-La, another QLogic f/w funny- this time with the 2300.
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
2001-10-23 23:05:20 +00:00
Matt Jacob
8b8e73049d Protect against deranged fabric nameservers that spit out 10000 identical
port numbers.

MFC after:	1 day
2001-10-18 17:26:52 +00:00
Matt Jacob
1c3749836f Add some somewhat vague documentation for this driver and a list
of Hardware that might, in fact, work.
2001-10-07 18:26:47 +00:00
Matt Jacob
71793c0dc4 Some patches from Doug for ia64 support- the principle one being the
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
2001-10-07 18:18:50 +00:00
Matt Jacob
cd37f56f5a Misunderstanding documentation caused me to try and set 1Gbps/2Gps/Auto
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.
2001-10-06 20:41:18 +00:00
Matt Jacob
3bd4033010 Whups- remember to zero the isr pointer arg. 2001-10-06 19:34:43 +00:00
Matt Jacob
db4fa023f8 Respect QLogic's errata- read BIU_ISR even on the 2300
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
2001-10-06 19:19:24 +00:00
Matt Jacob
53036e9289 Begin to implement target mode that for Fibre Channel has a private
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
2001-10-01 03:48:42 +00:00
Matt Jacob
c507669af4 Implement a call to get the actual link data rate (if 23XX) so we can
set whether it's a 2Gps or 1Gps link.

MFC after:	1 week
2001-10-01 03:45:54 +00:00
Matt Jacob
83548830a7 When calling isp_reset, set the request/response in/out pointers all at
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
2001-09-29 19:37:49 +00:00
Julian Elischer
b40ce4165d KSE Milestone 2
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
2001-09-12 08:38:13 +00:00
Matt Jacob
64edff948b I don't know what I was thinking- if I have two separate busses on on
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
2001-09-04 21:53:12 +00:00
Matt Jacob
23ac1fce7b Note for ATIOs returned because of BDRs or Bus Resets for which bus this
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.
2001-09-04 21:48:02 +00:00
Matt Jacob
b96934e89a If we're on an interrupt stack, mark things so that we don't try
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
2001-09-04 21:45:57 +00:00
Matt Jacob
f6a3bcf86c I don't know what I was thinking- if I have two separate busses on on
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
2001-09-04 21:33:06 +00:00
Matt Jacob
2332ac8c61 Fix SET_IID_VAL/SET_BUS_VAL macros to usable.
MFC after:	4 weeks
2001-09-04 19:42:13 +00:00
Matt Jacob
d82b6503a9 Because we now store SCCLUN capabilities in firmware attributes, get
rid of the silly test of isp_maxluns > 16 and use the attibutes directly.

MFC after:	4 weeks
2001-09-03 03:12:10 +00:00
Matt Jacob
181640a81c Clarify issues about whether we have SCCLUN (65535 luns) or non-SCCLUN (16
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
2001-09-03 03:09:48 +00:00
Matt Jacob
f8597b62e5 Add some more firmware revision macros. Add firmware attributes field
to fcparam structure.
MFC after:	4 weeks
2001-09-03 03:03:32 +00:00
Matt Jacob
126ec86486 Add 2 Gigabit Fibre Channel support (2300 && 2312 cards). This required
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
2001-08-31 21:39:04 +00:00
Matt Jacob
ed4bea259e Clean up some ways in which we set defaults for SCSI cards
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
2001-08-20 17:28:32 +00:00
Matt Jacob
dec1985672 Add MBOX_GET_PCI_PARAMS alias.
MFC after:	2 weeks
2001-08-20 17:26:45 +00:00
Matt Jacob
169ad8cfef oops- typo in a previous commit 2001-08-16 17:39:45 +00:00
Matt Jacob
561e7bb942 Fix a spelling error in a comment. 2001-08-16 17:31:27 +00:00
Matt Jacob
dda035d1fc Add more MBOX and ASYNC event defines.
MFC after:	2 weeks
2001-08-16 17:26:03 +00:00
Matt Jacob
be534d5f1a Thanks to PHK for spotting: ISPASYNC_UNHANDLED_RESPONSE not
handle in isp_async.
2001-08-16 17:25:41 +00:00
Matt Jacob
50719f7521 Enable LIP F8, LIP Reset async events.
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
2001-08-16 17:25:08 +00:00
Matt Jacob
d51456f800 Oops- don't set 'goal' twice when you mean to set 'nvrm' as well.
This breaks bogus NVRAM boards.

MFC after:	1 day
2001-08-02 00:34:56 +00:00
Matt Jacob
9ce9bdaf8a Redo how we manage SCSI device settings- have a 3rd flags (nvram) that records
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.
2001-07-30 01:00:21 +00:00
Matt Jacob
d9c272f3ea Redo how we manage SCSI device settings- have a 3rd flags (nvram) that records
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.
2001-07-30 00:59:32 +00:00
Matt Jacob
df225582bf Redo how we manage SCSI device settings- have a 3rd flags (nvram) that records
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).
2001-07-30 00:59:06 +00:00
Matt Jacob
f44257c29a Remove ISP_SMPLOCK stuff- we're just using locking now.
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
2001-07-25 04:23:52 +00:00
Matt Jacob
3910362ab8 Roll minor version. Remove ISP_SMPLOCK nonsense. We're using full locking,
and that's final.

MFC after:	1 week
2001-07-25 04:21:53 +00:00
Matt Jacob
761d6b7150 Hmm. Let's try this on for size...
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
2001-07-11 02:34:21 +00:00
Matt Jacob
8e6a12fcad Oops- missed a CAMLOCK_2_ISP case. 2001-07-05 19:34:06 +00:00
Matt Jacob
45c9a36af5 Things have become cinched down more tightly about assertions for Giant.
This uncovered some missing spots where I trade off between isp's lock
and Giant as I enter CAM.
2001-07-05 17:14:57 +00:00
Matt Jacob
ab163f5fee Add CAM_NEW_TRAN_CODE support. Use correct CAMLOCK_2_ISPLOCK macros.
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.
2001-07-04 18:54:29 +00:00
Matt Jacob
9927912756 Macroize request/response in/out queue pointer access. 2001-07-04 18:52:23 +00:00
Matt Jacob
559a1ad2c1 Some possibly helpful casts. 2001-07-04 18:51:58 +00:00