Fix an oops where we wiped out DMA maps. Don't allocate extended
command space for anything less than a 2300.

MFC after: 1 month
X-MFC: 238869

Merge head r233826 through r239010.

Oops. We only do allocate room for extended commands
and responses for 2300 cards are newer.

Sponsored by: Spectralogic
Noticed by: Our Friend Manfred
MFC after: 1 month
X-MFC: 238869

-----------
MISC CHANGES

Add a new async event- ISP_TARGET_NOTIFY_ACK, that will guarantee
eventual delivery of a NOTIFY ACK. This is tons better than just
ignoring the return from isp_notify_ack an

-----------
MISC CHANGES

Add a new async event- ISP_TARGET_NOTIFY_ACK, that will guarantee
eventual delivery of a NOTIFY ACK. This is tons better than just
ignoring the return from isp_notify_ack and hoping for the best.

Clean up the lower level lun enable code to be a bit more sensible.

Fix a botch in isp_endcmd which was messing up the sense data.

Fix notify ack for SRR to use a sensible error code in the case
of a reject.

Clean up and make clear what kind of firmware we've loaded and
what capabilities it has.
-----------
FULL (252 byte) SENSE DATA

In CTIOs for the ISP, there's only a limimted amount of space
to load SENSE DATA for associated CHECK CONDITIONS (24 or 26
bytes). This makes it difficult to send full SENSE DATA that can
be up to 252 bytes.

Implement MODE 2 responses which have us build the FCP Response
in system memory which the ISP will put onto the wire directly.

On the initiator side, the same problem occurs in that a command
status response only has a limited amount of space for SENSE DATA.
This data is supplemented by status continuation responses that
the ISP pushes onto the response queue after the status response.
We now pull them all together so that full sense data can be
returned to the periph driver.

This is supported on 23XX, 24XX and 25XX cards.

This is also preparation for doing >16 byte CDBs.

-----------
FC TAPE

Implement full FC-TAPE on both initiator and target mode side. This
capability is driven by firmware loaded, board type, board NVRAM
settings, or hint configuration options to enable or disable. This
is supported for 23XX, 24XX and 25XX cards.

On the initiator side, we pretty much just have to generate a command
reference number for each command we send out. This is FCP-4 compliant
in that we do this per ITL nexus to generate the allowed 1 thru 255
CRN.

In order to support the target side of FC-TAPE, we now pay attention
to more of the PRLI word 3 parameters which will tell us whether
an initiator wants confirmed responses. While we're at it, we'll
pay attention to the initiator view too and report it.

On sending back CTIOs, we will notice whether the initiator wants
confirmed responses and we'll set up flags to do so.

If a response or data frame is lost the initiator sends us an SRR
(Sequence Retransmit Request) ELS which shows up as an SRR notify
and all outstanding CTIOs are nuked with SRR Received status. The
SRR notify contains the offset that the initiator wants us to restart
the data transfer from or to retransmit the response frame.

If the ISP driver still has the CCB around for which the data segment
or response applies, it will retransmit.

However, we typically don't know about a lost data frame until we
send the FCP Response and the initiator totes up counters for data
moved and notices missing segments. In this case we've already
completed the data CCBs already and sent themn back up to the periph
driver. Because there's no really clean mechanism yet in CAM to
handle this, a hack has been put into place to complete the CTIO
CCB with the CAM_MESSAGE_RECV status which will have a MODIFY DATA
POINTER extended message in it. The internal ISP target groks this
and ctl(8) will be modified to deal with this as well.

At any rate, the data is retransmitted and an an FCP response is
sent. The whole point here is to successfully complete a command
so that you don't have to depend on ULP (SCSI) to have to recover,
which in the case of tape is not really possible (hence the name
FC-TAPE).

Sponsored by: Spectralogic
MFC after: 1 month

show more ...

Merge head r236710 through r238467.

IFC @238412.

IFC @ r238370

Clean up multi-id mode so it's driven by the f/w loaded,
not by some hint setting. Do more preparations for FC-Tape.
Clean up resource counting for 24XX or later chipsets so
we find out after EXEC_F

Clean up multi-id mode so it's driven by the f/w loaded,
not by some hint setting. Do more preparations for FC-Tape.
Clean up resource counting for 24XX or later chipsets so
we find out after EXEC_FIRMWARE what is actually supported.
Set target mode exchange count based upon whether or not
we are supporting simultaneous target/initiator mode. Clean
up some old (pre-24XX) xfwoption and zfwoption issues.

