1999-08-28 01:08:13 +00:00
|
|
|
/* $FreeBSD$ */
|
2005-01-06 01:43:34 +00:00
|
|
|
/*-
|
2001-07-25 04:21:53 +00:00
|
|
|
* Qlogic ISP SCSI Host Adapter FreeBSD Wrapper Definitions
|
2006-01-23 06:23:37 +00:00
|
|
|
*
|
2009-08-01 01:04:26 +00:00
|
|
|
* Copyright (c) 1997-2008 by Matthew Jacob
|
2006-01-23 06:23:37 +00:00
|
|
|
* All rights reserved.
|
1998-04-22 17:54:58 +00:00
|
|
|
*
|
|
|
|
|
* Redistribution and use in source and binary forms, with or without
|
|
|
|
|
* modification, are permitted provided that the following conditions
|
|
|
|
|
* are met:
|
|
|
|
|
* 1. Redistributions of source code must retain the above copyright
|
|
|
|
|
* notice immediately at the beginning of the file, without modification,
|
|
|
|
|
* this list of conditions, and the following disclaimer.
|
2000-09-21 20:16:04 +00:00
|
|
|
* 2. The name of the author may not be used to endorse or promote products
|
|
|
|
|
* derived from this software without specific prior written permission.
|
1998-04-22 17:54:58 +00:00
|
|
|
*
|
|
|
|
|
* THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
|
|
|
|
|
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
|
|
|
|
|
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
|
|
|
|
|
* ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE FOR
|
|
|
|
|
* ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
|
|
|
|
|
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
|
|
|
|
|
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
|
|
|
|
|
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
|
|
|
|
|
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
|
|
|
|
|
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
|
|
|
|
|
* SUCH DAMAGE.
|
|
|
|
|
*/
|
|
|
|
|
#ifndef _ISP_FREEBSD_H
|
|
|
|
|
#define _ISP_FREEBSD_H
|
|
|
|
|
|
1999-07-02 23:10:34 +00:00
|
|
|
#include <sys/param.h>
|
1998-04-22 17:54:58 +00:00
|
|
|
#include <sys/systm.h>
|
2002-04-26 22:48:23 +00:00
|
|
|
#include <sys/endian.h>
|
2016-04-09 14:50:47 +00:00
|
|
|
#include <sys/jail.h>
|
2001-03-28 09:17:56 +00:00
|
|
|
#include <sys/lock.h>
|
2006-04-21 18:30:01 +00:00
|
|
|
#include <sys/kernel.h>
|
|
|
|
|
#include <sys/queue.h>
|
2000-04-21 02:05:13 +00:00
|
|
|
#include <sys/malloc.h>
|
2000-10-20 07:58:15 +00:00
|
|
|
#include <sys/mutex.h>
|
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
2001-05-28 21:20:43 +00:00
|
|
|
#include <sys/condvar.h>
|
2015-12-04 19:46:49 +00:00
|
|
|
#include <sys/rman.h>
|
2011-11-06 00:44:40 +00:00
|
|
|
#include <sys/sysctl.h>
|
2006-04-21 18:30:01 +00:00
|
|
|
|
2000-07-04 01:04:35 +00:00
|
|
|
#include <sys/proc.h>
|
2001-03-01 02:15:58 +00:00
|
|
|
#include <sys/bus.h>
|
2011-08-12 19:51:28 +00:00
|
|
|
#include <sys/taskqueue.h>
|
1998-04-22 17:54:58 +00:00
|
|
|
|
1999-07-02 23:10:34 +00:00
|
|
|
#include <machine/bus.h>
|
2000-07-04 01:04:35 +00:00
|
|
|
#include <machine/cpu.h>
|
2009-08-01 01:04:26 +00:00
|
|
|
#include <machine/stdarg.h>
|
1998-04-22 17:54:58 +00:00
|
|
|
|
1999-07-02 23:10:34 +00:00
|
|
|
#include <cam/cam.h>
|
|
|
|
|
#include <cam/cam_debug.h>
|
|
|
|
|
#include <cam/cam_ccb.h>
|
|
|
|
|
#include <cam/cam_sim.h>
|
|
|
|
|
#include <cam/cam_xpt.h>
|
|
|
|
|
#include <cam/cam_xpt_sim.h>
|
|
|
|
|
#include <cam/cam_debug.h>
|
|
|
|
|
#include <cam/scsi/scsi_all.h>
|
|
|
|
|
#include <cam/scsi/scsi_message.h>
|
|
|
|
|
|
1999-10-17 18:48:16 +00:00
|
|
|
#include "opt_ddb.h"
|
1999-07-02 23:10:34 +00:00
|
|
|
#include "opt_isp.h"
|
2002-08-22 16:14:19 +00:00
|
|
|
|
2009-08-01 01:04:26 +00:00
|
|
|
#define ISP_PLATFORM_VERSION_MAJOR 7
|
2012-06-24 17:30:54 +00:00
|
|
|
#define ISP_PLATFORM_VERSION_MINOR 10
|
2006-05-16 16:31:58 +00:00
|
|
|
|
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
|
|
|
/*
|
|
|
|
|
* Efficiency- get rid of SBus code && tests unless we need them.
|
|
|
|
|
*/
|
2005-12-04 02:12:43 +00:00
|
|
|
#ifdef __sparc64__
|
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
|
|
|
#define ISP_SBUS_SUPPORTED 1
|
|
|
|
|
#else
|
|
|
|
|
#define ISP_SBUS_SUPPORTED 0
|
|
|
|
|
#endif
|
1999-04-04 01:34:06 +00:00
|
|
|
|
2002-07-25 16:02:09 +00:00
|
|
|
#define ISP_IFLAGS INTR_TYPE_CAM | INTR_ENTROPY | INTR_MPSAFE
|
2006-09-01 05:03:42 +00:00
|
|
|
|
-----------
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
2012-07-28 20:06:29 +00:00
|
|
|
#define N_XCMDS 64
|
|
|
|
|
#define XCMD_SIZE 512
|
|
|
|
|
struct ispsoftc;
|
|
|
|
|
typedef union isp_ecmd {
|
|
|
|
|
union isp_ecmd * next;
|
|
|
|
|
uint8_t data[XCMD_SIZE];
|
|
|
|
|
} isp_ecmd_t;
|
|
|
|
|
isp_ecmd_t * isp_get_ecmd(struct ispsoftc *);
|
|
|
|
|
void isp_put_ecmd(struct ispsoftc *, isp_ecmd_t *);
|
|
|
|
|
|
2000-01-03 22:15:16 +00:00
|
|
|
#ifdef ISP_TARGET_MODE
|
2009-08-01 01:04:26 +00:00
|
|
|
#define ATPDPSIZE 4096
|
2014-11-26 13:56:54 +00:00
|
|
|
#define ATPDPHASHSIZE 32
|
2013-10-17 20:19:15 +00:00
|
|
|
#define ATPDPHASH(x) ((((x) >> 24) ^ ((x) >> 16) ^ ((x) >> 8) ^ (x)) & \
|
|
|
|
|
((ATPDPHASHSIZE) - 1))
|
2009-08-01 01:04:26 +00:00
|
|
|
|
|
|
|
|
#include <dev/isp/isp_target.h>
|
2013-10-17 20:19:15 +00:00
|
|
|
typedef struct atio_private_data {
|
|
|
|
|
LIST_ENTRY(atio_private_data) next;
|
2006-02-15 00:31:48 +00:00
|
|
|
uint32_t orig_datalen;
|
|
|
|
|
uint32_t bytes_xfered;
|
2012-08-08 18:24:33 +00:00
|
|
|
uint32_t bytes_in_transit;
|
2012-06-24 17:30:54 +00:00
|
|
|
uint32_t tag; /* typically f/w RX_ID */
|
2009-08-01 01:04:26 +00:00
|
|
|
uint32_t lun;
|
|
|
|
|
uint32_t nphdl;
|
|
|
|
|
uint32_t sid;
|
|
|
|
|
uint32_t portid;
|
2012-06-24 17:30:54 +00:00
|
|
|
uint16_t rxid; /* wire rxid */
|
|
|
|
|
uint16_t oxid; /* wire oxid */
|
-----------
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
2012-07-28 20:06:29 +00:00
|
|
|
uint16_t word3; /* PRLI word3 params */
|
|
|
|
|
uint16_t ctcnt; /* number of CTIOs currently active */
|
2012-08-08 18:24:33 +00:00
|
|
|
uint8_t seqno; /* CTIO sequence number */
|
2009-08-01 01:04:26 +00:00
|
|
|
uint32_t
|
-----------
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
2012-07-28 20:06:29 +00:00
|
|
|
srr_notify_rcvd : 1,
|
|
|
|
|
cdb0 : 8,
|
|
|
|
|
sendst : 1,
|
|
|
|
|
dead : 1,
|
|
|
|
|
tattr : 3,
|
|
|
|
|
state : 3;
|
|
|
|
|
void * ests;
|
|
|
|
|
/*
|
|
|
|
|
* The current SRR notify copy
|
|
|
|
|
*/
|
|
|
|
|
uint8_t srr[64]; /* sb QENTRY_LEN, but order of definitions is wrong */
|
|
|
|
|
void * srr_ccb;
|
|
|
|
|
uint32_t nsrr;
|
2001-10-01 03:48:42 +00:00
|
|
|
} atio_private_data_t;
|
2002-06-16 05:02:25 +00:00
|
|
|
#define ATPD_STATE_FREE 0
|
|
|
|
|
#define ATPD_STATE_ATIO 1
|
|
|
|
|
#define ATPD_STATE_CAM 2
|
|
|
|
|
#define ATPD_STATE_CTIO 3
|
|
|
|
|
#define ATPD_STATE_LAST_CTIO 4
|
|
|
|
|
#define ATPD_STATE_PDON 5
|
2001-10-01 03:48:42 +00:00
|
|
|
|
2012-08-08 18:24:33 +00:00
|
|
|
#define ATPD_CCB_OUTSTANDING 16
|
|
|
|
|
|
|
|
|
|
#define ATPD_SEQ_MASK 0x7f
|
|
|
|
|
#define ATPD_SEQ_NOTIFY_CAM 0x80
|
|
|
|
|
#define ATPD_SET_SEQNO(hdrp, atp) ((isphdr_t *)hdrp)->rqs_seqno &= ~ATPD_SEQ_MASK, ((isphdr_t *)hdrp)->rqs_seqno |= (atp)->seqno
|
|
|
|
|
#define ATPD_GET_SEQNO(hdrp) (((isphdr_t *)hdrp)->rqs_seqno & ATPD_SEQ_MASK)
|
|
|
|
|
#define ATPD_GET_NCAM(hdrp) ((((isphdr_t *)hdrp)->rqs_seqno & ATPD_SEQ_NOTIFY_CAM) != 0)
|
|
|
|
|
|
2009-08-01 01:04:26 +00:00
|
|
|
typedef union inot_private_data inot_private_data_t;
|
|
|
|
|
union inot_private_data {
|
|
|
|
|
inot_private_data_t *next;
|
|
|
|
|
struct {
|
|
|
|
|
isp_notify_t nt; /* must be first! */
|
|
|
|
|
uint8_t data[64]; /* sb QENTRY_LEN, but order of definitions is wrong */
|
|
|
|
|
uint32_t tag_id, seq_id;
|
|
|
|
|
} rd;
|
|
|
|
|
};
|
-----------
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
2012-07-28 20:06:29 +00:00
|
|
|
typedef struct isp_timed_notify_ack {
|
|
|
|
|
void *isp;
|
|
|
|
|
void *not;
|
|
|
|
|
uint8_t data[64]; /* sb QENTRY_LEN, but order of definitions is wrong */
|
2014-11-18 21:03:46 +00:00
|
|
|
struct callout timer;
|
-----------
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
2012-07-28 20:06:29 +00:00
|
|
|
} isp_tna_t;
|
2009-08-01 01:04:26 +00:00
|
|
|
|
2000-01-03 22:15:16 +00:00
|
|
|
typedef struct tstate {
|
2009-08-01 01:04:26 +00:00
|
|
|
SLIST_ENTRY(tstate) next;
|
2014-11-26 13:56:54 +00:00
|
|
|
lun_id_t ts_lun;
|
2000-01-03 22:15:16 +00:00
|
|
|
struct cam_path *owner;
|
|
|
|
|
struct ccb_hdr_slist atios;
|
|
|
|
|
struct ccb_hdr_slist inots;
|
2015-11-23 10:06:19 +00:00
|
|
|
uint32_t hold;
|
|
|
|
|
uint16_t atio_count;
|
|
|
|
|
uint16_t inot_count;
|
2009-08-01 01:04:26 +00:00
|
|
|
inot_private_data_t * restart_queue;
|
|
|
|
|
inot_private_data_t * ntfree;
|
|
|
|
|
inot_private_data_t ntpool[ATPDPSIZE];
|
2013-10-17 20:19:15 +00:00
|
|
|
LIST_HEAD(, atio_private_data) atfree;
|
|
|
|
|
LIST_HEAD(, atio_private_data) atused[ATPDPHASHSIZE];
|
2009-08-01 01:04:26 +00:00
|
|
|
atio_private_data_t atpool[ATPDPSIZE];
|
2000-01-03 22:15:16 +00:00
|
|
|
} tstate_t;
|
|
|
|
|
|
2009-08-01 01:04:26 +00:00
|
|
|
#define LUN_HASH_SIZE 32
|
|
|
|
|
#define LUN_HASH_FUNC(lun) ((lun) & (LUN_HASH_SIZE - 1))
|
|
|
|
|
|
2000-01-03 22:15:16 +00:00
|
|
|
#endif
|
|
|
|
|
|
2007-05-05 20:17:23 +00:00
|
|
|
/*
|
|
|
|
|
* Per command info.
|
|
|
|
|
*/
|
|
|
|
|
struct isp_pcmd {
|
|
|
|
|
struct isp_pcmd * next;
|
-----------
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
2012-07-28 20:06:29 +00:00
|
|
|
bus_dmamap_t dmap; /* dma map for this command */
|
|
|
|
|
struct ispsoftc * isp; /* containing isp */
|
|
|
|
|
struct callout wdog; /* watchdog timer */
|
2012-08-08 18:24:33 +00:00
|
|
|
uint32_t datalen; /* data length for this command (target mode only) */
|
-----------
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
2012-07-28 20:06:29 +00:00
|
|
|
uint8_t totslen; /* sense length on status response */
|
|
|
|
|
uint8_t cumslen; /* sense length on status response */
|
|
|
|
|
uint8_t crn; /* command reference number */
|
2007-05-05 20:17:23 +00:00
|
|
|
};
|
|
|
|
|
#define ISP_PCMD(ccb) (ccb)->ccb_h.spriv_ptr1
|
|
|
|
|
#define PISP_PCMD(ccb) ((struct isp_pcmd *)ISP_PCMD(ccb))
|
|
|
|
|
|
-----------
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
2012-07-28 20:06:29 +00:00
|
|
|
/*
|
|
|
|
|
* Per nexus info.
|
|
|
|
|
*/
|
|
|
|
|
struct isp_nexus {
|
2015-10-24 17:34:40 +00:00
|
|
|
uint64_t lun; /* LUN for target */
|
|
|
|
|
uint32_t tgt; /* TGT for target */
|
|
|
|
|
uint8_t crnseed; /* next command reference number */
|
|
|
|
|
struct isp_nexus *next;
|
-----------
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
2012-07-28 20:06:29 +00:00
|
|
|
};
|
|
|
|
|
#define NEXUS_HASH_WIDTH 32
|
|
|
|
|
#define INITIAL_NEXUS_COUNT MAX_FC_TARG
|
|
|
|
|
#define NEXUS_HASH(tgt, lun) ((tgt + lun) % NEXUS_HASH_WIDTH)
|
|
|
|
|
|
2009-08-01 01:04:26 +00:00
|
|
|
/*
|
|
|
|
|
* Per channel information
|
|
|
|
|
*/
|
|
|
|
|
SLIST_HEAD(tslist, tstate);
|
2017-02-19 05:07:02 +00:00
|
|
|
TAILQ_HEAD(isp_ccbq, ccb_hdr);
|
2009-08-01 01:04:26 +00:00
|
|
|
|
|
|
|
|
struct isp_fc {
|
|
|
|
|
struct cam_sim *sim;
|
|
|
|
|
struct cam_path *path;
|
|
|
|
|
struct ispsoftc *isp;
|
|
|
|
|
struct proc *kproc;
|
2015-12-26 09:16:05 +00:00
|
|
|
bus_dmamap_t scmap;
|
2009-08-01 01:04:26 +00:00
|
|
|
uint64_t def_wwpn;
|
|
|
|
|
uint64_t def_wwnn;
|
2015-11-26 13:04:58 +00:00
|
|
|
time_t loop_down_time;
|
|
|
|
|
int loop_down_limit;
|
|
|
|
|
int gone_device_time;
|
-----------
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
2012-07-28 20:06:29 +00:00
|
|
|
/*
|
|
|
|
|
* Per target/lun info- just to keep a per-ITL nexus crn count
|
|
|
|
|
*/
|
|
|
|
|
struct isp_nexus *nexus_hash[NEXUS_HASH_WIDTH];
|
|
|
|
|
struct isp_nexus *nexus_free_list;
|
2009-08-01 01:04:26 +00:00
|
|
|
uint32_t
|
2006-11-02 03:21:32 +00:00
|
|
|
simqfrozen : 3,
|
2009-08-01 01:04:26 +00:00
|
|
|
default_id : 8,
|
2010-03-17 02:48:14 +00:00
|
|
|
def_role : 2, /* default role */
|
2006-11-14 08:45:48 +00:00
|
|
|
gdt_running : 1,
|
2009-08-01 01:04:26 +00:00
|
|
|
loop_dead : 1,
|
2015-11-26 13:04:58 +00:00
|
|
|
loop_seen_once : 1,
|
2009-12-04 03:34:12 +00:00
|
|
|
fcbsy : 1,
|
|
|
|
|
ready : 1;
|
2009-08-01 01:04:26 +00:00
|
|
|
struct callout gdt; /* gone device timer */
|
2011-08-12 19:51:28 +00:00
|
|
|
struct task gtask;
|
2009-08-01 01:04:26 +00:00
|
|
|
#ifdef ISP_TARGET_MODE
|
2017-02-19 05:07:02 +00:00
|
|
|
struct tslist lun_hash[LUN_HASH_SIZE];
|
|
|
|
|
struct isp_ccbq waitq; /* waiting CCBs */
|
-----------
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
2012-07-28 20:06:29 +00:00
|
|
|
#if defined(DEBUG)
|
|
|
|
|
unsigned int inject_lost_data_frame;
|
|
|
|
|
#endif
|
2009-08-01 01:04:26 +00:00
|
|
|
#endif
|
2014-09-18 02:01:36 +00:00
|
|
|
int num_threads;
|
2009-08-01 01:04:26 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct isp_spi {
|
|
|
|
|
struct cam_sim *sim;
|
|
|
|
|
struct cam_path *path;
|
|
|
|
|
uint32_t
|
|
|
|
|
simqfrozen : 3,
|
|
|
|
|
iid : 4;
|
|
|
|
|
#ifdef ISP_TARGET_MODE
|
2017-02-19 05:07:02 +00:00
|
|
|
struct tslist lun_hash[LUN_HASH_SIZE];
|
|
|
|
|
struct isp_ccbq waitq; /* waiting CCBs */
|
2009-08-01 01:04:26 +00:00
|
|
|
#endif
|
2014-09-18 02:01:36 +00:00
|
|
|
int num_threads;
|
2009-08-01 01:04:26 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct isposinfo {
|
|
|
|
|
/*
|
|
|
|
|
* Linkage, locking, and identity
|
|
|
|
|
*/
|
2000-10-17 18:18:14 +00:00
|
|
|
struct mtx lock;
|
2009-08-01 01:04:26 +00:00
|
|
|
device_t dev;
|
|
|
|
|
struct cdev * cdev;
|
|
|
|
|
struct intr_config_hook ehook;
|
|
|
|
|
struct cam_devq * devq;
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Firmware pointer
|
|
|
|
|
*/
|
2007-05-05 20:17:23 +00:00
|
|
|
const struct firmware * fw;
|
2009-08-01 01:04:26 +00:00
|
|
|
|
|
|
|
|
/*
|
2015-12-26 09:16:05 +00:00
|
|
|
* DMA related stuff
|
2009-08-01 01:04:26 +00:00
|
|
|
*/
|
2015-12-04 19:46:49 +00:00
|
|
|
struct resource * regs;
|
|
|
|
|
struct resource * regs2;
|
2009-08-01 01:04:26 +00:00
|
|
|
bus_dma_tag_t dmat;
|
2015-12-27 06:16:02 +00:00
|
|
|
bus_dma_tag_t reqdmat;
|
|
|
|
|
bus_dma_tag_t respdmat;
|
|
|
|
|
bus_dma_tag_t atiodmat;
|
2016-04-12 14:19:19 +00:00
|
|
|
bus_dma_tag_t iocbdmat;
|
2015-12-26 09:16:05 +00:00
|
|
|
bus_dma_tag_t scdmat;
|
2015-12-27 06:16:02 +00:00
|
|
|
bus_dmamap_t reqmap;
|
|
|
|
|
bus_dmamap_t respmap;
|
|
|
|
|
bus_dmamap_t atiomap;
|
2016-04-12 14:19:19 +00:00
|
|
|
bus_dmamap_t iocbmap;
|
2009-08-01 01:04:26 +00:00
|
|
|
|
2007-05-05 20:17:23 +00:00
|
|
|
/*
|
2009-08-01 01:04:26 +00:00
|
|
|
* Command and transaction related related stuff
|
2007-05-05 20:17:23 +00:00
|
|
|
*/
|
|
|
|
|
struct isp_pcmd * pcmd_pool;
|
|
|
|
|
struct isp_pcmd * pcmd_free;
|
|
|
|
|
|
2009-08-01 01:04:26 +00:00
|
|
|
uint32_t
|
|
|
|
|
#ifdef ISP_TARGET_MODE
|
|
|
|
|
tmwanted : 1,
|
|
|
|
|
tmbusy : 1,
|
|
|
|
|
#else
|
|
|
|
|
: 2,
|
|
|
|
|
#endif
|
-----------
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
2012-07-28 20:06:29 +00:00
|
|
|
sixtyfourbit : 1, /* sixtyfour bit platform */
|
2009-08-01 01:04:26 +00:00
|
|
|
timer_active : 1,
|
|
|
|
|
autoconf : 1,
|
|
|
|
|
ehook_active : 1,
|
|
|
|
|
mbox_sleeping : 1,
|
|
|
|
|
mbox_sleep_ok : 1,
|
|
|
|
|
mboxcmd_done : 1,
|
|
|
|
|
mboxbsy : 1;
|
|
|
|
|
|
|
|
|
|
struct callout tmo; /* general timer */
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* misc- needs to be sorted better XXXXXX
|
|
|
|
|
*/
|
|
|
|
|
int framesize;
|
|
|
|
|
int exec_throttle;
|
|
|
|
|
int cont_max;
|
|
|
|
|
|
-----------
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
2012-07-28 20:06:29 +00:00
|
|
|
bus_addr_t ecmd_dma;
|
|
|
|
|
isp_ecmd_t * ecmd_base;
|
|
|
|
|
isp_ecmd_t * ecmd_free;
|
|
|
|
|
|
2009-08-01 01:04:26 +00:00
|
|
|
/*
|
|
|
|
|
* Per-type private storage...
|
|
|
|
|
*/
|
|
|
|
|
union {
|
|
|
|
|
struct isp_fc *fc;
|
|
|
|
|
struct isp_spi *spi;
|
|
|
|
|
void *ptr;
|
|
|
|
|
} pc;
|
2014-09-18 02:01:36 +00:00
|
|
|
|
|
|
|
|
int is_exiting;
|
1998-04-22 17:54:58 +00:00
|
|
|
};
|
2009-08-01 01:04:26 +00:00
|
|
|
#define ISP_FC_PC(isp, chan) (&(isp)->isp_osinfo.pc.fc[(chan)])
|
|
|
|
|
#define ISP_SPI_PC(isp, chan) (&(isp)->isp_osinfo.pc.spi[(chan)])
|
|
|
|
|
#define ISP_GET_PC(isp, chan, tag, rslt) \
|
|
|
|
|
if (IS_SCSI(isp)) { \
|
|
|
|
|
rslt = ISP_SPI_PC(isp, chan)-> tag; \
|
|
|
|
|
} else { \
|
|
|
|
|
rslt = ISP_FC_PC(isp, chan)-> tag; \
|
|
|
|
|
}
|
|
|
|
|
#define ISP_GET_PC_ADDR(isp, chan, tag, rp) \
|
|
|
|
|
if (IS_SCSI(isp)) { \
|
|
|
|
|
rp = &ISP_SPI_PC(isp, chan)-> tag; \
|
|
|
|
|
} else { \
|
|
|
|
|
rp = &ISP_FC_PC(isp, chan)-> tag; \
|
|
|
|
|
}
|
|
|
|
|
#define ISP_SET_PC(isp, chan, tag, val) \
|
|
|
|
|
if (IS_SCSI(isp)) { \
|
|
|
|
|
ISP_SPI_PC(isp, chan)-> tag = val; \
|
|
|
|
|
} else { \
|
|
|
|
|
ISP_FC_PC(isp, chan)-> tag = val; \
|
|
|
|
|
}
|
1999-07-02 23:10:34 +00:00
|
|
|
|
-----------
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
2012-07-28 20:06:29 +00:00
|
|
|
#define FCP_NEXT_CRN isp_fcp_next_crn
|
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
2001-05-28 21:20:43 +00:00
|
|
|
#define isp_lock isp_osinfo.lock
|
2015-12-04 19:46:49 +00:00
|
|
|
#define isp_regs isp_osinfo.regs
|
|
|
|
|
#define isp_regs2 isp_osinfo.regs2
|
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
2001-05-28 21:20:43 +00:00
|
|
|
|
2000-12-02 18:33:29 +00:00
|
|
|
/*
|
|
|
|
|
* Locking macros...
|
|
|
|
|
*/
|
2014-11-19 13:04:25 +00:00
|
|
|
#define ISP_LOCK(isp) mtx_lock(&(isp)->isp_osinfo.lock)
|
|
|
|
|
#define ISP_UNLOCK(isp) mtx_unlock(&(isp)->isp_osinfo.lock)
|
|
|
|
|
#define ISP_ASSERT_LOCKED(isp) mtx_assert(&(isp)->isp_osinfo.lock, MA_OWNED)
|
2000-12-02 18:33:29 +00:00
|
|
|
|
2000-08-01 06:29:55 +00:00
|
|
|
/*
|
|
|
|
|
* Required Macros/Defines
|
|
|
|
|
*/
|
2009-08-01 01:04:26 +00:00
|
|
|
#define ISP_FC_SCRLEN 0x1000
|
2000-07-04 01:04:35 +00:00
|
|
|
|
2009-08-01 01:04:26 +00:00
|
|
|
#define ISP_MEMZERO(a, b) memset(a, 0, b)
|
|
|
|
|
#define ISP_MEMCPY memcpy
|
|
|
|
|
#define ISP_SNPRINTF snprintf
|
2015-11-07 18:26:02 +00:00
|
|
|
#define ISP_DELAY(x) DELAY(x)
|
|
|
|
|
#if __FreeBSD_version < 1000029
|
2015-11-07 19:33:57 +00:00
|
|
|
#define ISP_SLEEP(isp, x) msleep(&(isp)->isp_osinfo.is_exiting, \
|
2015-11-07 18:26:02 +00:00
|
|
|
&(isp)->isp_osinfo.lock, 0, "isp_sleep", ((x) + tick - 1) / tick)
|
|
|
|
|
#else
|
2015-11-07 19:33:57 +00:00
|
|
|
#define ISP_SLEEP(isp, x) msleep_sbt(&(isp)->isp_osinfo.is_exiting, \
|
2015-11-07 18:26:02 +00:00
|
|
|
&(isp)->isp_osinfo.lock, 0, "isp_sleep", (x) * SBT_1US, 0, 0)
|
|
|
|
|
#endif
|
2009-08-01 01:04:26 +00:00
|
|
|
|
2011-02-28 15:58:30 +00:00
|
|
|
#define ISP_MIN imin
|
|
|
|
|
|
2009-08-01 01:04:26 +00:00
|
|
|
#ifndef DIAGNOSTIC
|
|
|
|
|
#define ISP_INLINE __inline
|
|
|
|
|
#else
|
|
|
|
|
#define ISP_INLINE
|
|
|
|
|
#endif
|
2000-07-04 01:04:35 +00:00
|
|
|
|
2000-08-01 06:29:55 +00:00
|
|
|
#define NANOTIME_T struct timespec
|
|
|
|
|
#define GET_NANOTIME nanotime
|
|
|
|
|
#define GET_NANOSEC(x) ((x)->tv_sec * 1000000000 + (x)->tv_nsec)
|
2006-11-14 08:45:48 +00:00
|
|
|
#define NANOTIME_SUB isp_nanotime_sub
|
2000-07-04 01:04:35 +00:00
|
|
|
|
2002-07-08 17:42:47 +00:00
|
|
|
#define MAXISPREQUEST(isp) ((IS_FC(isp) || IS_ULTRA2(isp))? 1024 : 256)
|
2000-07-04 01:04:35 +00:00
|
|
|
|
2011-02-14 21:50:51 +00:00
|
|
|
#define MEMORYBARRIER(isp, type, offset, size, chan) \
|
2002-04-02 23:36:14 +00:00
|
|
|
switch (type) { \
|
2015-12-27 06:16:02 +00:00
|
|
|
case SYNC_REQUEST: \
|
|
|
|
|
bus_dmamap_sync(isp->isp_osinfo.reqdmat, \
|
|
|
|
|
isp->isp_osinfo.reqmap, BUS_DMASYNC_PREWRITE); \
|
|
|
|
|
break; \
|
|
|
|
|
case SYNC_RESULT: \
|
|
|
|
|
bus_dmamap_sync(isp->isp_osinfo.respdmat, \
|
|
|
|
|
isp->isp_osinfo.respmap, BUS_DMASYNC_POSTREAD); \
|
|
|
|
|
break; \
|
2002-04-02 23:36:14 +00:00
|
|
|
case SYNC_SFORDEV: \
|
2011-02-14 21:50:51 +00:00
|
|
|
{ \
|
|
|
|
|
struct isp_fc *fc = ISP_FC_PC(isp, chan); \
|
2015-12-26 09:16:05 +00:00
|
|
|
bus_dmamap_sync(isp->isp_osinfo.scdmat, fc->scmap, \
|
2011-02-14 21:50:51 +00:00
|
|
|
BUS_DMASYNC_PREREAD | BUS_DMASYNC_PREWRITE); \
|
|
|
|
|
break; \
|
|
|
|
|
} \
|
2002-04-02 23:36:14 +00:00
|
|
|
case SYNC_SFORCPU: \
|
2011-02-14 21:50:51 +00:00
|
|
|
{ \
|
|
|
|
|
struct isp_fc *fc = ISP_FC_PC(isp, chan); \
|
2015-12-26 09:16:05 +00:00
|
|
|
bus_dmamap_sync(isp->isp_osinfo.scdmat, fc->scmap, \
|
2011-02-14 21:50:51 +00:00
|
|
|
BUS_DMASYNC_POSTREAD | BUS_DMASYNC_POSTWRITE); \
|
|
|
|
|
break; \
|
|
|
|
|
} \
|
2007-03-13 06:46:08 +00:00
|
|
|
case SYNC_REG: \
|
2015-12-04 19:46:49 +00:00
|
|
|
bus_barrier(isp->isp_osinfo.regs, offset, size, \
|
2011-03-05 00:59:34 +00:00
|
|
|
BUS_SPACE_BARRIER_READ | BUS_SPACE_BARRIER_WRITE); \
|
2007-03-13 06:46:08 +00:00
|
|
|
break; \
|
2015-12-27 06:16:02 +00:00
|
|
|
case SYNC_ATIOQ: \
|
|
|
|
|
bus_dmamap_sync(isp->isp_osinfo.atiodmat, \
|
|
|
|
|
isp->isp_osinfo.atiomap, BUS_DMASYNC_POSTREAD); \
|
|
|
|
|
break; \
|
2016-04-12 14:19:19 +00:00
|
|
|
case SYNC_IFORDEV: \
|
|
|
|
|
bus_dmamap_sync(isp->isp_osinfo.iocbdmat, isp->isp_osinfo.iocbmap, \
|
|
|
|
|
BUS_DMASYNC_PREREAD | BUS_DMASYNC_PREWRITE); \
|
|
|
|
|
break; \
|
|
|
|
|
case SYNC_IFORCPU: \
|
|
|
|
|
bus_dmamap_sync(isp->isp_osinfo.iocbdmat, isp->isp_osinfo.iocbmap, \
|
|
|
|
|
BUS_DMASYNC_POSTREAD | BUS_DMASYNC_POSTWRITE); \
|
|
|
|
|
break; \
|
2013-11-10 23:48:16 +00:00
|
|
|
default: \
|
|
|
|
|
break; \
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
#define MEMORYBARRIERW(isp, type, offset, size, chan) \
|
|
|
|
|
switch (type) { \
|
2015-12-27 06:16:02 +00:00
|
|
|
case SYNC_REQUEST: \
|
|
|
|
|
bus_dmamap_sync(isp->isp_osinfo.reqdmat, \
|
|
|
|
|
isp->isp_osinfo.reqmap, BUS_DMASYNC_PREWRITE); \
|
|
|
|
|
break; \
|
2013-11-10 23:48:16 +00:00
|
|
|
case SYNC_SFORDEV: \
|
|
|
|
|
{ \
|
|
|
|
|
struct isp_fc *fc = ISP_FC_PC(isp, chan); \
|
2015-12-26 09:16:05 +00:00
|
|
|
bus_dmamap_sync(isp->isp_osinfo.scdmat, fc->scmap, \
|
2013-11-10 23:48:16 +00:00
|
|
|
BUS_DMASYNC_PREWRITE); \
|
|
|
|
|
break; \
|
|
|
|
|
} \
|
|
|
|
|
case SYNC_SFORCPU: \
|
|
|
|
|
{ \
|
|
|
|
|
struct isp_fc *fc = ISP_FC_PC(isp, chan); \
|
2015-12-26 09:16:05 +00:00
|
|
|
bus_dmamap_sync(isp->isp_osinfo.scdmat, fc->scmap, \
|
2013-11-10 23:48:16 +00:00
|
|
|
BUS_DMASYNC_POSTWRITE); \
|
|
|
|
|
break; \
|
|
|
|
|
} \
|
|
|
|
|
case SYNC_REG: \
|
2015-12-04 19:46:49 +00:00
|
|
|
bus_barrier(isp->isp_osinfo.regs, offset, size, \
|
2013-11-10 23:48:16 +00:00
|
|
|
BUS_SPACE_BARRIER_WRITE); \
|
|
|
|
|
break; \
|
2016-04-12 14:19:19 +00:00
|
|
|
case SYNC_IFORDEV: \
|
|
|
|
|
bus_dmamap_sync(isp->isp_osinfo.iocbdmat, isp->isp_osinfo.iocbmap, \
|
|
|
|
|
BUS_DMASYNC_PREWRITE); \
|
|
|
|
|
break; \
|
|
|
|
|
case SYNC_IFORCPU: \
|
|
|
|
|
bus_dmamap_sync(isp->isp_osinfo.iocbdmat, isp->isp_osinfo.iocbmap, \
|
|
|
|
|
BUS_DMASYNC_POSTWRITE); \
|
|
|
|
|
break; \
|
2002-04-02 23:36:14 +00:00
|
|
|
default: \
|
|
|
|
|
break; \
|
|
|
|
|
}
|
2000-07-04 01:04:35 +00:00
|
|
|
|
2006-11-02 03:21:32 +00:00
|
|
|
#define MBOX_ACQUIRE isp_mbox_acquire
|
2000-08-01 06:29:55 +00:00
|
|
|
#define MBOX_WAIT_COMPLETE isp_mbox_wait_complete
|
2006-11-14 08:45:48 +00:00
|
|
|
#define MBOX_NOTIFY_COMPLETE isp_mbox_notify_done
|
2006-11-02 03:21:32 +00:00
|
|
|
#define MBOX_RELEASE isp_mbox_release
|
1999-07-02 23:10:34 +00:00
|
|
|
|
2009-08-01 01:04:26 +00:00
|
|
|
#define FC_SCRATCH_ACQUIRE isp_fc_scratch_acquire
|
|
|
|
|
#define FC_SCRATCH_RELEASE(isp, chan) isp->isp_osinfo.pc.fc[chan].fcbsy = 0
|
2002-02-04 21:04:25 +00:00
|
|
|
|
2000-08-01 06:29:55 +00:00
|
|
|
#ifndef SCSI_GOOD
|
|
|
|
|
#define SCSI_GOOD SCSI_STATUS_OK
|
|
|
|
|
#endif
|
|
|
|
|
#ifndef SCSI_CHECK
|
|
|
|
|
#define SCSI_CHECK SCSI_STATUS_CHECK_COND
|
|
|
|
|
#endif
|
|
|
|
|
#ifndef SCSI_BUSY
|
|
|
|
|
#define SCSI_BUSY SCSI_STATUS_BUSY
|
|
|
|
|
#endif
|
|
|
|
|
#ifndef SCSI_QFULL
|
|
|
|
|
#define SCSI_QFULL SCSI_STATUS_QUEUE_FULL
|
|
|
|
|
#endif
|
1999-07-02 23:10:34 +00:00
|
|
|
|
2000-08-01 06:29:55 +00:00
|
|
|
#define XS_T struct ccb_scsiio
|
2006-02-15 00:31:48 +00:00
|
|
|
#define XS_DMA_ADDR_T bus_addr_t
|
2009-08-01 01:04:26 +00:00
|
|
|
#define XS_GET_DMA64_SEG(a, b, c) \
|
|
|
|
|
{ \
|
|
|
|
|
ispds64_t *d = a; \
|
|
|
|
|
bus_dma_segment_t *e = b; \
|
|
|
|
|
uint32_t f = c; \
|
|
|
|
|
e += f; \
|
|
|
|
|
d->ds_base = DMA_LO32(e->ds_addr); \
|
|
|
|
|
d->ds_basehi = DMA_HI32(e->ds_addr); \
|
|
|
|
|
d->ds_count = e->ds_len; \
|
|
|
|
|
}
|
|
|
|
|
#define XS_GET_DMA_SEG(a, b, c) \
|
|
|
|
|
{ \
|
|
|
|
|
ispds_t *d = a; \
|
|
|
|
|
bus_dma_segment_t *e = b; \
|
|
|
|
|
uint32_t f = c; \
|
|
|
|
|
e += f; \
|
|
|
|
|
d->ds_base = DMA_LO32(e->ds_addr); \
|
|
|
|
|
d->ds_count = e->ds_len; \
|
|
|
|
|
}
|
2007-05-05 20:17:23 +00:00
|
|
|
#define XS_ISP(ccb) cam_sim_softc(xpt_path_sim((ccb)->ccb_h.path))
|
1999-07-02 23:10:34 +00:00
|
|
|
#define XS_CHANNEL(ccb) cam_sim_bus(xpt_path_sim((ccb)->ccb_h.path))
|
2000-08-01 06:29:55 +00:00
|
|
|
#define XS_TGT(ccb) (ccb)->ccb_h.target_id
|
2015-10-24 17:34:40 +00:00
|
|
|
#define XS_LUN(ccb) (ccb)->ccb_h.target_lun
|
2000-08-01 06:29:55 +00:00
|
|
|
|
|
|
|
|
#define XS_CDBP(ccb) \
|
|
|
|
|
(((ccb)->ccb_h.flags & CAM_CDB_POINTER)? \
|
|
|
|
|
(ccb)->cdb_io.cdb_ptr : (ccb)->cdb_io.cdb_bytes)
|
|
|
|
|
|
1999-07-02 23:10:34 +00:00
|
|
|
#define XS_CDBLEN(ccb) (ccb)->cdb_len
|
2000-08-01 06:29:55 +00:00
|
|
|
#define XS_XFRLEN(ccb) (ccb)->dxfer_len
|
1999-07-02 23:10:34 +00:00
|
|
|
#define XS_TIME(ccb) (ccb)->ccb_h.timeout
|
2009-08-01 01:04:26 +00:00
|
|
|
#define XS_GET_RESID(ccb) (ccb)->resid
|
|
|
|
|
#define XS_SET_RESID(ccb, r) (ccb)->resid = r
|
2000-08-01 06:29:55 +00:00
|
|
|
#define XS_STSP(ccb) (&(ccb)->scsi_status)
|
1999-07-02 23:10:34 +00:00
|
|
|
#define XS_SNSP(ccb) (&(ccb)->sense_data)
|
2000-08-01 06:29:55 +00:00
|
|
|
|
-----------
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
2012-07-28 20:06:29 +00:00
|
|
|
#define XS_TOT_SNSLEN(ccb) ccb->sense_len
|
|
|
|
|
#define XS_CUR_SNSLEN(ccb) (ccb->sense_len - ccb->sense_resid)
|
2000-08-01 06:29:55 +00:00
|
|
|
|
Add descriptor sense support to CAM, and honor sense residuals properly in
CAM.
Desriptor sense is a new sense data format that originated in SPC-3. Among
other things, it allows for an 8-byte info field, which is necessary to
pass back block numbers larger than 4 bytes.
This change adds a number of new functions to scsi_all.c (and therefore
libcam) that abstract out most access to sense data.
This includes a bump of CAM_VERSION, because the CCB ABI has changed.
Userland programs that use the CAM pass(4) driver will need to be
recompiled.
camcontrol.c: Change uses of scsi_extract_sense() to use
scsi_extract_sense_len().
Use scsi_get_sks() instead of accessing sense key specific
data directly.
scsi_modes: Update the control mode page to the latest version (SPC-4).
scsi_cmds.c,
scsi_target.c: Change references to struct scsi_sense_data to struct
scsi_sense_data_fixed. This should be changed to allow the
user to specify fixed or descriptor sense, and then use
scsi_set_sense_data() to build the sense data.
ps3cdrom.c: Use scsi_set_sense_data() instead of setting sense data
manually.
cam_periph.c: Use scsi_extract_sense_len() instead of using
scsi_extract_sense() or accessing sense data directly.
cam_ccb.h: Bump the CAM_VERSION from 0x15 to 0x16. The change of
struct scsi_sense_data from 32 to 252 bytes changes the
size of struct ccb_scsiio, but not the size of union ccb.
So the version must be bumped to prevent structure
mis-matches.
scsi_all.h: Lots of updated SCSI sense data and other structures.
Add function prototypes for the new sense data functions.
Take out the inline implementation of scsi_extract_sense().
It is now too large to put in a header file.
Add macros to calculate whether fields are present and
filled in fixed and descriptor sense data
scsi_all.c: In scsi_op_desc(), allow the user to pass in NULL inquiry
data, and we'll assume a direct access device in that case.
Changed the SCSI RESERVED sense key name and description
to COMPLETED, as it is now defined in the spec.
Change the error recovery action for a number of read errors
to prevent lots of retries when the drive has said that the
block isn't accessible. This speeds up reconstruction of
the block by any RAID software running on top of the drive
(e.g. ZFS).
In scsi_sense_desc(), allow for invalid sense key numbers.
This allows calling this routine without checking the input
values first.
Change scsi_error_action() to use scsi_extract_sense_len(),
and handle things when invalid asc/ascq values are
encountered.
Add a new routine, scsi_desc_iterate(), that will call the
supplied function for every descriptor in descriptor format
sense data.
Add scsi_set_sense_data(), and scsi_set_sense_data_va(),
which build descriptor and fixed format sense data. They
currently default to fixed format sense data.
Add a number of scsi_get_*() functions, which get different
types of sense data fields from either fixed or descriptor
format sense data, if the data is present.
Add a number of scsi_*_sbuf() functions, which print
formatted versions of various sense data fields. These
functions work for either fixed or descriptor sense.
Add a number of scsi_sense_*_sbuf() functions, which have a
standard calling interface and print the indicated field.
These functions take descriptors only.
Add scsi_sense_desc_sbuf(), which will print a formatted
version of the given sense descriptor.
Pull out a majority of the scsi_sense_sbuf() function and
put it into scsi_sense_only_sbuf(). This allows callers
that don't use struct ccb_scsiio to easily utilize the
printing routines. Revamp that function to handle
descriptor sense and use the new sense fetching and
printing routines.
Move scsi_extract_sense() into scsi_all.c, and implement it
in terms of the new function, scsi_extract_sense_len().
The _len() version takes a length (which should be the
sense length - residual) and can indicate which fields are
present and valid in the sense data.
Add a couple of new scsi_get_*() routines to get the sense
key, asc, and ascq only.
mly.c: Rename struct scsi_sense_data to struct
scsi_sense_data_fixed.
sbp_targ.c: Use the new sense fetching routines to get sense data
instead of accessing it directly.
sbp.c: Change the firewire/SCSI sense data transformation code to
use struct scsi_sense_data_fixed instead of struct
scsi_sense_data. This should be changed later to use
scsi_set_sense_data().
ciss.c: Calculate the sense residual properly. Use
scsi_get_sense_key() to fetch the sense key.
mps_sas.c,
mpt_cam.c: Set the sense residual properly.
iir.c: Use scsi_set_sense_data() instead of building sense data by
hand.
iscsi_subr.c: Use scsi_extract_sense_len() instead of grabbing sense data
directly.
umass.c: Use scsi_set_sense_data() to build sense data.
Grab the sense key using scsi_get_sense_key().
Calculate the sense residual properly.
isp_freebsd.h: Use scsi_get_*() routines to grab asc, ascq, and sense key
values.
Calculate and set the sense residual.
MFC after: 3 days
Sponsored by: Spectra Logic Corporation
2011-10-03 20:32:55 +00:00
|
|
|
#define XS_SNSKEY(ccb) (scsi_get_sense_key(&(ccb)->sense_data, \
|
-----------
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
2012-07-28 20:06:29 +00:00
|
|
|
ccb->sense_len - ccb->sense_resid, 1))
|
Add descriptor sense support to CAM, and honor sense residuals properly in
CAM.
Desriptor sense is a new sense data format that originated in SPC-3. Among
other things, it allows for an 8-byte info field, which is necessary to
pass back block numbers larger than 4 bytes.
This change adds a number of new functions to scsi_all.c (and therefore
libcam) that abstract out most access to sense data.
This includes a bump of CAM_VERSION, because the CCB ABI has changed.
Userland programs that use the CAM pass(4) driver will need to be
recompiled.
camcontrol.c: Change uses of scsi_extract_sense() to use
scsi_extract_sense_len().
Use scsi_get_sks() instead of accessing sense key specific
data directly.
scsi_modes: Update the control mode page to the latest version (SPC-4).
scsi_cmds.c,
scsi_target.c: Change references to struct scsi_sense_data to struct
scsi_sense_data_fixed. This should be changed to allow the
user to specify fixed or descriptor sense, and then use
scsi_set_sense_data() to build the sense data.
ps3cdrom.c: Use scsi_set_sense_data() instead of setting sense data
manually.
cam_periph.c: Use scsi_extract_sense_len() instead of using
scsi_extract_sense() or accessing sense data directly.
cam_ccb.h: Bump the CAM_VERSION from 0x15 to 0x16. The change of
struct scsi_sense_data from 32 to 252 bytes changes the
size of struct ccb_scsiio, but not the size of union ccb.
So the version must be bumped to prevent structure
mis-matches.
scsi_all.h: Lots of updated SCSI sense data and other structures.
Add function prototypes for the new sense data functions.
Take out the inline implementation of scsi_extract_sense().
It is now too large to put in a header file.
Add macros to calculate whether fields are present and
filled in fixed and descriptor sense data
scsi_all.c: In scsi_op_desc(), allow the user to pass in NULL inquiry
data, and we'll assume a direct access device in that case.
Changed the SCSI RESERVED sense key name and description
to COMPLETED, as it is now defined in the spec.
Change the error recovery action for a number of read errors
to prevent lots of retries when the drive has said that the
block isn't accessible. This speeds up reconstruction of
the block by any RAID software running on top of the drive
(e.g. ZFS).
In scsi_sense_desc(), allow for invalid sense key numbers.
This allows calling this routine without checking the input
values first.
Change scsi_error_action() to use scsi_extract_sense_len(),
and handle things when invalid asc/ascq values are
encountered.
Add a new routine, scsi_desc_iterate(), that will call the
supplied function for every descriptor in descriptor format
sense data.
Add scsi_set_sense_data(), and scsi_set_sense_data_va(),
which build descriptor and fixed format sense data. They
currently default to fixed format sense data.
Add a number of scsi_get_*() functions, which get different
types of sense data fields from either fixed or descriptor
format sense data, if the data is present.
Add a number of scsi_*_sbuf() functions, which print
formatted versions of various sense data fields. These
functions work for either fixed or descriptor sense.
Add a number of scsi_sense_*_sbuf() functions, which have a
standard calling interface and print the indicated field.
These functions take descriptors only.
Add scsi_sense_desc_sbuf(), which will print a formatted
version of the given sense descriptor.
Pull out a majority of the scsi_sense_sbuf() function and
put it into scsi_sense_only_sbuf(). This allows callers
that don't use struct ccb_scsiio to easily utilize the
printing routines. Revamp that function to handle
descriptor sense and use the new sense fetching and
printing routines.
Move scsi_extract_sense() into scsi_all.c, and implement it
in terms of the new function, scsi_extract_sense_len().
The _len() version takes a length (which should be the
sense length - residual) and can indicate which fields are
present and valid in the sense data.
Add a couple of new scsi_get_*() routines to get the sense
key, asc, and ascq only.
mly.c: Rename struct scsi_sense_data to struct
scsi_sense_data_fixed.
sbp_targ.c: Use the new sense fetching routines to get sense data
instead of accessing it directly.
sbp.c: Change the firewire/SCSI sense data transformation code to
use struct scsi_sense_data_fixed instead of struct
scsi_sense_data. This should be changed later to use
scsi_set_sense_data().
ciss.c: Calculate the sense residual properly. Use
scsi_get_sense_key() to fetch the sense key.
mps_sas.c,
mpt_cam.c: Set the sense residual properly.
iir.c: Use scsi_set_sense_data() instead of building sense data by
hand.
iscsi_subr.c: Use scsi_extract_sense_len() instead of grabbing sense data
directly.
umass.c: Use scsi_set_sense_data() to build sense data.
Grab the sense key using scsi_get_sense_key().
Calculate the sense residual properly.
isp_freebsd.h: Use scsi_get_*() routines to grab asc, ascq, and sense key
values.
Calculate and set the sense residual.
MFC after: 3 days
Sponsored by: Spectra Logic Corporation
2011-10-03 20:32:55 +00:00
|
|
|
|
|
|
|
|
#define XS_SNSASC(ccb) (scsi_get_asc(&(ccb)->sense_data, \
|
-----------
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
2012-07-28 20:06:29 +00:00
|
|
|
ccb->sense_len - ccb->sense_resid, 1))
|
Add descriptor sense support to CAM, and honor sense residuals properly in
CAM.
Desriptor sense is a new sense data format that originated in SPC-3. Among
other things, it allows for an 8-byte info field, which is necessary to
pass back block numbers larger than 4 bytes.
This change adds a number of new functions to scsi_all.c (and therefore
libcam) that abstract out most access to sense data.
This includes a bump of CAM_VERSION, because the CCB ABI has changed.
Userland programs that use the CAM pass(4) driver will need to be
recompiled.
camcontrol.c: Change uses of scsi_extract_sense() to use
scsi_extract_sense_len().
Use scsi_get_sks() instead of accessing sense key specific
data directly.
scsi_modes: Update the control mode page to the latest version (SPC-4).
scsi_cmds.c,
scsi_target.c: Change references to struct scsi_sense_data to struct
scsi_sense_data_fixed. This should be changed to allow the
user to specify fixed or descriptor sense, and then use
scsi_set_sense_data() to build the sense data.
ps3cdrom.c: Use scsi_set_sense_data() instead of setting sense data
manually.
cam_periph.c: Use scsi_extract_sense_len() instead of using
scsi_extract_sense() or accessing sense data directly.
cam_ccb.h: Bump the CAM_VERSION from 0x15 to 0x16. The change of
struct scsi_sense_data from 32 to 252 bytes changes the
size of struct ccb_scsiio, but not the size of union ccb.
So the version must be bumped to prevent structure
mis-matches.
scsi_all.h: Lots of updated SCSI sense data and other structures.
Add function prototypes for the new sense data functions.
Take out the inline implementation of scsi_extract_sense().
It is now too large to put in a header file.
Add macros to calculate whether fields are present and
filled in fixed and descriptor sense data
scsi_all.c: In scsi_op_desc(), allow the user to pass in NULL inquiry
data, and we'll assume a direct access device in that case.
Changed the SCSI RESERVED sense key name and description
to COMPLETED, as it is now defined in the spec.
Change the error recovery action for a number of read errors
to prevent lots of retries when the drive has said that the
block isn't accessible. This speeds up reconstruction of
the block by any RAID software running on top of the drive
(e.g. ZFS).
In scsi_sense_desc(), allow for invalid sense key numbers.
This allows calling this routine without checking the input
values first.
Change scsi_error_action() to use scsi_extract_sense_len(),
and handle things when invalid asc/ascq values are
encountered.
Add a new routine, scsi_desc_iterate(), that will call the
supplied function for every descriptor in descriptor format
sense data.
Add scsi_set_sense_data(), and scsi_set_sense_data_va(),
which build descriptor and fixed format sense data. They
currently default to fixed format sense data.
Add a number of scsi_get_*() functions, which get different
types of sense data fields from either fixed or descriptor
format sense data, if the data is present.
Add a number of scsi_*_sbuf() functions, which print
formatted versions of various sense data fields. These
functions work for either fixed or descriptor sense.
Add a number of scsi_sense_*_sbuf() functions, which have a
standard calling interface and print the indicated field.
These functions take descriptors only.
Add scsi_sense_desc_sbuf(), which will print a formatted
version of the given sense descriptor.
Pull out a majority of the scsi_sense_sbuf() function and
put it into scsi_sense_only_sbuf(). This allows callers
that don't use struct ccb_scsiio to easily utilize the
printing routines. Revamp that function to handle
descriptor sense and use the new sense fetching and
printing routines.
Move scsi_extract_sense() into scsi_all.c, and implement it
in terms of the new function, scsi_extract_sense_len().
The _len() version takes a length (which should be the
sense length - residual) and can indicate which fields are
present and valid in the sense data.
Add a couple of new scsi_get_*() routines to get the sense
key, asc, and ascq only.
mly.c: Rename struct scsi_sense_data to struct
scsi_sense_data_fixed.
sbp_targ.c: Use the new sense fetching routines to get sense data
instead of accessing it directly.
sbp.c: Change the firewire/SCSI sense data transformation code to
use struct scsi_sense_data_fixed instead of struct
scsi_sense_data. This should be changed later to use
scsi_set_sense_data().
ciss.c: Calculate the sense residual properly. Use
scsi_get_sense_key() to fetch the sense key.
mps_sas.c,
mpt_cam.c: Set the sense residual properly.
iir.c: Use scsi_set_sense_data() instead of building sense data by
hand.
iscsi_subr.c: Use scsi_extract_sense_len() instead of grabbing sense data
directly.
umass.c: Use scsi_set_sense_data() to build sense data.
Grab the sense key using scsi_get_sense_key().
Calculate the sense residual properly.
isp_freebsd.h: Use scsi_get_*() routines to grab asc, ascq, and sense key
values.
Calculate and set the sense residual.
MFC after: 3 days
Sponsored by: Spectra Logic Corporation
2011-10-03 20:32:55 +00:00
|
|
|
|
|
|
|
|
#define XS_SNSASCQ(ccb) (scsi_get_ascq(&(ccb)->sense_data, \
|
-----------
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
2012-07-28 20:06:29 +00:00
|
|
|
ccb->sense_len - ccb->sense_resid, 1))
|
2000-08-01 06:29:55 +00:00
|
|
|
#define XS_TAG_P(ccb) \
|
|
|
|
|
(((ccb)->ccb_h.flags & CAM_TAG_ACTION_VALID) && \
|
|
|
|
|
(ccb)->tag_action != CAM_TAG_ACTION_NONE)
|
|
|
|
|
|
|
|
|
|
#define XS_TAG_TYPE(ccb) \
|
|
|
|
|
((ccb->tag_action == MSG_SIMPLE_Q_TAG)? REQFLAG_STAG : \
|
|
|
|
|
((ccb->tag_action == MSG_HEAD_OF_Q_TAG)? REQFLAG_HTAG : REQFLAG_OTAG))
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
#define XS_SETERR(ccb, v) (ccb)->ccb_h.status &= ~CAM_STATUS_MASK, \
|
-----------
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
2012-07-28 20:06:29 +00:00
|
|
|
(ccb)->ccb_h.status |= v
|
2000-08-01 06:29:55 +00:00
|
|
|
|
|
|
|
|
# define HBA_NOERROR CAM_REQ_INPROG
|
|
|
|
|
# define HBA_BOTCH CAM_UNREC_HBA_ERROR
|
|
|
|
|
# define HBA_CMDTIMEOUT CAM_CMD_TIMEOUT
|
|
|
|
|
# define HBA_SELTIMEOUT CAM_SEL_TIMEOUT
|
|
|
|
|
# define HBA_TGTBSY CAM_SCSI_STATUS_ERROR
|
|
|
|
|
# define HBA_BUSRESET CAM_SCSI_BUS_RESET
|
|
|
|
|
# define HBA_ABORTED CAM_REQ_ABORTED
|
|
|
|
|
# define HBA_DATAOVR CAM_DATA_RUN_ERR
|
|
|
|
|
# define HBA_ARQFAIL CAM_AUTOSENSE_FAIL
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
#define XS_ERR(ccb) ((ccb)->ccb_h.status & CAM_STATUS_MASK)
|
|
|
|
|
|
-----------
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
2012-07-28 20:06:29 +00:00
|
|
|
#define XS_NOERR(ccb) (((ccb)->ccb_h.status & CAM_STATUS_MASK) == CAM_REQ_INPROG)
|
|
|
|
|
|
|
|
|
|
#define XS_INITERR(ccb) XS_SETERR(ccb, CAM_REQ_INPROG), ccb->sense_resid = ccb->sense_len
|
|
|
|
|
|
|
|
|
|
#define XS_SAVE_SENSE(xs, sense_ptr, totslen, slen) do { \
|
|
|
|
|
uint32_t tlen = slen; \
|
|
|
|
|
if (tlen > (xs)->sense_len) \
|
|
|
|
|
tlen = (xs)->sense_len; \
|
|
|
|
|
PISP_PCMD(xs)->totslen = imin((xs)->sense_len, totslen); \
|
|
|
|
|
PISP_PCMD(xs)->cumslen = tlen; \
|
|
|
|
|
memcpy(&(xs)->sense_data, sense_ptr, tlen); \
|
|
|
|
|
(xs)->sense_resid = (xs)->sense_len - tlen; \
|
|
|
|
|
(xs)->ccb_h.status |= CAM_AUTOSNS_VALID; \
|
|
|
|
|
} while (0)
|
|
|
|
|
|
|
|
|
|
#define XS_SENSE_APPEND(xs, xsnsp, xsnsl) do { \
|
|
|
|
|
uint32_t off = PISP_PCMD(xs)->cumslen; \
|
|
|
|
|
uint8_t *ptr = &((uint8_t *)(&(xs)->sense_data))[off]; \
|
|
|
|
|
uint32_t amt = imin(xsnsl, PISP_PCMD(xs)->totslen - off); \
|
|
|
|
|
if (amt) { \
|
|
|
|
|
memcpy(ptr, xsnsp, amt); \
|
|
|
|
|
(xs)->sense_resid -= amt; \
|
|
|
|
|
PISP_PCMD(xs)->cumslen += amt; \
|
|
|
|
|
} \
|
|
|
|
|
} while (0)
|
2000-08-01 06:29:55 +00:00
|
|
|
|
2010-03-26 15:13:31 +00:00
|
|
|
#define XS_SENSE_VALID(xs) (((xs)->ccb_h.status & CAM_AUTOSNS_VALID) != 0)
|
2000-08-01 06:29:55 +00:00
|
|
|
|
2009-08-01 01:04:26 +00:00
|
|
|
#define DEFAULT_FRAMESIZE(isp) isp->isp_osinfo.framesize
|
|
|
|
|
#define DEFAULT_EXEC_THROTTLE(isp) isp->isp_osinfo.exec_throttle
|
2000-08-01 06:29:55 +00:00
|
|
|
|
2015-11-23 10:06:19 +00:00
|
|
|
#define DEFAULT_ROLE(isp, chan) \
|
|
|
|
|
(IS_FC(isp)? ISP_FC_PC(isp, chan)->def_role : ISP_ROLE_INITIATOR)
|
2009-08-01 01:04:26 +00:00
|
|
|
|
|
|
|
|
#define DEFAULT_IID(isp, chan) isp->isp_osinfo.pc.spi[chan].iid
|
|
|
|
|
|
|
|
|
|
#define DEFAULT_LOOPID(x, chan) isp->isp_osinfo.pc.fc[chan].default_id
|
|
|
|
|
|
|
|
|
|
#define DEFAULT_NODEWWN(isp, chan) isp_default_wwn(isp, chan, 0, 1)
|
|
|
|
|
#define DEFAULT_PORTWWN(isp, chan) isp_default_wwn(isp, chan, 0, 0)
|
|
|
|
|
#define ACTIVE_NODEWWN(isp, chan) isp_default_wwn(isp, chan, 1, 1)
|
|
|
|
|
#define ACTIVE_PORTWWN(isp, chan) isp_default_wwn(isp, chan, 1, 0)
|
2007-03-12 04:54:30 +00:00
|
|
|
|
|
|
|
|
|
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
|
|
|
#if BYTE_ORDER == BIG_ENDIAN
|
|
|
|
|
#ifdef ISP_SBUS_SUPPORTED
|
|
|
|
|
#define ISP_IOXPUT_8(isp, s, d) *(d) = s
|
|
|
|
|
#define ISP_IOXPUT_16(isp, s, d) \
|
|
|
|
|
*(d) = (isp->isp_bustype == ISP_BT_SBUS)? s : bswap16(s)
|
|
|
|
|
#define ISP_IOXPUT_32(isp, s, d) \
|
|
|
|
|
*(d) = (isp->isp_bustype == ISP_BT_SBUS)? s : bswap32(s)
|
2006-02-15 00:31:48 +00:00
|
|
|
#define ISP_IOXGET_8(isp, s, d) d = (*((uint8_t *)s))
|
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
|
|
|
#define ISP_IOXGET_16(isp, s, d) \
|
|
|
|
|
d = (isp->isp_bustype == ISP_BT_SBUS)? \
|
2006-02-15 00:31:48 +00:00
|
|
|
*((uint16_t *)s) : bswap16(*((uint16_t *)s))
|
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
|
|
|
#define ISP_IOXGET_32(isp, s, d) \
|
|
|
|
|
d = (isp->isp_bustype == ISP_BT_SBUS)? \
|
2006-02-15 00:31:48 +00:00
|
|
|
*((uint32_t *)s) : bswap32(*((uint32_t *)s))
|
2006-11-02 03:21:32 +00:00
|
|
|
|
|
|
|
|
#else /* ISP_SBUS_SUPPORTED */
|
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
|
|
|
#define ISP_IOXPUT_8(isp, s, d) *(d) = s
|
|
|
|
|
#define ISP_IOXPUT_16(isp, s, d) *(d) = bswap16(s)
|
|
|
|
|
#define ISP_IOXPUT_32(isp, s, d) *(d) = bswap32(s)
|
2006-02-15 00:31:48 +00:00
|
|
|
#define ISP_IOXGET_8(isp, s, d) d = (*((uint8_t *)s))
|
|
|
|
|
#define ISP_IOXGET_16(isp, s, d) d = bswap16(*((uint16_t *)s))
|
|
|
|
|
#define ISP_IOXGET_32(isp, s, d) d = bswap32(*((uint32_t *)s))
|
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
|
|
|
#endif
|
|
|
|
|
#define ISP_SWIZZLE_NVRAM_WORD(isp, rp) *rp = bswap16(*rp)
|
2007-07-02 20:08:20 +00:00
|
|
|
#define ISP_SWIZZLE_NVRAM_LONG(isp, rp) *rp = bswap32(*rp)
|
2006-11-02 03:21:32 +00:00
|
|
|
|
|
|
|
|
#define ISP_IOZGET_8(isp, s, d) d = (*((uint8_t *)s))
|
|
|
|
|
#define ISP_IOZGET_16(isp, s, d) d = (*((uint16_t *)s))
|
|
|
|
|
#define ISP_IOZGET_32(isp, s, d) d = (*((uint32_t *)s))
|
|
|
|
|
#define ISP_IOZPUT_8(isp, s, d) *(d) = s
|
|
|
|
|
#define ISP_IOZPUT_16(isp, s, d) *(d) = s
|
|
|
|
|
#define ISP_IOZPUT_32(isp, s, d) *(d) = s
|
|
|
|
|
|
|
|
|
|
|
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
|
|
|
#else
|
|
|
|
|
#define ISP_IOXPUT_8(isp, s, d) *(d) = s
|
|
|
|
|
#define ISP_IOXPUT_16(isp, s, d) *(d) = s
|
|
|
|
|
#define ISP_IOXPUT_32(isp, s, d) *(d) = s
|
|
|
|
|
#define ISP_IOXGET_8(isp, s, d) d = *(s)
|
|
|
|
|
#define ISP_IOXGET_16(isp, s, d) d = *(s)
|
|
|
|
|
#define ISP_IOXGET_32(isp, s, d) d = *(s)
|
|
|
|
|
#define ISP_SWIZZLE_NVRAM_WORD(isp, rp)
|
2007-07-02 20:08:20 +00:00
|
|
|
#define ISP_SWIZZLE_NVRAM_LONG(isp, rp)
|
2006-11-02 03:21:32 +00:00
|
|
|
|
|
|
|
|
#define ISP_IOZPUT_8(isp, s, d) *(d) = s
|
|
|
|
|
#define ISP_IOZPUT_16(isp, s, d) *(d) = bswap16(s)
|
|
|
|
|
#define ISP_IOZPUT_32(isp, s, d) *(d) = bswap32(s)
|
|
|
|
|
|
|
|
|
|
#define ISP_IOZGET_8(isp, s, d) d = (*((uint8_t *)(s)))
|
|
|
|
|
#define ISP_IOZGET_16(isp, s, d) d = bswap16(*((uint16_t *)(s)))
|
|
|
|
|
#define ISP_IOZGET_32(isp, s, d) d = bswap32(*((uint32_t *)(s)))
|
|
|
|
|
|
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
|
|
|
#endif
|
2000-08-01 06:29:55 +00:00
|
|
|
|
2007-07-02 20:08:20 +00:00
|
|
|
#define ISP_SWAP16(isp, s) bswap16(s)
|
|
|
|
|
#define ISP_SWAP32(isp, s) bswap32(s)
|
|
|
|
|
|
2000-08-01 06:29:55 +00:00
|
|
|
/*
|
|
|
|
|
* Includes of common header files
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#include <dev/isp/ispreg.h>
|
|
|
|
|
#include <dev/isp/ispvar.h>
|
|
|
|
|
#include <dev/isp/ispmbox.h>
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* isp_osinfo definiitions && shorthand
|
|
|
|
|
*/
|
|
|
|
|
#define SIMQFRZ_RESOURCE 0x1
|
|
|
|
|
#define SIMQFRZ_LOOPDOWN 0x2
|
|
|
|
|
#define SIMQFRZ_TIMED 0x4
|
|
|
|
|
|
2001-03-01 02:15:58 +00:00
|
|
|
#define isp_dev isp_osinfo.dev
|
2000-08-01 06:29:55 +00:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* prototypes for isp_pci && isp_freebsd to share
|
|
|
|
|
*/
|
2009-08-01 01:04:26 +00:00
|
|
|
extern int isp_attach(ispsoftc_t *);
|
2011-08-13 23:34:17 +00:00
|
|
|
extern int isp_detach(ispsoftc_t *);
|
2006-04-21 18:30:01 +00:00
|
|
|
extern void isp_uninit(ispsoftc_t *);
|
2009-08-01 01:04:26 +00:00
|
|
|
extern uint64_t isp_default_wwn(ispsoftc_t *, int, int, int);
|
1998-04-22 17:54:58 +00:00
|
|
|
|
2002-07-11 03:25:04 +00:00
|
|
|
/*
|
|
|
|
|
* driver global data
|
|
|
|
|
*/
|
|
|
|
|
extern int isp_announced;
|
2006-11-02 03:21:32 +00:00
|
|
|
extern int isp_loop_down_limit;
|
2006-11-14 08:45:48 +00:00
|
|
|
extern int isp_gone_device_time;
|
2006-11-02 03:21:32 +00:00
|
|
|
extern int isp_quickboot_time;
|
2002-07-11 03:25:04 +00:00
|
|
|
|
2000-08-01 06:29:55 +00:00
|
|
|
/*
|
|
|
|
|
* Platform private flags
|
|
|
|
|
*/
|
2006-02-02 21:31:34 +00:00
|
|
|
|
1999-07-02 23:10:34 +00:00
|
|
|
/*
|
2006-11-14 08:45:48 +00:00
|
|
|
* Platform Library Functions
|
1999-07-02 23:10:34 +00:00
|
|
|
*/
|
2006-11-14 08:45:48 +00:00
|
|
|
void isp_prt(ispsoftc_t *, int level, const char *, ...) __printflike(3, 4);
|
2010-03-26 15:13:31 +00:00
|
|
|
void isp_xs_prt(ispsoftc_t *, XS_T *, int level, const char *, ...) __printflike(4, 5);
|
2006-11-14 08:45:48 +00:00
|
|
|
uint64_t isp_nanotime_sub(struct timespec *, struct timespec *);
|
|
|
|
|
int isp_mbox_acquire(ispsoftc_t *);
|
|
|
|
|
void isp_mbox_wait_complete(ispsoftc_t *, mbreg_t *);
|
|
|
|
|
void isp_mbox_notify_done(ispsoftc_t *);
|
|
|
|
|
void isp_mbox_release(ispsoftc_t *);
|
2009-08-01 01:04:26 +00:00
|
|
|
int isp_fc_scratch_acquire(ispsoftc_t *, int);
|
2006-11-14 08:45:48 +00:00
|
|
|
int isp_mstohz(int);
|
2007-05-05 20:17:23 +00:00
|
|
|
void isp_platform_intr(void *);
|
|
|
|
|
void isp_common_dmateardown(ispsoftc_t *, struct ccb_scsiio *, uint32_t);
|
2015-11-14 19:47:17 +00:00
|
|
|
void isp_fcp_reset_crn(ispsoftc_t *, int, uint32_t, int);
|
-----------
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
2012-07-28 20:06:29 +00:00
|
|
|
int isp_fcp_next_crn(ispsoftc_t *, uint8_t *, XS_T *);
|
2000-08-01 06:29:55 +00:00
|
|
|
|
2007-01-23 00:02:29 +00:00
|
|
|
/*
|
2007-05-05 20:17:23 +00:00
|
|
|
* Platform Version specific defines
|
2007-01-23 00:02:29 +00:00
|
|
|
*/
|
2007-05-05 20:17:23 +00:00
|
|
|
#define BUS_DMA_ROOTARG(x) bus_get_dma_tag(x)
|
|
|
|
|
#define isp_dma_tag_create(a, b, c, d, e, f, g, h, i, j, k, z) \
|
|
|
|
|
bus_dma_tag_create(a, b, c, d, e, f, g, h, i, j, k, \
|
|
|
|
|
busdma_lock_mutex, &isp->isp_osinfo.lock, z)
|
|
|
|
|
|
2007-02-23 23:13:46 +00:00
|
|
|
#define isp_setup_intr bus_setup_intr
|
2007-01-23 00:02:29 +00:00
|
|
|
|
2007-05-05 20:17:23 +00:00
|
|
|
#define isp_sim_alloc(a, b, c, d, e, f, g, h) \
|
|
|
|
|
cam_sim_alloc(a, b, c, d, e, &(d)->isp_osinfo.lock, f, g, h)
|
|
|
|
|
|
2009-08-01 01:04:26 +00:00
|
|
|
#define ISP_PATH_PRT(i, l, p, ...) \
|
|
|
|
|
if ((l) == ISP_LOGALL || ((l)& (i)->isp_dblev) != 0) { \
|
|
|
|
|
xpt_print(p, __VA_ARGS__); \
|
|
|
|
|
}
|
2007-01-23 00:02:29 +00:00
|
|
|
|
2006-11-14 08:45:48 +00:00
|
|
|
/*
|
|
|
|
|
* Platform specific inline functions
|
|
|
|
|
*/
|
1999-03-17 05:04:39 +00:00
|
|
|
|
2000-08-01 06:29:55 +00:00
|
|
|
/*
|
2006-11-14 08:45:48 +00:00
|
|
|
* ISP General Library functions
|
2000-08-01 06:29:55 +00:00
|
|
|
*/
|
1999-03-17 05:04:39 +00:00
|
|
|
|
2006-02-02 21:31:34 +00:00
|
|
|
#include <dev/isp/isp_library.h>
|
|
|
|
|
|
1998-04-22 17:54:58 +00:00
|
|
|
#endif /* _ISP_FREEBSD_H */
|
