History log of /freebsd/sys/dev/isp/isp_pci.c (Results 201 – 225 of 444)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
Revision tags: release/5.0.0_cvs, release/5.0.0
# 76514802 02-Jan-2003 Matt Jacob <mjacob@FreeBSD.org>

Make compiles (LINT and/or ISP_TARGET_MODE options) happier by making sure
printf type format args and actual args match.

Reviewed by: Sam Leffler <sam@errno.com>


# f556e83b 11-Oct-2002 Matt Jacob <mjacob@FreeBSD.org>

This should enable 10160 support. As best as I can tell, the same
f/w as 12160 is used, and otherwise, this is just a single channel
variant of the 10160.

MFC after: 0 days


Revision tags: release/4.7.0_cvs
# 435a9337 23-Sep-2002 Matt Jacob <mjacob@FreeBSD.org>

Re-specify the bus space creation such that if we have ISP_DAC_SUPPORTED
defined, we set the address space limitation to BUS_SPACE_UNRESTRICTED,
otherwise to BUS_SPACE_MAXADDR_32BIT.

If we have a 12

Re-specify the bus space creation such that if we have ISP_DAC_SUPPORTED
defined, we set the address space limitation to BUS_SPACE_UNRESTRICTED,
otherwise to BUS_SPACE_MAXADDR_32BIT.

If we have a 1240, ULTRA2 or better, or an FC card, the boundary limit
is BUS_SPACE_UNRESTRICTED and segment limit is BUS_SPACE_MAXADDR_32BIT.

The older 1020/1040 cards have boundary and segment limits of
BUS_SPACE_MAXADDR_24BIT.

show more ...


# fc3bbaaa 17-Aug-2002 Matt Jacob <mjacob@FreeBSD.org>

Fix the incorrect parsing of the Risc2Host isr. For RIO_16,
fast posting command completion, and fast post CTIO completion,
the upper half of Risc2Host is a copy of mailbox #1- *not*
mailbox #0.

MFC

Fix the incorrect parsing of the Risc2Host isr. For RIO_16,
fast posting command completion, and fast post CTIO completion,
the upper half of Risc2Host is a copy of mailbox #1- *not*
mailbox #0.

MFC after: 1 day

show more ...


Revision tags: release/4.6.2_cvs, release/4.6.2
# 43722a42 25-Jul-2002 Matt Jacob <mjacob@FreeBSD.org>

Don't test against default_iid being zero as a test for whether we
set something- iid 0 is valid.


# 72429e49 25-Jul-2002 Matt Jacob <mjacob@FreeBSD.org>

Make sure that if are in fact using 'full SMP', make the interrupt
flags include INTR_MPSAFE. Put the flags in a common place so that
both isp_sbus && isp_pci DTRT.

In isp_mbxdma setup, drop any loc

Make sure that if are in fact using 'full SMP', make the interrupt
flags include INTR_MPSAFE. Put the flags in a common place so that
both isp_sbus && isp_pci DTRT.

In isp_mbxdma setup, drop any locks prior to calling things like
bus_dmatag_create. This gets rid of these obnoxious WITNESS messages
about 'sleeping with locks held' blah blah blah blah blah.

show more ...


Revision tags: release/4.6.1
# 73030e03 11-Jul-2002 Matt Jacob <mjacob@FreeBSD.org>

'Support' for ISP SBus cards.

This code does not imply that SBus cards work yet. They hang for me.
But I can't netboot the latest snapshot on my ultra1e, and things
hang at bus_setup_intr time.

Sin

'Support' for ISP SBus cards.

This code does not imply that SBus cards work yet. They hang for me.
But I can't netboot the latest snapshot on my ultra1e, and things
hang at bus_setup_intr time.

Since I'm offline for a while, I thought I'd toss this in in case somebody
else who has a bit better luck wants to fart around with it. Please try
and wait until I get back to check things in.

show more ...


# ed753e82 08-Jul-2002 Matt Jacob <mjacob@FreeBSD.org>

Add override so that we can force set our hard loopdid.

MFC after: 1 week


Revision tags: release/4.6.0_cvs
# fc087171 16-Jun-2002 Matt Jacob <mjacob@FreeBSD.org>

Set all 23XX cards as 'touched' (we have trouble, unpredictably, about
running ABOUT FIRMWARE with some that were started by BIOS downloads).

Redo CTIO2 dma mapping- use continuation segments instea

Set all 23XX cards as 'touched' (we have trouble, unpredictably, about
running ABOUT FIRMWARE with some that were started by BIOS downloads).

Redo CTIO2 dma mapping- use continuation segments instead of multiple
CTIO2s. Thanks to Veritas for sponsoring this work (in a different
context).

MFC after: 1 week