Sponsored by: Spectralogic
MFC after: 3 days

show more ...

Prepare for FC-Tape support. This involved doing a lot of little cleanups
and crosschecks against firmware documentation. We now check and report
FC firmware attributes and at least are now prepared

Prepare for FC-Tape support. This involved doing a lot of little cleanups
and crosschecks against firmware documentation. We now check and report
FC firmware attributes and at least are now prepared for the upper 48 bits
of f/w attributes (which are probably for the 8100 or later cards). This
involed changing how inbits and outbits are calculated for varios commands,
hopefully clearer and cleaner. This also caused me to clean up the actual
mailbox register usage. Finally, we are now unconditionally using a CRN
for initiator mode.

A longstanding issue with the 2400/2500 is that they do *not* support
a "Prefer PTP followed by loop", which explains why enabling that
caused the f/w to crash.

A slightly more invasive change is to let the firmware load entirely
drive whether multi_id support is enabled or not.

Sponsored by: Spectralogic
MFC after: 1 week

show more ...

If debug values were set, the default from tval floated
down and triggered an attempt to set multiple virtual
ports whether you wanted them or not.

MFC after: 3 days

Merge head r233826 through r236557.

Adding missing dependancies for loading hptiop(4), hptmv(4) and isp(4) as modules.

PR: kern/166239
Submitted by: Pavel Timofeev <timp87@gmail.com>
Discussed on: -stable, -scsi
Reviewed by: scottl
N

Adding missing dependancies for loading hptiop(4), hptmv(4) and isp(4) as modules.

PR: kern/166239
Submitted by: Pavel Timofeev <timp87@gmail.com>
Discussed on: -stable, -scsi
Reviewed by: scottl
No objection from: mjacob
Approved by: cperciva
MFC after: 3 days

show more ...

IFC @230489 (pending review).

IFC @ r227804

Pull in the virtio drivers from head.

Was chasing down a failure to load f/w on a 2400. It turns out that the card
is actually broken, or needs a BIOS upgrade for 64 bit loads, but this uncovered
a couple of misplaced opcode definitions

Was chasing down a failure to load f/w on a 2400. It turns out that the card
is actually broken, or needs a BIOS upgrade for 64 bit loads, but this uncovered
a couple of misplaced opcode definitions and some missing continual mbox command
cases, so might as well update them here.

show more ...

IFC @ r225592

sys/dev/bvm/bvm_console.c - move up to the new alt-break order.

Integrate FreeBSD/head into projects/zfsd/head as of SVN revision 224870.

Most of these changes to isp are to allow for isp.ko unloading.
We also revive loop down freezes. We also externaliz within isp
isp_prt_endcmd so something outside the core module can print
something

Most of these changes to isp are to allow for isp.ko unloading.
We also revive loop down freezes. We also externaliz within isp
isp_prt_endcmd so something outside the core module can print
something about a command completing. Also some work in progress to
assist in handling timed out commands better.

Partially Sponsored by: Panasas
Approved by: re (kib)
MFC after: 1 month

show more ...

Merge svn+ssh://svn.freebsd.org/base/head@219553

Add support QLE220 card- an 2500 lookalike.

Obtained mostly from: Roman && Konstantin
MFC after: 1 week

Merge svn+ssh://svn.freebsd.org/base/head@218816

- Use the correct DMA tag/map pair for synchronize the FC scratch area.
- Allocate coherent DMA memory for the request/response queue area and
and the FC scratch area.

These changes allow isp(4) t

- Use the correct DMA tag/map pair for synchronize the FC scratch area.
- Allocate coherent DMA memory for the request/response queue area and
and the FC scratch area.

These changes allow isp(4) to work properly on sparc64 with usage of the
IOMMU streaming buffers enabled.

Approved by: mjacob
MFC after: 2 weeks

show more ...

Merge svn+ssh://svn.freebsd.org/base/head@208879

Various minor and not so minor fixes suggested by Coverity.
In at least one case, it's amazing that target mode worked at all.

Found by: Coverity.
MFC after: 2 weeks

MFC: r207570

On sparc64 obtain the initiator ID from the Open Firmware device tree
in order to match what the PROM built-in driver uses.