show more ...


# 029f13c6 05-Apr-2002 Matt Jacob <mjacob@FreeBSD.org>

Fix bus dma segment count to be based off of MAXPHYS, not BUS_SPACE_MAXSIZE.
Grumble. I've seen better documented architectures out of Redmond.

Redo fabric evaluation to not use GET ALL NEXT (GA_NXT

Fix bus dma segment count to be based off of MAXPHYS, not BUS_SPACE_MAXSIZE.
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

show more ...


# 6008862b 04-Apr-2002 John Baldwin <jhb@FreeBSD.org>

Change callers of mtx_init() to pass in an appropriate lock type name. In
most cases NULL is passed, but in some cases such as network driver locks
(which use the MTX_NETWORK_LOCK macro) and UMA zon

Change callers of mtx_init() to pass in an appropriate lock type name. In
most cases NULL is passed, but in some cases such as network driver locks
(which use the MTX_NETWORK_LOCK macro) and UMA zone locks, a name is used.

Tested on: i386, alpha, sparc64

show more ...


# 1923f739 03-Apr-2002 Matt Jacob <mjacob@FreeBSD.org>

Redo stuff for sparc64- primarily fix bus dma implementation. The endian
stuff was right, but the busdma stuff was massively not right.

Didn't really test on ia64 or i386- don't have the former h/w

Redo stuff for sparc64- primarily fix bus dma implementation. The endian
stuff was right, but the busdma stuff was massively not right.

Didn't really test on ia64 or i386- don't have the former h/w and my
FreeBSD-current disk is unwell right now. Hope that this is okay.

MFC after: 1 week

show more ...


# d134aa0b 18-Feb-2002 Matt Jacob <mjacob@FreeBSD.org>

More for f/w crash dumps (bug fixing and adding ioctl entry points
and hints to enable for specific units)

MFC after: 1 week


# 3f02619f 17-Feb-2002 Matt Jacob <mjacob@FreeBSD.org>

Hints for WWN are now WWNN and/or WWPN.

MFC after: 1 week


# 75c1e828 04-Feb-2002 Matt Jacob <mjacob@FreeBSD.org>

+ 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 offs

+ 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

show more ...


Revision tags: release/4.5.0_cvs, release/4.4.0_cvs
# 4fd13c1b 11-Dec-2001 Matt Jacob <mjacob@FreeBSD.org>

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

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

show more ...


# 3bd40330 06-Oct-2001 Matt Jacob <mjacob@FreeBSD.org>

Whups- remember to zero the isr pointer arg.


# db4fa023 06-Oct-2001 Matt Jacob <mjacob@FreeBSD.org>

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

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

show more ...


# b96934e8 04-Sep-2001 Matt Jacob <mjacob@FreeBSD.org>

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 re

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

show more ...


# 126ec864 31-Aug-2001 Matt Jacob <mjacob@FreeBSD.org>

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 th

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

show more ...


# 559a1ad2 04-Jul-2001 Matt Jacob <mjacob@FreeBSD.org>

Some possibly helpful casts.


# 22941bd7 15-Jun-2001 Peter Wemm <peter@FreeBSD.org>

Fix warnings:
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

Fix warnings:
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

show more ...


# 5d571944 28-May-2001 Matt Jacob <mjacob@FreeBSD.org>

Spring MegaChange #1.

----

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

Spring MegaChange #1.

----

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

show more ...


Revision tags: release/4.3.0_cvs, release/4.3.0
# e9a2738a 04-Apr-2001 Matt Jacob <mjacob@FreeBSD.org>

Complete some Ansification. Check to make sure, in tdma_mk, that we won't
overflow the request queue. The reason we want to do this is that we
now push out completed CTIOs as we complete them- this g

Complete some Ansification. Check to make sure, in tdma_mk, that we won't
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.

show more ...


# b72b1569 21-Mar-2001 Matt Jacob <mjacob@FreeBSD.org>

For parallel SCSI, let us now do status with the final CTIO. For the 1080,
I was hanging after sending a xfer CTIO and a status CTIO for a non-discon
INQUIRY- the xfer CTIO was returned as completed

For parallel SCSI, let us now do status with the final CTIO. For the 1080,
I was hanging after sending a xfer CTIO and a status CTIO for a non-discon
INQUIRY- the xfer CTIO was returned as completed OK, but the status CTIO
was dropped on the floor. All the fields looked good. I don't know why
it got dropped. But allowing status to go back with data xfer seemed to
work. I also noticed that with a non-disconnecting command that the
firmware handle in the ATIO is zero- this leads me to believe that the
f/w really can only handle one CTIO at a time in the discon case, and
it had no idea what to do with the second (status) CTIO.

show more ...


12345678910>>...18