2005-01-06 01:43:34 +00:00
/*-
2017-11-27 14:52:40 +00:00
* SPDX - License - Identifier : BSD - 2 - Clause - FreeBSD
*
2017-07-03 15:56:45 +00:00
* Copyright ( c ) 2009 - 2017 Alexander Motin < mav @ FreeBSD . org >
2009-08-01 01:04:26 +00:00
* Copyright ( c ) 1997 - 2009 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 .
*/
2003-08-24 17:55:58 +00:00
2006-07-16 20:11:50 +00:00
/*
* Platform ( FreeBSD ) dependent common attachment code for Qlogic adapters .
*/
2003-08-24 17:55:58 +00:00
# include <sys/cdefs.h>
__FBSDID ( " $FreeBSD$ " ) ;
2015-01-21 20:27:11 +00:00
1998-04-22 17:54:58 +00:00
# include <dev/isp/isp_freebsd.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/unistd.h>
# include <sys/kthread.h>
# include <sys/conf.h>
2002-07-25 16:00:24 +00:00
# include <sys/module.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/ioccom.h>
# include <dev/isp/isp_ioctl.h>
2007-03-12 04:54:30 +00:00
# include <sys/devicestat.h>
2006-11-14 08:45:48 +00:00
# include <cam/cam_periph.h>
2007-01-20 04:00:21 +00:00
# include <cam/cam_xpt_periph.h>
1998-04-22 17:54:58 +00:00
2002-07-25 16:00:24 +00:00
MODULE_VERSION ( isp , 1 ) ;
2003-09-15 06:41:33 +00:00
MODULE_DEPEND ( isp , cam , 1 , 1 , 1 ) ;
2002-07-11 03:25:04 +00:00
int isp_announced = 0 ;
2009-08-01 01:04:26 +00:00
int isp_loop_down_limit = 60 ; /* default loop down limit */
int isp_quickboot_time = 7 ; /* don't wait more than N secs for loop up */
2006-11-14 08:45:48 +00:00
int isp_gone_device_time = 30 ; /* grace time before reporting device lost */
2015-07-13 15:11:05 +00:00
static const char prom3 [ ] = " Chan %d [%u] PortID 0x%06x Departed because of %s " ;
2002-07-11 03:25:04 +00:00
2015-11-26 13:04:58 +00:00
static void isp_freeze_loopdown ( ispsoftc_t * , int ) ;
static void isp_loop_changed ( ispsoftc_t * isp , int chan ) ;
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
static d_ioctl_t ispioctl ;
2006-02-15 00:31:48 +00:00
static void isp_cam_async ( void * , uint32_t , struct cam_path * , void * ) ;
1999-08-16 20:11:45 +00:00
static void isp_poll ( struct cam_sim * ) ;
Add in the enabling of interrupts (to isp_attach). Clean up a busted
comment. Check against firmware state- not loop state when enabling
target mode. Other changes have to do with no longer enabling/disabling
interrupts at will.
Rearchitect command watchdog timeouts-
First of all, set the timeout period for a command that has a
timeout (in isp_action) to the period of time requested *plus* two
seconds. We don't want the Qlogic firmware and the host system to
race each other to report a dead command (the watchdog is there to
catch dead and/or broken firmware).
Next, make sure that the command being watched isn't done yet. If
it's not done yet, check for INT_PENDING and call isp_intr- if that
said it serviced an interrupt, check to see whether the command is
now done (this is what the "IN WATCHDOG" private flag is for- if
isp_intr completes the command, it won't call xpt_done on it because
isp_watchdog is still looking at the command).
If no interrupt was pending, or the command wasn't completed, check
to see if we've set the private 'grace period' flag. If so, the
command really *is* dead, so report it as dead and complete it with
a CAM_CMD_TIMEOUT value.
If the grace period flag wasn't set, set it and issue a SYNCHRONIZE_ALL
Marker Request Queue entry and re-set the timeout for one second
from now (see Revision 1.45 isp.c notes for more on this) to give
the firmware a final chance to complete this command.
2000-06-27 19:31:02 +00:00
static timeout_t isp_watchdog ;
2011-08-12 19:51:28 +00:00
static timeout_t isp_gdt ;
static task_fn_t isp_gdt_task ;
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
static void isp_kthread ( void * ) ;
2000-01-03 23:55:30 +00:00
static void isp_action ( struct cam_sim * , union ccb * ) ;
2012-08-08 18:24:33 +00:00
static int isp_timer_count ;
2009-08-01 01:04:26 +00:00
static void isp_timer ( void * ) ;
2000-05-09 01:08:21 +00:00
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
static struct cdevsw isp_cdevsw = {
2004-02-21 21:10:55 +00:00
. d_version = D_VERSION ,
2003-03-03 12:15:54 +00:00
. d_ioctl = ispioctl ,
. d_name = " isp " ,
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
} ;
2015-06-23 16:13:20 +00:00
static int
isp_role_sysctl ( SYSCTL_HANDLER_ARGS )
{
ispsoftc_t * isp = ( ispsoftc_t * ) arg1 ;
int chan = arg2 ;
int error , old , value ;
value = FCPARAM ( isp , chan ) - > role ;
error = sysctl_handle_int ( oidp , & value , 0 , req ) ;
if ( ( error ! = 0 ) | | ( req - > newptr = = NULL ) )
return ( error ) ;
if ( value < ISP_ROLE_NONE | | value > ISP_ROLE_BOTH )
return ( EINVAL ) ;
ISP_LOCK ( isp ) ;
old = FCPARAM ( isp , chan ) - > role ;
2015-07-13 15:51:28 +00:00
/* We don't allow target mode switch from here. */
value = ( old & ISP_ROLE_TARGET ) | ( value & ISP_ROLE_INITIATOR ) ;
2015-06-23 16:13:20 +00:00
/* If nothing has changed -- we are done. */
if ( value = = old ) {
ISP_UNLOCK ( isp ) ;
return ( 0 ) ;
}
/* Actually change the role. */
2015-07-04 18:38:46 +00:00
error = isp_control ( isp , ISPCTL_CHANGE_ROLE , chan , value ) ;
2015-06-23 16:13:20 +00:00
ISP_UNLOCK ( isp ) ;
return ( error ) ;
}
2009-08-01 01:04:26 +00:00
static int
isp_attach_chan ( ispsoftc_t * isp , struct cam_devq * devq , int chan )
1998-09-15 08:42:56 +00:00
{
struct ccb_setasync csa ;
1999-05-11 05:10:06 +00:00
struct cam_sim * sim ;
struct cam_path * path ;
2017-02-22 06:43:49 +00:00
# ifdef ISP_TARGET_MODE
int i ;
# endif
1999-05-11 05:10:06 +00:00
2017-03-21 10:34:34 +00:00
sim = cam_sim_alloc ( isp_action , isp_poll , " isp " , isp ,
device_get_unit ( isp - > isp_dev ) , & isp - > isp_lock ,
isp - > isp_maxcmds , isp - > isp_maxcmds , devq ) ;
if ( sim = = NULL )
2009-08-01 01:04:26 +00:00
return ( ENOMEM ) ;
2000-07-04 01:05:43 +00:00
2007-05-13 17:45:00 +00:00
ISP_LOCK ( isp ) ;
2009-08-01 01:04:26 +00:00
if ( xpt_bus_register ( sim , isp - > isp_dev , chan ) ! = CAM_SUCCESS ) {
ISP_UNLOCK ( isp ) ;
cam_sim_free ( sim , FALSE ) ;
return ( EIO ) ;
1998-09-15 08:42:56 +00:00
}
2009-08-01 01:04:26 +00:00
ISP_UNLOCK ( isp ) ;
Merge CAM locking changes from the projects/camlock branch to radically
reduce lock congestion and improve SMP scalability of the SCSI/ATA stack,
preparing the ground for the coming next GEOM direct dispatch support.
Replace big per-SIM locks with bunch of smaller ones:
- per-LUN locks to protect device and peripheral drivers state;
- per-target locks to protect list of LUNs on target;
- per-bus locks to protect reference counting;
- per-send queue locks to protect queue of CCBs to be sent;
- per-done queue locks to protect queue of completed CCBs;
- remaining per-SIM locks now protect only HBA driver internals.
While holding LUN lock it is allowed (while not recommended for performance
reasons) to take SIM lock. The opposite acquisition order is forbidden.
All the other locks are leaf locks, that can be taken anywhere, but should
not be cascaded. Many functions, such as: xpt_action(), xpt_done(),
xpt_async(), xpt_create_path(), etc. are no longer require (but allow) SIM
lock to be held.
To keep compatibility and solve cases where SIM lock can't be dropped, all
xpt_async() calls in addition to xpt_done() calls are queued to completion
threads for async processing in clean environment without SIM lock held.
Instead of single CAM SWI thread, used for commands completion processing
before, use multiple (depending on number of CPUs) threads. Load balanced
between them using "hash" of the device B:T:L address.
HBA drivers that can drop SIM lock during completion processing and have
sufficient number of completion threads to efficiently scale to multiple
CPUs can use new function xpt_done_direct() to avoid extra context switch.
Make ahci(4) driver to use this mechanism depending on hardware setup.
Sponsored by: iXsystems, Inc.
MFC after: 2 months
2013-10-21 12:00:26 +00:00
if ( xpt_create_path ( & path , NULL , cam_sim_path ( sim ) , CAM_TARGET_WILDCARD , CAM_LUN_WILDCARD ) ! = CAM_REQ_CMP ) {
2009-08-01 01:04:26 +00:00
ISP_LOCK ( isp ) ;
1999-05-11 05:10:06 +00:00
xpt_bus_deregister ( cam_sim_path ( sim ) ) ;
2009-08-01 01:04:26 +00:00
ISP_UNLOCK ( isp ) ;
cam_sim_free ( sim , FALSE ) ;
return ( ENXIO ) ;
1998-09-15 08:42:56 +00:00
}
1999-05-11 05:10:06 +00:00
xpt_setup_ccb ( & csa . ccb_h , path , 5 ) ;
1998-09-15 08:42:56 +00:00
csa . ccb_h . func_code = XPT_SASYNC_CB ;
csa . event_enable = AC_LOST_DEVICE ;
1999-01-30 07:29:00 +00:00
csa . callback = isp_cam_async ;
1999-05-11 05:10:06 +00:00
csa . callback_arg = sim ;
-----------
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_LOCK ( isp ) ;
1998-09-15 08:42:56 +00:00
xpt_action ( ( union ccb * ) & csa ) ;
-----------
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_UNLOCK ( isp ) ;
1998-09-15 08:42:56 +00:00
2009-08-01 01:04:26 +00:00
if ( IS_SCSI ( isp ) ) {
struct isp_spi * spi = ISP_SPI_PC ( isp , chan ) ;
spi - > sim = sim ;
spi - > path = path ;
2017-02-19 05:29:06 +00:00
# ifdef ISP_TARGET_MODE
2017-02-19 05:07:02 +00:00
TAILQ_INIT ( & spi - > waitq ) ;
2017-02-22 06:43:49 +00:00
STAILQ_INIT ( & spi - > ntfree ) ;
for ( i = 0 ; i < ATPDPSIZE ; i + + )
STAILQ_INSERT_TAIL ( & spi - > ntfree , & spi - > ntpool [ i ] , next ) ;
LIST_INIT ( & spi - > atfree ) ;
for ( i = ATPDPSIZE - 1 ; i > = 0 ; i - - )
LIST_INSERT_HEAD ( & spi - > atfree , & spi - > atpool [ i ] , next ) ;
for ( i = 0 ; i < ATPDPHASHSIZE ; i + + )
LIST_INIT ( & spi - > atused [ i ] ) ;
2017-02-19 05:29:06 +00:00
# endif
2009-08-01 01:04:26 +00:00
} else {
2009-12-04 03:34:12 +00:00
fcparam * fcp = FCPARAM ( isp , chan ) ;
2009-08-01 01:04:26 +00:00
struct isp_fc * fc = ISP_FC_PC ( isp , chan ) ;
2015-06-23 16:13:20 +00:00
struct sysctl_ctx_list * ctx = device_get_sysctl_ctx ( isp - > isp_osinfo . dev ) ;
struct sysctl_oid * tree = device_get_sysctl_tree ( isp - > isp_osinfo . dev ) ;
char name [ 16 ] ;
1999-05-11 05:10:06 +00:00
2009-12-04 03:34:12 +00:00
ISP_LOCK ( isp ) ;
2009-08-01 01:04:26 +00:00
fc - > sim = sim ;
fc - > path = path ;
fc - > isp = isp ;
2009-12-04 03:34:12 +00:00
fc - > ready = 1 ;
2017-07-03 15:56:45 +00:00
fcp - > isp_use_gft_id = 1 ;
fcp - > isp_use_gff_id = 1 ;
2011-08-12 19:51:28 +00:00
2017-03-21 10:34:34 +00:00
callout_init_mtx ( & fc - > gdt , & isp - > isp_lock , 0 ) ;
2011-08-12 19:51:28 +00:00
TASK_INIT ( & fc - > gtask , 1 , isp_gdt_task , fc ) ;
2017-02-19 05:29:06 +00:00
# ifdef ISP_TARGET_MODE
2017-02-19 05:07:02 +00:00
TAILQ_INIT ( & fc - > waitq ) ;
2017-02-22 06:43:49 +00:00
STAILQ_INIT ( & fc - > ntfree ) ;
for ( i = 0 ; i < ATPDPSIZE ; i + + )
STAILQ_INSERT_TAIL ( & fc - > ntfree , & fc - > ntpool [ i ] , next ) ;
LIST_INIT ( & fc - > atfree ) ;
for ( i = ATPDPSIZE - 1 ; i > = 0 ; i - - )
LIST_INSERT_HEAD ( & fc - > atfree , & fc - > atpool [ i ] , next ) ;
for ( i = 0 ; i < ATPDPHASHSIZE ; i + + )
LIST_INIT ( & fc - > atused [ i ] ) ;
2017-02-19 05:29:06 +00:00
# endif
2015-11-26 13:04:58 +00:00
isp_loop_changed ( isp , chan ) ;
2009-08-01 01:04:26 +00:00
ISP_UNLOCK ( isp ) ;
2017-02-21 12:29:07 +00:00
if ( kproc_create ( isp_kthread , fc , & fc - > kproc , 0 , 0 ,
" %s_%d " , device_get_nameunit ( isp - > isp_osinfo . dev ) , chan ) ) {
2009-12-04 03:34:12 +00:00
xpt_free_path ( fc - > path ) ;
ISP_LOCK ( isp ) ;
xpt_bus_deregister ( cam_sim_path ( fc - > sim ) ) ;
ISP_UNLOCK ( isp ) ;
cam_sim_free ( fc - > sim , FALSE ) ;
return ( ENOMEM ) ;
}
2015-10-13 11:02:56 +00:00
fc - > num_threads + = 1 ;
2015-06-23 16:13:20 +00:00
if ( chan > 0 ) {
snprintf ( name , sizeof ( name ) , " chan%d " , chan ) ;
tree = SYSCTL_ADD_NODE ( ctx , SYSCTL_CHILDREN ( tree ) ,
OID_AUTO , name , CTLFLAG_RW , 0 , " Virtual channel " ) ;
}
2015-10-13 11:02:56 +00:00
SYSCTL_ADD_QUAD ( ctx , SYSCTL_CHILDREN ( tree ) , OID_AUTO ,
" wwnn " , CTLFLAG_RD , & fcp - > isp_wwnn ,
" World Wide Node Name " ) ;
SYSCTL_ADD_QUAD ( ctx , SYSCTL_CHILDREN ( tree ) , OID_AUTO ,
" wwpn " , CTLFLAG_RD , & fcp - > isp_wwpn ,
" World Wide Port Name " ) ;
SYSCTL_ADD_UINT ( ctx , SYSCTL_CHILDREN ( tree ) , OID_AUTO ,
" loop_down_limit " , CTLFLAG_RW , & fc - > loop_down_limit , 0 ,
" Loop Down Limit " ) ;
SYSCTL_ADD_UINT ( ctx , SYSCTL_CHILDREN ( tree ) , OID_AUTO ,
" gone_device_time " , CTLFLAG_RW , & fc - > gone_device_time , 0 ,
" 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
# if defined(ISP_TARGET_MODE) && defined(DEBUG)
2015-10-13 11:02:56 +00:00
SYSCTL_ADD_UINT ( ctx , SYSCTL_CHILDREN ( tree ) , OID_AUTO ,
" inject_lost_data_frame " , CTLFLAG_RW , & fc - > inject_lost_data_frame , 0 ,
" Cause a Lost Frame on a Read " ) ;
-----------
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
# endif
2015-06-23 16:13:20 +00:00
SYSCTL_ADD_PROC ( ctx , SYSCTL_CHILDREN ( tree ) , OID_AUTO ,
" role " , CTLTYPE_INT | CTLFLAG_RW , isp , chan ,
isp_role_sysctl , " I " , " Current role " ) ;
2015-10-13 11:02:56 +00:00
SYSCTL_ADD_UINT ( ctx , SYSCTL_CHILDREN ( tree ) , OID_AUTO ,
" speed " , CTLFLAG_RD , & fcp - > isp_gbspeed , 0 ,
" Connection speed in gigabits " ) ;
SYSCTL_ADD_UINT ( ctx , SYSCTL_CHILDREN ( tree ) , OID_AUTO ,
" linkstate " , CTLFLAG_RD , & fcp - > isp_linkstate , 0 ,
" Link state " ) ;
SYSCTL_ADD_UINT ( ctx , SYSCTL_CHILDREN ( tree ) , OID_AUTO ,
" fwstate " , CTLFLAG_RD , & fcp - > isp_fwstate , 0 ,
" Firmware state " ) ;
SYSCTL_ADD_UINT ( ctx , SYSCTL_CHILDREN ( tree ) , OID_AUTO ,
" loopstate " , CTLFLAG_RD , & fcp - > isp_loopstate , 0 ,
" Loop state " ) ;
SYSCTL_ADD_UINT ( ctx , SYSCTL_CHILDREN ( tree ) , OID_AUTO ,
" topo " , CTLFLAG_RD , & fcp - > isp_topo , 0 ,
" Connection topology " ) ;
2017-07-03 15:56:45 +00:00
SYSCTL_ADD_INT ( ctx , SYSCTL_CHILDREN ( tree ) , OID_AUTO ,
" use_gft_id " , CTLFLAG_RWTUN , & fcp - > isp_use_gft_id , 0 ,
" Use GFT_ID during fabric scan " ) ;
SYSCTL_ADD_INT ( ctx , SYSCTL_CHILDREN ( tree ) , OID_AUTO ,
" use_gff_id " , CTLFLAG_RWTUN , & fcp - > isp_use_gff_id , 0 ,
" Use GFF_ID during fabric scan " ) ;
2009-08-01 01:04:26 +00:00
}
return ( 0 ) ;
}
2014-09-18 02:01:36 +00:00
static void
isp_detach_chan ( ispsoftc_t * isp , int chan )
{
struct cam_sim * sim ;
struct cam_path * path ;
struct ccb_setasync csa ;
int * num_threads ;
ISP_GET_PC ( isp , chan , sim , sim ) ;
ISP_GET_PC ( isp , chan , path , path ) ;
ISP_GET_PC_ADDR ( isp , chan , num_threads , num_threads ) ;
xpt_setup_ccb ( & csa . ccb_h , path , 5 ) ;
csa . ccb_h . func_code = XPT_SASYNC_CB ;
csa . event_enable = 0 ;
csa . callback = isp_cam_async ;
csa . callback_arg = sim ;
xpt_action ( ( union ccb * ) & csa ) ;
xpt_free_path ( path ) ;
xpt_bus_deregister ( cam_sim_path ( sim ) ) ;
cam_sim_free ( sim , FALSE ) ;
/* Wait for the channel's spawned threads to exit. */
wakeup ( isp - > isp_osinfo . pc . ptr ) ;
while ( * num_threads ! = 0 )
2017-03-21 10:34:34 +00:00
mtx_sleep ( isp , & isp - > isp_lock , PRIBIO , " isp_reap " , 100 ) ;
2014-09-18 02:01:36 +00:00
}
2009-08-01 01:04:26 +00:00
int
isp_attach ( ispsoftc_t * isp )
{
const char * nu = device_get_nameunit ( isp - > isp_osinfo . dev ) ;
int du = device_get_unit ( isp - > isp_dev ) ;
int chan ;
1999-05-11 05:10:06 +00:00
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
/*
2009-08-01 01:04:26 +00:00
* Create the device queue for our SIM ( s ) .
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
*/
2009-08-01 01:04:26 +00:00
isp - > isp_osinfo . devq = cam_simq_alloc ( isp - > isp_maxcmds ) ;
if ( isp - > isp_osinfo . devq = = NULL ) {
return ( EIO ) ;
2001-02-11 03:47:39 +00:00
}
2009-08-01 01:04:26 +00:00
for ( chan = 0 ; chan < isp - > isp_nchan ; chan + + ) {
if ( isp_attach_chan ( isp , isp - > isp_osinfo . devq , chan ) ) {
goto unwind ;
2000-01-03 23:55:30 +00:00
}
}
2007-05-05 20:17:23 +00:00
2017-03-21 10:34:34 +00:00
callout_init_mtx ( & isp - > isp_osinfo . tmo , & isp - > isp_lock , 0 ) ;
2012-08-08 18:24:33 +00:00
isp_timer_count = hz > > 2 ;
callout_reset ( & isp - > isp_osinfo . tmo , isp_timer_count , isp_timer , isp ) ;
2009-08-01 01:04:26 +00:00
isp - > isp_osinfo . cdev = make_dev ( & isp_cdevsw , du , UID_ROOT , GID_OPERATOR , 0600 , " %s " , nu ) ;
if ( isp - > isp_osinfo . cdev ) {
isp - > isp_osinfo . cdev - > si_drv1 = isp ;
}
return ( 0 ) ;
unwind :
while ( - - chan > = 0 ) {
struct cam_sim * sim ;
struct cam_path * path ;
2014-09-18 02:01:36 +00:00
ISP_GET_PC ( isp , chan , sim , sim ) ;
ISP_GET_PC ( isp , chan , path , path ) ;
2009-08-01 01:04:26 +00:00
xpt_free_path ( path ) ;
2007-05-05 20:17:23 +00:00
ISP_LOCK ( isp ) ;
2009-08-01 01:04:26 +00:00
xpt_bus_deregister ( cam_sim_path ( sim ) ) ;
ISP_UNLOCK ( isp ) ;
cam_sim_free ( sim , FALSE ) ;
}
cam_simq_free ( isp - > isp_osinfo . devq ) ;
isp - > isp_osinfo . devq = NULL ;
return ( - 1 ) ;
}
2011-08-13 23:34:17 +00:00
int
2009-08-01 01:04:26 +00:00
isp_detach ( ispsoftc_t * isp )
{
int chan ;
2017-03-20 20:44:14 +00:00
if ( isp - > isp_osinfo . cdev ) {
destroy_dev ( isp - > isp_osinfo . cdev ) ;
isp - > isp_osinfo . cdev = NULL ;
2011-08-13 23:34:17 +00:00
}
2017-03-20 20:44:14 +00:00
ISP_LOCK ( isp ) ;
2014-09-18 02:01:36 +00:00
/* Tell spawned threads that we're exiting. */
isp - > isp_osinfo . is_exiting = 1 ;
for ( chan = isp - > isp_nchan - 1 ; chan > = 0 ; chan - = 1 )
isp_detach_chan ( isp , chan ) ;
2011-08-13 23:34:17 +00:00
ISP_UNLOCK ( isp ) ;
2017-03-20 20:44:14 +00:00
callout_drain ( & isp - > isp_osinfo . tmo ) ;
cam_simq_free ( isp - > isp_osinfo . devq ) ;
2011-08-13 23:34:17 +00:00
return ( 0 ) ;
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
}
2006-11-14 08:45:48 +00:00
static void
2015-11-26 13:04:58 +00:00
isp_freeze_loopdown ( ispsoftc_t * isp , int chan )
2002-07-08 17:42:47 +00:00
{
2017-03-15 11:16:26 +00:00
struct isp_fc * fc = ISP_FC_PC ( isp , chan ) ;
if ( fc - > sim = = NULL )
return ;
if ( fc - > simqfrozen = = 0 ) {
isp_prt ( isp , ISP_LOGDEBUG0 ,
" Chan %d Freeze simq (loopdown) " , chan ) ;
fc - > simqfrozen = SIMQFRZ_LOOPDOWN ;
xpt_hold_boot ( ) ;
xpt_freeze_simq ( fc - > sim , 1 ) ;
} else {
isp_prt ( isp , ISP_LOGDEBUG0 ,
" Chan %d Mark simq frozen (loopdown) " , chan ) ;
fc - > simqfrozen | = SIMQFRZ_LOOPDOWN ;
2002-07-08 17:42:47 +00:00
}
}
2011-08-13 23:34:17 +00:00
static void
isp_unfreeze_loopdown ( ispsoftc_t * isp , int chan )
{
2017-03-15 11:16:26 +00:00
struct isp_fc * fc = ISP_FC_PC ( isp , chan ) ;
if ( fc - > sim = = NULL )
return ;
int wasfrozen = fc - > simqfrozen & SIMQFRZ_LOOPDOWN ;
fc - > simqfrozen & = ~ SIMQFRZ_LOOPDOWN ;
if ( wasfrozen & & fc - > simqfrozen = = 0 ) {
isp_prt ( isp , ISP_LOGDEBUG0 ,
" Chan %d Release simq " , chan ) ;
xpt_release_simq ( fc - > sim , 1 ) ;
xpt_release_boot ( ) ;
2011-08-13 23:34:17 +00:00
}
}
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
static int
2009-08-01 01:04:26 +00:00
ispioctl ( struct cdev * dev , u_long c , caddr_t addr , int flags , struct thread * td )
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
{
2006-04-21 18:30:01 +00:00
ispsoftc_t * isp ;
2009-08-01 01:04:26 +00:00
int nr , chan , retval = ENOTTY ;
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
2009-08-01 01:04:26 +00:00
isp = dev - > si_drv1 ;
-----------
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
2006-03-03 07:04:43 +00:00
switch ( c ) {
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
case ISP_SDBLEV :
{
int olddblev = isp - > isp_dblev ;
isp - > isp_dblev = * ( int * ) addr ;
* ( int * ) addr = olddblev ;
retval = 0 ;
break ;
}
2004-02-07 03:47:33 +00:00
case ISP_GETROLE :
2009-08-01 01:04:26 +00:00
chan = * ( int * ) addr ;
if ( chan < 0 | | chan > = isp - > isp_nchan ) {
retval = - ENXIO ;
break ;
}
if ( IS_FC ( isp ) ) {
* ( int * ) addr = FCPARAM ( isp , chan ) - > role ;
} else {
2015-11-23 10:06:19 +00:00
* ( int * ) addr = ISP_ROLE_INITIATOR ;
2009-08-01 01:04:26 +00:00
}
2004-02-07 03:47:33 +00:00
retval = 0 ;
break ;
case ISP_SETROLE :
2015-11-23 10:06:19 +00:00
if ( IS_SCSI ( isp ) )
break ;
2004-02-07 03:47:33 +00:00
nr = * ( int * ) addr ;
2009-08-01 01:04:26 +00:00
chan = nr > > 8 ;
if ( chan < 0 | | chan > = isp - > isp_nchan ) {
retval = - ENXIO ;
break ;
}
nr & = 0xff ;
2004-02-07 03:47:33 +00:00
if ( nr & ~ ( ISP_ROLE_INITIATOR | ISP_ROLE_TARGET ) ) {
retval = EINVAL ;
break ;
}
2015-07-05 03:38:58 +00:00
ISP_LOCK ( isp ) ;
2015-11-23 10:06:19 +00:00
* ( int * ) addr = FCPARAM ( isp , chan ) - > role ;
2015-07-04 18:38:46 +00:00
retval = isp_control ( isp , ISPCTL_CHANGE_ROLE , chan , nr ) ;
ISP_UNLOCK ( isp ) ;
2009-08-01 01:04:26 +00:00
retval = 0 ;
break ;
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
case ISP_RESETHBA :
2007-06-11 19:15:49 +00:00
ISP_LOCK ( isp ) ;
2009-08-01 01:04:26 +00:00
isp_reinit ( isp , 0 ) ;
2007-06-11 19:15:49 +00:00
ISP_UNLOCK ( isp ) ;
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
retval = 0 ;
break ;
2009-08-01 01:04:26 +00:00
2002-02-21 23:30:05 +00:00
case ISP_RESCAN :
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
if ( IS_FC ( isp ) ) {
2018-03-13 19:56:10 +00:00
chan = * ( intptr_t * ) addr ;
2009-08-01 01:04:26 +00:00
if ( chan < 0 | | chan > = isp - > isp_nchan ) {
retval = - ENXIO ;
break ;
}
2007-06-11 19:15:49 +00:00
ISP_LOCK ( isp ) ;
2015-11-26 13:04:58 +00:00
if ( isp_fc_runstate ( isp , chan , 5 * 1000000 ) ! = LOOP_READY ) {
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
retval = EIO ;
} else {
retval = 0 ;
}
2007-06-11 19:15:49 +00:00
ISP_UNLOCK ( isp ) ;
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
}
break ;
2009-08-01 01:04:26 +00:00
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
case ISP_FC_LIP :
if ( IS_FC ( isp ) ) {
2018-03-13 19:56:10 +00:00
chan = * ( intptr_t * ) addr ;
2009-08-01 01:04:26 +00:00
if ( chan < 0 | | chan > = isp - > isp_nchan ) {
retval = - ENXIO ;
break ;
}
2007-06-11 19:15:49 +00:00
ISP_LOCK ( isp ) ;
2009-08-01 01:04:26 +00:00
if ( isp_control ( isp , ISPCTL_SEND_LIP , chan ) ) {
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
retval = EIO ;
} else {
retval = 0 ;
}
2007-06-11 19:15:49 +00:00
ISP_UNLOCK ( isp ) ;
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
}
break ;
case ISP_FC_GETDINFO :
{
struct isp_fc_device * ifc = ( struct isp_fc_device * ) addr ;
2006-11-02 03:21:32 +00:00
fcportdb_t * lp ;
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
2006-07-10 22:39:32 +00:00
if ( IS_SCSI ( isp ) ) {
break ;
}
2007-07-10 07:55:59 +00:00
if ( ifc - > loopid > = MAX_FC_TARG ) {
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
retval = EINVAL ;
break ;
}
2009-08-01 01:04:26 +00:00
lp = & FCPARAM ( isp , ifc - > chan ) - > portdb [ ifc - > loopid ] ;
2015-07-13 15:11:05 +00:00
if ( lp - > state ! = FC_PORTDB_STATE_NIL ) {
-----------
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
ifc - > role = ( lp - > prli_word3 & SVC3_ROLE_MASK ) > > SVC3_ROLE_SHIFT ;
2006-11-02 03:21:32 +00:00
ifc - > loopid = lp - > handle ;
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
ifc - > portid = lp - > portid ;
ifc - > node_wwn = lp - > node_wwn ;
ifc - > port_wwn = lp - > port_wwn ;
retval = 0 ;
} else {
retval = ENODEV ;
}
break ;
}
2002-06-16 05:08:02 +00:00
case ISP_FC_GETHINFO :
{
struct isp_hba_device * hba = ( struct isp_hba_device * ) addr ;
2009-08-01 01:04:26 +00:00
int chan = hba - > fc_channel ;
2006-07-10 22:39:32 +00:00
2009-08-01 01:04:26 +00:00
if ( chan < 0 | | chan > = isp - > isp_nchan ) {
retval = ENXIO ;
break ;
}
2004-01-23 23:22:11 +00:00
hba - > fc_fw_major = ISP_FW_MAJORX ( isp - > isp_fwrev ) ;
hba - > fc_fw_minor = ISP_FW_MINORX ( isp - > isp_fwrev ) ;
hba - > fc_fw_micro = ISP_FW_MICROX ( isp - > isp_fwrev ) ;
2009-08-01 01:04:26 +00:00
hba - > fc_nchannels = isp - > isp_nchan ;
2006-07-10 22:39:32 +00:00
if ( IS_FC ( isp ) ) {
2009-08-01 01:04:26 +00:00
hba - > fc_nports = MAX_FC_TARG ;
hba - > fc_speed = FCPARAM ( isp , hba - > fc_channel ) - > isp_gbspeed ;
hba - > fc_topology = FCPARAM ( isp , chan ) - > isp_topo + 1 ;
hba - > fc_loopid = FCPARAM ( isp , chan ) - > isp_loopid ;
hba - > nvram_node_wwn = FCPARAM ( isp , chan ) - > isp_wwnn_nvram ;
hba - > nvram_port_wwn = FCPARAM ( isp , chan ) - > isp_wwpn_nvram ;
hba - > active_node_wwn = FCPARAM ( isp , chan ) - > isp_wwnn ;
hba - > active_port_wwn = FCPARAM ( isp , chan ) - > isp_wwpn ;
} else {
hba - > fc_nports = MAX_TARGETS ;
hba - > fc_speed = 0 ;
hba - > fc_topology = 0 ;
hba - > nvram_node_wwn = 0ull ;
hba - > nvram_port_wwn = 0ull ;
hba - > active_node_wwn = 0ull ;
hba - > active_port_wwn = 0ull ;
2006-07-10 22:39:32 +00:00
}
2002-06-16 05:08:02 +00:00
retval = 0 ;
break ;
}
2005-10-29 02:46:59 +00:00
case ISP_TSK_MGMT :
{
int needmarker ;
struct isp_fc_tsk_mgmt * fct = ( struct isp_fc_tsk_mgmt * ) addr ;
2015-11-18 11:14:59 +00:00
uint16_t nphdl ;
2005-10-29 02:46:59 +00:00
mbreg_t mbs ;
if ( IS_SCSI ( isp ) ) {
break ;
}
2009-08-01 01:04:26 +00:00
chan = fct - > chan ;
if ( chan < 0 | | chan > = isp - > isp_nchan ) {
retval = - ENXIO ;
2005-10-29 02:46:59 +00:00
break ;
}
2009-08-01 01:04:26 +00:00
needmarker = retval = 0 ;
2015-11-18 11:14:59 +00:00
nphdl = fct - > loopid ;
2009-08-01 01:04:26 +00:00
ISP_LOCK ( isp ) ;
if ( IS_24XX ( isp ) ) {
2016-04-12 12:31:41 +00:00
void * reqp ;
uint8_t resp [ QENTRY_LEN ] ;
isp24xx_tmf_t tmf ;
isp24xx_statusreq_t sp ;
2009-08-01 01:04:26 +00:00
fcparam * fcp = FCPARAM ( isp , chan ) ;
fcportdb_t * lp ;
int i ;
for ( i = 0 ; i < MAX_FC_TARG ; i + + ) {
lp = & fcp - > portdb [ i ] ;
2015-11-18 11:14:59 +00:00
if ( lp - > handle = = nphdl ) {
2009-08-01 01:04:26 +00:00
break ;
}
2005-10-29 02:46:59 +00:00
}
2009-08-01 01:04:26 +00:00
if ( i = = MAX_FC_TARG ) {
retval = ENXIO ;
ISP_UNLOCK ( isp ) ;
break ;
}
2016-04-12 12:31:41 +00:00
ISP_MEMZERO ( & tmf , sizeof ( tmf ) ) ;
tmf . tmf_header . rqs_entry_type = RQSTYPE_TSK_MGMT ;
tmf . tmf_header . rqs_entry_count = 1 ;
tmf . tmf_nphdl = lp - > handle ;
tmf . tmf_delay = 2 ;
tmf . tmf_timeout = 4 ;
tmf . tmf_tidlo = lp - > portid ;
tmf . tmf_tidhi = lp - > portid > > 16 ;
tmf . tmf_vpidx = ISP_GET_VPIDX ( isp , chan ) ;
tmf . tmf_lun [ 1 ] = fct - > lun & 0xff ;
2009-08-01 01:04:26 +00:00
if ( fct - > lun > = 256 ) {
2016-04-12 12:31:41 +00:00
tmf . tmf_lun [ 0 ] = 0x40 | ( fct - > lun > > 8 ) ;
2009-08-01 01:04:26 +00:00
}
switch ( fct - > action ) {
case IPT_CLEAR_ACA :
2016-04-12 12:31:41 +00:00
tmf . tmf_flags = ISP24XX_TMF_CLEAR_ACA ;
2009-08-01 01:04:26 +00:00
break ;
case IPT_TARGET_RESET :
2016-04-12 12:31:41 +00:00
tmf . tmf_flags = ISP24XX_TMF_TARGET_RESET ;
2009-08-01 01:04:26 +00:00
needmarker = 1 ;
break ;
case IPT_LUN_RESET :
2016-04-12 12:31:41 +00:00
tmf . tmf_flags = ISP24XX_TMF_LUN_RESET ;
2009-08-01 01:04:26 +00:00
needmarker = 1 ;
break ;
case IPT_CLEAR_TASK_SET :
2016-04-12 12:31:41 +00:00
tmf . tmf_flags = ISP24XX_TMF_CLEAR_TASK_SET ;
2009-08-01 01:04:26 +00:00
needmarker = 1 ;
break ;
case IPT_ABORT_TASK_SET :
2016-04-12 12:31:41 +00:00
tmf . tmf_flags = ISP24XX_TMF_ABORT_TASK_SET ;
2009-08-01 01:04:26 +00:00
needmarker = 1 ;
break ;
default :
retval = EINVAL ;
break ;
}
if ( retval ) {
ISP_UNLOCK ( isp ) ;
break ;
}
2016-04-12 12:31:41 +00:00
/* Prepare space for response in memory */
memset ( resp , 0xff , sizeof ( resp ) ) ;
tmf . tmf_handle = isp_allocate_handle ( isp , resp ,
ISP_HANDLE_CTRL ) ;
if ( tmf . tmf_handle = = 0 ) {
isp_prt ( isp , ISP_LOGERR ,
" %s: TMF of Chan %d out of handles " ,
__func__ , chan ) ;
2009-08-01 01:04:26 +00:00
ISP_UNLOCK ( isp ) ;
retval = ENOMEM ;
break ;
}
2016-04-12 12:31:41 +00:00
/* Send request and wait for response. */
reqp = isp_getrqentry ( isp ) ;
if ( reqp = = NULL ) {
isp_prt ( isp , ISP_LOGERR ,
" %s: TMF of Chan %d out of rqent " ,
__func__ , chan ) ;
isp_destroy_handle ( isp , tmf . tmf_handle ) ;
ISP_UNLOCK ( isp ) ;
2005-10-29 02:46:59 +00:00
retval = EIO ;
2016-04-12 12:31:41 +00:00
break ;
2009-08-01 01:04:26 +00:00
}
2016-04-12 12:31:41 +00:00
isp_put_24xx_tmf ( isp , & tmf , ( isp24xx_tmf_t * ) reqp ) ;
if ( isp - > isp_dblev & ISP_LOGDEBUG1 )
isp_print_bytes ( isp , " IOCB TMF " , QENTRY_LEN , reqp ) ;
ISP_SYNC_REQUEST ( isp ) ;
if ( msleep ( resp , & isp - > isp_lock , 0 , " TMF " , 5 * hz ) = = EWOULDBLOCK ) {
isp_prt ( isp , ISP_LOGERR ,
" %s: TMF of Chan %d timed out " ,
__func__ , chan ) ;
isp_destroy_handle ( isp , tmf . tmf_handle ) ;
ISP_UNLOCK ( isp ) ;
retval = EIO ;
break ;
2009-08-01 01:04:26 +00:00
}
2016-04-12 12:31:41 +00:00
if ( isp - > isp_dblev & ISP_LOGDEBUG1 )
isp_print_bytes ( isp , " IOCB TMF response " , QENTRY_LEN , resp ) ;
isp_get_24xx_response ( isp , ( isp24xx_statusreq_t * ) resp , & sp ) ;
if ( sp . req_completion_status ! = 0 )
retval = EIO ;
else if ( needmarker )
fcp - > sendmarker = 1 ;
2009-08-01 01:04:26 +00:00
} else {
MBSINIT ( & mbs , 0 , MBLOGALL , 0 ) ;
if ( ISP_CAP_2KLOGIN ( isp ) = = 0 ) {
2015-11-18 11:14:59 +00:00
nphdl < < = 8 ;
2009-08-01 01:04:26 +00:00
}
switch ( fct - > action ) {
case IPT_CLEAR_ACA :
mbs . param [ 0 ] = MBOX_CLEAR_ACA ;
2015-11-18 11:14:59 +00:00
mbs . param [ 1 ] = nphdl ;
2009-08-01 01:04:26 +00:00
mbs . param [ 2 ] = fct - > lun ;
break ;
case IPT_TARGET_RESET :
mbs . param [ 0 ] = MBOX_TARGET_RESET ;
2015-11-18 11:14:59 +00:00
mbs . param [ 1 ] = nphdl ;
2009-08-01 01:04:26 +00:00
needmarker = 1 ;
break ;
case IPT_LUN_RESET :
mbs . param [ 0 ] = MBOX_LUN_RESET ;
2015-11-18 11:14:59 +00:00
mbs . param [ 1 ] = nphdl ;
2009-08-01 01:04:26 +00:00
mbs . param [ 2 ] = fct - > lun ;
needmarker = 1 ;
break ;
case IPT_CLEAR_TASK_SET :
mbs . param [ 0 ] = MBOX_CLEAR_TASK_SET ;
2015-11-18 11:14:59 +00:00
mbs . param [ 1 ] = nphdl ;
2009-08-01 01:04:26 +00:00
mbs . param [ 2 ] = fct - > lun ;
needmarker = 1 ;
break ;
case IPT_ABORT_TASK_SET :
mbs . param [ 0 ] = MBOX_ABORT_TASK_SET ;
2015-11-18 11:14:59 +00:00
mbs . param [ 1 ] = nphdl ;
2009-08-01 01:04:26 +00:00
mbs . param [ 2 ] = fct - > lun ;
needmarker = 1 ;
break ;
default :
retval = EINVAL ;
break ;
}
if ( retval = = 0 ) {
if ( needmarker ) {
FCPARAM ( isp , chan ) - > sendmarker = 1 ;
}
retval = isp_control ( isp , ISPCTL_RUN_MBOXCMD , & mbs ) ;
if ( retval ) {
retval = EIO ;
}
}
2005-10-29 02:46:59 +00:00
}
2009-08-01 01:04:26 +00:00
ISP_UNLOCK ( isp ) ;
2005-10-29 02:46:59 +00:00
break ;
}
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
default :
break ;
}
return ( retval ) ;
2000-01-03 23:55:30 +00:00
}
2009-08-01 01:04:26 +00:00
/*
* Local Inlines
*/
2006-11-14 08:45:48 +00:00
2009-08-01 01:04:26 +00:00
static ISP_INLINE int isp_get_pcmd ( ispsoftc_t * , union ccb * ) ;
static ISP_INLINE void isp_free_pcmd ( ispsoftc_t * , union ccb * ) ;
2006-11-14 08:45:48 +00:00
2009-08-01 01:04:26 +00:00
static ISP_INLINE int
isp_get_pcmd ( ispsoftc_t * isp , union ccb * ccb )
2000-07-04 01:05:43 +00:00
{
2009-08-01 01:04:26 +00:00
ISP_PCMD ( ccb ) = isp - > isp_osinfo . pcmd_free ;
if ( ISP_PCMD ( ccb ) = = NULL ) {
return ( - 1 ) ;
2001-02-11 03:47:39 +00:00
}
2009-08-01 01:04:26 +00:00
isp - > isp_osinfo . pcmd_free = ( ( struct isp_pcmd * ) ISP_PCMD ( ccb ) ) - > next ;
return ( 0 ) ;
2000-07-04 01:05:43 +00:00
}
2000-01-03 23:55:30 +00:00
2009-08-01 01:04:26 +00:00
static ISP_INLINE void
isp_free_pcmd ( ispsoftc_t * isp , union ccb * 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
if ( ISP_PCMD ( ccb ) ) {
2012-08-12 20:45:47 +00:00
# ifdef ISP_TARGET_MODE
PISP_PCMD ( ccb ) - > datalen = 0 ;
# endif
PISP_PCMD ( ccb ) - > next = isp - > isp_osinfo . pcmd_free ;
-----------
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 - > isp_osinfo . pcmd_free = ISP_PCMD ( ccb ) ;
ISP_PCMD ( ccb ) = NULL ;
}
2009-08-01 01:04:26 +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
2000-01-03 23:55:30 +00:00
/*
* Put the target mode functions here , because some are inlines
*/
# ifdef ISP_TARGET_MODE
2009-08-01 01:04:26 +00:00
static ISP_INLINE tstate_t * get_lun_statep ( ispsoftc_t * , int , lun_id_t ) ;
2017-02-22 06:43:49 +00:00
static atio_private_data_t * isp_get_atpd ( ispsoftc_t * , int , uint32_t ) ;
static atio_private_data_t * isp_find_atpd ( ispsoftc_t * , int , uint32_t ) ;
static void isp_put_atpd ( ispsoftc_t * , int , atio_private_data_t * ) ;
static inot_private_data_t * isp_get_ntpd ( ispsoftc_t * , int ) ;
static inot_private_data_t * isp_find_ntpd ( ispsoftc_t * , int , uint32_t , uint32_t ) ;
static void isp_put_ntpd ( ispsoftc_t * , int , inot_private_data_t * ) ;
2009-08-01 01:04:26 +00:00
static cam_status create_lun_state ( ispsoftc_t * , int , struct cam_path * , tstate_t * * ) ;
2017-02-22 06:43:49 +00:00
static void destroy_lun_state ( ispsoftc_t * , int , tstate_t * ) ;
2009-08-01 01:04:26 +00:00
static void isp_enable_lun ( ispsoftc_t * , union ccb * ) ;
static void isp_disable_lun ( ispsoftc_t * , union ccb * ) ;
2000-07-18 06:58:28 +00:00
static timeout_t isp_refire_putback_atio ;
-----------
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
static timeout_t isp_refire_notify_ack ;
2001-04-04 21:58:29 +00:00
static void isp_complete_ctio ( union ccb * ) ;
static void isp_target_putback_atio ( union ccb * ) ;
2012-08-08 18:24:33 +00:00
enum Start_Ctio_How { FROM_CAM , FROM_TIMER , FROM_SRR , FROM_CTIO_DONE } ;
-----------
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
static void isp_target_start_ctio ( ispsoftc_t * , union ccb * , enum Start_Ctio_How ) ;
2009-08-01 01:04:26 +00:00
static void isp_handle_platform_atio2 ( ispsoftc_t * , at2_entry_t * ) ;
static void isp_handle_platform_atio7 ( ispsoftc_t * , at7_entry_t * ) ;
static void isp_handle_platform_ctio ( ispsoftc_t * , void * ) ;
2016-05-20 10:26:12 +00:00
static int isp_handle_platform_target_notify_ack ( ispsoftc_t * , isp_notify_t * , uint32_t rsp ) ;
2009-08-01 01:04:26 +00:00
static void isp_handle_platform_target_tmf ( ispsoftc_t * , isp_notify_t * ) ;
2017-02-22 06:43:49 +00:00
static void isp_target_mark_aborted_early ( ispsoftc_t * , int chan , tstate_t * , uint32_t ) ;
2000-01-03 23:55:30 +00:00
2009-08-01 01:04:26 +00:00
static ISP_INLINE tstate_t *
2006-04-21 18:30:01 +00:00
get_lun_statep ( ispsoftc_t * isp , int bus , lun_id_t lun )
2000-01-03 23:55:30 +00:00
{
I don't know what I was thinking- if I have two separate busses on on
SIM (as is true for the 1280 and the 12160), then I have to have separate
flags && status for *both* busses. *Whap*.
Implement condition variables for coordination with some target mode
events. It's nice to use these and not panic in obscure little places
in the kernel like 'propagate_priority' just because we went to sleep
holding a mutex, or some other absurd thing.
Remove some bogus ISP_UNLOCK calls. *Whap*.
No longer require that somebody do a lun enable on the wildcard device
to enable target mode. They are, in fact, orthogonal. A wildcard open
is a statement that somebody upstream is willing to accept commands which
are otherwise unrouteable. Now, for QLogic regular SCSI target mode, this
won't matter for a damn because we'll never see ATIOs for luns we haven't
enabled (are listening for, if you will). But for SCCLUN fibre channel
SCSI, we get all kinds of ATIOs. We can either reflect them back here
with minimal info (which is isp_target.c:isp_endcmd() is for), or the
wildcard device (nominally targbh) can handle them.
Do further checking against firmware attributes to see whether we can,
in fact, support target mode in Fibre Channel. For now, require SCCLUN
f/w to supoprt FC target mode.
This is an awful lot of change, but target mode *still* isn't quite right.
MFC after: 4 weeks
2001-09-04 21:53:12 +00:00
tstate_t * tptr = NULL ;
2009-08-01 01:04:26 +00:00
struct tslist * lhp ;
if ( bus < isp - > isp_nchan ) {
2014-11-26 13:56:54 +00:00
ISP_GET_PC_ADDR ( isp , bus , lun_hash [ LUN_HASH_FUNC ( lun ) ] , lhp ) ;
SLIST_FOREACH ( tptr , lhp , next ) {
2017-02-22 06:43:49 +00:00
if ( tptr - > ts_lun = = lun )
2014-11-26 13:56:54 +00:00
return ( tptr ) ;
I don't know what I was thinking- if I have two separate busses on on
SIM (as is true for the 1280 and the 12160), then I have to have separate
flags && status for *both* busses. *Whap*.
Implement condition variables for coordination with some target mode
events. It's nice to use these and not panic in obscure little places
in the kernel like 'propagate_priority' just because we went to sleep
holding a mutex, or some other absurd thing.
Remove some bogus ISP_UNLOCK calls. *Whap*.
No longer require that somebody do a lun enable on the wildcard device
to enable target mode. They are, in fact, orthogonal. A wildcard open
is a statement that somebody upstream is willing to accept commands which
are otherwise unrouteable. Now, for QLogic regular SCSI target mode, this
won't matter for a damn because we'll never see ATIOs for luns we haven't
enabled (are listening for, if you will). But for SCCLUN fibre channel
SCSI, we get all kinds of ATIOs. We can either reflect them back here
with minimal info (which is isp_target.c:isp_endcmd() is for), or the
wildcard device (nominally targbh) can handle them.
Do further checking against firmware attributes to see whether we can,
in fact, support target mode in Fibre Channel. For now, require SCCLUN
f/w to supoprt FC target mode.
This is an awful lot of change, but target mode *still* isn't quite right.
MFC after: 4 weeks
2001-09-04 21:53:12 +00:00
}
2000-01-03 23:55:30 +00:00
}
2009-08-01 01:04:26 +00:00
return ( NULL ) ;
}
2000-01-03 23:55:30 +00:00
2017-02-22 06:43:49 +00:00
static int
isp_atio_restart ( ispsoftc_t * isp , int bus , tstate_t * tptr )
2009-08-01 01:04:26 +00:00
{
inot_private_data_t * ntp ;
2017-02-22 06:43:49 +00:00
struct ntpdlist rq ;
2009-08-01 01:04:26 +00:00
2017-02-22 06:43:49 +00:00
if ( STAILQ_EMPTY ( & tptr - > restart_queue ) )
return ( 0 ) ;
STAILQ_INIT ( & rq ) ;
STAILQ_CONCAT ( & rq , & tptr - > restart_queue ) ;
while ( ( ntp = STAILQ_FIRST ( & rq ) ) ! = NULL ) {
STAILQ_REMOVE_HEAD ( & rq , next ) ;
if ( IS_24XX ( isp ) ) {
isp_prt ( isp , ISP_LOGTDEBUG0 ,
" %s: restarting resrc deprived %x " , __func__ ,
( ( at7_entry_t * ) ntp - > data ) - > at_rxid ) ;
isp_handle_platform_atio7 ( isp , ( at7_entry_t * ) ntp - > data ) ;
} else {
isp_prt ( isp , ISP_LOGTDEBUG0 ,
" %s: restarting resrc deprived %x " , __func__ ,
( ( at2_entry_t * ) ntp - > data ) - > at_rxid ) ;
isp_handle_platform_atio2 ( isp , ( at2_entry_t * ) ntp - > data ) ;
2009-08-01 01:04:26 +00:00
}
2017-02-22 06:43:49 +00:00
isp_put_ntpd ( isp , bus , ntp ) ;
if ( ! STAILQ_EMPTY ( & tptr - > restart_queue ) )
break ;
2009-08-01 01:04:26 +00:00
}
2017-02-22 06:43:49 +00:00
if ( ! STAILQ_EMPTY ( & rq ) ) {
STAILQ_CONCAT ( & rq , & tptr - > restart_queue ) ;
STAILQ_CONCAT ( & tptr - > restart_queue , & rq ) ;
}
return ( ! STAILQ_EMPTY ( & tptr - > restart_queue ) ) ;
2009-08-01 01:04:26 +00:00
}
static void
isp_tmcmd_restart ( ispsoftc_t * isp )
{
tstate_t * tptr ;
2012-08-08 18:24:33 +00:00
union ccb * ccb ;
2009-08-01 01:04:26 +00:00
struct tslist * lhp ;
2017-02-19 05:07:02 +00:00
struct isp_ccbq * waitq ;
2009-08-01 01:04:26 +00:00
int bus , i ;
for ( bus = 0 ; bus < isp - > isp_nchan ; bus + + ) {
for ( i = 0 ; i < LUN_HASH_SIZE ; i + + ) {
ISP_GET_PC_ADDR ( isp , bus , lun_hash [ i ] , lhp ) ;
2017-02-22 06:43:49 +00:00
SLIST_FOREACH ( tptr , lhp , next )
isp_atio_restart ( isp , bus , tptr ) ;
2009-08-01 01:04:26 +00:00
}
2017-02-19 05:07:02 +00:00
/*
* We only need to do this once per channel .
*/
ISP_GET_PC_ADDR ( isp , bus , waitq , waitq ) ;
ccb = ( union ccb * ) TAILQ_FIRST ( waitq ) ;
if ( ccb ! = NULL ) {
2017-03-22 11:06:33 +00:00
TAILQ_REMOVE ( waitq , & ccb - > ccb_h , sim_links . tqe ) ;
2017-02-19 05:07:02 +00:00
isp_target_start_ctio ( isp , ccb , FROM_TIMER ) ;
}
2009-08-01 01:04:26 +00:00
}
2000-01-03 23:55:30 +00:00
}
2017-02-22 06:43:49 +00:00
static atio_private_data_t *
isp_get_atpd ( ispsoftc_t * isp , int chan , uint32_t tag )
2001-10-01 03:48:42 +00:00
{
2017-02-22 06:43:49 +00:00
struct atpdlist * atfree ;
struct atpdlist * atused ;
2001-10-01 03:48:42 +00:00
atio_private_data_t * atp ;
2009-08-01 01:04:26 +00:00
2017-02-22 06:43:49 +00:00
ISP_GET_PC_ADDR ( isp , chan , atfree , atfree ) ;
atp = LIST_FIRST ( atfree ) ;
2013-10-17 20:19:15 +00:00
if ( atp ) {
LIST_REMOVE ( atp , next ) ;
atp - > tag = tag ;
2017-02-22 06:43:49 +00:00
ISP_GET_PC ( isp , chan , atused , atused ) ;
LIST_INSERT_HEAD ( & atused [ ATPDPHASH ( tag ) ] , atp , next ) ;
2009-08-01 01:04:26 +00:00
}
2013-10-17 20:19:15 +00:00
return ( atp ) ;
}
2017-02-22 06:43:49 +00:00
static atio_private_data_t *
isp_find_atpd ( ispsoftc_t * isp , int chan , uint32_t tag )
2013-10-17 20:19:15 +00:00
{
2017-02-22 06:43:49 +00:00
struct atpdlist * atused ;
2013-10-17 20:19:15 +00:00
atio_private_data_t * atp ;
2017-02-22 06:43:49 +00:00
ISP_GET_PC ( isp , chan , atused , atused ) ;
LIST_FOREACH ( atp , & atused [ ATPDPHASH ( tag ) ] , next ) {
2013-10-17 20:19:15 +00:00
if ( atp - > tag = = tag )
2001-10-01 03:48:42 +00:00
return ( atp ) ;
2009-08-01 01:04:26 +00:00
}
return ( NULL ) ;
}
2017-02-22 06:43:49 +00:00
static void
isp_put_atpd ( ispsoftc_t * isp , int chan , atio_private_data_t * atp )
2009-08-01 01:04:26 +00:00
{
2017-02-22 06:43:49 +00:00
struct atpdlist * atfree ;
-----------
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 ( atp - > ests ) {
isp_put_ecmd ( isp , atp - > ests ) ;
}
2013-10-17 20:19:15 +00:00
LIST_REMOVE ( atp , 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
memset ( atp , 0 , sizeof ( * atp ) ) ;
2017-02-22 06:43:49 +00:00
ISP_GET_PC_ADDR ( isp , chan , atfree , atfree ) ;
LIST_INSERT_HEAD ( atfree , atp , next ) ;
2009-08-01 01:04:26 +00:00
}
static void
2017-02-22 06:43:49 +00:00
isp_dump_atpd ( ispsoftc_t * isp , int chan )
2009-08-01 01:04:26 +00:00
{
2017-02-22 06:43:49 +00:00
atio_private_data_t * atp , * atpool ;
2009-08-01 01:04:26 +00:00
const char * states [ 8 ] = { " Free " , " ATIO " , " CAM " , " CTIO " , " LAST_CTIO " , " PDON " , " ?6 " , " 7 " } ;
2017-02-22 06:43:49 +00:00
ISP_GET_PC ( isp , chan , atpool , atpool ) ;
for ( atp = atpool ; atp < & atpool [ ATPDPSIZE ] ; atp + + ) {
2017-02-22 07:12:20 +00:00
if ( atp - > state = = ATPD_STATE_FREE )
continue ;
isp_prt ( isp , ISP_LOGALL , " Chan %d ATP [0x%x] origdlen %u bytes_xfrd %u lun %jx nphdl 0x%04x s_id 0x%06x d_id 0x%06x oxid 0x%04x state %s " ,
2017-02-27 08:20:28 +00:00
chan , atp - > tag , atp - > orig_datalen , atp - > bytes_xfered , ( uintmax_t ) atp - > lun , atp - > nphdl , atp - > sid , atp - > did , atp - > oxid , states [ atp - > state & 0x7 ] ) ;
2009-08-01 01:04:26 +00:00
}
}
2017-02-22 06:43:49 +00:00
static inot_private_data_t *
isp_get_ntpd ( ispsoftc_t * isp , int chan )
2009-08-01 01:04:26 +00:00
{
2017-02-22 06:43:49 +00:00
struct ntpdlist * ntfree ;
2009-08-01 01:04:26 +00:00
inot_private_data_t * ntp ;
2017-02-22 06:43:49 +00:00
ISP_GET_PC_ADDR ( isp , chan , ntfree , ntfree ) ;
ntp = STAILQ_FIRST ( ntfree ) ;
if ( ntp )
STAILQ_REMOVE_HEAD ( ntfree , next ) ;
2009-08-01 01:04:26 +00:00
return ( ntp ) ;
}
2017-02-22 06:43:49 +00:00
static inot_private_data_t *
isp_find_ntpd ( ispsoftc_t * isp , int chan , uint32_t tag_id , uint32_t seq_id )
2009-08-01 01:04:26 +00:00
{
2017-02-22 06:43:49 +00:00
inot_private_data_t * ntp , * ntp2 ;
ISP_GET_PC ( isp , chan , ntpool , ntp ) ;
ISP_GET_PC_ADDR ( isp , chan , ntpool [ ATPDPSIZE ] , ntp2 ) ;
for ( ; ntp < ntp2 ; ntp + + ) {
if ( ntp - > tag_id = = tag_id & & ntp - > seq_id = = seq_id )
2009-08-01 01:04:26 +00:00
return ( ntp ) ;
2001-10-01 03:48:42 +00:00
}
return ( NULL ) ;
}
2017-02-22 06:43:49 +00:00
static void
isp_put_ntpd ( ispsoftc_t * isp , int chan , inot_private_data_t * ntp )
2009-08-01 01:04:26 +00:00
{
2017-02-22 06:43:49 +00:00
struct ntpdlist * ntfree ;
ntp - > tag_id = ntp - > seq_id = 0 ;
ISP_GET_PC_ADDR ( isp , chan , ntfree , ntfree ) ;
STAILQ_INSERT_HEAD ( ntfree , ntp , next ) ;
2009-08-01 01:04:26 +00:00
}
2000-01-03 23:55:30 +00:00
static cam_status
2009-08-01 01:04:26 +00:00
create_lun_state ( ispsoftc_t * isp , int bus , struct cam_path * path , tstate_t * * rslt )
2000-01-03 23:55:30 +00:00
{
lun_id_t lun ;
2009-08-01 01:04:26 +00:00
struct tslist * lhp ;
tstate_t * tptr ;
2000-01-03 23:55:30 +00:00
lun = xpt_path_lun_id ( path ) ;
2009-08-01 01:04:26 +00:00
if ( lun ! = CAM_LUN_WILDCARD ) {
2015-10-24 17:34:40 +00:00
if ( ISP_MAX_LUNS ( isp ) > 0 & & lun > = ISP_MAX_LUNS ( isp ) ) {
2009-08-01 01:04:26 +00:00
return ( CAM_LUN_INVALID ) ;
}
2000-01-03 23:55:30 +00:00
}
2012-06-01 23:29:48 +00:00
tptr = malloc ( sizeof ( tstate_t ) , M_DEVBUF , M_NOWAIT | M_ZERO ) ;
2009-08-01 01:04:26 +00:00
if ( tptr = = NULL ) {
2000-01-03 23:55:30 +00:00
return ( CAM_RESRC_UNAVAIL ) ;
}
2014-11-26 13:56:54 +00:00
tptr - > ts_lun = lun ;
2009-08-01 01:04:26 +00:00
SLIST_INIT ( & tptr - > atios ) ;
SLIST_INIT ( & tptr - > inots ) ;
2017-08-23 19:00:06 +00:00
STAILQ_INIT ( & tptr - > restart_queue ) ;
2014-11-26 13:56:54 +00:00
ISP_GET_PC_ADDR ( isp , bus , lun_hash [ LUN_HASH_FUNC ( lun ) ] , lhp ) ;
2009-08-01 01:04:26 +00:00
SLIST_INSERT_HEAD ( lhp , tptr , next ) ;
* rslt = tptr ;
ISP_PATH_PRT ( isp , ISP_LOGTDEBUG0 , path , " created tstate \n " ) ;
2000-01-03 23:55:30 +00:00
return ( CAM_REQ_CMP ) ;
}
2017-02-22 06:43:49 +00:00
static void
destroy_lun_state ( ispsoftc_t * isp , int bus , tstate_t * tptr )
2000-01-03 23:55:30 +00:00
{
2012-08-16 15:32:16 +00:00
union ccb * ccb ;
2009-08-01 01:04:26 +00:00
struct tslist * lhp ;
2017-02-22 06:43:49 +00:00
inot_private_data_t * ntp ;
2012-06-01 23:29:48 +00:00
2017-02-22 06:43:49 +00:00
while ( ( ccb = ( union ccb * ) SLIST_FIRST ( & tptr - > atios ) ) ! = NULL ) {
SLIST_REMOVE_HEAD ( & tptr - > atios , sim_links . sle ) ;
ccb - > ccb_h . status = CAM_REQ_ABORTED ;
xpt_done ( ccb ) ;
} ;
while ( ( ccb = ( union ccb * ) SLIST_FIRST ( & tptr - > inots ) ) ! = NULL ) {
SLIST_REMOVE_HEAD ( & tptr - > inots , sim_links . sle ) ;
ccb - > ccb_h . status = CAM_REQ_ABORTED ;
xpt_done ( ccb ) ;
}
while ( ( ntp = STAILQ_FIRST ( & tptr - > restart_queue ) ) ! = NULL ) {
isp_endcmd ( isp , ntp - > data , NIL_HANDLE , bus , SCSI_STATUS_BUSY , 0 ) ;
STAILQ_REMOVE_HEAD ( & tptr - > restart_queue , next ) ;
isp_put_ntpd ( isp , bus , ntp ) ;
}
ISP_GET_PC_ADDR ( isp , bus , lun_hash [ LUN_HASH_FUNC ( tptr - > ts_lun ) ] , lhp ) ;
2009-08-01 01:04:26 +00:00
SLIST_REMOVE ( lhp , tptr , tstate , next ) ;
2000-01-03 23:55:30 +00:00
free ( tptr , M_DEVBUF ) ;
1998-09-15 08:42:56 +00:00
}
2009-08-01 01:04:26 +00:00
static void
isp_enable_lun ( ispsoftc_t * isp , union ccb * ccb )
2000-01-03 23:55:30 +00:00
{
2015-11-23 10:06:19 +00:00
tstate_t * tptr ;
int bus ;
2009-08-01 01:04:26 +00:00
target_id_t target ;
2000-01-03 23:55:30 +00:00
lun_id_t lun ;
2015-11-23 10:06:19 +00:00
if ( ! IS_FC ( isp ) | | ! ISP_CAP_TMODE ( isp ) | | ! ISP_CAP_SCCFW ( isp ) ) {
xpt_print ( ccb - > ccb_h . path , " Target mode is not supported \n " ) ;
ccb - > ccb_h . status = CAM_FUNC_NOTAVAIL ;
xpt_done ( ccb ) ;
return ;
}
2012-06-01 23:29:48 +00:00
2009-08-01 01:04:26 +00:00
/*
2015-11-23 10:06:19 +00:00
* We only support either target and lun both wildcard
* or target and lun both non - wildcard .
2009-08-01 01:04:26 +00:00
*/
2004-02-08 19:17:56 +00:00
bus = XS_CHANNEL ( ccb ) ;
2009-08-01 01:04:26 +00:00
target = ccb - > ccb_h . target_id ;
2000-01-03 23:55:30 +00:00
lun = ccb - > ccb_h . target_lun ;
2015-10-24 17:34:40 +00:00
ISP_PATH_PRT ( isp , ISP_LOGTDEBUG0 | ISP_LOGCONFIG , ccb - > ccb_h . path ,
" enabling lun %jx \n " , ( uintmax_t ) lun ) ;
2015-11-23 10:06:19 +00:00
if ( ( target = = CAM_TARGET_WILDCARD ) ! = ( lun = = CAM_LUN_WILDCARD ) ) {
2009-08-01 01:04:26 +00:00
ccb - > ccb_h . status = CAM_LUN_INVALID ;
xpt_done ( ccb ) ;
return ;
}
2015-11-23 10:06:19 +00:00
/* Create the state pointer. It should not already exist. */
2009-08-01 01:04:26 +00:00
tptr = get_lun_statep ( isp , bus , lun ) ;
if ( tptr ) {
ccb - > ccb_h . status = CAM_LUN_ALRDY_ENA ;
2015-11-23 10:06:19 +00:00
xpt_done ( ccb ) ;
return ;
2009-08-01 01:04:26 +00:00
}
ccb - > ccb_h . status = create_lun_state ( isp , bus , ccb - > ccb_h . path , & tptr ) ;
if ( ccb - > ccb_h . status ! = CAM_REQ_CMP ) {
2015-11-23 10:06:19 +00:00
xpt_done ( ccb ) ;
return ;
2004-02-08 19:17:56 +00:00
}
2012-06-01 23:29:48 +00:00
2015-11-23 10:06:19 +00:00
ccb - > ccb_h . status = CAM_REQ_CMP ;
2009-08-01 01:04:26 +00:00
xpt_done ( ccb ) ;
}
2000-01-03 23:55:30 +00:00
2004-02-08 19:17:56 +00:00
static void
2009-08-01 01:04:26 +00:00
isp_disable_lun ( ispsoftc_t * isp , union ccb * ccb )
2004-02-08 19:17:56 +00:00
{
2009-08-01 01:04:26 +00:00
tstate_t * tptr = NULL ;
int bus ;
target_id_t target ;
lun_id_t lun ;
2000-01-03 23:55:30 +00:00
2009-08-01 01:04:26 +00:00
bus = XS_CHANNEL ( ccb ) ;
target = ccb - > ccb_h . target_id ;
lun = ccb - > ccb_h . target_lun ;
2015-10-24 17:34:40 +00:00
ISP_PATH_PRT ( isp , ISP_LOGTDEBUG0 | ISP_LOGCONFIG , ccb - > ccb_h . path ,
" disabling lun %jx \n " , ( uintmax_t ) lun ) ;
2015-11-23 10:06:19 +00:00
if ( ( target = = CAM_TARGET_WILDCARD ) ! = ( lun = = CAM_LUN_WILDCARD ) ) {
2009-08-01 01:04:26 +00:00
ccb - > ccb_h . status = CAM_LUN_INVALID ;
xpt_done ( ccb ) ;
2004-02-08 19:17:56 +00:00
return ;
2000-01-03 23:55:30 +00:00
}
2001-08-31 21:39:04 +00:00
2015-11-23 10:06:19 +00:00
/* Find the state pointer. */
if ( ( tptr = get_lun_statep ( isp , bus , lun ) ) = = NULL ) {
ccb - > ccb_h . status = CAM_PATH_INVALID ;
2004-02-08 19:17:56 +00:00
xpt_done ( ccb ) ;
return ;
2009-08-01 01:04:26 +00:00
}
2004-02-08 19:17:56 +00:00
2017-02-22 06:43:49 +00:00
destroy_lun_state ( isp , bus , tptr ) ;
2015-11-23 10:06:19 +00:00
ccb - > ccb_h . status = CAM_REQ_CMP ;
2009-08-01 01:04:26 +00:00
xpt_done ( ccb ) ;
}
2006-04-21 18:30:01 +00:00
static void
-----------
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_target_start_ctio ( ispsoftc_t * isp , union ccb * ccb , enum Start_Ctio_How how )
2000-01-03 23:55:30 +00:00
{
2012-08-08 18:24:33 +00:00
int fctape , sendstatus , resid ;
-----------
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
fcparam * fcp ;
2009-08-01 01:04:26 +00:00
atio_private_data_t * atp ;
2012-08-08 18:24:33 +00:00
struct ccb_scsiio * cso ;
2017-02-19 05:07:02 +00:00
struct isp_ccbq * waitq ;
2012-08-08 18:24:33 +00:00
uint32_t dmaresult , handle , xfrlen , sense_length , tmp ;
2006-02-15 00:31:48 +00:00
uint8_t local [ QENTRY_LEN ] ;
2000-01-03 23:55:30 +00:00
2012-08-08 18:24:33 +00:00
isp_prt ( isp , ISP_LOGTDEBUG0 , " %s: ENTRY[0x%x] how %u xfrlen %u sendstatus %d sense_len %u " , __func__ , ccb - > csio . tag_id , how , ccb - > csio . dxfer_len ,
( ccb - > ccb_h . flags & CAM_SEND_STATUS ) ! = 0 , ( ( ccb - > ccb_h . flags & CAM_SEND_SENSE ) ? ccb - > csio . sense_len : 0 ) ) ;
2009-08-01 01:04:26 +00:00
2017-02-19 05:07:02 +00:00
ISP_GET_PC_ADDR ( isp , XS_CHANNEL ( ccb ) , waitq , waitq ) ;
2012-08-08 18:24:33 +00:00
switch ( how ) {
case FROM_CAM :
/*
* Insert at the tail of the list , if any , waiting CTIO CCBs
*/
2017-03-22 11:06:33 +00:00
TAILQ_INSERT_TAIL ( waitq , & ccb - > ccb_h , sim_links . tqe ) ;
2012-08-08 18:24:33 +00:00
break ;
2017-02-19 05:07:02 +00:00
case FROM_TIMER :
2012-08-08 18:24:33 +00:00
case FROM_SRR :
case FROM_CTIO_DONE :
2017-03-22 11:06:33 +00:00
TAILQ_INSERT_HEAD ( waitq , & ccb - > ccb_h , sim_links . tqe ) ;
2012-08-08 18:24:33 +00:00
break ;
2009-08-01 01:04:26 +00:00
}
2017-02-19 05:07:02 +00:00
while ( ( ccb = ( union ccb * ) TAILQ_FIRST ( waitq ) ) ! = NULL ) {
2017-03-22 11:06:33 +00:00
TAILQ_REMOVE ( waitq , & ccb - > ccb_h , sim_links . tqe ) ;
2000-07-18 06:58:28 +00:00
2012-08-08 18:24:33 +00:00
cso = & ccb - > csio ;
xfrlen = cso - > dxfer_len ;
if ( xfrlen = = 0 ) {
if ( ( ccb - > ccb_h . flags & CAM_SEND_STATUS ) = = 0 ) {
ISP_PATH_PRT ( isp , ISP_LOGERR , ccb - > ccb_h . path , " a data transfer length of zero but no status to send is wrong \n " ) ;
ccb - > ccb_h . status = CAM_REQ_INVALID ;
xpt_done ( ccb ) ;
continue ;
}
}
-----------
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
2017-02-22 06:43:49 +00:00
atp = isp_find_atpd ( isp , XS_CHANNEL ( ccb ) , cso - > tag_id ) ;
2012-08-08 18:24:33 +00:00
if ( atp = = NULL ) {
isp_prt ( isp , ISP_LOGERR , " %s: [0x%x] cannot find private data adjunct in %s " , __func__ , cso - > tag_id , __func__ ) ;
2017-02-22 06:43:49 +00:00
isp_dump_atpd ( isp , XS_CHANNEL ( ccb ) ) ;
2012-08-08 18:24:33 +00:00
ccb - > ccb_h . status = CAM_REQ_CMP_ERR ;
xpt_done ( ccb ) ;
continue ;
}
-----------
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
2012-08-08 18:24:33 +00:00
/*
* Is this command a dead duck ?
*/
if ( atp - > dead ) {
isp_prt ( isp , ISP_LOGERR , " %s: [0x%x] not sending a CTIO for a dead command " , __func__ , cso - > tag_id ) ;
ccb - > ccb_h . status = CAM_REQ_ABORTED ;
xpt_done ( ccb ) ;
continue ;
}
2000-01-03 23:55:30 +00:00
2012-08-08 18:24:33 +00:00
/*
* Check to make sure we ' re still in target mode .
*/
fcp = FCPARAM ( isp , XS_CHANNEL ( ccb ) ) ;
if ( ( fcp - > role & ISP_ROLE_TARGET ) = = 0 ) {
isp_prt ( isp , ISP_LOGERR , " %s: [0x%x] stopping sending a CTIO because we're no longer in target mode " , __func__ , cso - > tag_id ) ;
ccb - > ccb_h . status = CAM_PROVIDE_FAIL ;
xpt_done ( ccb ) ;
continue ;
}
-----------
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
2012-08-08 18:24:33 +00:00
/*
* We ' re only handling ATPD_CCB_OUTSTANDING outstanding CCB at a time ( one of which
* could be split into two CTIOs to split data and status ) .
*/
if ( atp - > ctcnt > = ATPD_CCB_OUTSTANDING ) {
isp_prt ( isp , ISP_LOGTINFO , " [0x%x] handling only %d CCBs at a time (flags for this ccb: 0x%x) " , cso - > tag_id , ATPD_CCB_OUTSTANDING , ccb - > ccb_h . flags ) ;
2017-03-22 11:06:33 +00:00
TAILQ_INSERT_HEAD ( waitq , & ccb - > ccb_h , sim_links . tqe ) ;
2012-08-08 18:24:33 +00:00
break ;
}
-----------
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
/*
2012-08-08 18:24:33 +00:00
* Does the initiator expect FC - Tape style responses ?
-----------
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
*/
2012-08-08 18:24:33 +00:00
if ( ( atp - > word3 & PRLI_WD3_RETRY ) & & fcp - > fctape_enabled ) {
fctape = 1 ;
} else {
fctape = 0 ;
}
-----------
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
/*
2012-08-08 18:24:33 +00:00
* If we already did the data xfer portion of a CTIO that sends data
* and status , don ' t do it again and do the status portion now .
-----------
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
*/
2012-08-08 18:24:33 +00:00
if ( atp - > sendst ) {
2016-05-16 17:18:26 +00:00
isp_prt ( isp , ISP_LOGTDEBUG0 , " [0x%x] now sending synthesized status orig_dl=%u xfered=%u bit=%u " ,
2012-08-08 18:24:33 +00:00
cso - > tag_id , atp - > orig_datalen , atp - > bytes_xfered , atp - > bytes_in_transit ) ;
xfrlen = 0 ; /* we already did the data transfer */
atp - > sendst = 0 ;
}
if ( ccb - > ccb_h . flags & CAM_SEND_STATUS ) {
sendstatus = 1 ;
} else {
sendstatus = 0 ;
-----------
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
}
2012-08-08 18:24:33 +00:00
if ( ccb - > ccb_h . flags & CAM_SEND_SENSE ) {
KASSERT ( ( sendstatus ! = 0 ) , ( " how can you have CAM_SEND_SENSE w/o CAM_SEND_STATUS? " ) ) ;
/*
* Sense length is not the entire sense data structure size . Periph
* drivers don ' t seem to be setting sense_len to reflect the actual
* size . We ' ll peek inside to get the right amount .
*/
sense_length = cso - > sense_len ;
-----------
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
2012-08-08 18:24:33 +00:00
/*
* This ' cannot ' happen
*/
if ( sense_length > ( XCMD_SIZE - MIN_FCP_RESPONSE_SIZE ) ) {
sense_length = XCMD_SIZE - MIN_FCP_RESPONSE_SIZE ;
}
} else {
sense_length = 0 ;
}
2000-01-03 23:55:30 +00:00
2012-08-08 18:24:33 +00:00
memset ( local , 0 , QENTRY_LEN ) ;
-----------
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
/*
2012-08-08 18:24:33 +00:00
* Check for overflow
-----------
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
*/
2017-02-26 12:52:44 +00:00
tmp = atp - > bytes_xfered + atp - > bytes_in_transit ;
if ( xfrlen > 0 & & tmp > atp - > orig_datalen ) {
isp_prt ( isp , ISP_LOGERR ,
" %s: [0x%x] data overflow by %u bytes " , __func__ ,
cso - > tag_id , tmp + xfrlen - atp - > orig_datalen ) ;
2012-08-08 18:24:33 +00:00
ccb - > ccb_h . status = CAM_DATA_RUN_ERR ;
xpt_done ( ccb ) ;
continue ;
}
2017-02-26 12:52:44 +00:00
if ( xfrlen > atp - > orig_datalen - tmp ) {
xfrlen = atp - > orig_datalen - tmp ;
if ( xfrlen = = 0 & & ! sendstatus ) {
cso - > resid = cso - > dxfer_len ;
ccb - > ccb_h . status = CAM_REQ_CMP ;
xpt_done ( ccb ) ;
continue ;
}
}
2012-08-08 18:24:33 +00:00
if ( IS_24XX ( isp ) ) {
ct7_entry_t * cto = ( ct7_entry_t * ) local ;
cto - > ct_header . rqs_entry_type = RQSTYPE_CTIO7 ;
cto - > ct_header . rqs_entry_count = 1 ;
cto - > ct_header . rqs_seqno | = ATPD_SEQ_NOTIFY_CAM ;
ATPD_SET_SEQNO ( cto , atp ) ;
cto - > ct_nphdl = atp - > nphdl ;
cto - > ct_rxid = atp - > tag ;
2017-02-27 08:20:28 +00:00
cto - > ct_iid_lo = atp - > sid ;
cto - > ct_iid_hi = atp - > sid > > 16 ;
2012-08-08 18:24:33 +00:00
cto - > ct_oxid = atp - > oxid ;
cto - > ct_vpidx = ISP_GET_VPIDX ( isp , XS_CHANNEL ( ccb ) ) ;
2017-03-21 13:10:37 +00:00
cto - > ct_timeout = XS_TIME ( ccb ) ;
2012-08-08 18:24:33 +00:00
cto - > ct_flags = atp - > tattr < < CT7_TASK_ATTR_SHIFT ;
/*
* Mode 1 , status , no data . Only possible when we are sending status , have
2012-09-17 02:50:16 +00:00
* no data to transfer , and any sense data can fit into a ct7_entry_t .
2012-08-08 18:24:33 +00:00
*
2012-09-17 02:49:02 +00:00
* Mode 2 , status , no data . We have to use this in the case that
* the sense data won ' t fit into a ct7_entry_t .
2012-08-08 18:24:33 +00:00
*
*/
if ( sendstatus & & xfrlen = = 0 ) {
cto - > ct_flags | = CT7_SENDSTATUS | CT7_NO_DATA ;
resid = atp - > orig_datalen - atp - > bytes_xfered - atp - > bytes_in_transit ;
if ( sense_length < = MAXRESPLEN_24XX ) {
cto - > ct_flags | = CT7_FLAG_MODE1 ;
cto - > ct_scsi_status = cso - > scsi_status ;
if ( resid < 0 ) {
2017-02-26 12:52:44 +00:00
cto - > ct_resid = - resid ;
2012-08-08 18:24:33 +00:00
cto - > ct_scsi_status | = ( FCP_RESID_OVERFLOW < < 8 ) ;
} else if ( resid > 0 ) {
2017-02-26 12:52:44 +00:00
cto - > ct_resid = resid ;
2012-08-08 18:24:33 +00:00
cto - > ct_scsi_status | = ( FCP_RESID_UNDERFLOW < < 8 ) ;
}
if ( fctape ) {
cto - > ct_flags | = CT7_CONFIRM | CT7_EXPLCT_CONF ;
}
if ( sense_length ) {
cto - > ct_scsi_status | = ( FCP_SNSLEN_VALID < < 8 ) ;
cto - > rsp . m1 . ct_resplen = cto - > ct_senselen = sense_length ;
memcpy ( cto - > rsp . m1 . ct_resp , & cso - > sense_data , sense_length ) ;
}
} else {
bus_addr_t addr ;
char buf [ XCMD_SIZE ] ;
fcp_rsp_iu_t * rp ;
-----------
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 ( atp - > ests = = NULL ) {
2012-08-08 18:24:33 +00:00
atp - > ests = isp_get_ecmd ( isp ) ;
if ( atp - > ests = = NULL ) {
2017-03-22 11:06:33 +00:00
TAILQ_INSERT_HEAD ( waitq , & ccb - > ccb_h , sim_links . tqe ) ;
2012-08-08 18:24:33 +00:00
break ;
}
-----------
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
}
2012-08-08 18:24:33 +00:00
memset ( buf , 0 , sizeof ( buf ) ) ;
rp = ( fcp_rsp_iu_t * ) buf ;
if ( fctape ) {
cto - > ct_flags | = CT7_CONFIRM | CT7_EXPLCT_CONF ;
rp - > fcp_rsp_bits | = FCP_CONF_REQ ;
}
cto - > ct_flags | = CT7_FLAG_MODE2 ;
rp - > fcp_rsp_scsi_status = cso - > scsi_status ;
if ( resid < 0 ) {
rp - > fcp_rsp_resid = - resid ;
rp - > fcp_rsp_bits | = FCP_RESID_OVERFLOW ;
} else if ( resid > 0 ) {
rp - > fcp_rsp_resid = resid ;
rp - > fcp_rsp_bits | = FCP_RESID_UNDERFLOW ;
}
if ( sense_length ) {
rp - > fcp_rsp_snslen = sense_length ;
cto - > ct_senselen = sense_length ;
rp - > fcp_rsp_bits | = FCP_SNSLEN_VALID ;
isp_put_fcp_rsp_iu ( isp , rp , atp - > ests ) ;
memcpy ( ( ( fcp_rsp_iu_t * ) atp - > ests ) - > fcp_rsp_extra , & cso - > sense_data , sense_length ) ;
} else {
isp_put_fcp_rsp_iu ( isp , rp , atp - > ests ) ;
}
if ( isp - > isp_dblev & ISP_LOGTDEBUG1 ) {
isp_print_bytes ( isp , " FCP Response Frame After Swizzling " , MIN_FCP_RESPONSE_SIZE + sense_length , atp - > ests ) ;
}
addr = isp - > isp_osinfo . ecmd_dma ;
addr + = ( ( ( ( isp_ecmd_t * ) atp - > ests ) - isp - > isp_osinfo . ecmd_base ) * XCMD_SIZE ) ;
isp_prt ( isp , ISP_LOGTDEBUG0 , " %s: ests base %p vaddr %p ecmd_dma %jx addr %jx len %u " , __func__ , isp - > isp_osinfo . ecmd_base , atp - > ests ,
( uintmax_t ) isp - > isp_osinfo . ecmd_dma , ( uintmax_t ) addr , MIN_FCP_RESPONSE_SIZE + sense_length ) ;
cto - > rsp . m2 . ct_datalen = MIN_FCP_RESPONSE_SIZE + sense_length ;
cto - > rsp . m2 . ct_fcp_rsp_iudata . ds_base = DMA_LO32 ( addr ) ;
cto - > rsp . m2 . ct_fcp_rsp_iudata . ds_basehi = DMA_HI32 ( addr ) ;
cto - > rsp . m2 . ct_fcp_rsp_iudata . ds_count = MIN_FCP_RESPONSE_SIZE + sense_length ;
-----------
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 ( sense_length ) {
2012-08-08 18:24:33 +00:00
isp_prt ( isp , ISP_LOGTDEBUG0 , " %s: CTIO7[0x%x] seq %u nc %d CDB0=%x sstatus=0x%x flags=0x%x resid=%d slen %u sense: %x %x/%x/%x " , __func__ ,
cto - > ct_rxid , ATPD_GET_SEQNO ( cto ) , ATPD_GET_NCAM ( cto ) , atp - > cdb0 , cto - > ct_scsi_status , cto - > ct_flags , cto - > ct_resid , sense_length ,
cso - > sense_data . error_code , cso - > sense_data . sense_buf [ 1 ] , cso - > sense_data . sense_buf [ 11 ] , cso - > sense_data . sense_buf [ 12 ] ) ;
-----------
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
} else {
2012-08-08 18:24:33 +00:00
isp_prt ( isp , ISP_LOGDEBUG0 , " %s: CTIO7[0x%x] seq %u nc %d CDB0=%x sstatus=0x%x flags=0x%x resid=%d " , __func__ ,
cto - > ct_rxid , ATPD_GET_SEQNO ( cto ) , ATPD_GET_NCAM ( cto ) , atp - > cdb0 , cto - > ct_scsi_status , cto - > ct_flags , cto - > ct_resid ) ;
-----------
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
}
2012-08-08 18:24:33 +00:00
atp - > state = ATPD_STATE_LAST_CTIO ;
2009-08-01 01:04:26 +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
2009-08-01 01:04:26 +00:00
/*
2012-08-08 18:24:33 +00:00
* Mode 0 data transfers , * possibly * with status .
2009-08-01 01:04:26 +00:00
*/
2012-08-08 18:24:33 +00:00
if ( xfrlen ! = 0 ) {
cto - > ct_flags | = CT7_FLAG_MODE0 ;
if ( ( cso - > ccb_h . flags & CAM_DIR_MASK ) = = CAM_DIR_IN ) {
cto - > ct_flags | = CT7_DATA_IN ;
} else {
cto - > ct_flags | = CT7_DATA_OUT ;
}
cto - > rsp . m0 . reloff = atp - > bytes_xfered + atp - > bytes_in_transit ;
cto - > rsp . m0 . ct_xfrlen = xfrlen ;
-----------
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
# ifdef DEBUG
2012-08-08 18:24:33 +00:00
if ( ISP_FC_PC ( isp , XS_CHANNEL ( ccb ) ) - > inject_lost_data_frame & & xfrlen > ISP_FC_PC ( isp , XS_CHANNEL ( ccb ) ) - > inject_lost_data_frame ) {
isp_prt ( isp , ISP_LOGWARN , " %s: truncating data frame with xfrlen %d to %d " , __func__ , xfrlen , xfrlen - ( xfrlen > > 2 ) ) ;
ISP_FC_PC ( isp , XS_CHANNEL ( ccb ) ) - > inject_lost_data_frame = 0 ;
cto - > rsp . m0 . ct_xfrlen - = xfrlen > > 2 ;
}
-----------
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
# endif
2012-08-08 18:24:33 +00:00
if ( sendstatus ) {
resid = atp - > orig_datalen - atp - > bytes_xfered - xfrlen ;
if ( cso - > scsi_status = = SCSI_STATUS_OK & & resid = = 0 /* && fctape == 0 */ ) {
cto - > ct_flags | = CT7_SENDSTATUS ;
atp - > state = ATPD_STATE_LAST_CTIO ;
if ( fctape ) {
cto - > ct_flags | = CT7_CONFIRM | CT7_EXPLCT_CONF ;
}
} else {
atp - > sendst = 1 ; /* send status later */
cto - > ct_header . rqs_seqno & = ~ ATPD_SEQ_NOTIFY_CAM ;
atp - > state = ATPD_STATE_CTIO ;
}
-----------
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
} else {
atp - > state = ATPD_STATE_CTIO ;
}
2012-08-08 18:24:33 +00:00
isp_prt ( isp , ISP_LOGTDEBUG0 , " %s: CTIO7[0x%x] seq %u nc %d CDB0=%x sstatus=0x%x flags=0x%x xfrlen=%u off=%u " , __func__ ,
cto - > ct_rxid , ATPD_GET_SEQNO ( cto ) , ATPD_GET_NCAM ( cto ) , atp - > cdb0 , cto - > ct_scsi_status , cto - > ct_flags , xfrlen , atp - > bytes_xfered ) ;
-----------
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
}
2015-11-23 10:06:19 +00:00
} else {
2012-08-08 18:24:33 +00:00
ct2_entry_t * cto = ( ct2_entry_t * ) local ;
2000-01-15 01:50:48 +00:00
2017-03-24 14:44:03 +00:00
cto - > ct_header . rqs_entry_type = RQSTYPE_CTIO2 ;
2012-08-08 18:24:33 +00:00
cto - > ct_header . rqs_entry_count = 1 ;
cto - > ct_header . rqs_seqno | = ATPD_SEQ_NOTIFY_CAM ;
ATPD_SET_SEQNO ( cto , atp ) ;
2015-07-13 21:01:24 +00:00
if ( ISP_CAP_2KLOGIN ( isp ) ) {
( ( ct2e_entry_t * ) cto ) - > ct_iid = atp - > nphdl ;
2012-08-08 18:24:33 +00:00
} else {
2015-07-13 21:01:24 +00:00
cto - > ct_iid = atp - > nphdl ;
2012-08-08 18:24:33 +00:00
if ( ISP_CAP_SCCFW ( isp ) = = 0 ) {
cto - > ct_lun = ccb - > ccb_h . target_lun ;
}
2006-05-22 06:49:49 +00:00
}
2017-03-21 13:10:37 +00:00
cto - > ct_timeout = XS_TIME ( ccb ) ;
2012-08-08 18:24:33 +00:00
cto - > ct_rxid = cso - > tag_id ;
-----------
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
2012-08-08 18:24:33 +00:00
/*
* Mode 1 , status , no data . Only possible when we are sending status , have
* no data to transfer , and the sense length can fit in the ct7_entry .
*
2012-09-14 21:28:56 +00:00
* Mode 2 , status , no data . We have to use this in the case the response
2012-08-08 18:24:33 +00:00
* length won ' t fit into a ct2_entry_t .
*
* We ' ll fill out this structure with information as if this were a
* Mode 1. The hardware layer will create the Mode 2 FCP RSP IU as
* needed based upon this .
*/
if ( sendstatus & & xfrlen = = 0 ) {
cto - > ct_flags | = CT2_SENDSTATUS | CT2_NO_DATA ;
resid = atp - > orig_datalen - atp - > bytes_xfered - atp - > bytes_in_transit ;
if ( sense_length < = MAXRESPLEN ) {
if ( resid < 0 ) {
cto - > ct_resid = - resid ;
} else if ( resid > 0 ) {
cto - > ct_resid = resid ;
}
cto - > ct_flags | = CT2_FLAG_MODE1 ;
cto - > rsp . m1 . ct_scsi_status = cso - > scsi_status ;
if ( resid < 0 ) {
cto - > rsp . m1 . ct_scsi_status | = CT2_DATA_OVER ;
} else if ( resid > 0 ) {
cto - > rsp . m1 . ct_scsi_status | = CT2_DATA_UNDER ;
}
if ( fctape ) {
cto - > ct_flags | = CT2_CONFIRM ;
}
if ( sense_length ) {
cto - > rsp . m1 . ct_scsi_status | = CT2_SNSLEN_VALID ;
cto - > rsp . m1 . ct_resplen = cto - > rsp . m1 . ct_senselen = sense_length ;
memcpy ( cto - > rsp . m1 . ct_resp , & cso - > sense_data , sense_length ) ;
}
} else {
bus_addr_t addr ;
char buf [ XCMD_SIZE ] ;
fcp_rsp_iu_t * rp ;
-----------
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 ( atp - > ests = = NULL ) {
2012-08-08 18:24:33 +00:00
atp - > ests = isp_get_ecmd ( isp ) ;
if ( atp - > ests = = NULL ) {
2017-03-22 11:06:33 +00:00
TAILQ_INSERT_HEAD ( waitq , & ccb - > ccb_h , sim_links . tqe ) ;
2012-08-08 18:24:33 +00:00
break ;
}
}
memset ( buf , 0 , sizeof ( buf ) ) ;
rp = ( fcp_rsp_iu_t * ) buf ;
if ( fctape ) {
cto - > ct_flags | = CT2_CONFIRM ;
rp - > fcp_rsp_bits | = FCP_CONF_REQ ;
}
cto - > ct_flags | = CT2_FLAG_MODE2 ;
rp - > fcp_rsp_scsi_status = cso - > scsi_status ;
if ( resid < 0 ) {
rp - > fcp_rsp_resid = - resid ;
rp - > fcp_rsp_bits | = FCP_RESID_OVERFLOW ;
} else if ( resid > 0 ) {
rp - > fcp_rsp_resid = resid ;
rp - > fcp_rsp_bits | = FCP_RESID_UNDERFLOW ;
}
if ( sense_length ) {
rp - > fcp_rsp_snslen = sense_length ;
rp - > fcp_rsp_bits | = FCP_SNSLEN_VALID ;
isp_put_fcp_rsp_iu ( isp , rp , atp - > ests ) ;
memcpy ( ( ( fcp_rsp_iu_t * ) atp - > ests ) - > fcp_rsp_extra , & cso - > sense_data , sense_length ) ;
} else {
isp_put_fcp_rsp_iu ( isp , rp , atp - > ests ) ;
}
if ( isp - > isp_dblev & ISP_LOGTDEBUG1 ) {
isp_print_bytes ( isp , " FCP Response Frame After Swizzling " , MIN_FCP_RESPONSE_SIZE + sense_length , atp - > ests ) ;
}
addr = isp - > isp_osinfo . ecmd_dma ;
addr + = ( ( ( ( isp_ecmd_t * ) atp - > ests ) - isp - > isp_osinfo . ecmd_base ) * XCMD_SIZE ) ;
isp_prt ( isp , ISP_LOGTDEBUG0 , " %s: ests base %p vaddr %p ecmd_dma %jx addr %jx len %u " , __func__ , isp - > isp_osinfo . ecmd_base , atp - > ests ,
( uintmax_t ) isp - > isp_osinfo . ecmd_dma , ( uintmax_t ) addr , MIN_FCP_RESPONSE_SIZE + sense_length ) ;
cto - > rsp . m2 . ct_datalen = MIN_FCP_RESPONSE_SIZE + sense_length ;
2017-03-24 14:44:03 +00:00
cto - > rsp . m2 . u . ct_fcp_rsp_iudata_32 . ds_base = DMA_LO32 ( addr ) ;
cto - > rsp . m2 . u . ct_fcp_rsp_iudata_32 . ds_count = MIN_FCP_RESPONSE_SIZE + sense_length ;
-----------
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 ( sense_length ) {
2012-08-08 18:24:33 +00:00
isp_prt ( isp , ISP_LOGTDEBUG0 , " %s: CTIO2[0x%x] seq %u nc %d CDB0=%x sstatus=0x%x flags=0x%x resid=%d sense: %x %x/%x/%x " , __func__ ,
cto - > ct_rxid , ATPD_GET_SEQNO ( cto ) , ATPD_GET_NCAM ( cto ) , atp - > cdb0 , cso - > scsi_status , cto - > ct_flags , cto - > ct_resid ,
cso - > sense_data . error_code , cso - > sense_data . sense_buf [ 1 ] , cso - > sense_data . sense_buf [ 11 ] , cso - > sense_data . sense_buf [ 12 ] ) ;
-----------
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
} else {
2012-08-08 18:24:33 +00:00
isp_prt ( isp , ISP_LOGTDEBUG0 , " %s: CTIO2[0x%x] seq %u nc %d CDB0=%x sstatus=0x%x flags=0x%x resid=%d " , __func__ , cto - > ct_rxid ,
ATPD_GET_SEQNO ( cto ) , ATPD_GET_NCAM ( cto ) , atp - > cdb0 , cso - > scsi_status , cto - > ct_flags , cto - > ct_resid ) ;
-----------
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
}
2012-08-08 18:24:33 +00:00
atp - > state = ATPD_STATE_LAST_CTIO ;
2000-07-18 06:58:28 +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
2012-08-08 18:24:33 +00:00
if ( xfrlen ! = 0 ) {
cto - > ct_flags | = CT2_FLAG_MODE0 ;
if ( ( cso - > ccb_h . flags & CAM_DIR_MASK ) = = CAM_DIR_IN ) {
cto - > ct_flags | = CT2_DATA_IN ;
} else {
cto - > ct_flags | = CT2_DATA_OUT ;
}
-----------
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
2012-08-08 18:24:33 +00:00
cto - > ct_reloff = atp - > bytes_xfered + atp - > bytes_in_transit ;
cto - > rsp . m0 . ct_xfrlen = xfrlen ;
-----------
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
2012-08-08 18:24:33 +00:00
if ( sendstatus ) {
resid = atp - > orig_datalen - atp - > bytes_xfered - xfrlen ;
if ( cso - > scsi_status = = SCSI_STATUS_OK & & resid = = 0 /*&& fctape == 0*/ ) {
cto - > ct_flags | = CT2_SENDSTATUS ;
atp - > state = ATPD_STATE_LAST_CTIO ;
if ( fctape ) {
cto - > ct_flags | = CT2_CONFIRM ;
}
} else {
atp - > sendst = 1 ; /* send status later */
cto - > ct_header . rqs_seqno & = ~ ATPD_SEQ_NOTIFY_CAM ;
atp - > state = ATPD_STATE_CTIO ;
}
-----------
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
} else {
atp - > state = ATPD_STATE_CTIO ;
2002-06-16 05:08:02 +00:00
}
2012-08-08 18:24:33 +00:00
}
isp_prt ( isp , ISP_LOGTDEBUG0 , " %s: CTIO2[%x] seq %u nc %d CDB0=%x scsi status %x flags %x resid %d xfrlen %u offset %u " , __func__ , cto - > ct_rxid ,
ATPD_GET_SEQNO ( cto ) , ATPD_GET_NCAM ( cto ) , atp - > cdb0 , cso - > scsi_status , cto - > ct_flags , cto - > ct_resid , cso - > dxfer_len , atp - > bytes_xfered ) ;
2006-04-21 18:30:01 +00:00
}
2000-01-15 01:50:48 +00:00
2012-08-08 18:24:33 +00:00
if ( isp_get_pcmd ( isp , ccb ) ) {
ISP_PATH_PRT ( isp , ISP_LOGWARN , ccb - > ccb_h . path , " out of PCMDs \n " ) ;
2017-03-22 11:06:33 +00:00
TAILQ_INSERT_HEAD ( waitq , & ccb - > ccb_h , sim_links . tqe ) ;
2012-08-08 18:24:33 +00:00
break ;
2000-01-03 23:55:30 +00:00
}
2015-12-25 13:03:18 +00:00
handle = isp_allocate_handle ( isp , ccb , ISP_HANDLE_TARGET ) ;
if ( handle = = 0 ) {
2012-08-08 18:24:33 +00:00
ISP_PATH_PRT ( isp , ISP_LOGWARN , ccb - > ccb_h . path , " No XFLIST pointers for %s \n " , __func__ ) ;
2017-03-22 11:06:33 +00:00
TAILQ_INSERT_HEAD ( waitq , & ccb - > ccb_h , sim_links . tqe ) ;
2012-08-08 18:24:33 +00:00
isp_free_pcmd ( isp , ccb ) ;
break ;
2000-01-04 03:45:49 +00:00
}
2012-08-08 18:24:33 +00:00
atp - > bytes_in_transit + = xfrlen ;
PISP_PCMD ( ccb ) - > datalen = xfrlen ;
2000-01-03 23:55:30 +00:00
2012-08-08 18:24:33 +00:00
/*
* Call the dma setup routines for this entry ( and any subsequent
* CTIOs ) if there ' s data to move , and then tell the f / w it ' s got
* new things to play with . As with isp_start ' s usage of DMA setup ,
* any swizzling is done in the machine dependent layer . Because
* of this , we put the request onto the queue area first in native
* format .
*/
2000-01-03 23:55:30 +00:00
2012-08-08 18:24:33 +00:00
if ( IS_24XX ( isp ) ) {
ct7_entry_t * cto = ( ct7_entry_t * ) local ;
cto - > ct_syshandle = handle ;
} else {
2015-11-23 10:06:19 +00:00
ct2_entry_t * cto = ( ct2_entry_t * ) local ;
2012-08-08 18:24:33 +00:00
cto - > ct_syshandle = handle ;
}
2001-04-04 21:58:29 +00:00
2012-08-08 18:24:33 +00:00
dmaresult = ISP_DMASETUP ( isp , cso , ( ispreq_t * ) local ) ;
if ( dmaresult ! = CMD_QUEUED ) {
2015-12-25 13:03:18 +00:00
isp_destroy_handle ( isp , handle ) ;
2012-08-08 18:24:33 +00:00
isp_free_pcmd ( isp , ccb ) ;
if ( dmaresult = = CMD_EAGAIN ) {
2017-03-22 11:06:33 +00:00
TAILQ_INSERT_HEAD ( waitq , & ccb - > ccb_h , sim_links . tqe ) ;
2012-08-08 18:24:33 +00:00
break ;
}
ccb - > ccb_h . status = CAM_REQ_CMP_ERR ;
xpt_done ( ccb ) ;
continue ;
}
ccb - > ccb_h . status = CAM_REQ_INPROG | CAM_SIM_QUEUED ;
-----------
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 ( xfrlen ) {
ccb - > ccb_h . spriv_field0 = atp - > bytes_xfered ;
} else {
ccb - > ccb_h . spriv_field0 = ~ 0 ;
}
atp - > ctcnt + + ;
2012-08-08 18:24:33 +00:00
atp - > seqno + + ;
2000-01-03 23:55:30 +00:00
}
}
2001-04-04 21:58:29 +00:00
static void
isp_refire_putback_atio ( void * arg )
2000-07-18 06:58:28 +00:00
{
2009-08-01 01:04:26 +00:00
union ccb * ccb = arg ;
2014-11-18 21:03:46 +00:00
2014-11-19 13:04:25 +00:00
ISP_ASSERT_LOCKED ( ( ispsoftc_t * ) XS_ISP ( ccb ) ) ;
2009-08-01 01:04:26 +00:00
isp_target_putback_atio ( ccb ) ;
2001-04-04 21:58:29 +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
static void
isp_refire_notify_ack ( void * arg )
{
isp_tna_t * tp = arg ;
ispsoftc_t * isp = tp - > isp ;
2014-11-18 21:03:46 +00:00
ISP_ASSERT_LOCKED ( isp ) ;
-----------
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 ( isp_notify_ack ( isp , tp - > not ) ) {
2014-11-18 21:03:46 +00:00
callout_schedule ( & tp - > timer , 5 ) ;
-----------
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
} else {
free ( tp , M_DEVBUF ) ;
}
}
2001-04-04 21:58:29 +00:00
static void
isp_target_putback_atio ( union ccb * ccb )
{
2017-03-18 13:42:08 +00:00
ispsoftc_t * isp = XS_ISP ( ccb ) ;
struct ccb_scsiio * cso = & ccb - > csio ;
2015-11-23 10:06:19 +00:00
at2_entry_t local , * at = & local ;
2001-04-04 21:58:29 +00:00
2015-11-23 10:06:19 +00:00
ISP_MEMZERO ( at , sizeof ( at2_entry_t ) ) ;
at - > at_header . rqs_entry_type = RQSTYPE_ATIO2 ;
at - > at_header . rqs_entry_count = 1 ;
if ( ISP_CAP_SCCFW ( isp ) ) {
at - > at_scclun = ( uint16_t ) ccb - > ccb_h . target_lun ;
2000-07-18 06:58:28 +00:00
} else {
2015-11-23 10:06:19 +00:00
at - > at_lun = ( uint8_t ) ccb - > ccb_h . target_lun ;
2000-07-18 06:58:28 +00:00
}
2015-11-23 10:06:19 +00:00
at - > at_status = CT_OK ;
at - > at_rxid = cso - > tag_id ;
2017-06-30 06:10:18 +00:00
at - > at_iid = cso - > init_id ;
2017-03-18 13:42:08 +00:00
if ( isp_target_put_entry ( isp , at ) ) {
callout_reset ( & PISP_PCMD ( ccb ) - > wdog , 10 ,
isp_refire_putback_atio , ccb ) ;
} else
isp_complete_ctio ( ccb ) ;
2000-07-18 06:58:28 +00:00
}
static void
2001-04-04 21:58:29 +00:00
isp_complete_ctio ( union ccb * ccb )
2000-07-18 06:58:28 +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
if ( ( ccb - > ccb_h . status & CAM_STATUS_MASK ) ! = CAM_REQ_INPROG ) {
ccb - > ccb_h . status & = ~ CAM_SIM_QUEUED ;
xpt_done ( ccb ) ;
2000-07-18 06:58:28 +00:00
}
}
2009-08-01 01:04:26 +00:00
static void
2006-04-21 18:30:01 +00:00
isp_handle_platform_atio2 ( ispsoftc_t * isp , at2_entry_t * aep )
2000-01-03 23:55:30 +00:00
{
2015-11-22 16:55:43 +00:00
fcparam * fcp ;
2000-01-04 03:45:49 +00:00
lun_id_t lun ;
2009-08-01 01:04:26 +00:00
fcportdb_t * lp ;
2000-01-03 23:55:30 +00:00
tstate_t * tptr ;
struct ccb_accept_tio * atiop ;
2009-08-01 01:04:26 +00:00
uint16_t nphdl ;
2010-06-02 23:31:27 +00:00
atio_private_data_t * atp ;
2009-08-01 01:04:26 +00:00
inot_private_data_t * ntp ;
2000-01-03 23:55:30 +00:00
/*
* The firmware status ( except for the QLTM_SVALID bit )
* indicates why this ATIO was sent to us .
*
2010-11-09 10:59:09 +00:00
* If QLTM_SVALID is set , the firmware has recommended Sense Data .
2000-01-03 23:55:30 +00:00
*/
if ( ( aep - > at_status & ~ QLTM_SVALID ) ! = AT_CDB ) {
2009-08-01 01:04:26 +00:00
isp_prt ( isp , ISP_LOGWARN , " bogus atio (0x%x) leaked to platform " , aep - > at_status ) ;
2017-02-22 06:43:49 +00:00
isp_endcmd ( isp , aep , NIL_HANDLE , 0 , SCSI_STATUS_BUSY , 0 ) ;
2009-08-01 01:04:26 +00:00
return ;
2000-01-03 23:55:30 +00:00
}
2015-11-22 16:55:43 +00:00
fcp = FCPARAM ( isp , 0 ) ;
2009-08-01 01:04:26 +00:00
if ( ISP_CAP_SCCFW ( isp ) ) {
2000-06-18 04:50:26 +00:00
lun = aep - > at_scclun ;
} else {
lun = aep - > at_lun ;
}
2009-08-01 01:04:26 +00:00
if ( ISP_CAP_2KLOGIN ( isp ) ) {
nphdl = ( ( at2e_entry_t * ) aep ) - > at_iid ;
} else {
nphdl = aep - > at_iid ;
}
2001-04-04 21:58:29 +00:00
tptr = get_lun_statep ( isp , 0 , lun ) ;
2000-01-03 23:55:30 +00:00
if ( tptr = = NULL ) {
2001-04-04 21:58:29 +00:00
tptr = get_lun_statep ( isp , 0 , CAM_LUN_WILDCARD ) ;
2004-02-07 03:47:33 +00:00
if ( tptr = = NULL ) {
2013-10-30 14:04:47 +00:00
isp_prt ( isp , ISP_LOGWARN , " %s: [0x%x] no state pointer for lun %jx or wildcard " , __func__ , aep - > at_rxid , ( uintmax_t ) lun ) ;
-----------
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 ( lun = = 0 ) {
2017-02-22 06:43:49 +00:00
isp_endcmd ( isp , aep , nphdl , 0 , SCSI_STATUS_BUSY , 0 ) ;
-----------
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
} else {
2017-02-22 06:43:49 +00:00
isp_endcmd ( isp , aep , nphdl , 0 , SCSI_STATUS_CHECK_COND | ECMD_SVALID | ( 0x5 < < 12 ) | ( 0x25 < < 16 ) , 0 ) ;
-----------
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
}
2009-08-01 01:04:26 +00:00
return ;
}
}
/*
* Start any commands pending resources first .
*/
2017-02-22 06:43:49 +00:00
if ( isp_atio_restart ( isp , 0 , tptr ) )
goto noresrc ;
2000-01-03 23:55:30 +00:00
atiop = ( struct ccb_accept_tio * ) SLIST_FIRST ( & tptr - > atios ) ;
2009-08-01 01:04:26 +00:00
if ( atiop = = NULL ) {
goto noresrc ;
}
2004-02-07 03:47:33 +00:00
2017-02-22 06:43:49 +00:00
atp = isp_get_atpd ( isp , 0 , aep - > at_rxid ) ;
2009-08-01 01:04:26 +00:00
if ( atp = = NULL ) {
goto noresrc ;
2000-01-03 23:55:30 +00:00
}
2009-08-01 01:04:26 +00:00
2002-06-16 05:08:02 +00:00
atp - > state = ATPD_STATE_ATIO ;
2000-01-03 23:55:30 +00:00
SLIST_REMOVE_HEAD ( & tptr - > atios , sim_links . sle ) ;
2017-03-15 19:49:45 +00:00
ISP_PATH_PRT ( isp , ISP_LOGTDEBUG2 , atiop - > ccb_h . path , " Take FREE ATIO \n " ) ;
2017-06-30 06:10:18 +00:00
atiop - > ccb_h . target_id = ISP_MAX_TARGETS ( isp ) ;
2009-08-01 01:04:26 +00:00
atiop - > ccb_h . target_lun = lun ;
2000-07-18 06:58:28 +00:00
2001-02-27 00:14:39 +00:00
/*
* We don ' t get ' suggested ' sense data as we do with SCSI cards .
*/
atiop - > sense_len = 0 ;
2000-07-18 06:58:28 +00:00
2009-08-01 01:04:26 +00:00
/*
* If we ' re not in the port database , add ourselves .
*/
2015-07-13 21:01:24 +00:00
if ( IS_2100 ( isp ) )
atiop - > init_id = nphdl ;
else {
2017-03-19 10:28:04 +00:00
if ( isp_find_pdb_by_handle ( isp , 0 , nphdl , & lp ) ) {
atiop - > init_id = FC_PORTDB_TGT ( isp , 0 , lp ) ;
} else {
isp_prt ( isp , ISP_LOGTINFO , " %s: port %x isn't in PDB " ,
__func__ , nphdl ) ;
isp_dump_portdb ( isp , 0 ) ;
isp_endcmd ( isp , aep , NIL_HANDLE , 0 , ECMD_TERMINATE , 0 ) ;
return ;
2015-07-13 21:01:24 +00:00
}
2009-08-01 01:04:26 +00:00
}
2000-01-03 23:55:30 +00:00
atiop - > cdb_len = ATIO2_CDBLEN ;
2009-08-01 01:04:26 +00:00
ISP_MEMCPY ( atiop - > cdb_io . cdb_bytes , aep - > at_cdb , ATIO2_CDBLEN ) ;
2000-01-03 23:55:30 +00:00
atiop - > ccb_h . status = CAM_CDB_RECVD ;
2009-08-01 01:04:26 +00:00
atiop - > tag_id = atp - > tag ;
2000-01-03 23:55:30 +00:00
switch ( aep - > at_taskflags & ATIO2_TC_ATTR_MASK ) {
case ATIO2_TC_ATTR_SIMPLEQ :
2013-10-21 06:04:39 +00:00
atiop - > ccb_h . flags | = CAM_TAG_ACTION_VALID ;
2000-01-03 23:55:30 +00:00
atiop - > tag_action = MSG_SIMPLE_Q_TAG ;
break ;
2009-08-01 01:04:26 +00:00
case ATIO2_TC_ATTR_HEADOFQ :
2013-10-21 06:04:39 +00:00
atiop - > ccb_h . flags | = CAM_TAG_ACTION_VALID ;
2000-01-03 23:55:30 +00:00
atiop - > tag_action = MSG_HEAD_OF_Q_TAG ;
break ;
2009-08-01 01:04:26 +00:00
case ATIO2_TC_ATTR_ORDERED :
2013-10-21 06:04:39 +00:00
atiop - > ccb_h . flags | = CAM_TAG_ACTION_VALID ;
2000-01-03 23:55:30 +00:00
atiop - > tag_action = MSG_ORDERED_Q_TAG ;
break ;
2009-08-01 01:04:26 +00:00
case ATIO2_TC_ATTR_ACAQ : /* ?? */
2000-01-03 23:55:30 +00:00
case ATIO2_TC_ATTR_UNTAGGED :
default :
atiop - > tag_action = 0 ;
break ;
}
2000-07-18 06:58:28 +00:00
2001-10-01 03:48:42 +00:00
atp - > orig_datalen = aep - > at_datalen ;
atp - > bytes_xfered = 0 ;
2009-08-01 01:04:26 +00:00
atp - > lun = lun ;
2015-07-13 21:01:24 +00:00
atp - > nphdl = nphdl ;
2009-08-01 01:04:26 +00:00
atp - > sid = PORT_ANY ;
atp - > oxid = aep - > at_oxid ;
atp - > cdb0 = aep - > at_cdb [ 0 ] ;
atp - > tattr = aep - > at_taskflags & ATIO2_TC_ATTR_MASK ;
2002-06-16 05:08:02 +00:00
atp - > state = ATPD_STATE_CAM ;
2009-08-01 01:04:26 +00:00
xpt_done ( ( union ccb * ) atiop ) ;
2013-10-30 14:04:47 +00:00
isp_prt ( isp , ISP_LOGTDEBUG0 , " ATIO2[0x%x] CDB=0x%x lun %jx datalen %u " , aep - > at_rxid , atp - > cdb0 , ( uintmax_t ) lun , atp - > orig_datalen ) ;
2009-08-01 01:04:26 +00:00
return ;
noresrc :
2017-02-22 06:43:49 +00:00
ntp = isp_get_ntpd ( isp , 0 ) ;
2009-08-01 01:04:26 +00:00
if ( ntp = = NULL ) {
2017-02-22 06:43:49 +00:00
isp_endcmd ( isp , aep , nphdl , 0 , SCSI_STATUS_BUSY , 0 ) ;
2009-08-01 01:04:26 +00:00
return ;
}
2017-02-22 06:43:49 +00:00
memcpy ( ntp - > data , aep , QENTRY_LEN ) ;
STAILQ_INSERT_TAIL ( & tptr - > restart_queue , ntp , next ) ;
2000-01-03 23:55:30 +00:00
}
2009-08-01 01:04:26 +00:00
static void
isp_handle_platform_atio7 ( ispsoftc_t * isp , at7_entry_t * aep )
2000-01-03 23:55:30 +00:00
{
2009-08-01 01:04:26 +00:00
int cdbxlen ;
2015-10-24 17:34:40 +00:00
lun_id_t lun ;
uint16_t chan , nphdl = NIL_HANDLE ;
2009-08-01 01:04:26 +00:00
uint32_t did , sid ;
fcportdb_t * lp ;
tstate_t * tptr ;
struct ccb_accept_tio * atiop ;
atio_private_data_t * atp = NULL ;
2012-06-24 17:30:54 +00:00
atio_private_data_t * oatp ;
2009-08-01 01:04:26 +00:00
inot_private_data_t * ntp ;
did = ( aep - > at_hdr . d_id [ 0 ] < < 16 ) | ( aep - > at_hdr . d_id [ 1 ] < < 8 ) | aep - > at_hdr . d_id [ 2 ] ;
sid = ( aep - > at_hdr . s_id [ 0 ] < < 16 ) | ( aep - > at_hdr . s_id [ 1 ] < < 8 ) | aep - > at_hdr . s_id [ 2 ] ;
2015-10-24 17:34:40 +00:00
lun = CAM_EXTLUN_BYTE_SWIZZLE ( be64dec ( aep - > at_cmnd . fcp_cmnd_lun ) ) ;
2000-01-03 23:55:30 +00:00
2015-07-15 12:04:12 +00:00
if ( ISP_CAP_MULTI_ID ( isp ) & & isp - > isp_nchan > 1 ) {
2017-03-19 13:46:11 +00:00
/* Channel has to be derived from D_ID */
2009-08-01 01:04:26 +00:00
isp_find_chan_by_did ( isp , did , & chan ) ;
if ( chan = = ISP_NOCHAN ) {
2017-03-19 13:46:11 +00:00
isp_prt ( isp , ISP_LOGWARN ,
" %s: [RX_ID 0x%x] D_ID %x not found on any channel " ,
__func__ , aep - > at_rxid , did ) ;
isp_endcmd ( isp , aep , NIL_HANDLE , ISP_NOCHAN ,
ECMD_TERMINATE , 0 ) ;
return ;
2002-06-16 05:08:02 +00:00
}
2000-01-03 23:55:30 +00:00
} else {
2009-08-01 01:04:26 +00:00
chan = 0 ;
}
/*
* Find the PDB entry for this initiator
*/
2015-11-19 17:43:47 +00:00
if ( isp_find_pdb_by_portid ( isp , chan , sid , & lp ) = = 0 ) {
2009-08-01 01:04:26 +00:00
/*
* If we ' re not in the port database terminate the exchange .
*/
isp_prt ( isp , ISP_LOGTINFO , " %s: [RX_ID 0x%x] D_ID 0x%06x found on Chan %d for S_ID 0x%06x wasn't in PDB already " ,
__func__ , aep - > at_rxid , did , chan , sid ) ;
2015-07-13 15:11:05 +00:00
isp_dump_portdb ( isp , chan ) ;
2009-08-01 01:04:26 +00:00
isp_endcmd ( isp , aep , NIL_HANDLE , chan , ECMD_TERMINATE , 0 ) ;
return ;
}
nphdl = lp - > handle ;
/*
* Get the tstate pointer
*/
tptr = get_lun_statep ( isp , chan , lun ) ;
if ( tptr = = NULL ) {
tptr = get_lun_statep ( isp , chan , CAM_LUN_WILDCARD ) ;
if ( tptr = = NULL ) {
2015-10-24 17:34:40 +00:00
isp_prt ( isp , ISP_LOGWARN ,
" %s: [0x%x] no state pointer for lun %jx or wildcard " ,
__func__ , aep - > at_rxid , ( uintmax_t ) lun ) ;
-----------
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 ( lun = = 0 ) {
2016-05-19 17:02:33 +00:00
isp_endcmd ( isp , aep , nphdl , chan , SCSI_STATUS_BUSY , 0 ) ;
-----------
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
} else {
isp_endcmd ( isp , aep , nphdl , chan , SCSI_STATUS_CHECK_COND | ECMD_SVALID | ( 0x5 < < 12 ) | ( 0x25 < < 16 ) , 0 ) ;
}
2009-08-01 01:04:26 +00:00
return ;
}
}
/*
* Start any commands pending resources first .
*/
2017-02-22 06:43:49 +00:00
if ( isp_atio_restart ( isp , chan , tptr ) )
goto noresrc ;
2009-08-01 01:04:26 +00:00
/*
* If the f / w is out of resources , just send a BUSY status back .
*/
if ( aep - > at_rxid = = AT7_NORESRC_RXID ) {
isp_endcmd ( isp , aep , nphdl , chan , SCSI_BUSY , 0 ) ;
return ;
}
/*
* If we ' re out of resources , just send a BUSY status back .
*/
atiop = ( struct ccb_accept_tio * ) SLIST_FIRST ( & tptr - > atios ) ;
if ( atiop = = NULL ) {
isp_prt ( isp , ISP_LOGTDEBUG0 , " [0x%x] out of atios " , aep - > at_rxid ) ;
goto noresrc ;
}
2017-02-22 06:43:49 +00:00
oatp = isp_find_atpd ( isp , chan , aep - > at_rxid ) ;
2012-06-24 17:30:54 +00:00
if ( oatp ) {
-----------
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_prt ( isp , ISP_LOGTDEBUG0 , " [0x%x] tag wraparound in isp_handle_platforms_atio7 (N-Port Handle 0x%04x S_ID 0x%04x OX_ID 0x%04x) oatp state %d " ,
2012-06-24 17:30:54 +00:00
aep - > at_rxid , nphdl , sid , aep - > at_hdr . ox_id , oatp - > state ) ;
2009-08-01 01:04:26 +00:00
/*
* It ' s not a " no resource " condition - but we can treat it like one
*/
goto noresrc ;
}
2017-02-22 06:43:49 +00:00
atp = isp_get_atpd ( isp , chan , aep - > at_rxid ) ;
2013-10-17 20:19:15 +00:00
if ( atp = = NULL ) {
isp_prt ( isp , ISP_LOGTDEBUG0 , " [0x%x] out of atps " , aep - > at_rxid ) ;
goto noresrc ;
}
-----------
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
atp - > word3 = lp - > prli_word3 ;
2009-08-01 01:04:26 +00:00
atp - > state = ATPD_STATE_ATIO ;
SLIST_REMOVE_HEAD ( & tptr - > atios , sim_links . sle ) ;
2017-03-15 19:49:45 +00:00
ISP_PATH_PRT ( isp , ISP_LOGTDEBUG2 , atiop - > ccb_h . path , " Take FREE ATIO \n " ) ;
2015-07-13 21:01:24 +00:00
atiop - > init_id = FC_PORTDB_TGT ( isp , chan , lp ) ;
2017-06-30 06:10:18 +00:00
atiop - > ccb_h . target_id = ISP_MAX_TARGETS ( isp ) ;
2009-08-01 01:04:26 +00:00
atiop - > ccb_h . target_lun = lun ;
atiop - > sense_len = 0 ;
cdbxlen = aep - > at_cmnd . fcp_cmnd_alen_datadir > > FCP_CMND_ADDTL_CDBLEN_SHIFT ;
if ( cdbxlen ) {
isp_prt ( isp , ISP_LOGWARN , " additional CDBLEN ignored " ) ;
}
cdbxlen = sizeof ( aep - > at_cmnd . cdb_dl . sf . fcp_cmnd_cdb ) ;
ISP_MEMCPY ( atiop - > cdb_io . cdb_bytes , aep - > at_cmnd . cdb_dl . sf . fcp_cmnd_cdb , cdbxlen ) ;
atiop - > cdb_len = cdbxlen ;
atiop - > ccb_h . status = CAM_CDB_RECVD ;
atiop - > tag_id = atp - > tag ;
switch ( aep - > at_cmnd . fcp_cmnd_task_attribute & FCP_CMND_TASK_ATTR_MASK ) {
case FCP_CMND_TASK_ATTR_SIMPLE :
2013-10-21 06:04:39 +00:00
atiop - > ccb_h . flags | = CAM_TAG_ACTION_VALID ;
2009-08-01 01:04:26 +00:00
atiop - > tag_action = MSG_SIMPLE_Q_TAG ;
break ;
case FCP_CMND_TASK_ATTR_HEAD :
2013-10-21 06:04:39 +00:00
atiop - > ccb_h . flags | = CAM_TAG_ACTION_VALID ;
2009-08-01 01:04:26 +00:00
atiop - > tag_action = MSG_HEAD_OF_Q_TAG ;
break ;
case FCP_CMND_TASK_ATTR_ORDERED :
2013-10-21 06:04:39 +00:00
atiop - > ccb_h . flags | = CAM_TAG_ACTION_VALID ;
2009-08-01 01:04:26 +00:00
atiop - > tag_action = MSG_ORDERED_Q_TAG ;
break ;
default :
/* FALLTHROUGH */
case FCP_CMND_TASK_ATTR_ACA :
case FCP_CMND_TASK_ATTR_UNTAGGED :
atiop - > tag_action = 0 ;
break ;
}
atp - > orig_datalen = aep - > at_cmnd . cdb_dl . sf . fcp_cmnd_dl ;
atp - > bytes_xfered = 0 ;
atp - > lun = lun ;
atp - > nphdl = nphdl ;
2017-02-27 08:20:28 +00:00
atp - > sid = sid ;
atp - > did = did ;
2009-08-01 01:04:26 +00:00
atp - > oxid = aep - > at_hdr . ox_id ;
2012-06-24 17:30:54 +00:00
atp - > rxid = aep - > at_hdr . rx_id ;
2009-08-01 01:04:26 +00:00
atp - > cdb0 = atiop - > cdb_io . cdb_bytes [ 0 ] ;
atp - > tattr = aep - > at_cmnd . fcp_cmnd_task_attribute & FCP_CMND_TASK_ATTR_MASK ;
atp - > state = ATPD_STATE_CAM ;
2015-10-24 17:34:40 +00:00
isp_prt ( isp , ISP_LOGTDEBUG0 , " ATIO7[0x%x] CDB=0x%x lun %jx datalen %u " ,
aep - > at_rxid , atp - > cdb0 , ( uintmax_t ) lun , atp - > orig_datalen ) ;
2009-08-01 01:04:26 +00:00
xpt_done ( ( union ccb * ) atiop ) ;
return ;
noresrc :
2017-02-22 06:43:49 +00:00
if ( atp )
isp_put_atpd ( isp , chan , atp ) ;
ntp = isp_get_ntpd ( isp , chan ) ;
2009-08-01 01:04:26 +00:00
if ( ntp = = NULL ) {
isp_endcmd ( isp , aep , nphdl , chan , SCSI_STATUS_BUSY , 0 ) ;
return ;
}
2017-02-22 06:43:49 +00:00
memcpy ( ntp - > data , aep , QENTRY_LEN ) ;
STAILQ_INSERT_TAIL ( & tptr - > restart_queue , ntp , next ) ;
2009-08-01 01:04:26 +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
/*
* Handle starting an SRR ( sequence retransmit request )
* We get here when we ' ve gotten the immediate notify
* and the return of all outstanding CTIOs for this
* transaction .
*/
static void
2017-02-22 06:43:49 +00:00
isp_handle_srr_start ( ispsoftc_t * isp , atio_private_data_t * atp )
-----------
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
{
in_fcentry_24xx_t * inot ;
uint32_t srr_off , ccb_off , ccb_len , ccb_end ;
union ccb * ccb ;
inot = ( in_fcentry_24xx_t * ) atp - > srr ;
srr_off = inot - > in_srr_reloff_lo | ( inot - > in_srr_reloff_hi < < 16 ) ;
ccb = atp - > srr_ccb ;
atp - > srr_ccb = NULL ;
atp - > nsrr + + ;
if ( ccb = = NULL ) {
2012-08-08 18:24:33 +00:00
isp_prt ( isp , ISP_LOGWARN , " SRR[0x%x] null ccb " , atp - > tag ) ;
-----------
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
goto fail ;
}
ccb_off = ccb - > ccb_h . spriv_field0 ;
ccb_len = ccb - > csio . dxfer_len ;
ccb_end = ( ccb_off = = ~ 0 ) ? ~ 0 : ccb_off + ccb_len ;
switch ( inot - > in_srr_iu ) {
case R_CTL_INFO_SOLICITED_DATA :
/*
* We have to restart a FCP_DATA data out transaction
*/
atp - > sendst = 0 ;
atp - > bytes_xfered = srr_off ;
if ( ccb_len = = 0 ) {
2012-08-08 18:24:33 +00:00
isp_prt ( isp , ISP_LOGWARN , " SRR[0x%x] SRR offset 0x%x but current CCB doesn't transfer data " , atp - > tag , srr_off ) ;
-----------
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
goto mdp ;
}
if ( srr_off < ccb_off | | ccb_off > srr_off + ccb_len ) {
2012-08-08 18:24:33 +00:00
isp_prt ( isp , ISP_LOGWARN , " SRR[0x%x] SRR offset 0x%x not covered by current CCB data range [0x%x..0x%x] " , atp - > tag , srr_off , ccb_off , ccb_end ) ;
-----------
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
goto mdp ;
}
2012-08-08 18:24:33 +00:00
isp_prt ( isp , ISP_LOGWARN , " SRR[0x%x] SRR offset 0x%x covered by current CCB data range [0x%x..0x%x] " , atp - > tag , srr_off , ccb_off , ccb_end ) ;
-----------
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
break ;
case R_CTL_INFO_COMMAND_STATUS :
2012-08-08 18:24:33 +00:00
isp_prt ( isp , ISP_LOGTINFO , " SRR[0x%x] Got an FCP RSP SRR- resending status " , atp - > tag ) ;
-----------
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
atp - > sendst = 1 ;
/*
* We have to restart a FCP_RSP IU transaction
*/
break ;
case R_CTL_INFO_DATA_DESCRIPTOR :
/*
* We have to restart an FCP DATA in transaction
*/
isp_prt ( isp , ISP_LOGWARN , " Got an FCP DATA IN SRR- dropping " ) ;
goto fail ;
default :
isp_prt ( isp , ISP_LOGWARN , " Got an unknown information (%x) SRR- dropping " , inot - > in_srr_iu ) ;
goto fail ;
}
/*
* We can ' t do anything until this is acked , so we might as well start it now .
* We aren ' t going to do the usual asynchronous ack issue because we need
* to make sure this gets on the wire first .
*/
if ( isp_notify_ack ( isp , inot ) ) {
isp_prt ( isp , ISP_LOGWARN , " could not push positive ack for SRR- you lose " ) ;
goto fail ;
}
isp_target_start_ctio ( isp , ccb , FROM_SRR ) ;
return ;
fail :
inot - > in_reserved = 1 ;
isp_async ( isp , ISPASYNC_TARGET_NOTIFY_ACK , inot ) ;
ccb - > ccb_h . status & = ~ CAM_STATUS_MASK ;
ccb - > ccb_h . status | = CAM_REQ_CMP_ERR ;
isp_complete_ctio ( ccb ) ;
return ;
mdp :
if ( isp_notify_ack ( isp , inot ) ) {
isp_prt ( isp , ISP_LOGWARN , " could not push positive ack for SRR- you lose " ) ;
goto fail ;
}
ccb - > ccb_h . status & = ~ CAM_STATUS_MASK ;
ccb - > ccb_h . status = CAM_MESSAGE_RECV ;
/*
* This is not a strict interpretation of MDP , but it ' s close
*/
ccb - > csio . msg_ptr = & ccb - > csio . sense_data . sense_buf [ SSD_FULL_SIZE - 16 ] ;
ccb - > csio . msg_len = 7 ;
ccb - > csio . msg_ptr [ 0 ] = MSG_EXTENDED ;
ccb - > csio . msg_ptr [ 1 ] = 5 ;
ccb - > csio . msg_ptr [ 2 ] = 0 ; /* modify data pointer */
ccb - > csio . msg_ptr [ 3 ] = srr_off > > 24 ;
ccb - > csio . msg_ptr [ 4 ] = srr_off > > 16 ;
ccb - > csio . msg_ptr [ 5 ] = srr_off > > 8 ;
ccb - > csio . msg_ptr [ 6 ] = srr_off ;
isp_complete_ctio ( ccb ) ;
}
static void
2017-03-19 09:30:03 +00:00
isp_handle_platform_srr ( ispsoftc_t * isp , isp_notify_t * notify )
-----------
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
{
2017-03-19 09:30:03 +00:00
in_fcentry_24xx_t * inot = notify - > nt_lreserved ;
-----------
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
atio_private_data_t * atp ;
2017-03-19 09:30:03 +00:00
uint32_t tag = notify - > nt_tagval & 0xffffffff ;
-----------
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
2017-03-19 09:30:03 +00:00
atp = isp_find_atpd ( isp , notify - > nt_channel , tag ) ;
-----------
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 ( atp = = NULL ) {
2017-03-19 09:30:03 +00:00
isp_prt ( isp , ISP_LOGERR , " %s: cannot find adjunct for %x in SRR Notify " ,
__func__ , tag ) ;
-----------
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_async ( isp , ISPASYNC_TARGET_NOTIFY_ACK , inot ) ;
return ;
}
atp - > srr_notify_rcvd = 1 ;
memcpy ( atp - > srr , inot , sizeof ( atp - > srr ) ) ;
2017-03-19 09:30:03 +00:00
isp_prt ( isp , ISP_LOGTINFO , " SRR[0x%x] flags 0x%x srr_iu %x reloff 0x%x " ,
inot - > in_rxid , inot - > in_flags , inot - > in_srr_iu ,
( ( uint32_t ) inot - > in_srr_reloff_hi < < 16 ) | inot - > in_srr_reloff_lo ) ;
-----------
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 ( atp - > srr_ccb )
2017-02-22 06:43:49 +00:00
isp_handle_srr_start ( isp , atp ) ;
-----------
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
}
2009-08-01 01:04:26 +00:00
static void
isp_handle_platform_ctio ( ispsoftc_t * isp , void * arg )
{
union ccb * ccb ;
2017-02-26 12:52:44 +00:00
int sentstatus = 0 , ok = 0 , notify_cam = 0 , failure = 0 ;
2009-08-01 01:04:26 +00:00
atio_private_data_t * atp = NULL ;
int bus ;
2017-02-26 12:52:44 +00:00
uint32_t handle , data_requested , resid ;
2009-08-01 01:04:26 +00:00
2015-11-23 10:06:19 +00:00
handle = ( ( ct2_entry_t * ) arg ) - > ct_syshandle ;
2015-12-25 13:03:18 +00:00
ccb = isp_find_xs ( isp , handle ) ;
2009-08-01 01:04:26 +00:00
if ( ccb = = NULL ) {
isp_print_bytes ( isp , " null ccb in isp_handle_platform_ctio " , QENTRY_LEN , arg ) ;
return ;
}
2015-12-25 13:03:18 +00:00
isp_destroy_handle ( isp , handle ) ;
2017-02-26 12:52:44 +00:00
resid = data_requested = PISP_PCMD ( ccb ) - > datalen ;
-----------
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_free_pcmd ( isp , ccb ) ;
2009-08-01 01:04:26 +00:00
bus = XS_CHANNEL ( 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
if ( IS_24XX ( isp ) ) {
2017-02-22 06:43:49 +00:00
atp = isp_find_atpd ( isp , bus , ( ( ct7_entry_t * ) arg ) - > ct_rxid ) ;
-----------
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
} else {
2017-02-22 06:43:49 +00:00
atp = isp_find_atpd ( isp , bus , ( ( ct2_entry_t * ) arg ) - > ct_rxid ) ;
-----------
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
}
2015-06-18 07:50:27 +00:00
if ( atp = = NULL ) {
/*
2015-07-04 18:51:54 +00:00
* XXX : isp_clear_commands ( ) generates fake CTIO with zero
* ct_rxid value , filling only ct_syshandle . Workaround
* that using tag_id from the CCB , pointed by ct_syshandle .
2015-06-18 07:50:27 +00:00
*/
2017-02-22 06:43:49 +00:00
atp = isp_find_atpd ( isp , bus , ccb - > csio . tag_id ) ;
2015-06-18 07:50:27 +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
if ( atp = = NULL ) {
isp_prt ( isp , ISP_LOGERR , " %s: cannot find adjunct for %x after I/O " , __func__ , ccb - > csio . tag_id ) ;
return ;
}
KASSERT ( ( atp - > ctcnt > 0 ) , ( " ctio count not greater than zero " ) ) ;
2012-08-08 18:24:33 +00:00
atp - > bytes_in_transit - = data_requested ;
-----------
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
atp - > ctcnt - = 1 ;
ccb - > ccb_h . status & = ~ CAM_STATUS_MASK ;
2009-08-01 01:04:26 +00:00
if ( IS_24XX ( isp ) ) {
ct7_entry_t * ct = arg ;
-----------
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 ( ct - > ct_nphdl = = CT7_SRR ) {
atp - > srr_ccb = ccb ;
if ( atp - > srr_notify_rcvd )
2017-02-22 06:43:49 +00:00
isp_handle_srr_start ( isp , atp ) ;
2009-08-01 01:04:26 +00:00
return ;
}
if ( ct - > ct_nphdl = = CT_HBA_RESET ) {
2017-02-24 14:48:17 +00:00
sentstatus = ( ccb - > ccb_h . flags & CAM_SEND_STATUS ) & &
( atp - > sendst = = 0 ) ;
-----------
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
failure = CAM_UNREC_HBA_ERROR ;
} else {
sentstatus = ct - > ct_flags & CT7_SENDSTATUS ;
ok = ( ct - > ct_nphdl = = CT7_OK ) ;
2012-08-08 18:24:33 +00:00
notify_cam = ( ct - > ct_header . rqs_seqno & ATPD_SEQ_NOTIFY_CAM ) ! = 0 ;
2017-02-26 12:52:44 +00:00
if ( ( ct - > ct_flags & CT7_DATAMASK ) ! = CT7_NO_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
resid = ct - > ct_resid ;
2009-08-01 01:04:26 +00:00
}
2012-08-08 18:24:33 +00:00
isp_prt ( isp , ok ? ISP_LOGTDEBUG0 : ISP_LOGWARN , " %s: CTIO7[%x] seq %u nc %d sts 0x%x flg 0x%x sns %d resid %d %s " , __func__ , ct - > ct_rxid , ATPD_GET_SEQNO ( ct ) ,
notify_cam , ct - > ct_nphdl , ct - > ct_flags , ( ccb - > ccb_h . status & CAM_SENT_SENSE ) ! = 0 , resid , sentstatus ? " FIN " : " MID " ) ;
2015-11-23 10:06:19 +00:00
} else {
2009-08-01 01:04:26 +00:00
ct2_entry_t * ct = arg ;
-----------
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 ( ct - > ct_status = = CT_SRR ) {
atp - > srr_ccb = ccb ;
if ( atp - > srr_notify_rcvd )
2017-02-22 06:43:49 +00:00
isp_handle_srr_start ( isp , atp ) ;
-----------
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_target_putback_atio ( ccb ) ;
2009-08-01 01:04:26 +00:00
return ;
}
if ( ct - > ct_status = = CT_HBA_RESET ) {
2017-02-24 14:48:17 +00:00
sentstatus = ( ccb - > ccb_h . flags & CAM_SEND_STATUS ) & &
( atp - > sendst = = 0 ) ;
-----------
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
failure = CAM_UNREC_HBA_ERROR ;
} else {
sentstatus = ct - > ct_flags & CT2_SENDSTATUS ;
ok = ( ct - > ct_status & ~ QLTM_SVALID ) = = CT_OK ;
2012-08-08 18:24:33 +00:00
notify_cam = ( ct - > ct_header . rqs_seqno & ATPD_SEQ_NOTIFY_CAM ) ! = 0 ;
2017-02-26 12:52:44 +00:00
if ( ( ct - > ct_flags & CT2_DATAMASK ) ! = CT2_NO_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
resid = ct - > ct_resid ;
2009-08-01 01:04:26 +00:00
}
2012-08-08 18:24:33 +00:00
isp_prt ( isp , ok ? ISP_LOGTDEBUG0 : ISP_LOGWARN , " %s: CTIO2[%x] seq %u nc %d sts 0x%x flg 0x%x sns %d resid %d %s " , __func__ , ct - > ct_rxid , ATPD_GET_SEQNO ( ct ) ,
notify_cam , ct - > ct_status , ct - > ct_flags , ( ccb - > ccb_h . status & CAM_SENT_SENSE ) ! = 0 , resid , sentstatus ? " FIN " : " MID " ) ;
2000-01-03 23:55:30 +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
if ( ok ) {
2017-02-26 12:52:44 +00:00
if ( data_requested > 0 ) {
atp - > bytes_xfered + = data_requested - resid ;
ccb - > csio . resid = ccb - > csio . dxfer_len -
( data_requested - resid ) ;
-----------
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
}
2017-02-26 12:52:44 +00:00
if ( sentstatus & & ( ccb - > ccb_h . flags & CAM_SEND_SENSE ) )
-----------
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 | = CAM_SENT_SENSE ;
ccb - > ccb_h . status | = CAM_REQ_CMP ;
} else {
notify_cam = 1 ;
if ( failure = = CAM_UNREC_HBA_ERROR )
ccb - > ccb_h . status | = CAM_UNREC_HBA_ERROR ;
else
ccb - > ccb_h . status | = CAM_REQ_CMP_ERR ;
}
atp - > state = ATPD_STATE_PDON ;
2000-01-03 23:55:30 +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
* We never * not * notify CAM when there has been any error ( ok = = 0 ) ,
* so we never need to do an ATIO putback if we ' re not notifying CAM .
2000-01-03 23:55:30 +00:00
*/
2012-08-08 18:24:33 +00:00
isp_prt ( isp , ISP_LOGTDEBUG0 , " %s CTIO[0x%x] done (ok=%d nc=%d nowsendstatus=%d ccb ss=%d) " ,
( sentstatus ) ? " FINAL " : " MIDTERM " , atp - > tag , ok , notify_cam , atp - > sendst , ( ccb - > ccb_h . flags & CAM_SEND_STATUS ) ! = 0 ) ;
2000-07-18 06:58:28 +00:00
if ( notify_cam = = 0 ) {
-----------
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 ( atp - > sendst ) {
isp_target_start_ctio ( isp , ccb , FROM_CTIO_DONE ) ;
}
2009-08-01 01:04:26 +00:00
return ;
2000-07-18 06:58:28 +00:00
}
2001-04-04 21:58:29 +00:00
2017-02-22 06:43:49 +00:00
/*
2017-02-24 14:48:17 +00:00
* We are done with this ATIO if we successfully sent status .
* In all other cases expect either another CTIO or XPT_ABORT .
2017-02-22 06:43:49 +00:00
*/
2017-02-24 14:48:17 +00:00
if ( ok & & sentstatus )
2017-02-22 06:43:49 +00:00
isp_put_atpd ( isp , bus , atp ) ;
-----------
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
/*
* We ' re telling CAM we ' re done with this CTIO transaction .
*
* 24 XX cards never need an ATIO put back .
*
* Other cards need one put back only on error .
* In the latter case , a timeout will re - fire
* and try again in case we didn ' t have
* queue resources to do so at first . In any case ,
* once the putback is done we do the completion
* call .
*/
if ( ok | | IS_24XX ( isp ) ) {
2001-04-04 21:58:29 +00:00
isp_complete_ctio ( 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
} else {
isp_target_putback_atio ( ccb ) ;
2009-08-01 01:04:26 +00:00
}
}
static int
2016-05-20 10:26:12 +00:00
isp_handle_platform_target_notify_ack ( ispsoftc_t * isp , isp_notify_t * mp , uint32_t rsp )
2009-08-01 01:04:26 +00:00
{
if ( isp - > isp_state ! = ISP_RUNSTATE ) {
isp_prt ( isp , ISP_LOGTINFO , " Notify Code 0x%x (qevalid=%d) acked- h/w not ready (dropping) " , mp - > nt_ncode , mp - > nt_lreserved ! = NULL ) ;
return ( 0 ) ;
}
/*
* This case is for a Task Management Function , which shows up as an ATIO7 entry .
*/
if ( IS_24XX ( isp ) & & mp - > nt_lreserved & & ( ( isphdr_t * ) mp - > nt_lreserved ) - > rqs_entry_type = = RQSTYPE_ATIO ) {
ct7_entry_t local , * cto = & local ;
at7_entry_t * aep = ( at7_entry_t * ) mp - > nt_lreserved ;
fcportdb_t * lp ;
uint32_t sid ;
uint16_t nphdl ;
sid = ( aep - > at_hdr . s_id [ 0 ] < < 16 ) | ( aep - > at_hdr . s_id [ 1 ] < < 8 ) | aep - > at_hdr . s_id [ 2 ] ;
2015-11-19 17:43:47 +00:00
if ( isp_find_pdb_by_portid ( isp , mp - > nt_channel , sid , & lp ) ) {
2009-08-01 01:04:26 +00:00
nphdl = lp - > handle ;
} else {
nphdl = NIL_HANDLE ;
}
ISP_MEMZERO ( & local , sizeof ( local ) ) ;
cto - > ct_header . rqs_entry_type = RQSTYPE_CTIO7 ;
cto - > ct_header . rqs_entry_count = 1 ;
cto - > ct_nphdl = nphdl ;
cto - > ct_rxid = aep - > at_rxid ;
cto - > ct_vpidx = mp - > nt_channel ;
cto - > ct_iid_lo = sid ;
cto - > ct_iid_hi = sid > > 16 ;
cto - > ct_oxid = aep - > at_hdr . ox_id ;
cto - > ct_flags = CT7_SENDSTATUS | CT7_NOACK | CT7_NO_DATA | CT7_FLAG_MODE1 ;
cto - > ct_flags | = ( aep - > at_ta_len > > 12 ) < < CT7_TASK_ATTR_SHIFT ;
2016-05-20 10:26:12 +00:00
if ( rsp ! = 0 ) {
cto - > ct_scsi_status | = ( FCP_RSPLEN_VALID < < 8 ) ;
cto - > rsp . m1 . ct_resplen = 4 ;
ISP_MEMZERO ( cto - > rsp . m1 . ct_resp , sizeof ( cto - > rsp . m1 . ct_resp ) ) ;
cto - > rsp . m1 . ct_resp [ 0 ] = rsp & 0xff ;
cto - > rsp . m1 . ct_resp [ 1 ] = ( rsp > > 8 ) & 0xff ;
cto - > rsp . m1 . ct_resp [ 2 ] = ( rsp > > 16 ) & 0xff ;
cto - > rsp . m1 . ct_resp [ 3 ] = ( rsp > > 24 ) & 0xff ;
}
2009-08-01 01:04:26 +00:00
return ( isp_target_put_entry ( isp , & local ) ) ;
}
/*
* This case is for a responding to an ABTS frame
*/
if ( IS_24XX ( isp ) & & mp - > nt_lreserved & & ( ( isphdr_t * ) mp - > nt_lreserved ) - > rqs_entry_type = = RQSTYPE_ABTS_RCVD ) {
/*
* Overload nt_need_ack here to mark whether we ' ve terminated the associated command .
*/
if ( mp - > nt_need_ack ) {
uint8_t storage [ QENTRY_LEN ] ;
ct7_entry_t * cto = ( ct7_entry_t * ) storage ;
abts_t * abts = ( abts_t * ) mp - > nt_lreserved ;
ISP_MEMZERO ( cto , sizeof ( ct7_entry_t ) ) ;
isp_prt ( isp , ISP_LOGTDEBUG0 , " %s: [%x] terminating after ABTS received " , __func__ , abts - > abts_rxid_task ) ;
cto - > ct_header . rqs_entry_type = RQSTYPE_CTIO7 ;
cto - > ct_header . rqs_entry_count = 1 ;
cto - > ct_nphdl = mp - > nt_nphdl ;
cto - > ct_rxid = abts - > abts_rxid_task ;
cto - > ct_iid_lo = mp - > nt_sid ;
cto - > ct_iid_hi = mp - > nt_sid > > 16 ;
cto - > ct_oxid = abts - > abts_ox_id ;
cto - > ct_vpidx = mp - > nt_channel ;
cto - > ct_flags = CT7_NOACK | CT7_TERMINATE ;
if ( isp_target_put_entry ( isp , cto ) ) {
return ( ENOMEM ) ;
}
mp - > nt_need_ack = 0 ;
}
if ( isp_acknak_abts ( isp , mp - > nt_lreserved , 0 ) = = ENOMEM ) {
return ( ENOMEM ) ;
} else {
return ( 0 ) ;
}
}
/*
* Handle logout cases here
*/
if ( mp - > nt_ncode = = NT_GLOBAL_LOGOUT ) {
isp_del_all_wwn_entries ( isp , mp - > nt_channel ) ;
}
if ( mp - > nt_ncode = = NT_LOGOUT ) {
if ( ! IS_2100 ( isp ) & & IS_FC ( isp ) ) {
isp_del_wwn_entries ( isp , mp ) ;
}
}
/*
* General purpose acknowledgement
*/
if ( mp - > nt_need_ack ) {
isp_prt ( isp , ISP_LOGTINFO , " Notify Code 0x%x (qevalid=%d) being acked " , mp - > nt_ncode , mp - > nt_lreserved ! = NULL ) ;
-----------
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
/*
* Don ' t need to use the guaranteed send because the caller can retry
*/
2009-08-01 01:04:26 +00:00
return ( isp_notify_ack ( isp , mp - > nt_lreserved ) ) ;
}
return ( 0 ) ;
}
/*
2010-11-09 10:59:09 +00:00
* Handle task management functions .
2009-08-01 01:04:26 +00:00
*
* We show up here with a notify structure filled out .
*
* The nt_lreserved tag points to the original queue entry
*/
static void
isp_handle_platform_target_tmf ( ispsoftc_t * isp , isp_notify_t * notify )
{
tstate_t * tptr ;
fcportdb_t * lp ;
struct ccb_immediate_notify * inot ;
inot_private_data_t * ntp = NULL ;
2017-03-18 17:01:11 +00:00
atio_private_data_t * atp ;
2009-08-01 01:04:26 +00:00
lun_id_t lun ;
2017-03-18 16:09:36 +00:00
isp_prt ( isp , ISP_LOGTDEBUG0 , " %s: code 0x%x sid 0x%x tagval 0x%016llx chan %d lun %jx " , __func__ , notify - > nt_ncode ,
2009-08-01 01:04:26 +00:00
notify - > nt_sid , ( unsigned long long ) notify - > nt_tagval , notify - > nt_channel , notify - > nt_lun ) ;
if ( notify - > nt_lun = = LUN_ANY ) {
2017-03-18 17:01:11 +00:00
if ( notify - > nt_tagval = = TAG_ANY ) {
lun = CAM_LUN_WILDCARD ;
} else {
atp = isp_find_atpd ( isp , notify - > nt_channel ,
notify - > nt_tagval & 0xffffffff ) ;
lun = atp ? atp - > lun : CAM_LUN_WILDCARD ;
}
2009-08-01 01:04:26 +00:00
} else {
lun = notify - > nt_lun ;
}
tptr = get_lun_statep ( isp , notify - > nt_channel , lun ) ;
if ( tptr = = NULL ) {
tptr = get_lun_statep ( isp , notify - > nt_channel , CAM_LUN_WILDCARD ) ;
if ( tptr = = NULL ) {
2013-10-30 14:04:47 +00:00
isp_prt ( isp , ISP_LOGWARN , " %s: no state pointer found for chan %d lun %#jx " , __func__ , notify - > nt_channel , ( uintmax_t ) lun ) ;
2009-08-01 01:04:26 +00:00
goto bad ;
}
}
inot = ( struct ccb_immediate_notify * ) SLIST_FIRST ( & tptr - > inots ) ;
if ( inot = = NULL ) {
2013-10-30 14:04:47 +00:00
isp_prt ( isp , ISP_LOGWARN , " %s: out of immediate notify structures for chan %d lun %#jx " , __func__ , notify - > nt_channel , ( uintmax_t ) lun ) ;
2009-08-01 01:04:26 +00:00
goto bad ;
}
2017-06-30 06:10:18 +00:00
inot - > ccb_h . target_id = ISP_MAX_TARGETS ( isp ) ;
inot - > ccb_h . target_lun = lun ;
2015-11-19 17:43:47 +00:00
if ( isp_find_pdb_by_portid ( isp , notify - > nt_channel , notify - > nt_sid , & lp ) = = 0 & &
2015-07-13 21:01:24 +00:00
isp_find_pdb_by_handle ( isp , notify - > nt_channel , notify - > nt_nphdl , & lp ) = = 0 ) {
2009-08-01 01:04:26 +00:00
inot - > initiator_id = CAM_TARGET_WILDCARD ;
} else {
2015-07-13 21:01:24 +00:00
inot - > initiator_id = FC_PORTDB_TGT ( isp , notify - > nt_channel , lp ) ;
2009-08-01 01:04:26 +00:00
}
inot - > seq_id = notify - > nt_tagval ;
inot - > tag_id = notify - > nt_tagval > > 32 ;
switch ( notify - > nt_ncode ) {
case NT_ABORT_TASK :
2017-02-22 06:43:49 +00:00
isp_target_mark_aborted_early ( isp , notify - > nt_channel , tptr , inot - > tag_id ) ;
2009-08-01 01:04:26 +00:00
inot - > arg = MSG_ABORT_TASK ;
break ;
case NT_ABORT_TASK_SET :
2017-02-22 06:43:49 +00:00
isp_target_mark_aborted_early ( isp , notify - > nt_channel , tptr , TAG_ANY ) ;
2009-08-01 01:04:26 +00:00
inot - > arg = MSG_ABORT_TASK_SET ;
break ;
case NT_CLEAR_ACA :
inot - > arg = MSG_CLEAR_ACA ;
break ;
case NT_CLEAR_TASK_SET :
inot - > arg = MSG_CLEAR_TASK_SET ;
break ;
case NT_LUN_RESET :
inot - > arg = MSG_LOGICAL_UNIT_RESET ;
break ;
case NT_TARGET_RESET :
inot - > arg = MSG_TARGET_RESET ;
break ;
2015-10-23 18:34:18 +00:00
case NT_QUERY_TASK_SET :
inot - > arg = MSG_QUERY_TASK_SET ;
break ;
case NT_QUERY_ASYNC_EVENT :
inot - > arg = MSG_QUERY_ASYNC_EVENT ;
break ;
2009-08-01 01:04:26 +00:00
default :
2013-10-30 14:04:47 +00:00
isp_prt ( isp , ISP_LOGWARN , " %s: unknown TMF code 0x%x for chan %d lun %#jx " , __func__ , notify - > nt_ncode , notify - > nt_channel , ( uintmax_t ) lun ) ;
2009-08-01 01:04:26 +00:00
goto bad ;
}
2017-02-22 06:43:49 +00:00
ntp = isp_get_ntpd ( isp , notify - > nt_channel ) ;
2009-08-01 01:04:26 +00:00
if ( ntp = = NULL ) {
isp_prt ( isp , ISP_LOGWARN , " %s: out of inotify private structures " , __func__ ) ;
goto bad ;
}
2017-02-22 06:43:49 +00:00
ISP_MEMCPY ( & ntp - > nt , notify , sizeof ( isp_notify_t ) ) ;
2009-08-01 01:04:26 +00:00
if ( notify - > nt_lreserved ) {
2017-02-22 06:43:49 +00:00
ISP_MEMCPY ( & ntp - > data , notify - > nt_lreserved , QENTRY_LEN ) ;
ntp - > nt . nt_lreserved = & ntp - > data ;
2009-08-01 01:04:26 +00:00
}
2017-02-22 06:43:49 +00:00
ntp - > seq_id = notify - > nt_tagval ;
ntp - > tag_id = notify - > nt_tagval > > 32 ;
2009-08-01 01:04:26 +00:00
SLIST_REMOVE_HEAD ( & tptr - > inots , sim_links . sle ) ;
2017-03-15 19:49:45 +00:00
ISP_PATH_PRT ( isp , ISP_LOGTDEBUG2 , inot - > ccb_h . path , " Take FREE INOT \n " ) ;
2009-08-01 01:04:26 +00:00
inot - > ccb_h . status = CAM_MESSAGE_RECV ;
xpt_done ( ( union ccb * ) inot ) ;
return ;
bad :
2017-03-18 10:34:29 +00:00
if ( notify - > nt_need_ack ) {
2009-08-01 01:04:26 +00:00
if ( ( ( isphdr_t * ) notify - > nt_lreserved ) - > rqs_entry_type = = RQSTYPE_ABTS_RCVD ) {
-----------
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 ( isp_acknak_abts ( isp , notify - > nt_lreserved , ENOMEM ) ) {
isp_prt ( isp , ISP_LOGWARN , " you lose- unable to send an ACKNAK " ) ;
}
2009-08-01 01:04:26 +00:00
} else {
-----------
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_async ( isp , ISPASYNC_TARGET_NOTIFY_ACK , notify - > nt_lreserved ) ;
2009-08-01 01:04:26 +00:00
}
}
}
static void
2017-02-22 06:43:49 +00:00
isp_target_mark_aborted_early ( ispsoftc_t * isp , int chan , tstate_t * tptr , uint32_t tag_id )
2009-08-01 01:04:26 +00:00
{
2017-02-22 06:43:49 +00:00
atio_private_data_t * atp , * atpool ;
inot_private_data_t * ntp , * tmp ;
uint32_t this_tag_id ;
2009-08-01 01:04:26 +00:00
/*
* First , clean any commands pending restart
*/
2017-02-22 06:43:49 +00:00
STAILQ_FOREACH_SAFE ( ntp , & tptr - > restart_queue , next , tmp ) {
if ( IS_24XX ( isp ) )
this_tag_id = ( ( at7_entry_t * ) ntp - > data ) - > at_rxid ;
else
this_tag_id = ( ( at2_entry_t * ) ntp - > data ) - > at_rxid ;
2009-08-01 01:04:26 +00:00
if ( ( uint64_t ) tag_id = = TAG_ANY | | tag_id = = this_tag_id ) {
2017-02-22 06:43:49 +00:00
isp_endcmd ( isp , ntp - > data , NIL_HANDLE , chan ,
ECMD_TERMINATE , 0 ) ;
isp_put_ntpd ( isp , chan , ntp ) ;
STAILQ_REMOVE ( & tptr - > restart_queue , ntp ,
inot_private_data , next ) ;
2009-08-01 01:04:26 +00:00
}
}
/*
* Now mark other ones dead as well .
*/
2017-02-22 06:43:49 +00:00
ISP_GET_PC ( isp , chan , atpool , atpool ) ;
for ( atp = atpool ; atp < & atpool [ ATPDPSIZE ] ; atp + + ) {
if ( atp - > lun ! = tptr - > ts_lun )
continue ;
if ( ( uint64_t ) tag_id = = TAG_ANY | | atp - > tag = = tag_id )
2009-08-01 01:04:26 +00:00
atp - > dead = 1 ;
}
}
2000-01-03 23:55:30 +00:00
# endif
1998-09-15 08:42:56 +00:00
static void
2006-02-15 00:31:48 +00:00
isp_cam_async ( void * cbarg , uint32_t code , struct cam_path * path , void * arg )
1998-09-15 08:42:56 +00:00
{
struct cam_sim * sim ;
2011-08-13 23:34:17 +00:00
int bus , tgt ;
2006-04-21 18:30:01 +00:00
ispsoftc_t * isp ;
1998-09-15 08:42:56 +00:00
sim = ( struct cam_sim * ) cbarg ;
2006-04-21 18:30:01 +00:00
isp = ( ispsoftc_t * ) cam_sim_softc ( sim ) ;
2011-08-13 23:34:17 +00:00
bus = cam_sim_bus ( sim ) ;
tgt = xpt_path_target_id ( path ) ;
1998-09-15 08:42:56 +00:00
switch ( code ) {
case AC_LOST_DEVICE :
1999-10-17 18:50:47 +00:00
if ( IS_SCSI ( isp ) ) {
2006-02-15 00:31:48 +00:00
uint16_t oflags , nflags ;
2009-08-01 01:04:26 +00:00
sdparam * sdp = SDPARAM ( isp , bus ) ;
1998-09-15 08:42:56 +00:00
2002-10-10 17:29:05 +00:00
if ( tgt > = 0 ) {
nflags = sdp - > isp_devparam [ tgt ] . nvrm_flags ;
nflags & = DPARM_SAFE_DFLT ;
if ( isp - > isp_loaded_fw ) {
nflags | = DPARM_NARROW | DPARM_ASYNC ;
}
oflags = sdp - > isp_devparam [ tgt ] . goal_flags ;
sdp - > isp_devparam [ tgt ] . goal_flags = nflags ;
sdp - > isp_devparam [ tgt ] . dev_update = 1 ;
2009-08-01 01:04:26 +00:00
sdp - > update = 1 ;
( void ) isp_control ( isp , ISPCTL_UPDATE_PARAMS , bus ) ;
2002-10-10 17:29:05 +00:00
sdp - > isp_devparam [ tgt ] . goal_flags = oflags ;
}
1998-09-15 08:42:56 +00:00
}
break ;
default :
2001-03-01 02:14:54 +00:00
isp_prt ( isp , ISP_LOGWARN , " isp_cam_async: Code 0x%x " , code ) ;
1998-09-15 08:42:56 +00:00
break ;
}
}
static void
1998-12-28 19:22:27 +00:00
isp_poll ( struct cam_sim * sim )
1998-09-15 08:42:56 +00:00
{
2006-04-21 18:30:01 +00:00
ispsoftc_t * isp = cam_sim_softc ( sim ) ;
2001-08-31 21:39:04 +00:00
2017-03-15 14:58:29 +00:00
ISP_RUN_ISR ( isp ) ;
1998-09-15 08:42:56 +00:00
}
1999-10-17 18:50:47 +00:00
2009-08-01 01:04:26 +00:00
static void
isp_watchdog ( void * arg )
2000-05-09 01:08:21 +00:00
{
2009-08-01 01:04:26 +00:00
struct ccb_scsiio * xs = arg ;
ispsoftc_t * isp ;
2011-08-13 23:34:17 +00:00
uint32_t ohandle = ISP_HANDLE_FREE , handle ;
Add in the enabling of interrupts (to isp_attach). Clean up a busted
comment. Check against firmware state- not loop state when enabling
target mode. Other changes have to do with no longer enabling/disabling
interrupts at will.
Rearchitect command watchdog timeouts-
First of all, set the timeout period for a command that has a
timeout (in isp_action) to the period of time requested *plus* two
seconds. We don't want the Qlogic firmware and the host system to
race each other to report a dead command (the watchdog is there to
catch dead and/or broken firmware).
Next, make sure that the command being watched isn't done yet. If
it's not done yet, check for INT_PENDING and call isp_intr- if that
said it serviced an interrupt, check to see whether the command is
now done (this is what the "IN WATCHDOG" private flag is for- if
isp_intr completes the command, it won't call xpt_done on it because
isp_watchdog is still looking at the command).
If no interrupt was pending, or the command wasn't completed, check
to see if we've set the private 'grace period' flag. If so, the
command really *is* dead, so report it as dead and complete it with
a CAM_CMD_TIMEOUT value.
If the grace period flag wasn't set, set it and issue a SYNCHRONIZE_ALL
Marker Request Queue entry and re-set the timeout for one second
from now (see Revision 1.45 isp.c notes for more on this) to give
the firmware a final chance to complete this command.
2000-06-27 19:31:02 +00:00
2009-08-01 01:04:26 +00:00
isp = XS_ISP ( xs ) ;
2000-05-09 01:08:21 +00:00
handle = isp_find_handle ( isp , xs ) ;
2011-08-13 23:34:17 +00:00
/*
* Hand crank the interrupt code just to be sure the command isn ' t stuck somewhere .
*/
if ( handle ! = ISP_HANDLE_FREE ) {
2017-03-15 14:58:29 +00:00
ISP_RUN_ISR ( isp ) ;
2011-08-13 23:34:17 +00:00
ohandle = handle ;
handle = isp_find_handle ( isp , xs ) ;
}
2010-02-03 21:09:32 +00:00
if ( handle ! = ISP_HANDLE_FREE ) {
2009-08-01 01:04:26 +00:00
/*
2010-02-03 21:09:32 +00:00
* Try and make sure the command is really dead before
* we release the handle ( and DMA resources ) for reuse .
*
* If we are successful in aborting the command then
* we ' re done here because we ' ll get the command returned
* back separately .
*/
if ( isp_control ( isp , ISPCTL_ABORT_CMD , xs ) = = 0 ) {
return ;
}
/*
* Note that after calling the above , the command may in
* fact have been completed .
2009-08-01 01:04:26 +00:00
*/
2010-02-03 21:09:32 +00:00
xs = isp_find_xs ( isp , handle ) ;
/*
* If the command no longer exists , then we won ' t
* be able to find the xs again with this handle .
*/
if ( xs = = NULL ) {
return ;
}
2000-07-05 06:44:17 +00:00
2009-08-01 01:04:26 +00:00
/*
2010-02-03 21:09:32 +00:00
* After this point , the command is really dead .
2009-08-01 01:04:26 +00:00
*/
if ( XS_XFRLEN ( xs ) ) {
ISP_DMAFREE ( isp , xs , handle ) ;
}
isp_destroy_handle ( isp , handle ) ;
2010-02-03 21:09:32 +00:00
isp_prt ( isp , ISP_LOGERR , " %s: timeout for handle 0x%x " , __func__ , handle ) ;
Correct loop mode CRN resets to adhere to FCP-4 section 4.10
Prior to this change, the CRN (Command Reference Number) is reset on any
firmware LIP, LOOP DOWN, or LOOP RESET event in violation of FCP-4 which
specifies that the CRN should only be reset in response to a LIP Reset
(LIPyx) primitive. FCP-4 also indicates PLOGI/LOGO and PRLI/PRLO ELS
actions as conditions for resetting the CRN for the associated initiator
port.
These violations manifest themselves when the HBA is removed from the
loop, or a target device is removed (especially during an outstanding
command) without power cycling. If the HBA and and the target device
determine upon re-establishing the loop that no PLOGI or PRLI is
required, and the target does not issue a LIPxy to the initiator, the
CRN for the target will have been improperly reset by the isp driver. As
a result, the target port will silently ignore all FCP commands issued
during the device probe (which will time out) preventing the device from
attaching.
This change corrects thie CRN reset behavior in response to loop state
changes, also introduces CRN resets for the above mentioned ELS actions
as encountered through async PDB change events.
This change also adds cleanup of outstanding commands in isp_loop_dead()
that was previously missing.
sys/dev/isp/isp.c
Add the last login state to debug output when syncing the pdb
sys/dev/isp/isp_freebsd.c
Replace binary statement setting aborted ccb status in
isp_watchdog() with the XS_SETERR macro used elsewhere
In isp_loop_dead(), abort or complete pending commands as done
in isp_watchdog()
In isp_async(), segregate the ISPASYNC_LOOP_RESET action from
ISPASYNC_LIP, ISPASYNC_LOOP_DOWN, and ISPASYNC_LOOP_UP
fallthroughs, and only reset the CRN in the RESET case. Also add
checks to handle false LOOP RESET actions that do not have a
proper associated LIP primitive, and log the primitive in the
debug messages
In isp_async(), remove the goto from ISP_ASYNC_DEV_STAYED, and
only reset the CRN in the DEV_CHANGED action
In isp_async(), when processing an ISPASYNC_CHANGE_PDB status,
reset CRN(s) for the associated nphdl (or all ports) if the
change reason is some form of ELS login/logout. Also remove
assignment to fc since it is not used in the scope
sys/dev/isp/ispmbox.h
Add macro definition for the global N-Port handle, and correct a
macro typo 'PDB24XX_AE_PRLI_DONJE'
sys/dev/isp/ispvar.h
Add macros FCP_AL_DA_ALL, FCP_AL_PA, and FCP_IS_DEST_ALPD for
more legible code when determining if an AL_PD port matches the
portid for a given struct fcparam* by value or by virtue of the
AL_PD port being 0xFF
Submitted by: Reid Linnemann
Sponsored by: Spectra Logic
MFC after: 1 week
2017-05-03 13:17:01 +00:00
XS_SETERR ( xs , CAM_CMD_TIMEOUT ) ;
2009-08-01 01:04:26 +00:00
isp_done ( xs ) ;
2011-08-13 23:34:17 +00:00
} else {
if ( ohandle ! = ISP_HANDLE_FREE ) {
isp_prt ( isp , ISP_LOGWARN , " %s: timeout for handle 0x%x, recovered during interrupt " , __func__ , ohandle ) ;
} else {
isp_prt ( isp , ISP_LOGWARN , " %s: timeout for handle already free " , __func__ ) ;
}
2006-11-14 08:45:48 +00:00
}
}
static void
Close a race in the isp(4) driver that caused devices to disappear
and not automatically come back if they were gone for a short
period of time.
The isp(4) driver has a 30 second gone device timer that gets
activated whenever a device goes away. If the device comes back
before the timer expires, we don't send a notification to CAM that
it has gone away. If, however, there is a command sent to the
device while it is gone and before it comes back, the isp(4) driver
sends the command back with CAM_SEL_TIMEOUT status.
CAM responds to the CAM_SEL_TIMEOUT status by removing the device.
In the case where a device comes back within the 30 second gone
device timer window, though, we weren't telling CAM the device
came back.
So, fix this by tracking whether we have told CAM the device is
gone, and if we have, send a rescan if it comes back within the 30
second window.
ispvar.h:
In the fcportdb_t structure, add a new bitfield,
reported_gone. This gets set whenever we return a command
with CAM_SEL_TIMEOUT status on a Fibre Channel device.
isp_freebsd.c:
In isp_done(), if we're sending CAM_SEL_TIMEOUT for for a
command sent to a FC device, set the reported_gone bit.
In isp_async(), in the ISPASYNC_DEV_STAYED case, rescan the
device in question if it is mapped to a target ID and has
been reported gone.
In isp_make_here(), take a port database entry argument,
and clear the reported_gone bit when we send a rescan to
CAM.
In isp_make_gone(), take a port database entry as an
argument, and set the reported_gone bit when we send an
async event telling CAM consumers that the device is gone.
Sponsored by: Spectra Logic
MFC after: 1 week
2015-01-08 17:51:12 +00:00
isp_make_here ( ispsoftc_t * isp , fcportdb_t * fcp , int chan , int tgt )
2006-11-14 08:45:48 +00:00
{
2009-08-01 01:04:26 +00:00
union ccb * ccb ;
struct isp_fc * fc = ISP_FC_PC ( isp , chan ) ;
2007-05-05 20:17:23 +00:00
2007-02-23 05:51:57 +00:00
/*
2010-05-26 22:49:42 +00:00
* Allocate a CCB , create a wildcard path for this target and schedule a rescan .
2007-02-23 05:51:57 +00:00
*/
2007-04-18 04:58:53 +00:00
ccb = xpt_alloc_ccb_nowait ( ) ;
2007-02-23 05:51:57 +00:00
if ( ccb = = NULL ) {
2009-08-01 01:04:26 +00:00
isp_prt ( isp , ISP_LOGWARN , " Chan %d unable to alloc CCB for rescan " , chan ) ;
2007-02-23 05:51:57 +00:00
return ;
}
2013-04-14 09:55:48 +00:00
if ( xpt_create_path ( & ccb - > ccb_h . path , NULL , cam_sim_path ( fc - > sim ) ,
tgt , CAM_LUN_WILDCARD ) ! = CAM_REQ_CMP ) {
2007-02-23 05:51:57 +00:00
isp_prt ( isp , ISP_LOGWARN , " unable to create path for rescan " ) ;
xpt_free_ccb ( ccb ) ;
return ;
}
xpt_rescan ( ccb ) ;
}
static void
Close a race in the isp(4) driver that caused devices to disappear
and not automatically come back if they were gone for a short
period of time.
The isp(4) driver has a 30 second gone device timer that gets
activated whenever a device goes away. If the device comes back
before the timer expires, we don't send a notification to CAM that
it has gone away. If, however, there is a command sent to the
device while it is gone and before it comes back, the isp(4) driver
sends the command back with CAM_SEL_TIMEOUT status.
CAM responds to the CAM_SEL_TIMEOUT status by removing the device.
In the case where a device comes back within the 30 second gone
device timer window, though, we weren't telling CAM the device
came back.
So, fix this by tracking whether we have told CAM the device is
gone, and if we have, send a rescan if it comes back within the 30
second window.
ispvar.h:
In the fcportdb_t structure, add a new bitfield,
reported_gone. This gets set whenever we return a command
with CAM_SEL_TIMEOUT status on a Fibre Channel device.
isp_freebsd.c:
In isp_done(), if we're sending CAM_SEL_TIMEOUT for for a
command sent to a FC device, set the reported_gone bit.
In isp_async(), in the ISPASYNC_DEV_STAYED case, rescan the
device in question if it is mapped to a target ID and has
been reported gone.
In isp_make_here(), take a port database entry argument,
and clear the reported_gone bit when we send a rescan to
CAM.
In isp_make_gone(), take a port database entry as an
argument, and set the reported_gone bit when we send an
async event telling CAM consumers that the device is gone.
Sponsored by: Spectra Logic
MFC after: 1 week
2015-01-08 17:51:12 +00:00
isp_make_gone ( ispsoftc_t * isp , fcportdb_t * fcp , int chan , int tgt )
2007-02-23 05:51:57 +00:00
{
struct cam_path * tp ;
2009-08-01 01:04:26 +00:00
struct isp_fc * fc = ISP_FC_PC ( isp , chan ) ;
if ( xpt_create_path ( & tp , NULL , cam_sim_path ( fc - > sim ) , tgt , CAM_LUN_WILDCARD ) = = CAM_REQ_CMP ) {
2007-02-23 05:51:57 +00:00
xpt_async ( AC_LOST_DEVICE , tp , NULL ) ;
xpt_free_path ( tp ) ;
2006-11-14 08:45:48 +00:00
}
}
/*
* Gone Device Timer Function - when we have decided that a device has gone
* away , we wait a specific period of time prior to telling the OS it has
* gone away .
*
* This timer function fires once a second and then scans the port database
* for devices that are marked dead but still have a virtual target assigned .
* We decrement a counter for that port database entry , and when it hits zero ,
* we tell the OS the device has gone away .
*/
static void
isp_gdt ( void * arg )
2011-08-12 19:51:28 +00:00
{
struct isp_fc * fc = arg ;
taskqueue_enqueue ( taskqueue_thread , & fc - > gtask ) ;
}
static void
isp_gdt_task ( void * arg , int pending )
2006-11-14 08:45:48 +00:00
{
2009-08-01 01:04:26 +00:00
struct isp_fc * fc = arg ;
ispsoftc_t * isp = fc - > isp ;
int chan = fc - isp - > isp_osinfo . pc . fc ;
2006-11-14 08:45:48 +00:00
fcportdb_t * lp ;
2015-07-13 15:11:05 +00:00
struct ac_contract ac ;
struct ac_device_changed * adc ;
2015-07-05 02:09:46 +00:00
int dbidx , more_to_do = 0 ;
2006-11-14 08:45:48 +00:00
2011-08-12 19:51:28 +00:00
ISP_LOCK ( isp ) ;
isp_prt ( isp , ISP_LOGDEBUG0 , " Chan %d GDT timer expired " , chan ) ;
2006-11-14 08:45:48 +00:00
for ( dbidx = 0 ; dbidx < MAX_FC_TARG ; dbidx + + ) {
2009-08-01 01:04:26 +00:00
lp = & FCPARAM ( isp , chan ) - > portdb [ dbidx ] ;
2006-11-14 08:45:48 +00:00
if ( lp - > state ! = FC_PORTDB_STATE_ZOMBIE ) {
continue ;
}
2010-05-15 20:26:10 +00:00
if ( lp - > gone_timer ! = 0 ) {
lp - > gone_timer - = 1 ;
2006-11-14 08:45:48 +00:00
more_to_do + + ;
continue ;
}
2015-07-13 15:11:05 +00:00
isp_prt ( isp , ISP_LOGCONFIG , prom3 , chan , dbidx , lp - > portid , " Gone Device Timeout " ) ;
if ( lp - > is_target ) {
lp - > is_target = 0 ;
isp_make_gone ( isp , lp , chan , dbidx ) ;
}
if ( lp - > is_initiator ) {
lp - > is_initiator = 0 ;
ac . contract_number = AC_CONTRACT_DEV_CHG ;
adc = ( struct ac_device_changed * ) ac . contract_data ;
adc - > wwpn = lp - > port_wwn ;
adc - > port = lp - > portid ;
2015-07-13 21:01:24 +00:00
adc - > target = dbidx ;
2015-07-13 15:11:05 +00:00
adc - > arrived = 0 ;
xpt_async ( AC_CONTRACT , fc - > path , & ac ) ;
}
2006-11-14 08:45:48 +00:00
lp - > state = FC_PORTDB_STATE_NIL ;
}
2009-12-04 03:34:12 +00:00
if ( fc - > ready ) {
if ( more_to_do ) {
callout_reset ( & fc - > gdt , hz , isp_gdt , fc ) ;
} else {
2011-08-12 19:51:28 +00:00
callout_deactivate ( & fc - > gdt ) ;
-----------
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_prt ( isp , ISP_LOG_SANCFG , " Chan %d Stopping Gone Device Timer @ %lu " , chan , ( unsigned long ) time_uptime ) ;
2009-12-04 03:34:12 +00:00
}
2000-05-09 01:08:21 +00:00
}
2011-08-12 19:51:28 +00:00
ISP_UNLOCK ( isp ) ;
2000-05-09 01:08:21 +00:00
}
2006-11-14 08:45:48 +00:00
/*
2015-11-26 13:04:58 +00:00
* When loop goes down we remember the time and freeze CAM command queue .
* During some time period we are trying to reprobe the loop . But if we
* fail , we tell the OS that devices have gone away and drop the freeze .
*
2006-11-14 08:45:48 +00:00
* We don ' t clear the devices out of our port database because , when loop
* come back up , we have to do some actual cleanup with the chip at that
* point ( implicit PLOGO , e . g . , to get the chip ' s port database state right ) .
*/
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
static void
2015-11-26 13:04:58 +00:00
isp_loop_changed ( ispsoftc_t * isp , int chan )
2011-08-12 19:51:28 +00:00
{
2015-11-26 13:04:58 +00:00
fcparam * fcp = FCPARAM ( isp , chan ) ;
struct isp_fc * fc = ISP_FC_PC ( isp , chan ) ;
if ( fc - > loop_down_time )
return ;
isp_prt ( isp , ISP_LOG_SANCFG | ISP_LOGDEBUG0 , " Chan %d Loop changed " , chan ) ;
if ( fcp - > role & ISP_ROLE_INITIATOR )
isp_freeze_loopdown ( isp , chan ) ;
fc - > loop_down_time = time_uptime ;
wakeup ( fc ) ;
2011-08-12 19:51:28 +00:00
}
static void
2015-11-26 13:04:58 +00:00
isp_loop_up ( ispsoftc_t * isp , int chan )
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
{
2015-11-26 13:04:58 +00:00
struct isp_fc * fc = ISP_FC_PC ( isp , chan ) ;
isp_prt ( isp , ISP_LOG_SANCFG | ISP_LOGDEBUG0 , " Chan %d Loop is up " , chan ) ;
fc - > loop_seen_once = 1 ;
fc - > loop_down_time = 0 ;
isp_unfreeze_loopdown ( isp , chan ) ;
}
static void
isp_loop_dead ( ispsoftc_t * isp , int chan )
{
fcparam * fcp = FCPARAM ( isp , chan ) ;
struct isp_fc * fc = ISP_FC_PC ( isp , chan ) ;
2006-11-14 08:45:48 +00:00
fcportdb_t * lp ;
2015-07-13 15:11:05 +00:00
struct ac_contract ac ;
struct ac_device_changed * adc ;
2015-07-05 02:09:46 +00:00
int dbidx , i ;
2006-11-14 08:45:48 +00:00
2015-11-26 13:04:58 +00:00
isp_prt ( isp , ISP_LOG_SANCFG | ISP_LOGDEBUG0 , " Chan %d Loop is dead " , chan ) ;
2007-05-05 20:17:23 +00:00
2006-11-14 08:45:48 +00:00
/*
* Notify to the OS all targets who we now consider have departed .
*/
for ( dbidx = 0 ; dbidx < MAX_FC_TARG ; dbidx + + ) {
2015-11-26 13:04:58 +00:00
lp = & fcp - > portdb [ dbidx ] ;
2006-11-14 08:45:48 +00:00
2015-07-13 15:11:05 +00:00
if ( lp - > state = = FC_PORTDB_STATE_NIL )
2006-11-14 08:45:48 +00:00
continue ;
2011-08-13 23:34:17 +00:00
for ( i = 0 ; i < isp - > isp_maxcmds ; i + + ) {
struct ccb_scsiio * xs ;
2015-12-25 13:03:18 +00:00
if ( ISP_H2HT ( isp - > isp_xflist [ i ] . handle ) ! = ISP_HANDLE_INITIATOR ) {
2011-08-13 23:34:17 +00:00
continue ;
}
if ( ( xs = isp - > isp_xflist [ i ] . cmd ) = = NULL ) {
continue ;
}
2015-07-05 02:09:46 +00:00
if ( dbidx ! = XS_TGT ( xs ) ) {
2011-08-13 23:34:17 +00:00
continue ;
}
2015-10-24 17:34:40 +00:00
isp_prt ( isp , ISP_LOGWARN , " command handle 0x%x for %d.%d.%jx orphaned by loop down timeout " ,
isp - > isp_xflist [ i ] . handle , chan , XS_TGT ( xs ) ,
( uintmax_t ) XS_LUN ( xs ) ) ;
Correct loop mode CRN resets to adhere to FCP-4 section 4.10
Prior to this change, the CRN (Command Reference Number) is reset on any
firmware LIP, LOOP DOWN, or LOOP RESET event in violation of FCP-4 which
specifies that the CRN should only be reset in response to a LIP Reset
(LIPyx) primitive. FCP-4 also indicates PLOGI/LOGO and PRLI/PRLO ELS
actions as conditions for resetting the CRN for the associated initiator
port.
These violations manifest themselves when the HBA is removed from the
loop, or a target device is removed (especially during an outstanding
command) without power cycling. If the HBA and and the target device
determine upon re-establishing the loop that no PLOGI or PRLI is
required, and the target does not issue a LIPxy to the initiator, the
CRN for the target will have been improperly reset by the isp driver. As
a result, the target port will silently ignore all FCP commands issued
during the device probe (which will time out) preventing the device from
attaching.
This change corrects thie CRN reset behavior in response to loop state
changes, also introduces CRN resets for the above mentioned ELS actions
as encountered through async PDB change events.
This change also adds cleanup of outstanding commands in isp_loop_dead()
that was previously missing.
sys/dev/isp/isp.c
Add the last login state to debug output when syncing the pdb
sys/dev/isp/isp_freebsd.c
Replace binary statement setting aborted ccb status in
isp_watchdog() with the XS_SETERR macro used elsewhere
In isp_loop_dead(), abort or complete pending commands as done
in isp_watchdog()
In isp_async(), segregate the ISPASYNC_LOOP_RESET action from
ISPASYNC_LIP, ISPASYNC_LOOP_DOWN, and ISPASYNC_LOOP_UP
fallthroughs, and only reset the CRN in the RESET case. Also add
checks to handle false LOOP RESET actions that do not have a
proper associated LIP primitive, and log the primitive in the
debug messages
In isp_async(), remove the goto from ISP_ASYNC_DEV_STAYED, and
only reset the CRN in the DEV_CHANGED action
In isp_async(), when processing an ISPASYNC_CHANGE_PDB status,
reset CRN(s) for the associated nphdl (or all ports) if the
change reason is some form of ELS login/logout. Also remove
assignment to fc since it is not used in the scope
sys/dev/isp/ispmbox.h
Add macro definition for the global N-Port handle, and correct a
macro typo 'PDB24XX_AE_PRLI_DONJE'
sys/dev/isp/ispvar.h
Add macros FCP_AL_DA_ALL, FCP_AL_PA, and FCP_IS_DEST_ALPD for
more legible code when determining if an AL_PD port matches the
portid for a given struct fcparam* by value or by virtue of the
AL_PD port being 0xFF
Submitted by: Reid Linnemann
Sponsored by: Spectra Logic
MFC after: 1 week
2017-05-03 13:17:01 +00:00
/*
* Just like in isp_watchdog , abort the outstanding
* command or immediately free its resources if it is
* not active
*/
if ( isp_control ( isp , ISPCTL_ABORT_CMD , xs ) = = 0 ) {
continue ;
}
if ( XS_XFRLEN ( xs ) ) {
ISP_DMAFREE ( isp , xs , isp - > isp_xflist [ i ] . handle ) ;
}
isp_destroy_handle ( isp , isp - > isp_xflist [ i ] . handle ) ;
isp_prt ( isp , ISP_LOGWARN , " command handle 0x%x for %d.%d.%jx could not be aborted and was destroyed " ,
isp - > isp_xflist [ i ] . handle , chan , XS_TGT ( xs ) ,
( uintmax_t ) XS_LUN ( xs ) ) ;
XS_SETERR ( xs , HBA_BUSRESET ) ;
isp_done ( xs ) ;
2011-08-13 23:34:17 +00:00
}
2006-11-14 08:45:48 +00:00
2015-07-13 15:11:05 +00:00
isp_prt ( isp , ISP_LOGCONFIG , prom3 , chan , dbidx , lp - > portid , " Loop Down Timeout " ) ;
if ( lp - > is_target ) {
lp - > is_target = 0 ;
isp_make_gone ( isp , lp , chan , dbidx ) ;
}
if ( lp - > is_initiator ) {
lp - > is_initiator = 0 ;
ac . contract_number = AC_CONTRACT_DEV_CHG ;
adc = ( struct ac_device_changed * ) ac . contract_data ;
adc - > wwpn = lp - > port_wwn ;
adc - > port = lp - > portid ;
2015-07-13 21:01:24 +00:00
adc - > target = dbidx ;
2015-07-13 15:11:05 +00:00
adc - > arrived = 0 ;
xpt_async ( AC_CONTRACT , fc - > path , & ac ) ;
}
2006-11-14 08:45:48 +00:00
}
2006-04-21 18:30:01 +00:00
2015-07-13 15:11:05 +00:00
isp_unfreeze_loopdown ( isp , chan ) ;
2015-11-26 13:04:58 +00:00
fc - > loop_down_time = 0 ;
2006-11-14 08:45:48 +00:00
}
static void
isp_kthread ( void * arg )
{
2009-08-01 01:04:26 +00:00
struct isp_fc * fc = arg ;
ispsoftc_t * isp = fc - > isp ;
int chan = fc - isp - > isp_osinfo . pc . fc ;
2015-11-26 13:04:58 +00:00
int slp = 0 , d ;
int lb , lim ;
2009-12-04 03:34:12 +00:00
2017-03-21 10:34:34 +00:00
ISP_LOCK ( isp ) ;
2014-09-18 02:01:36 +00:00
while ( isp - > isp_osinfo . is_exiting = = 0 ) {
2015-11-26 13:04:58 +00:00
isp_prt ( isp , ISP_LOG_SANCFG | ISP_LOGDEBUG0 ,
" Chan %d Checking FC state " , chan ) ;
2009-08-01 01:04:26 +00:00
lb = isp_fc_runstate ( isp , chan , 250000 ) ;
2015-11-26 13:04:58 +00:00
isp_prt ( isp , ISP_LOG_SANCFG | ISP_LOGDEBUG0 ,
" Chan %d FC got to %s state " , chan ,
isp_fc_loop_statename ( lb ) ) ;
2009-08-01 01:04:26 +00:00
/*
* Our action is different based upon whether we ' re supporting
* Initiator mode or not . If we are , we might freeze the simq
* when loop is down and set all sorts of different delays to
* check again .
*
* If not , we simply just wait for loop to come up .
*/
2015-11-26 13:04:58 +00:00
if ( lb = = LOOP_READY | | lb < 0 ) {
slp = 0 ;
} else {
2006-11-02 03:21:32 +00:00
/*
* If we ' ve never seen loop up and we ' ve waited longer
2006-11-14 08:45:48 +00:00
* than quickboot time , or we ' ve seen loop up but we ' ve
* waited longer than loop_down_limit , give up and go
* to sleep until loop comes up .
2006-11-02 03:21:32 +00:00
*/
2015-11-26 13:04:58 +00:00
if ( fc - > loop_seen_once = = 0 )
2006-11-14 08:45:48 +00:00
lim = isp_quickboot_time ;
2015-11-26 13:04:58 +00:00
else
2009-08-01 01:04:26 +00:00
lim = fc - > loop_down_limit ;
2015-11-26 13:04:58 +00:00
d = time_uptime - fc - > loop_down_time ;
if ( d > = lim )
2006-11-14 08:45:48 +00:00
slp = 0 ;
2015-11-26 13:04:58 +00:00
else if ( d < 10 )
2006-11-14 08:45:48 +00:00
slp = 1 ;
2015-11-26 13:04:58 +00:00
else if ( d < 30 )
2006-11-14 08:45:48 +00:00
slp = 5 ;
2015-11-26 13:04:58 +00:00
else if ( d < 60 )
2006-11-14 08:45:48 +00:00
slp = 10 ;
2015-11-26 13:04:58 +00:00
else if ( d < 120 )
2006-11-14 08:45:48 +00:00
slp = 20 ;
-----------
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
else
2015-11-26 13:04:58 +00:00
slp = 30 ;
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
}
2002-07-08 17:42:47 +00:00
2015-11-26 13:04:58 +00:00
if ( slp = = 0 ) {
if ( lb = = LOOP_READY )
isp_loop_up ( isp , chan ) ;
else
isp_loop_dead ( isp , chan ) ;
2009-08-01 01:04:26 +00:00
}
2015-11-26 13:04:58 +00:00
isp_prt ( isp , ISP_LOG_SANCFG | ISP_LOGDEBUG0 ,
" Chan %d sleep for %d seconds " , chan , slp ) ;
2017-03-21 10:34:34 +00:00
msleep ( fc , & isp - > isp_lock , PRIBIO , " ispf " , slp * hz ) ;
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
}
2014-09-18 02:01:36 +00:00
fc - > num_threads - = 1 ;
2017-03-21 10:34:34 +00:00
ISP_UNLOCK ( isp ) ;
2014-09-18 02:01:36 +00:00
kthread_exit ( ) ;
2007-05-05 20:17:23 +00:00
}
2017-02-22 06:43:49 +00:00
# ifdef ISP_TARGET_MODE
static void
isp_abort_atio ( ispsoftc_t * isp , union ccb * ccb )
{
atio_private_data_t * atp ;
union ccb * accb = ccb - > cab . abort_ccb ;
struct ccb_hdr * sccb ;
tstate_t * tptr ;
tptr = get_lun_statep ( isp , XS_CHANNEL ( accb ) , XS_LUN ( accb ) ) ;
if ( tptr ! = NULL ) {
/* Search for the ATIO among queueued. */
SLIST_FOREACH ( sccb , & tptr - > atios , sim_links . sle ) {
if ( sccb ! = & accb - > ccb_h )
continue ;
SLIST_REMOVE ( & tptr - > atios , sccb , ccb_hdr , sim_links . sle ) ;
2017-03-15 19:49:45 +00:00
ISP_PATH_PRT ( isp , ISP_LOGTDEBUG2 , sccb - > path ,
" Abort FREE ATIO \n " ) ;
2017-02-22 06:43:49 +00:00
accb - > ccb_h . status = CAM_REQ_ABORTED ;
xpt_done ( accb ) ;
ccb - > ccb_h . status = CAM_REQ_CMP ;
return ;
}
}
/* Search for the ATIO among running. */
atp = isp_find_atpd ( isp , XS_CHANNEL ( accb ) , accb - > atio . tag_id ) ;
if ( atp ! = NULL ) {
2017-02-27 08:20:28 +00:00
/* Send TERMINATE to firmware. */
if ( ! atp - > dead & & IS_24XX ( isp ) ) {
uint8_t storage [ QENTRY_LEN ] ;
ct7_entry_t * cto = ( ct7_entry_t * ) storage ;
ISP_MEMZERO ( cto , sizeof ( ct7_entry_t ) ) ;
cto - > ct_header . rqs_entry_type = RQSTYPE_CTIO7 ;
cto - > ct_header . rqs_entry_count = 1 ;
cto - > ct_nphdl = atp - > nphdl ;
cto - > ct_rxid = atp - > tag ;
cto - > ct_iid_lo = atp - > sid ;
cto - > ct_iid_hi = atp - > sid > > 16 ;
cto - > ct_oxid = atp - > oxid ;
cto - > ct_vpidx = XS_CHANNEL ( accb ) ;
cto - > ct_flags = CT7_NOACK | CT7_TERMINATE ;
isp_target_put_entry ( isp , cto ) ;
}
2017-02-22 06:43:49 +00:00
isp_put_atpd ( isp , XS_CHANNEL ( accb ) , atp ) ;
ccb - > ccb_h . status = CAM_REQ_CMP ;
} else {
ccb - > ccb_h . status = CAM_UA_ABORT ;
}
}
static void
isp_abort_inot ( ispsoftc_t * isp , union ccb * ccb )
{
inot_private_data_t * ntp ;
union ccb * accb = ccb - > cab . abort_ccb ;
struct ccb_hdr * sccb ;
tstate_t * tptr ;
tptr = get_lun_statep ( isp , XS_CHANNEL ( accb ) , XS_LUN ( accb ) ) ;
if ( tptr ! = NULL ) {
/* Search for the INOT among queueued. */
SLIST_FOREACH ( sccb , & tptr - > inots , sim_links . sle ) {
if ( sccb ! = & accb - > ccb_h )
continue ;
SLIST_REMOVE ( & tptr - > inots , sccb , ccb_hdr , sim_links . sle ) ;
2017-03-15 19:49:45 +00:00
ISP_PATH_PRT ( isp , ISP_LOGTDEBUG2 , sccb - > path ,
" Abort FREE INOT \n " ) ;
2017-02-22 06:43:49 +00:00
accb - > ccb_h . status = CAM_REQ_ABORTED ;
xpt_done ( accb ) ;
ccb - > ccb_h . status = CAM_REQ_CMP ;
return ;
}
}
/* Search for the INOT among running. */
ntp = isp_find_ntpd ( isp , XS_CHANNEL ( accb ) , accb - > cin1 . tag_id , accb - > cin1 . seq_id ) ;
if ( ntp ! = NULL ) {
2017-03-18 10:34:29 +00:00
if ( ntp - > nt . nt_need_ack ) {
isp_async ( isp , ISPASYNC_TARGET_NOTIFY_ACK ,
ntp - > nt . nt_lreserved ) ;
}
2017-02-22 06:43:49 +00:00
isp_put_ntpd ( isp , XS_CHANNEL ( accb ) , ntp ) ;
ccb - > ccb_h . status = CAM_REQ_CMP ;
} else {
ccb - > ccb_h . status = CAM_UA_ABORT ;
return ;
}
}
# endif
2007-05-05 20:17:23 +00:00
static void
isp_action ( struct cam_sim * sim , union ccb * ccb )
{
2017-03-21 13:10:37 +00:00
int bus , tgt , error ;
2006-04-21 18:30:01 +00:00
ispsoftc_t * isp ;
1998-10-15 23:46:33 +00:00
struct ccb_trans_settings * cts ;
2017-03-21 13:10:37 +00:00
sbintime_t ts ;
1998-09-15 08:42:56 +00:00
CAM_DEBUG ( ccb - > ccb_h . path , CAM_DEBUG_TRACE , ( " isp_action \n " ) ) ;
-----------
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
2006-04-21 18:30:01 +00:00
isp = ( ispsoftc_t * ) cam_sim_softc ( sim ) ;
2017-03-21 10:34:34 +00:00
ISP_ASSERT_LOCKED ( isp ) ;
bus = cam_sim_bus ( sim ) ;
2015-06-24 09:06:12 +00:00
isp_prt ( isp , ISP_LOGDEBUG2 , " isp_action code %x " , ccb - > ccb_h . func_code ) ;
ISP_PCMD ( ccb ) = NULL ;
2009-08-01 01:04:26 +00:00
1998-09-15 08:42:56 +00:00
switch ( ccb - > ccb_h . func_code ) {
case XPT_SCSI_IO : /* Execute the requested I/O operation */
/*
* Do a couple of preliminary checks . . .
*/
if ( ( ccb - > ccb_h . flags & CAM_CDB_POINTER ) ! = 0 ) {
if ( ( ccb - > ccb_h . flags & CAM_CDB_PHYS ) ! = 0 ) {
ccb - > ccb_h . status = CAM_REQ_INVALID ;
2015-06-24 09:06:12 +00:00
isp_done ( ( struct ccb_scsiio * ) ccb ) ;
1998-09-15 08:42:56 +00:00
break ;
}
}
-----------
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 - > csio . req_map = NULL ;
1999-08-16 20:11:45 +00:00
# ifdef DIAGNOSTIC
2015-10-24 17:34:40 +00:00
if ( ccb - > ccb_h . target_id > = ISP_MAX_TARGETS ( isp ) ) {
2006-12-05 07:50:23 +00:00
xpt_print ( ccb - > ccb_h . path , " invalid target \n " ) ;
1999-08-16 20:11:45 +00:00
ccb - > ccb_h . status = CAM_PATH_INVALID ;
2015-10-24 17:34:40 +00:00
} else if ( ISP_MAX_LUNS ( isp ) > 0 & &
ccb - > ccb_h . target_lun > = ISP_MAX_LUNS ( isp ) ) {
2006-12-05 07:50:23 +00:00
xpt_print ( ccb - > ccb_h . path , " invalid lun \n " ) ;
1999-08-16 20:11:45 +00:00
ccb - > ccb_h . status = CAM_PATH_INVALID ;
1998-09-15 08:42:56 +00:00
}
if ( ccb - > ccb_h . status = = CAM_PATH_INVALID ) {
xpt_done ( ccb ) ;
break ;
}
1999-08-16 20:11:45 +00:00
# endif
2007-05-05 20:17:23 +00:00
ccb - > csio . scsi_status = SCSI_STATUS_OK ;
if ( isp_get_pcmd ( isp , ccb ) ) {
isp_prt ( isp , ISP_LOGWARN , " out of PCMDs " ) ;
cam_freeze_devq ( ccb - > ccb_h . path ) ;
2009-08-01 01:04:26 +00:00
cam_release_devq ( ccb - > ccb_h . path , RELSIM_RELEASE_AFTER_TIMEOUT , 0 , 250 , 0 ) ;
2015-06-24 09:06:12 +00:00
ccb - > ccb_h . status = CAM_REQUEUE_REQ ;
2007-05-05 20:17:23 +00:00
xpt_done ( ccb ) ;
break ;
}
2000-08-01 06:31:44 +00:00
error = isp_start ( ( XS_T * ) ccb ) ;
1999-08-16 20:11:45 +00:00
switch ( error ) {
1998-09-15 08:42:56 +00:00
case CMD_QUEUED :
ccb - > ccb_h . status | = CAM_SIM_QUEUED ;
2017-03-21 13:10:37 +00:00
if ( ccb - > ccb_h . timeout = = CAM_TIME_INFINITY )
2007-05-05 20:17:23 +00:00
break ;
2017-03-21 13:10:37 +00:00
/* Give firmware extra 10s to handle timeout. */
ts = SBT_1MS * ccb - > ccb_h . timeout + 10 * SBT_1S ;
callout_reset_sbt ( & PISP_PCMD ( ccb ) - > wdog , ts , 0 ,
isp_watchdog , ccb , 0 ) ;
1998-09-15 08:42:56 +00:00
break ;
1999-08-16 20:11:45 +00:00
case CMD_RQLATER :
2015-10-24 17:34:40 +00:00
isp_prt ( isp , ISP_LOGDEBUG0 , " %d.%jx retry later " ,
XS_TGT ( ccb ) , ( uintmax_t ) XS_LUN ( ccb ) ) ;
2006-11-14 08:45:48 +00:00
cam_freeze_devq ( ccb - > ccb_h . path ) ;
2009-08-01 01:04:26 +00:00
cam_release_devq ( ccb - > ccb_h . path , RELSIM_RELEASE_AFTER_TIMEOUT , 0 , 1000 , 0 ) ;
-----------
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 = CAM_REQUEUE_REQ ;
2007-05-05 20:17:23 +00:00
isp_free_pcmd ( isp , ccb ) ;
1998-09-15 08:42:56 +00:00
xpt_done ( ccb ) ;
break ;
1999-08-16 20:11:45 +00:00
case CMD_EAGAIN :
2007-05-05 20:17:23 +00:00
isp_free_pcmd ( isp , ccb ) ;
2009-08-01 01:04:26 +00:00
cam_freeze_devq ( ccb - > ccb_h . path ) ;
cam_release_devq ( ccb - > ccb_h . path , RELSIM_RELEASE_AFTER_TIMEOUT , 0 , 100 , 0 ) ;
-----------
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 = CAM_REQUEUE_REQ ;
1998-09-15 08:42:56 +00:00
xpt_done ( ccb ) ;
break ;
1999-08-16 20:11:45 +00:00
case CMD_COMPLETE :
isp_done ( ( struct ccb_scsiio * ) ccb ) ;
break ;
default :
2009-08-01 01:04:26 +00:00
isp_prt ( isp , ISP_LOGERR , " What's this? 0x%x at %d in file %s " , error , __LINE__ , __FILE__ ) ;
-----------
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 = CAM_REQUEUE_REQ ;
2007-05-05 20:17:23 +00:00
isp_free_pcmd ( isp , ccb ) ;
1999-08-16 20:11:45 +00:00
xpt_done ( ccb ) ;
1998-09-15 08:42:56 +00:00
}
break ;
2000-01-03 23:55:30 +00:00
# ifdef ISP_TARGET_MODE
2009-08-01 01:04:26 +00:00
case XPT_EN_LUN : /* Enable/Disable LUN as a target */
if ( ccb - > cel . enable ) {
isp_enable_lun ( isp , ccb ) ;
} else {
isp_disable_lun ( isp , ccb ) ;
2004-02-08 19:17:56 +00:00
}
1998-09-15 08:42:56 +00:00
break ;
2009-08-01 01:04:26 +00:00
case XPT_IMMEDIATE_NOTIFY : /* Add Immediate Notify Resource */
2000-01-03 23:55:30 +00:00
case XPT_ACCEPT_TARGET_IO : /* Add Accept Target IO Resource */
{
2009-08-01 01:04:26 +00:00
tstate_t * tptr = get_lun_statep ( isp , XS_CHANNEL ( ccb ) , ccb - > ccb_h . target_lun ) ;
if ( tptr = = NULL ) {
const char * str ;
2017-02-22 06:43:49 +00:00
if ( ccb - > ccb_h . func_code = = XPT_IMMEDIATE_NOTIFY )
2009-08-01 01:04:26 +00:00
str = " XPT_IMMEDIATE_NOTIFY " ;
2017-02-22 06:43:49 +00:00
else
2009-08-01 01:04:26 +00:00
str = " XPT_ACCEPT_TARGET_IO " ;
2017-02-22 06:43:49 +00:00
ISP_PATH_PRT ( isp , ISP_LOGWARN , ccb - > ccb_h . path ,
2017-02-24 12:11:17 +00:00
" %s: no state pointer found for %s \n " ,
2017-02-22 06:43:49 +00:00
__func__ , str ) ;
2009-08-01 01:04:26 +00:00
ccb - > ccb_h . status = CAM_DEV_NOT_THERE ;
2017-02-24 12:11:17 +00:00
xpt_done ( ccb ) ;
2000-01-03 23:55:30 +00:00
break ;
}
-----------
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 . spriv_field0 = 0 ;
ccb - > ccb_h . spriv_ptr1 = isp ;
2002-06-16 05:08:02 +00:00
2000-01-03 23:55:30 +00:00
if ( ccb - > ccb_h . func_code = = XPT_ACCEPT_TARGET_IO ) {
2017-02-22 06:43:49 +00:00
ccb - > atio . tag_id = 0 ;
2009-08-01 01:04:26 +00:00
SLIST_INSERT_HEAD ( & tptr - > atios , & ccb - > ccb_h , sim_links . sle ) ;
2017-02-22 06:43:49 +00:00
ISP_PATH_PRT ( isp , ISP_LOGTDEBUG2 , ccb - > ccb_h . path ,
2017-03-15 19:49:45 +00:00
" Put FREE ATIO \n " ) ;
2009-08-01 01:04:26 +00:00
} else if ( ccb - > ccb_h . func_code = = XPT_IMMEDIATE_NOTIFY ) {
2017-02-22 06:43:49 +00:00
ccb - > cin1 . seq_id = ccb - > cin1 . tag_id = 0 ;
2009-08-01 01:04:26 +00:00
SLIST_INSERT_HEAD ( & tptr - > inots , & ccb - > ccb_h , sim_links . sle ) ;
2017-02-22 06:43:49 +00:00
ISP_PATH_PRT ( isp , ISP_LOGTDEBUG2 , ccb - > ccb_h . path ,
2017-03-15 19:49:45 +00:00
" Put FREE INOT \n " ) ;
2000-01-03 23:55:30 +00:00
}
ccb - > ccb_h . status = CAM_REQ_INPROG ;
break ;
}
2009-08-01 01:04:26 +00:00
case XPT_NOTIFY_ACKNOWLEDGE : /* notify ack */
2000-01-03 23:55:30 +00:00
{
2009-08-01 01:04:26 +00:00
inot_private_data_t * ntp ;
/*
* XXX : Because we cannot guarantee that the path information in the notify acknowledge ccb
* XXX : matches that for the immediate notify , we have to * search * for the notify structure
*/
/*
* All the relevant path information is in the associated immediate notify
*/
ISP_PATH_PRT ( isp , ISP_LOGTDEBUG0 , ccb - > ccb_h . path , " %s: [0x%x] NOTIFY ACKNOWLEDGE for 0x%x seen \n " , __func__ , ccb - > cna2 . tag_id , ccb - > cna2 . seq_id ) ;
2017-02-22 06:43:49 +00:00
ntp = isp_find_ntpd ( isp , XS_CHANNEL ( ccb ) , ccb - > cna2 . tag_id , ccb - > cna2 . seq_id ) ;
2009-08-01 01:04:26 +00:00
if ( ntp = = NULL ) {
ISP_PATH_PRT ( isp , ISP_LOGWARN , ccb - > ccb_h . path , " %s: [0x%x] XPT_NOTIFY_ACKNOWLEDGE of 0x%x cannot find ntp private data \n " , __func__ ,
ccb - > cna2 . tag_id , ccb - > cna2 . seq_id ) ;
ccb - > ccb_h . status = CAM_DEV_NOT_THERE ;
xpt_done ( ccb ) ;
break ;
}
2017-02-22 06:43:49 +00:00
if ( isp_handle_platform_target_notify_ack ( isp , & ntp - > nt ,
2016-05-20 10:26:12 +00:00
( ccb - > ccb_h . flags & CAM_SEND_STATUS ) ? ccb - > cna2 . arg : 0 ) ) {
2009-08-01 01:04:26 +00:00
cam_freeze_devq ( ccb - > ccb_h . path ) ;
cam_release_devq ( ccb - > ccb_h . path , RELSIM_RELEASE_AFTER_TIMEOUT , 0 , 1000 , 0 ) ;
-----------
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 & = ~ CAM_STATUS_MASK ;
ccb - > ccb_h . status | = CAM_REQUEUE_REQ ;
2009-08-01 01:04:26 +00:00
break ;
}
2017-02-22 06:43:49 +00:00
isp_put_ntpd ( isp , XS_CHANNEL ( ccb ) , ntp ) ;
2009-08-01 01:04:26 +00:00
ccb - > ccb_h . status = CAM_REQ_CMP ;
ISP_PATH_PRT ( isp , ISP_LOGTDEBUG0 , ccb - > ccb_h . path , " %s: [0x%x] calling xpt_done for tag 0x%x \n " , __func__ , ccb - > cna2 . tag_id , ccb - > cna2 . seq_id ) ;
xpt_done ( ccb ) ;
2000-01-03 23:55:30 +00:00
break ;
}
2009-08-01 01:04:26 +00:00
case XPT_CONT_TARGET_IO :
-----------
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_target_start_ctio ( isp , ccb , FROM_CAM ) ;
2009-08-01 01:04:26 +00:00
break ;
2000-01-03 23:55:30 +00:00
# endif
1998-09-15 08:42:56 +00:00
case XPT_RESET_DEV : /* BDR the specified SCSI device */
2000-01-03 23:55:30 +00:00
tgt = ccb - > ccb_h . target_id ;
tgt | = ( bus < < 16 ) ;
2009-08-01 01:04:26 +00:00
error = isp_control ( isp , ISPCTL_RESET_DEV , bus , tgt ) ;
1998-09-15 08:42:56 +00:00
if ( error ) {
ccb - > ccb_h . status = CAM_REQ_CMP_ERR ;
} else {
2015-01-21 20:22:53 +00:00
/*
* If we have a FC device , reset the Command
* Reference Number , because the target will expect
* that we re - start the CRN at 1 after a reset .
*/
2015-11-14 19:47:17 +00:00
if ( IS_FC ( isp ) )
isp_fcp_reset_crn ( isp , bus , tgt , /*tgt_set*/ 1 ) ;
2015-01-21 20:22:53 +00:00
1998-09-15 08:42:56 +00:00
ccb - > ccb_h . status = CAM_REQ_CMP ;
}
xpt_done ( ccb ) ;
break ;
2009-08-01 01:04:26 +00:00
case XPT_ABORT : /* Abort the specified CCB */
{
union ccb * accb = ccb - > cab . abort_ccb ;
switch ( accb - > ccb_h . func_code ) {
# ifdef ISP_TARGET_MODE
case XPT_ACCEPT_TARGET_IO :
2017-02-22 06:43:49 +00:00
isp_abort_atio ( isp , ccb ) ;
break ;
case XPT_IMMEDIATE_NOTIFY :
isp_abort_inot ( isp , ccb ) ;
2009-08-01 01:04:26 +00:00
break ;
# endif
case XPT_SCSI_IO :
2014-07-08 13:01:36 +00:00
error = isp_control ( isp , ISPCTL_ABORT_CMD , accb ) ;
2009-08-01 01:04:26 +00:00
if ( error ) {
ccb - > ccb_h . status = CAM_UA_ABORT ;
2006-12-18 23:50:30 +00:00
} else {
2009-08-01 01:04:26 +00:00
ccb - > ccb_h . status = CAM_REQ_CMP ;
2006-12-18 23:50:30 +00:00
}
2009-08-01 01:04:26 +00:00
break ;
default :
ccb - > ccb_h . status = CAM_REQ_INVALID ;
break ;
}
2010-05-25 20:19:45 +00:00
/*
* This is not a queued CCB , so the caller expects it to be
* complete when control is returned .
*/
2009-08-01 01:04:26 +00:00
break ;
}
# define IS_CURRENT_SETTINGS(c) (c->type == CTS_TYPE_CURRENT_SETTINGS)
case XPT_SET_TRAN_SETTINGS : /* Nexus Settings */
cts = & ccb - > cts ;
if ( ! IS_CURRENT_SETTINGS ( cts ) ) {
ccb - > ccb_h . status = CAM_REQ_INVALID ;
xpt_done ( ccb ) ;
break ;
}
tgt = cts - > ccb_h . target_id ;
if ( IS_SCSI ( isp ) ) {
struct ccb_trans_settings_scsi * scsi = & cts - > proto_specific . scsi ;
struct ccb_trans_settings_spi * spi = & cts - > xport_specific . spi ;
sdparam * sdp = SDPARAM ( isp , bus ) ;
2006-02-15 00:31:48 +00:00
uint16_t * dptr ;
2001-07-04 18:54:29 +00:00
2006-12-03 07:22:15 +00:00
if ( spi - > valid = = 0 & & scsi - > valid = = 0 ) {
ccb - > ccb_h . status = CAM_REQ_CMP ;
xpt_done ( ccb ) ;
break ;
}
2009-08-01 01:04:26 +00:00
2001-07-04 18:54:29 +00:00
/*
2001-07-30 01:00:21 +00:00
* We always update ( internally ) from goal_flags
2001-07-04 18:54:29 +00:00
* so any request to change settings just gets
* vectored to that location .
*/
2001-07-30 01:00:21 +00:00
dptr = & sdp - > isp_devparam [ tgt ] . goal_flags ;
2001-07-04 18:54:29 +00:00
if ( ( spi - > valid & CTS_SPI_VALID_DISC ) ! = 0 ) {
if ( ( spi - > flags & CTS_SPI_FLAGS_DISC_ENB ) ! = 0 )
* dptr | = DPARM_DISC ;
else
* dptr & = ~ DPARM_DISC ;
}
if ( ( scsi - > valid & CTS_SCSI_VALID_TQ ) ! = 0 ) {
if ( ( scsi - > flags & CTS_SCSI_FLAGS_TAG_ENB ) ! = 0 )
* dptr | = DPARM_TQING ;
else
* dptr & = ~ DPARM_TQING ;
}
if ( ( spi - > valid & CTS_SPI_VALID_BUS_WIDTH ) ! = 0 ) {
if ( spi - > bus_width = = MSG_EXT_WDTR_BUS_16_BIT )
* dptr | = DPARM_WIDE ;
else
* dptr & = ~ DPARM_WIDE ;
}
/*
* XXX : FIX ME
*/
2009-08-01 01:04:26 +00:00
if ( ( spi - > valid & CTS_SPI_VALID_SYNC_OFFSET ) & & ( spi - > valid & CTS_SPI_VALID_SYNC_RATE ) & & ( spi - > sync_period & & spi - > sync_offset ) ) {
2001-07-04 18:54:29 +00:00
* dptr | = DPARM_SYNC ;
2001-07-30 01:00:21 +00:00
/*
* XXX : CHECK FOR LEGALITY
*/
2009-08-01 01:04:26 +00:00
sdp - > isp_devparam [ tgt ] . goal_period = spi - > sync_period ;
sdp - > isp_devparam [ tgt ] . goal_offset = spi - > sync_offset ;
2001-07-04 18:54:29 +00:00
} else {
* dptr & = ~ DPARM_SYNC ;
}
2013-10-30 14:04:47 +00:00
isp_prt ( isp , ISP_LOGDEBUG0 , " SET (%d.%d.%jx) to flags %x off %x per %x " , bus , tgt , ( uintmax_t ) cts - > ccb_h . target_lun , sdp - > isp_devparam [ tgt ] . goal_flags ,
2009-08-01 01:04:26 +00:00
sdp - > isp_devparam [ tgt ] . goal_offset , sdp - > isp_devparam [ tgt ] . goal_period ) ;
1998-09-15 08:42:56 +00:00
sdp - > isp_devparam [ tgt ] . dev_update = 1 ;
2009-08-01 01:04:26 +00:00
sdp - > update = 1 ;
1998-09-15 08:42:56 +00:00
}
ccb - > ccb_h . status = CAM_REQ_CMP ;
xpt_done ( ccb ) ;
break ;
case XPT_GET_TRAN_SETTINGS :
cts = & ccb - > cts ;
tgt = cts - > ccb_h . target_id ;
1999-10-17 18:50:47 +00:00
if ( IS_FC ( isp ) ) {
2009-08-01 01:04:26 +00:00
fcparam * fcp = FCPARAM ( isp , bus ) ;
struct ccb_trans_settings_scsi * scsi = & cts - > proto_specific . scsi ;
struct ccb_trans_settings_fc * fc = & cts - > xport_specific . fc ;
2001-07-04 18:54:29 +00:00
cts - > protocol = PROTO_SCSI ;
cts - > protocol_version = SCSI_REV_2 ;
cts - > transport = XPORT_FC ;
cts - > transport_version = 0 ;
2006-12-09 01:30:05 +00:00
scsi - > valid = CTS_SCSI_VALID_TQ ;
scsi - > flags = CTS_SCSI_FLAGS_TAG_ENB ;
2001-07-04 18:54:29 +00:00
fc - > valid = CTS_FC_VALID_SPEED ;
2007-08-23 15:57:13 +00:00
fc - > bitrate = 100000 ;
2009-08-01 01:04:26 +00:00
fc - > bitrate * = fcp - > isp_gbspeed ;
2015-07-05 02:09:46 +00:00
if ( tgt < MAX_FC_TARG ) {
fcportdb_t * lp = & fcp - > portdb [ tgt ] ;
2001-07-04 18:54:29 +00:00
fc - > wwnn = lp - > node_wwn ;
fc - > wwpn = lp - > port_wwn ;
fc - > port = lp - > portid ;
2009-08-01 01:04:26 +00:00
fc - > valid | = CTS_FC_VALID_WWNN | CTS_FC_VALID_WWPN | CTS_FC_VALID_PORT ;
2001-07-04 18:54:29 +00:00
}
1998-09-15 08:42:56 +00:00
} else {
2009-08-01 01:04:26 +00:00
struct ccb_trans_settings_scsi * scsi = & cts - > proto_specific . scsi ;
struct ccb_trans_settings_spi * spi = & cts - > xport_specific . spi ;
sdparam * sdp = SDPARAM ( isp , bus ) ;
2006-02-15 00:31:48 +00:00
uint16_t dval , pval , oval ;
1998-09-15 08:42:56 +00:00
2001-07-04 18:54:29 +00:00
if ( IS_CURRENT_SETTINGS ( cts ) ) {
1999-05-12 19:00:16 +00:00
sdp - > isp_devparam [ tgt ] . dev_refresh = 1 ;
2009-08-01 01:04:26 +00:00
sdp - > update = 1 ;
( void ) isp_control ( isp , ISPCTL_UPDATE_PARAMS , bus ) ;
2001-07-30 01:00:21 +00:00
dval = sdp - > isp_devparam [ tgt ] . actv_flags ;
oval = sdp - > isp_devparam [ tgt ] . actv_offset ;
pval = sdp - > isp_devparam [ tgt ] . actv_period ;
1999-03-25 22:52:45 +00:00
} else {
2001-07-30 01:00:21 +00:00
dval = sdp - > isp_devparam [ tgt ] . nvrm_flags ;
oval = sdp - > isp_devparam [ tgt ] . nvrm_offset ;
pval = sdp - > isp_devparam [ tgt ] . nvrm_period ;
1999-03-25 22:52:45 +00:00
}
1998-09-15 08:42:56 +00:00
2001-07-04 18:54:29 +00:00
cts - > protocol = PROTO_SCSI ;
cts - > protocol_version = SCSI_REV_2 ;
cts - > transport = XPORT_SPI ;
cts - > transport_version = 2 ;
2006-12-03 07:22:15 +00:00
spi - > valid = 0 ;
scsi - > valid = 0 ;
spi - > flags = 0 ;
scsi - > flags = 0 ;
2001-07-04 18:54:29 +00:00
if ( dval & DPARM_DISC ) {
spi - > flags | = CTS_SPI_FLAGS_DISC_ENB ;
}
2001-07-30 01:00:21 +00:00
if ( ( dval & DPARM_SYNC ) & & oval & & pval ) {
2001-07-04 18:54:29 +00:00
spi - > sync_offset = oval ;
spi - > sync_period = pval ;
2006-12-03 07:22:15 +00:00
} else {
spi - > sync_offset = 0 ;
spi - > sync_period = 0 ;
2001-07-04 18:54:29 +00:00
}
2006-12-03 07:22:15 +00:00
spi - > valid | = CTS_SPI_VALID_SYNC_OFFSET ;
spi - > valid | = CTS_SPI_VALID_SYNC_RATE ;
2001-07-04 18:54:29 +00:00
spi - > valid | = CTS_SPI_VALID_BUS_WIDTH ;
if ( dval & DPARM_WIDE ) {
spi - > bus_width = MSG_EXT_WDTR_BUS_16_BIT ;
} else {
spi - > bus_width = MSG_EXT_WDTR_BUS_8_BIT ;
}
if ( cts - > ccb_h . target_lun ! = CAM_LUN_WILDCARD ) {
scsi - > valid = CTS_SCSI_VALID_TQ ;
2006-12-03 07:22:15 +00:00
if ( dval & DPARM_TQING ) {
scsi - > flags | = CTS_SCSI_FLAGS_TAG_ENB ;
}
2001-07-04 18:54:29 +00:00
spi - > valid | = CTS_SPI_VALID_DISC ;
}
2013-10-30 14:04:47 +00:00
isp_prt ( isp , ISP_LOGDEBUG0 , " GET %s (%d.%d.%jx) to flags %x off %x per %x " , IS_CURRENT_SETTINGS ( cts ) ? " ACTIVE " : " NVRAM " ,
bus , tgt , ( uintmax_t ) cts - > ccb_h . target_lun , dval , oval , pval ) ;
1998-09-15 08:42:56 +00:00
}
ccb - > ccb_h . status = CAM_REQ_CMP ;
xpt_done ( ccb ) ;
break ;
case XPT_CALC_GEOMETRY :
2009-08-01 01:04:26 +00:00
cam_calc_geometry ( & ccb - > ccg , 1 ) ;
xpt_done ( ccb ) ;
break ;
1998-09-15 08:42:56 +00:00
2009-08-01 01:04:26 +00:00
case XPT_RESET_BUS : /* Reset the specified bus */
error = isp_control ( isp , ISPCTL_RESET_BUS , bus ) ;
if ( error ) {
ccb - > ccb_h . status = CAM_REQ_CMP_ERR ;
1998-09-15 08:42:56 +00:00
xpt_done ( ccb ) ;
break ;
}
2009-08-01 01:04:26 +00:00
if ( bootverbose ) {
xpt_print ( ccb - > ccb_h . path , " reset bus on channel %d \n " , bus ) ;
}
if ( IS_FC ( isp ) ) {
xpt_async ( AC_BUS_RESET , ISP_FC_PC ( isp , bus ) - > path , 0 ) ;
2006-04-21 18:30:01 +00:00
} else {
2009-08-01 01:04:26 +00:00
xpt_async ( AC_BUS_RESET , ISP_SPI_PC ( isp , bus ) - > path , 0 ) ;
2006-04-21 18:30:01 +00:00
}
ccb - > ccb_h . status = CAM_REQ_CMP ;
xpt_done ( ccb ) ;
break ;
2009-08-01 01:04:26 +00:00
case XPT_TERM_IO : /* Terminate the I/O process */
ccb - > ccb_h . status = CAM_REQ_INVALID ;
1998-09-15 08:42:56 +00:00
xpt_done ( ccb ) ;
break ;
2009-08-01 01:04:26 +00:00
case XPT_SET_SIM_KNOB : /* Set SIM knobs */
{
struct ccb_sim_knob * kp = & ccb - > knob ;
fcparam * fcp ;
if ( ! IS_FC ( isp ) ) {
ccb - > ccb_h . status = CAM_REQ_INVALID ;
xpt_done ( ccb ) ;
break ;
}
fcp = FCPARAM ( isp , bus ) ;
if ( kp - > xport_specific . fc . valid & KNOB_VALID_ADDRESS ) {
fcp - > isp_wwnn = ISP_FC_PC ( isp , bus ) - > def_wwnn = kp - > xport_specific . fc . wwnn ;
fcp - > isp_wwpn = ISP_FC_PC ( isp , bus ) - > def_wwpn = kp - > xport_specific . fc . wwpn ;
2011-08-12 19:51:28 +00:00
isp_prt ( isp , ISP_LOGALL , " Setting Channel %d wwns to 0x%jx 0x%jx " , bus , fcp - > isp_wwnn , fcp - > isp_wwpn ) ;
2009-08-01 01:04:26 +00:00
}
ccb - > ccb_h . status = CAM_REQ_CMP ;
if ( kp - > xport_specific . fc . valid & KNOB_VALID_ROLE ) {
int rchange = 0 ;
int newrole = 0 ;
switch ( kp - > xport_specific . fc . role ) {
case KNOB_ROLE_NONE :
if ( fcp - > role ! = ISP_ROLE_NONE ) {
rchange = 1 ;
newrole = ISP_ROLE_NONE ;
}
break ;
case KNOB_ROLE_TARGET :
if ( fcp - > role ! = ISP_ROLE_TARGET ) {
rchange = 1 ;
newrole = ISP_ROLE_TARGET ;
}
break ;
case KNOB_ROLE_INITIATOR :
if ( fcp - > role ! = ISP_ROLE_INITIATOR ) {
rchange = 1 ;
newrole = ISP_ROLE_INITIATOR ;
}
break ;
case KNOB_ROLE_BOTH :
if ( fcp - > role ! = ISP_ROLE_BOTH ) {
rchange = 1 ;
newrole = ISP_ROLE_BOTH ;
}
break ;
}
if ( rchange ) {
2012-06-01 23:29:48 +00:00
ISP_PATH_PRT ( isp , ISP_LOGCONFIG , ccb - > ccb_h . path , " changing role on from %d to %d \n " , fcp - > role , newrole ) ;
2015-07-04 18:38:46 +00:00
if ( isp_control ( isp , ISPCTL_CHANGE_ROLE ,
bus , newrole ) ! = 0 ) {
2009-08-01 01:04:26 +00:00
ccb - > ccb_h . status = CAM_REQ_CMP_ERR ;
-----------
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
xpt_done ( ccb ) ;
break ;
}
2009-08-01 01:04:26 +00:00
}
1999-02-09 01:08:38 +00:00
}
1998-09-15 08:42:56 +00:00
xpt_done ( ccb ) ;
break ;
2009-08-01 01:04:26 +00:00
}
2016-03-10 06:25:05 +00:00
case XPT_GET_SIM_KNOB_OLD : /* Get SIM knobs -- compat value */
2012-06-01 23:29:48 +00:00
case XPT_GET_SIM_KNOB : /* Get SIM knobs */
2009-08-01 01:04:26 +00:00
{
struct ccb_sim_knob * kp = & ccb - > knob ;
1998-09-15 08:42:56 +00:00
2009-08-01 01:04:26 +00:00
if ( IS_FC ( isp ) ) {
fcparam * fcp ;
fcp = FCPARAM ( isp , bus ) ;
kp - > xport_specific . fc . wwnn = fcp - > isp_wwnn ;
kp - > xport_specific . fc . wwpn = fcp - > isp_wwpn ;
switch ( fcp - > role ) {
case ISP_ROLE_NONE :
kp - > xport_specific . fc . role = KNOB_ROLE_NONE ;
break ;
case ISP_ROLE_TARGET :
kp - > xport_specific . fc . role = KNOB_ROLE_TARGET ;
break ;
case ISP_ROLE_INITIATOR :
kp - > xport_specific . fc . role = KNOB_ROLE_INITIATOR ;
break ;
case ISP_ROLE_BOTH :
kp - > xport_specific . fc . role = KNOB_ROLE_BOTH ;
break ;
}
kp - > xport_specific . fc . valid = KNOB_VALID_ADDRESS | KNOB_VALID_ROLE ;
ccb - > ccb_h . status = CAM_REQ_CMP ;
} else {
ccb - > ccb_h . status = CAM_REQ_INVALID ;
}
1998-09-15 08:42:56 +00:00
xpt_done ( ccb ) ;
break ;
2009-08-01 01:04:26 +00:00
}
1998-09-15 08:42:56 +00:00
case XPT_PATH_INQ : /* Path routing inquiry */
{
struct ccb_pathinq * cpi = & ccb - > cpi ;
cpi - > version_num = 1 ;
2000-01-03 23:55:30 +00:00
# ifdef ISP_TARGET_MODE
2015-11-23 10:06:19 +00:00
if ( IS_FC ( isp ) & & ISP_CAP_TMODE ( isp ) & & ISP_CAP_SCCFW ( isp ) )
cpi - > target_sprt = PIT_PROCESSOR | PIT_DISCONNECT | PIT_TERM_IO ;
else
2000-01-03 23:55:30 +00:00
# endif
2015-11-23 10:06:19 +00:00
cpi - > target_sprt = 0 ;
1998-09-15 08:42:56 +00:00
cpi - > hba_eng_cnt = 0 ;
1999-08-16 20:11:45 +00:00
cpi - > max_target = ISP_MAX_TARGETS ( isp ) - 1 ;
2015-10-24 17:34:40 +00:00
cpi - > max_lun = ISP_MAX_LUNS ( isp ) = = 0 ?
255 : ISP_MAX_LUNS ( isp ) - 1 ;
1999-08-16 20:11:45 +00:00
cpi - > bus_id = cam_sim_bus ( sim ) ;
2017-03-24 14:44:03 +00:00
if ( sizeof ( bus_size_t ) > 4 )
2013-08-15 16:41:27 +00:00
cpi - > maxio = ( ISP_NSEG64_MAX - 1 ) * PAGE_SIZE ;
else
cpi - > maxio = ( ISP_NSEG_MAX - 1 ) * PAGE_SIZE ;
1999-03-25 22:52:45 +00:00
if ( IS_FC ( isp ) ) {
2009-08-01 01:04:26 +00:00
fcparam * fcp = FCPARAM ( isp , bus ) ;
2013-06-04 11:05:57 +00:00
cpi - > hba_misc = PIM_NOBUSRESET | PIM_UNMAPPED ;
2017-03-12 14:17:57 +00:00
cpi - > hba_misc | = PIM_EXTLUNS | PIM_NOSCAN ;
2009-08-01 01:04:26 +00:00
1999-08-16 20:11:45 +00:00
/*
* Because our loop ID can shift from time to time ,
* make our initiator ID out of range of our bus .
*/
cpi - > initiator_id = cpi - > max_target + 1 ;
Add a number of interrelated CAM feature enhancements and bug fixes.
NOTE: These changes will require recompilation of any userland
applications, like cdrecord, xmcd, etc., that use the CAM passthrough
interface. A make world is recommended.
camcontrol.[c8]:
- We now support two new commands, "tags" and "negotiate".
- The tags commands allows users to view the number of tagged
openings for a device as well as a number of other related
parameters, and it allows users to set tagged openings for
a device.
- The negotiate command allows users to enable and disable
disconnection and tagged queueing, set sync rates, offsets
and bus width. Note that not all of those features are
available for all controllers. Only the adv, ahc, and ncr
drivers fully support all of the features at this point.
Some cards do not allow the setting of sync rates, offsets and
the like, and some of the drivers don't have any facilities to
do so. Some drivers, like the adw driver, only support enabling
or disabling sync negotiation, but do not support setting sync
rates.
- new description in the camcontrol man page of how to format a disk
- cleanup of the camcontrol inquiry command
- add support in the 'devlist' command for skipping unconfigured devices if
-v was not specified on the command line.
- make use of the new base_transfer_speed in the path inquiry CCB.
- fix CCB bzero cases
cam_xpt.c, cam_sim.[ch], cam_ccb.h:
- new flags on many CCB function codes to designate whether they're
non-immediate, use a user-supplied CCB, and can only be passed from
userland programs via the xpt device. Use these flags in the transport
layer and pass driver to categorize CCBs.
- new flag in the transport layer device matching code for device nodes
that indicates whether a device is unconfigured
- bump the CAM version from 0x10 to 0x11
- Change the CAM ioctls to use the version as their group code, so we can
force users to recompile code even when the CCB size doesn't change.
- add + fill in a new value in the path inquiry CCB, base_transfer_speed.
Remove a corresponding field from the cam_sim structure, and add code to
every SIM to set this field to the proper value.
- Fix the set transfer settings code in the transport layer.
scsi_cd.c:
- make some variables volatile instead of just casting them in various
places
- fix a race condition in the changer code
- attach unless we get a "logical unit not supported" error. This should
fix all of the cases where people have devices that return weird errors
when they don't have media in the drive.
scsi_da.c:
- attach unless we get a "logical unit not supported" error
scsi_pass.c:
- for immediate CCBs, just malloc a CCB to send the user request in. This
gets rid of the 'held' count problem in camcontrol tags.
scsi_pass.h:
- change the CAM ioctls to use the CAM version as their group code.
adv driver:
- Allow changing the sync rate and offset separately.
adw driver
- Allow changing the sync rate and offset separately.
aha driver:
- Don't return CAM_REQ_CMP for SET_TRAN_SETTINGS CCBs.
ahc driver:
- Allow setting offset and sync rate separately
bt driver:
- Don't return CAM_REQ_CMP for SET_TRAN_SETTINGS CCBs.
NCR driver:
- Fix the ultra/ultra 2 negotiation bug
- allow setting both the sync rate and offset separately
Other HBA drivers:
- Put code in to set the base_transfer_speed field for
XPT_GET_TRAN_SETTINGS CCBs.
Reviewed by: gibbs, mjacob (isp), imp (aha)
1999-05-06 20:16:39 +00:00
/*
2009-08-01 01:04:26 +00:00
* Set base transfer capabilities for Fibre Channel , for this HBA .
Add a number of interrelated CAM feature enhancements and bug fixes.
NOTE: These changes will require recompilation of any userland
applications, like cdrecord, xmcd, etc., that use the CAM passthrough
interface. A make world is recommended.
camcontrol.[c8]:
- We now support two new commands, "tags" and "negotiate".
- The tags commands allows users to view the number of tagged
openings for a device as well as a number of other related
parameters, and it allows users to set tagged openings for
a device.
- The negotiate command allows users to enable and disable
disconnection and tagged queueing, set sync rates, offsets
and bus width. Note that not all of those features are
available for all controllers. Only the adv, ahc, and ncr
drivers fully support all of the features at this point.
Some cards do not allow the setting of sync rates, offsets and
the like, and some of the drivers don't have any facilities to
do so. Some drivers, like the adw driver, only support enabling
or disabling sync negotiation, but do not support setting sync
rates.
- new description in the camcontrol man page of how to format a disk
- cleanup of the camcontrol inquiry command
- add support in the 'devlist' command for skipping unconfigured devices if
-v was not specified on the command line.
- make use of the new base_transfer_speed in the path inquiry CCB.
- fix CCB bzero cases
cam_xpt.c, cam_sim.[ch], cam_ccb.h:
- new flags on many CCB function codes to designate whether they're
non-immediate, use a user-supplied CCB, and can only be passed from
userland programs via the xpt device. Use these flags in the transport
layer and pass driver to categorize CCBs.
- new flag in the transport layer device matching code for device nodes
that indicates whether a device is unconfigured
- bump the CAM version from 0x10 to 0x11
- Change the CAM ioctls to use the version as their group code, so we can
force users to recompile code even when the CCB size doesn't change.
- add + fill in a new value in the path inquiry CCB, base_transfer_speed.
Remove a corresponding field from the cam_sim structure, and add code to
every SIM to set this field to the proper value.
- Fix the set transfer settings code in the transport layer.
scsi_cd.c:
- make some variables volatile instead of just casting them in various
places
- fix a race condition in the changer code
- attach unless we get a "logical unit not supported" error. This should
fix all of the cases where people have devices that return weird errors
when they don't have media in the drive.
scsi_da.c:
- attach unless we get a "logical unit not supported" error
scsi_pass.c:
- for immediate CCBs, just malloc a CCB to send the user request in. This
gets rid of the 'held' count problem in camcontrol tags.
scsi_pass.h:
- change the CAM ioctls to use the CAM version as their group code.
adv driver:
- Allow changing the sync rate and offset separately.
adw driver
- Allow changing the sync rate and offset separately.
aha driver:
- Don't return CAM_REQ_CMP for SET_TRAN_SETTINGS CCBs.
ahc driver:
- Allow setting offset and sync rate separately
bt driver:
- Don't return CAM_REQ_CMP for SET_TRAN_SETTINGS CCBs.
NCR driver:
- Fix the ultra/ultra 2 negotiation bug
- allow setting both the sync rate and offset separately
Other HBA drivers:
- Put code in to set the base_transfer_speed field for
XPT_GET_TRAN_SETTINGS CCBs.
Reviewed by: gibbs, mjacob (isp), imp (aha)
1999-05-06 20:16:39 +00:00
*/
2011-08-13 23:34:17 +00:00
if ( IS_25XX ( isp ) ) {
cpi - > base_transfer_speed = 8000000 ;
} else if ( IS_24XX ( isp ) ) {
2009-08-01 01:04:26 +00:00
cpi - > base_transfer_speed = 4000000 ;
} else if ( IS_23XX ( isp ) ) {
cpi - > base_transfer_speed = 2000000 ;
} else {
cpi - > base_transfer_speed = 1000000 ;
}
1999-08-16 20:11:45 +00:00
cpi - > hba_inquiry = PI_TAG_ABLE ;
2001-07-04 18:54:29 +00:00
cpi - > transport = XPORT_FC ;
2006-12-18 23:50:30 +00:00
cpi - > transport_version = 0 ;
2009-08-01 01:04:26 +00:00
cpi - > xport_specific . fc . wwnn = fcp - > isp_wwnn ;
cpi - > xport_specific . fc . wwpn = fcp - > isp_wwpn ;
cpi - > xport_specific . fc . port = fcp - > isp_portid ;
cpi - > xport_specific . fc . bitrate = fcp - > isp_gbspeed * 1000 ;
1998-09-15 08:42:56 +00:00
} else {
2009-08-01 01:04:26 +00:00
sdparam * sdp = SDPARAM ( isp , bus ) ;
1999-08-16 20:11:45 +00:00
cpi - > hba_inquiry = PI_SDTR_ABLE | PI_TAG_ABLE | PI_WIDE_16 ;
2013-06-04 11:05:57 +00:00
cpi - > hba_misc = PIM_UNMAPPED ;
1999-05-11 05:10:06 +00:00
cpi - > initiator_id = sdp - > isp_initiator_id ;
Add a number of interrelated CAM feature enhancements and bug fixes.
NOTE: These changes will require recompilation of any userland
applications, like cdrecord, xmcd, etc., that use the CAM passthrough
interface. A make world is recommended.
camcontrol.[c8]:
- We now support two new commands, "tags" and "negotiate".
- The tags commands allows users to view the number of tagged
openings for a device as well as a number of other related
parameters, and it allows users to set tagged openings for
a device.
- The negotiate command allows users to enable and disable
disconnection and tagged queueing, set sync rates, offsets
and bus width. Note that not all of those features are
available for all controllers. Only the adv, ahc, and ncr
drivers fully support all of the features at this point.
Some cards do not allow the setting of sync rates, offsets and
the like, and some of the drivers don't have any facilities to
do so. Some drivers, like the adw driver, only support enabling
or disabling sync negotiation, but do not support setting sync
rates.
- new description in the camcontrol man page of how to format a disk
- cleanup of the camcontrol inquiry command
- add support in the 'devlist' command for skipping unconfigured devices if
-v was not specified on the command line.
- make use of the new base_transfer_speed in the path inquiry CCB.
- fix CCB bzero cases
cam_xpt.c, cam_sim.[ch], cam_ccb.h:
- new flags on many CCB function codes to designate whether they're
non-immediate, use a user-supplied CCB, and can only be passed from
userland programs via the xpt device. Use these flags in the transport
layer and pass driver to categorize CCBs.
- new flag in the transport layer device matching code for device nodes
that indicates whether a device is unconfigured
- bump the CAM version from 0x10 to 0x11
- Change the CAM ioctls to use the version as their group code, so we can
force users to recompile code even when the CCB size doesn't change.
- add + fill in a new value in the path inquiry CCB, base_transfer_speed.
Remove a corresponding field from the cam_sim structure, and add code to
every SIM to set this field to the proper value.
- Fix the set transfer settings code in the transport layer.
scsi_cd.c:
- make some variables volatile instead of just casting them in various
places
- fix a race condition in the changer code
- attach unless we get a "logical unit not supported" error. This should
fix all of the cases where people have devices that return weird errors
when they don't have media in the drive.
scsi_da.c:
- attach unless we get a "logical unit not supported" error
scsi_pass.c:
- for immediate CCBs, just malloc a CCB to send the user request in. This
gets rid of the 'held' count problem in camcontrol tags.
scsi_pass.h:
- change the CAM ioctls to use the CAM version as their group code.
adv driver:
- Allow changing the sync rate and offset separately.
adw driver
- Allow changing the sync rate and offset separately.
aha driver:
- Don't return CAM_REQ_CMP for SET_TRAN_SETTINGS CCBs.
ahc driver:
- Allow setting offset and sync rate separately
bt driver:
- Don't return CAM_REQ_CMP for SET_TRAN_SETTINGS CCBs.
NCR driver:
- Fix the ultra/ultra 2 negotiation bug
- allow setting both the sync rate and offset separately
Other HBA drivers:
- Put code in to set the base_transfer_speed field for
XPT_GET_TRAN_SETTINGS CCBs.
Reviewed by: gibbs, mjacob (isp), imp (aha)
1999-05-06 20:16:39 +00:00
cpi - > base_transfer_speed = 3300 ;
2001-07-04 18:54:29 +00:00
cpi - > transport = XPORT_SPI ;
2006-12-18 23:50:30 +00:00
cpi - > transport_version = 2 ;
1998-09-15 08:42:56 +00:00
}
2001-07-04 18:54:29 +00:00
cpi - > protocol = PROTO_SCSI ;
cpi - > protocol_version = SCSI_REV_2 ;
Always null-terminate ccb_pathinq.(sim_vid|hba_vid|dev_name)
The sim_vid, hba_vid, and dev_name fields of struct ccb_pathinq are
fixed-length strings. AFAICT the only place they're read is in
sbin/camcontrol/camcontrol.c, which assumes they'll be null-terminated.
However, the kernel doesn't null-terminate them. A bunch of copy-pasted code
uses strncpy to write them, and doesn't guarantee null-termination. For at
least 4 drivers (mpr, mps, ciss, and hyperv), the hba_vid field actually
overflows. You can see the result by doing "camcontrol negotiate da0 -v".
This change null-terminates those fields everywhere they're set in the
kernel. It also shortens a few strings to ensure they'll fit within the
16-character field.
PR: 215474
Reported by: Coverity
CID: 1009997 1010000 1010001 1010002 1010003 1010004 1010005
CID: 1331519 1010006 1215097 1010007 1288967 1010008 1306000
CID: 1211924 1010009 1010010 1010011 1010012 1010013 1010014
CID: 1147190 1010017 1010016 1010018 1216435 1010020 1010021
CID: 1010022 1009666 1018185 1010023 1010025 1010026 1010027
CID: 1010028 1010029 1010030 1010031 1010033 1018186 1018187
CID: 1010035 1010036 1010042 1010041 1010040 1010039
Reviewed by: imp, sephe, slm
MFC after: 4 weeks
Sponsored by: Spectra Logic Corp
Differential Revision: https://reviews.freebsd.org/D9037
Differential Revision: https://reviews.freebsd.org/D9038
2017-01-04 20:26:42 +00:00
strlcpy ( cpi - > sim_vid , " FreeBSD " , SIM_IDLEN ) ;
strlcpy ( cpi - > hba_vid , " Qlogic " , HBA_IDLEN ) ;
strlcpy ( cpi - > dev_name , cam_sim_name ( sim ) , DEV_IDLEN ) ;
1998-09-15 08:42:56 +00:00
cpi - > unit_number = cam_sim_unit ( sim ) ;
cpi - > ccb_h . status = CAM_REQ_CMP ;
xpt_done ( ccb ) ;
break ;
}
default :
ccb - > ccb_h . status = CAM_REQ_INVALID ;
xpt_done ( ccb ) ;
break ;
}
}
1998-12-05 01:31:21 +00:00
void
2009-08-01 01:04:26 +00:00
isp_done ( XS_T * sccb )
1998-12-05 01:31:21 +00:00
{
2006-04-21 18:30:01 +00:00
ispsoftc_t * isp = XS_ISP ( sccb ) ;
2011-08-13 23:34:17 +00:00
uint32_t status ;
1998-12-05 01:31:21 +00:00
if ( XS_NOERR ( sccb ) )
XS_SETERR ( sccb , CAM_REQ_CMP ) ;
Add in the enabling of interrupts (to isp_attach). Clean up a busted
comment. Check against firmware state- not loop state when enabling
target mode. Other changes have to do with no longer enabling/disabling
interrupts at will.
Rearchitect command watchdog timeouts-
First of all, set the timeout period for a command that has a
timeout (in isp_action) to the period of time requested *plus* two
seconds. We don't want the Qlogic firmware and the host system to
race each other to report a dead command (the watchdog is there to
catch dead and/or broken firmware).
Next, make sure that the command being watched isn't done yet. If
it's not done yet, check for INT_PENDING and call isp_intr- if that
said it serviced an interrupt, check to see whether the command is
now done (this is what the "IN WATCHDOG" private flag is for- if
isp_intr completes the command, it won't call xpt_done on it because
isp_watchdog is still looking at the command).
If no interrupt was pending, or the command wasn't completed, check
to see if we've set the private 'grace period' flag. If so, the
command really *is* dead, so report it as dead and complete it with
a CAM_CMD_TIMEOUT value.
If the grace period flag wasn't set, set it and issue a SYNCHRONIZE_ALL
Marker Request Queue entry and re-set the timeout for one second
from now (see Revision 1.45 isp.c notes for more on this) to give
the firmware a final chance to complete this command.
2000-06-27 19:31:02 +00:00
2009-08-01 01:04:26 +00:00
if ( ( sccb - > ccb_h . status & CAM_STATUS_MASK ) = = CAM_REQ_CMP & & ( sccb - > scsi_status ! = SCSI_STATUS_OK ) ) {
1998-12-05 01:31:21 +00:00
sccb - > ccb_h . status & = ~ CAM_STATUS_MASK ;
2009-08-01 01:04:26 +00:00
if ( ( sccb - > scsi_status = = SCSI_STATUS_CHECK_COND ) & & ( sccb - > ccb_h . status & CAM_AUTOSNS_VALID ) = = 0 ) {
2000-01-04 03:45:49 +00:00
sccb - > ccb_h . status | = CAM_AUTOSENSE_FAIL ;
} else {
sccb - > ccb_h . status | = CAM_SCSI_STATUS_ERROR ;
}
1998-12-05 01:31:21 +00:00
}
Add in the enabling of interrupts (to isp_attach). Clean up a busted
comment. Check against firmware state- not loop state when enabling
target mode. Other changes have to do with no longer enabling/disabling
interrupts at will.
Rearchitect command watchdog timeouts-
First of all, set the timeout period for a command that has a
timeout (in isp_action) to the period of time requested *plus* two
seconds. We don't want the Qlogic firmware and the host system to
race each other to report a dead command (the watchdog is there to
catch dead and/or broken firmware).
Next, make sure that the command being watched isn't done yet. If
it's not done yet, check for INT_PENDING and call isp_intr- if that
said it serviced an interrupt, check to see whether the command is
now done (this is what the "IN WATCHDOG" private flag is for- if
isp_intr completes the command, it won't call xpt_done on it because
isp_watchdog is still looking at the command).
If no interrupt was pending, or the command wasn't completed, check
to see if we've set the private 'grace period' flag. If so, the
command really *is* dead, so report it as dead and complete it with
a CAM_CMD_TIMEOUT value.
If the grace period flag wasn't set, set it and issue a SYNCHRONIZE_ALL
Marker Request Queue entry and re-set the timeout for one second
from now (see Revision 1.45 isp.c notes for more on this) to give
the firmware a final chance to complete this command.
2000-06-27 19:31:02 +00:00
1999-08-16 20:11:45 +00:00
sccb - > ccb_h . status & = ~ CAM_SIM_QUEUED ;
2011-08-13 23:34:17 +00:00
status = sccb - > ccb_h . status & CAM_STATUS_MASK ;
2017-03-12 15:36:07 +00:00
if ( status ! = CAM_REQ_CMP & &
( sccb - > ccb_h . status & CAM_DEV_QFRZN ) = = 0 ) {
sccb - > ccb_h . status | = CAM_DEV_QFRZN ;
xpt_freeze_devq ( sccb - > ccb_h . path , 1 ) ;
1998-12-05 01:31:21 +00:00
}
Add in the enabling of interrupts (to isp_attach). Clean up a busted
comment. Check against firmware state- not loop state when enabling
target mode. Other changes have to do with no longer enabling/disabling
interrupts at will.
Rearchitect command watchdog timeouts-
First of all, set the timeout period for a command that has a
timeout (in isp_action) to the period of time requested *plus* two
seconds. We don't want the Qlogic firmware and the host system to
race each other to report a dead command (the watchdog is there to
catch dead and/or broken firmware).
Next, make sure that the command being watched isn't done yet. If
it's not done yet, check for INT_PENDING and call isp_intr- if that
said it serviced an interrupt, check to see whether the command is
now done (this is what the "IN WATCHDOG" private flag is for- if
isp_intr completes the command, it won't call xpt_done on it because
isp_watchdog is still looking at the command).
If no interrupt was pending, or the command wasn't completed, check
to see if we've set the private 'grace period' flag. If so, the
command really *is* dead, so report it as dead and complete it with
a CAM_CMD_TIMEOUT value.
If the grace period flag wasn't set, set it and issue a SYNCHRONIZE_ALL
Marker Request Queue entry and re-set the timeout for one second
from now (see Revision 1.45 isp.c notes for more on this) to give
the firmware a final chance to complete this command.
2000-06-27 19:31:02 +00:00
2015-06-24 09:06:12 +00:00
if ( ISP_PCMD ( sccb ) ) {
if ( callout_active ( & PISP_PCMD ( sccb ) - > wdog ) )
callout_stop ( & PISP_PCMD ( sccb ) - > wdog ) ;
isp_free_pcmd ( isp , ( union ccb * ) sccb ) ;
}
2009-08-01 01:04:26 +00:00
xpt_done ( ( union ccb * ) sccb ) ;
1998-12-05 01:31:21 +00:00
}
2009-08-01 01:04:26 +00:00
void
isp_async ( ispsoftc_t * isp , ispasync_t cmd , . . . )
{
2015-07-13 15:11:05 +00:00
int bus ;
static const char prom [ ] = " Chan %d [%d] WWPN 0x%16jx PortID 0x%06x handle 0x%x %s %s " ;
-----------
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
char buf [ 64 ] ;
2006-11-14 08:45:48 +00:00
char * msg = NULL ;
Correct loop mode CRN resets to adhere to FCP-4 section 4.10
Prior to this change, the CRN (Command Reference Number) is reset on any
firmware LIP, LOOP DOWN, or LOOP RESET event in violation of FCP-4 which
specifies that the CRN should only be reset in response to a LIP Reset
(LIPyx) primitive. FCP-4 also indicates PLOGI/LOGO and PRLI/PRLO ELS
actions as conditions for resetting the CRN for the associated initiator
port.
These violations manifest themselves when the HBA is removed from the
loop, or a target device is removed (especially during an outstanding
command) without power cycling. If the HBA and and the target device
determine upon re-establishing the loop that no PLOGI or PRLI is
required, and the target does not issue a LIPxy to the initiator, the
CRN for the target will have been improperly reset by the isp driver. As
a result, the target port will silently ignore all FCP commands issued
during the device probe (which will time out) preventing the device from
attaching.
This change corrects thie CRN reset behavior in response to loop state
changes, also introduces CRN resets for the above mentioned ELS actions
as encountered through async PDB change events.
This change also adds cleanup of outstanding commands in isp_loop_dead()
that was previously missing.
sys/dev/isp/isp.c
Add the last login state to debug output when syncing the pdb
sys/dev/isp/isp_freebsd.c
Replace binary statement setting aborted ccb status in
isp_watchdog() with the XS_SETERR macro used elsewhere
In isp_loop_dead(), abort or complete pending commands as done
in isp_watchdog()
In isp_async(), segregate the ISPASYNC_LOOP_RESET action from
ISPASYNC_LIP, ISPASYNC_LOOP_DOWN, and ISPASYNC_LOOP_UP
fallthroughs, and only reset the CRN in the RESET case. Also add
checks to handle false LOOP RESET actions that do not have a
proper associated LIP primitive, and log the primitive in the
debug messages
In isp_async(), remove the goto from ISP_ASYNC_DEV_STAYED, and
only reset the CRN in the DEV_CHANGED action
In isp_async(), when processing an ISPASYNC_CHANGE_PDB status,
reset CRN(s) for the associated nphdl (or all ports) if the
change reason is some form of ELS login/logout. Also remove
assignment to fc since it is not used in the scope
sys/dev/isp/ispmbox.h
Add macro definition for the global N-Port handle, and correct a
macro typo 'PDB24XX_AE_PRLI_DONJE'
sys/dev/isp/ispvar.h
Add macros FCP_AL_DA_ALL, FCP_AL_PA, and FCP_IS_DEST_ALPD for
more legible code when determining if an AL_PD port matches the
portid for a given struct fcparam* by value or by virtue of the
AL_PD port being 0xFF
Submitted by: Reid Linnemann
Sponsored by: Spectra Logic
MFC after: 1 week
2017-05-03 13:17:01 +00:00
target_id_t tgt = 0 ;
2006-11-02 03:21:32 +00:00
fcportdb_t * lp ;
2009-12-04 03:34:12 +00:00
struct isp_fc * fc ;
2006-11-02 03:21:32 +00:00
struct cam_path * tmppath ;
2015-07-13 15:11:05 +00:00
struct ac_contract ac ;
struct ac_device_changed * adc ;
2009-08-01 01:04:26 +00:00
va_list ap ;
2006-11-02 03:21:32 +00:00
1999-01-30 07:29:00 +00:00
switch ( cmd ) {
case ISPASYNC_NEW_TGT_PARAMS :
1999-08-16 20:11:45 +00:00
{
2001-07-04 18:54:29 +00:00
struct ccb_trans_settings_scsi * scsi ;
struct ccb_trans_settings_spi * spi ;
1999-08-16 20:11:45 +00:00
int flags , tgt ;
2009-08-01 01:04:26 +00:00
sdparam * sdp ;
2001-07-04 18:54:29 +00:00
struct ccb_trans_settings cts ;
1999-08-16 20:11:45 +00:00
2006-05-22 06:49:49 +00:00
memset ( & cts , 0 , sizeof ( struct ccb_trans_settings ) ) ;
2001-07-04 18:54:29 +00:00
2009-08-01 01:04:26 +00:00
va_start ( ap , cmd ) ;
bus = va_arg ( ap , int ) ;
tgt = va_arg ( ap , int ) ;
va_end ( ap ) ;
sdp = SDPARAM ( isp , bus ) ;
if ( xpt_create_path ( & tmppath , NULL , cam_sim_path ( ISP_SPI_PC ( isp , bus ) - > sim ) , tgt , CAM_LUN_WILDCARD ) ! = CAM_REQ_CMP ) {
isp_prt ( isp , ISP_LOGWARN , " isp_async cannot make temp path for %d.%d " , tgt , bus ) ;
1999-08-16 20:11:45 +00:00
break ;
}
2001-07-30 01:00:21 +00:00
flags = sdp - > isp_devparam [ tgt ] . actv_flags ;
2001-07-04 18:54:29 +00:00
cts . type = CTS_TYPE_CURRENT_SETTINGS ;
cts . protocol = PROTO_SCSI ;
cts . transport = XPORT_SPI ;
scsi = & cts . proto_specific . scsi ;
spi = & cts . xport_specific . spi ;
if ( flags & DPARM_TQING ) {
scsi - > valid | = CTS_SCSI_VALID_TQ ;
scsi - > flags | = CTS_SCSI_FLAGS_TAG_ENB ;
}
1999-08-16 20:11:45 +00:00
if ( flags & DPARM_DISC ) {
2001-07-04 18:54:29 +00:00
spi - > valid | = CTS_SPI_VALID_DISC ;
spi - > flags | = CTS_SPI_FLAGS_DISC_ENB ;
}
spi - > flags | = CTS_SPI_VALID_BUS_WIDTH ;
if ( flags & DPARM_WIDE ) {
spi - > bus_width = MSG_EXT_WDTR_BUS_16_BIT ;
} else {
spi - > bus_width = MSG_EXT_WDTR_BUS_8_BIT ;
}
if ( flags & DPARM_SYNC ) {
spi - > valid | = CTS_SPI_VALID_SYNC_RATE ;
spi - > valid | = CTS_SPI_VALID_SYNC_OFFSET ;
2001-07-30 01:00:21 +00:00
spi - > sync_period = sdp - > isp_devparam [ tgt ] . actv_period ;
spi - > sync_offset = sdp - > isp_devparam [ tgt ] . actv_offset ;
2001-07-04 18:54:29 +00:00
}
2009-08-01 01:04:26 +00:00
isp_prt ( isp , ISP_LOGDEBUG2 , " NEW_TGT_PARAMS bus %d tgt %d period %x offset %x flags %x " , bus , tgt , sdp - > isp_devparam [ tgt ] . actv_period , sdp - > isp_devparam [ tgt ] . actv_offset , flags ) ;
2001-07-04 18:54:29 +00:00
xpt_setup_ccb ( & cts . ccb_h , tmppath , 1 ) ;
xpt_async ( AC_TRANSFER_NEG , tmppath , & cts ) ;
1999-08-16 20:11:45 +00:00
xpt_free_path ( tmppath ) ;
1999-01-30 07:29:00 +00:00
break ;
1999-08-16 20:11:45 +00:00
}
1999-03-17 05:04:39 +00:00
case ISPASYNC_BUS_RESET :
2009-08-01 01:04:26 +00:00
{
va_start ( ap , cmd ) ;
bus = va_arg ( ap , int ) ;
va_end ( ap ) ;
isp_prt ( isp , ISP_LOGINFO , " SCSI bus reset on bus %d detected " , bus ) ;
if ( IS_FC ( isp ) ) {
xpt_async ( AC_BUS_RESET , ISP_FC_PC ( isp , bus ) - > path , NULL ) ;
} else {
xpt_async ( AC_BUS_RESET , ISP_SPI_PC ( isp , bus ) - > path , NULL ) ;
1999-03-17 05:04:39 +00:00
}
break ;
2009-08-01 01:04:26 +00:00
}
Correct loop mode CRN resets to adhere to FCP-4 section 4.10
Prior to this change, the CRN (Command Reference Number) is reset on any
firmware LIP, LOOP DOWN, or LOOP RESET event in violation of FCP-4 which
specifies that the CRN should only be reset in response to a LIP Reset
(LIPyx) primitive. FCP-4 also indicates PLOGI/LOGO and PRLI/PRLO ELS
actions as conditions for resetting the CRN for the associated initiator
port.
These violations manifest themselves when the HBA is removed from the
loop, or a target device is removed (especially during an outstanding
command) without power cycling. If the HBA and and the target device
determine upon re-establishing the loop that no PLOGI or PRLI is
required, and the target does not issue a LIPxy to the initiator, the
CRN for the target will have been improperly reset by the isp driver. As
a result, the target port will silently ignore all FCP commands issued
during the device probe (which will time out) preventing the device from
attaching.
This change corrects thie CRN reset behavior in response to loop state
changes, also introduces CRN resets for the above mentioned ELS actions
as encountered through async PDB change events.
This change also adds cleanup of outstanding commands in isp_loop_dead()
that was previously missing.
sys/dev/isp/isp.c
Add the last login state to debug output when syncing the pdb
sys/dev/isp/isp_freebsd.c
Replace binary statement setting aborted ccb status in
isp_watchdog() with the XS_SETERR macro used elsewhere
In isp_loop_dead(), abort or complete pending commands as done
in isp_watchdog()
In isp_async(), segregate the ISPASYNC_LOOP_RESET action from
ISPASYNC_LIP, ISPASYNC_LOOP_DOWN, and ISPASYNC_LOOP_UP
fallthroughs, and only reset the CRN in the RESET case. Also add
checks to handle false LOOP RESET actions that do not have a
proper associated LIP primitive, and log the primitive in the
debug messages
In isp_async(), remove the goto from ISP_ASYNC_DEV_STAYED, and
only reset the CRN in the DEV_CHANGED action
In isp_async(), when processing an ISPASYNC_CHANGE_PDB status,
reset CRN(s) for the associated nphdl (or all ports) if the
change reason is some form of ELS login/logout. Also remove
assignment to fc since it is not used in the scope
sys/dev/isp/ispmbox.h
Add macro definition for the global N-Port handle, and correct a
macro typo 'PDB24XX_AE_PRLI_DONJE'
sys/dev/isp/ispvar.h
Add macros FCP_AL_DA_ALL, FCP_AL_PA, and FCP_IS_DEST_ALPD for
more legible code when determining if an AL_PD port matches the
portid for a given struct fcparam* by value or by virtue of the
AL_PD port being 0xFF
Submitted by: Reid Linnemann
Sponsored by: Spectra Logic
MFC after: 1 week
2017-05-03 13:17:01 +00:00
case ISPASYNC_LOOP_RESET :
{
uint16_t lipp ;
fcparam * fcp ;
va_start ( ap , cmd ) ;
bus = va_arg ( ap , int ) ;
va_end ( ap ) ;
lipp = ISP_READ ( isp , OUTMAILBOX1 ) ;
fcp = FCPARAM ( isp , bus ) ;
isp_prt ( isp , ISP_LOGINFO , " Chan %d LOOP Reset, LIP primitive %x " , bus , lipp ) ;
/*
* Per FCP - 4 , a Reset LIP should result in a CRN reset . Other
* LIPs and loop up / down events should never reset the CRN . For
* an as of yet unknown reason , 24 xx series cards ( and
* potentially others ) can interrupt with a LIP Reset status
* when no LIP reset came down the wire . Additionally , the LIP
* primitive accompanying this status would not be a valid LIP
* Reset primitive , but some variation of an invalid AL_PA
* LIP . As a result , we have to verify the AL_PD in the LIP
* addresses our port before blindly resetting .
*/
if ( FCP_IS_DEST_ALPD ( fcp , ( lipp & 0x00FF ) ) )
isp_fcp_reset_crn ( isp , bus , /*tgt*/ 0 , /*tgt_set*/ 0 ) ;
isp_loop_changed ( isp , bus ) ;
break ;
}
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
case ISPASYNC_LIP :
2015-10-23 16:54:24 +00:00
if ( msg = = NULL )
2006-11-14 08:45:48 +00:00
msg = " LIP Received " ;
/* FALLTHROUGH */
1999-03-17 05:04:39 +00:00
case ISPASYNC_LOOP_DOWN :
2015-10-23 16:54:24 +00:00
if ( msg = = NULL )
2006-11-14 08:45:48 +00:00
msg = " LOOP Down " ;
Correct loop mode CRN resets to adhere to FCP-4 section 4.10
Prior to this change, the CRN (Command Reference Number) is reset on any
firmware LIP, LOOP DOWN, or LOOP RESET event in violation of FCP-4 which
specifies that the CRN should only be reset in response to a LIP Reset
(LIPyx) primitive. FCP-4 also indicates PLOGI/LOGO and PRLI/PRLO ELS
actions as conditions for resetting the CRN for the associated initiator
port.
These violations manifest themselves when the HBA is removed from the
loop, or a target device is removed (especially during an outstanding
command) without power cycling. If the HBA and and the target device
determine upon re-establishing the loop that no PLOGI or PRLI is
required, and the target does not issue a LIPxy to the initiator, the
CRN for the target will have been improperly reset by the isp driver. As
a result, the target port will silently ignore all FCP commands issued
during the device probe (which will time out) preventing the device from
attaching.
This change corrects thie CRN reset behavior in response to loop state
changes, also introduces CRN resets for the above mentioned ELS actions
as encountered through async PDB change events.
This change also adds cleanup of outstanding commands in isp_loop_dead()
that was previously missing.
sys/dev/isp/isp.c
Add the last login state to debug output when syncing the pdb
sys/dev/isp/isp_freebsd.c
Replace binary statement setting aborted ccb status in
isp_watchdog() with the XS_SETERR macro used elsewhere
In isp_loop_dead(), abort or complete pending commands as done
in isp_watchdog()
In isp_async(), segregate the ISPASYNC_LOOP_RESET action from
ISPASYNC_LIP, ISPASYNC_LOOP_DOWN, and ISPASYNC_LOOP_UP
fallthroughs, and only reset the CRN in the RESET case. Also add
checks to handle false LOOP RESET actions that do not have a
proper associated LIP primitive, and log the primitive in the
debug messages
In isp_async(), remove the goto from ISP_ASYNC_DEV_STAYED, and
only reset the CRN in the DEV_CHANGED action
In isp_async(), when processing an ISPASYNC_CHANGE_PDB status,
reset CRN(s) for the associated nphdl (or all ports) if the
change reason is some form of ELS login/logout. Also remove
assignment to fc since it is not used in the scope
sys/dev/isp/ispmbox.h
Add macro definition for the global N-Port handle, and correct a
macro typo 'PDB24XX_AE_PRLI_DONJE'
sys/dev/isp/ispvar.h
Add macros FCP_AL_DA_ALL, FCP_AL_PA, and FCP_IS_DEST_ALPD for
more legible code when determining if an AL_PD port matches the
portid for a given struct fcparam* by value or by virtue of the
AL_PD port being 0xFF
Submitted by: Reid Linnemann
Sponsored by: Spectra Logic
MFC after: 1 week
2017-05-03 13:17:01 +00:00
/* FALLTHROUGH */
1999-03-17 05:04:39 +00:00
case ISPASYNC_LOOP_UP :
Correct loop mode CRN resets to adhere to FCP-4 section 4.10
Prior to this change, the CRN (Command Reference Number) is reset on any
firmware LIP, LOOP DOWN, or LOOP RESET event in violation of FCP-4 which
specifies that the CRN should only be reset in response to a LIP Reset
(LIPyx) primitive. FCP-4 also indicates PLOGI/LOGO and PRLI/PRLO ELS
actions as conditions for resetting the CRN for the associated initiator
port.
These violations manifest themselves when the HBA is removed from the
loop, or a target device is removed (especially during an outstanding
command) without power cycling. If the HBA and and the target device
determine upon re-establishing the loop that no PLOGI or PRLI is
required, and the target does not issue a LIPxy to the initiator, the
CRN for the target will have been improperly reset by the isp driver. As
a result, the target port will silently ignore all FCP commands issued
during the device probe (which will time out) preventing the device from
attaching.
This change corrects thie CRN reset behavior in response to loop state
changes, also introduces CRN resets for the above mentioned ELS actions
as encountered through async PDB change events.
This change also adds cleanup of outstanding commands in isp_loop_dead()
that was previously missing.
sys/dev/isp/isp.c
Add the last login state to debug output when syncing the pdb
sys/dev/isp/isp_freebsd.c
Replace binary statement setting aborted ccb status in
isp_watchdog() with the XS_SETERR macro used elsewhere
In isp_loop_dead(), abort or complete pending commands as done
in isp_watchdog()
In isp_async(), segregate the ISPASYNC_LOOP_RESET action from
ISPASYNC_LIP, ISPASYNC_LOOP_DOWN, and ISPASYNC_LOOP_UP
fallthroughs, and only reset the CRN in the RESET case. Also add
checks to handle false LOOP RESET actions that do not have a
proper associated LIP primitive, and log the primitive in the
debug messages
In isp_async(), remove the goto from ISP_ASYNC_DEV_STAYED, and
only reset the CRN in the DEV_CHANGED action
In isp_async(), when processing an ISPASYNC_CHANGE_PDB status,
reset CRN(s) for the associated nphdl (or all ports) if the
change reason is some form of ELS login/logout. Also remove
assignment to fc since it is not used in the scope
sys/dev/isp/ispmbox.h
Add macro definition for the global N-Port handle, and correct a
macro typo 'PDB24XX_AE_PRLI_DONJE'
sys/dev/isp/ispvar.h
Add macros FCP_AL_DA_ALL, FCP_AL_PA, and FCP_IS_DEST_ALPD for
more legible code when determining if an AL_PD port matches the
portid for a given struct fcparam* by value or by virtue of the
AL_PD port being 0xFF
Submitted by: Reid Linnemann
Sponsored by: Spectra Logic
MFC after: 1 week
2017-05-03 13:17:01 +00:00
if ( msg = = NULL )
msg = " LOOP Up " ;
2009-08-01 01:04:26 +00:00
va_start ( ap , cmd ) ;
bus = va_arg ( ap , int ) ;
va_end ( ap ) ;
2015-11-26 13:04:58 +00:00
isp_loop_changed ( isp , bus ) ;
Correct loop mode CRN resets to adhere to FCP-4 section 4.10
Prior to this change, the CRN (Command Reference Number) is reset on any
firmware LIP, LOOP DOWN, or LOOP RESET event in violation of FCP-4 which
specifies that the CRN should only be reset in response to a LIP Reset
(LIPyx) primitive. FCP-4 also indicates PLOGI/LOGO and PRLI/PRLO ELS
actions as conditions for resetting the CRN for the associated initiator
port.
These violations manifest themselves when the HBA is removed from the
loop, or a target device is removed (especially during an outstanding
command) without power cycling. If the HBA and and the target device
determine upon re-establishing the loop that no PLOGI or PRLI is
required, and the target does not issue a LIPxy to the initiator, the
CRN for the target will have been improperly reset by the isp driver. As
a result, the target port will silently ignore all FCP commands issued
during the device probe (which will time out) preventing the device from
attaching.
This change corrects thie CRN reset behavior in response to loop state
changes, also introduces CRN resets for the above mentioned ELS actions
as encountered through async PDB change events.
This change also adds cleanup of outstanding commands in isp_loop_dead()
that was previously missing.
sys/dev/isp/isp.c
Add the last login state to debug output when syncing the pdb
sys/dev/isp/isp_freebsd.c
Replace binary statement setting aborted ccb status in
isp_watchdog() with the XS_SETERR macro used elsewhere
In isp_loop_dead(), abort or complete pending commands as done
in isp_watchdog()
In isp_async(), segregate the ISPASYNC_LOOP_RESET action from
ISPASYNC_LIP, ISPASYNC_LOOP_DOWN, and ISPASYNC_LOOP_UP
fallthroughs, and only reset the CRN in the RESET case. Also add
checks to handle false LOOP RESET actions that do not have a
proper associated LIP primitive, and log the primitive in the
debug messages
In isp_async(), remove the goto from ISP_ASYNC_DEV_STAYED, and
only reset the CRN in the DEV_CHANGED action
In isp_async(), when processing an ISPASYNC_CHANGE_PDB status,
reset CRN(s) for the associated nphdl (or all ports) if the
change reason is some form of ELS login/logout. Also remove
assignment to fc since it is not used in the scope
sys/dev/isp/ispmbox.h
Add macro definition for the global N-Port handle, and correct a
macro typo 'PDB24XX_AE_PRLI_DONJE'
sys/dev/isp/ispvar.h
Add macros FCP_AL_DA_ALL, FCP_AL_PA, and FCP_IS_DEST_ALPD for
more legible code when determining if an AL_PD port matches the
portid for a given struct fcparam* by value or by virtue of the
AL_PD port being 0xFF
Submitted by: Reid Linnemann
Sponsored by: Spectra Logic
MFC after: 1 week
2017-05-03 13:17:01 +00:00
isp_prt ( isp , ISP_LOGINFO , " Chan %d %s " , bus , msg ) ;
1999-03-17 05:04:39 +00:00
break ;
2006-11-02 03:21:32 +00:00
case ISPASYNC_DEV_ARRIVED :
2009-08-01 01:04:26 +00:00
va_start ( ap , cmd ) ;
bus = va_arg ( ap , int ) ;
lp = va_arg ( ap , fcportdb_t * ) ;
va_end ( ap ) ;
2009-12-04 03:34:12 +00:00
fc = ISP_FC_PC ( isp , bus ) ;
2015-07-13 15:11:05 +00:00
tgt = FC_PORTDB_TGT ( isp , bus , lp ) ;
-----------
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_gen_role_str ( buf , sizeof ( buf ) , lp - > prli_word3 ) ;
2015-07-13 15:11:05 +00:00
isp_prt ( isp , ISP_LOGCONFIG , prom , bus , tgt , lp - > port_wwn , lp - > portid , lp - > handle , buf , " arrived " ) ;
if ( ( FCPARAM ( isp , bus ) - > role & ISP_ROLE_INITIATOR ) & &
( lp - > prli_word3 & PRLI_WD3_TARGET_FUNCTION ) ) {
lp - > is_target = 1 ;
2015-11-14 19:47:17 +00:00
isp_fcp_reset_crn ( isp , bus , tgt , /*tgt_set*/ 1 ) ;
Close a race in the isp(4) driver that caused devices to disappear
and not automatically come back if they were gone for a short
period of time.
The isp(4) driver has a 30 second gone device timer that gets
activated whenever a device goes away. If the device comes back
before the timer expires, we don't send a notification to CAM that
it has gone away. If, however, there is a command sent to the
device while it is gone and before it comes back, the isp(4) driver
sends the command back with CAM_SEL_TIMEOUT status.
CAM responds to the CAM_SEL_TIMEOUT status by removing the device.
In the case where a device comes back within the 30 second gone
device timer window, though, we weren't telling CAM the device
came back.
So, fix this by tracking whether we have told CAM the device is
gone, and if we have, send a rescan if it comes back within the 30
second window.
ispvar.h:
In the fcportdb_t structure, add a new bitfield,
reported_gone. This gets set whenever we return a command
with CAM_SEL_TIMEOUT status on a Fibre Channel device.
isp_freebsd.c:
In isp_done(), if we're sending CAM_SEL_TIMEOUT for for a
command sent to a FC device, set the reported_gone bit.
In isp_async(), in the ISPASYNC_DEV_STAYED case, rescan the
device in question if it is mapped to a target ID and has
been reported gone.
In isp_make_here(), take a port database entry argument,
and clear the reported_gone bit when we send a rescan to
CAM.
In isp_make_gone(), take a port database entry as an
argument, and set the reported_gone bit when we send an
async event telling CAM consumers that the device is gone.
Sponsored by: Spectra Logic
MFC after: 1 week
2015-01-08 17:51:12 +00:00
isp_make_here ( isp , lp , bus , tgt ) ;
2015-07-13 15:11:05 +00:00
}
if ( ( FCPARAM ( isp , bus ) - > role & ISP_ROLE_TARGET ) & &
( lp - > prli_word3 & PRLI_WD3_INITIATOR_FUNCTION ) ) {
lp - > is_initiator = 1 ;
ac . contract_number = AC_CONTRACT_DEV_CHG ;
adc = ( struct ac_device_changed * ) ac . contract_data ;
adc - > wwpn = lp - > port_wwn ;
adc - > port = lp - > portid ;
2015-07-13 21:01:24 +00:00
adc - > target = tgt ;
2015-07-13 15:11:05 +00:00
adc - > arrived = 1 ;
xpt_async ( AC_CONTRACT , fc - > path , & ac ) ;
2006-11-02 03:21:32 +00:00
}
break ;
case ISPASYNC_DEV_CHANGED :
Correct loop mode CRN resets to adhere to FCP-4 section 4.10
Prior to this change, the CRN (Command Reference Number) is reset on any
firmware LIP, LOOP DOWN, or LOOP RESET event in violation of FCP-4 which
specifies that the CRN should only be reset in response to a LIP Reset
(LIPyx) primitive. FCP-4 also indicates PLOGI/LOGO and PRLI/PRLO ELS
actions as conditions for resetting the CRN for the associated initiator
port.
These violations manifest themselves when the HBA is removed from the
loop, or a target device is removed (especially during an outstanding
command) without power cycling. If the HBA and and the target device
determine upon re-establishing the loop that no PLOGI or PRLI is
required, and the target does not issue a LIPxy to the initiator, the
CRN for the target will have been improperly reset by the isp driver. As
a result, the target port will silently ignore all FCP commands issued
during the device probe (which will time out) preventing the device from
attaching.
This change corrects thie CRN reset behavior in response to loop state
changes, also introduces CRN resets for the above mentioned ELS actions
as encountered through async PDB change events.
This change also adds cleanup of outstanding commands in isp_loop_dead()
that was previously missing.
sys/dev/isp/isp.c
Add the last login state to debug output when syncing the pdb
sys/dev/isp/isp_freebsd.c
Replace binary statement setting aborted ccb status in
isp_watchdog() with the XS_SETERR macro used elsewhere
In isp_loop_dead(), abort or complete pending commands as done
in isp_watchdog()
In isp_async(), segregate the ISPASYNC_LOOP_RESET action from
ISPASYNC_LIP, ISPASYNC_LOOP_DOWN, and ISPASYNC_LOOP_UP
fallthroughs, and only reset the CRN in the RESET case. Also add
checks to handle false LOOP RESET actions that do not have a
proper associated LIP primitive, and log the primitive in the
debug messages
In isp_async(), remove the goto from ISP_ASYNC_DEV_STAYED, and
only reset the CRN in the DEV_CHANGED action
In isp_async(), when processing an ISPASYNC_CHANGE_PDB status,
reset CRN(s) for the associated nphdl (or all ports) if the
change reason is some form of ELS login/logout. Also remove
assignment to fc since it is not used in the scope
sys/dev/isp/ispmbox.h
Add macro definition for the global N-Port handle, and correct a
macro typo 'PDB24XX_AE_PRLI_DONJE'
sys/dev/isp/ispvar.h
Add macros FCP_AL_DA_ALL, FCP_AL_PA, and FCP_IS_DEST_ALPD for
more legible code when determining if an AL_PD port matches the
portid for a given struct fcparam* by value or by virtue of the
AL_PD port being 0xFF
Submitted by: Reid Linnemann
Sponsored by: Spectra Logic
MFC after: 1 week
2017-05-03 13:17:01 +00:00
case ISPASYNC_DEV_STAYED :
2009-08-01 01:04:26 +00:00
va_start ( ap , cmd ) ;
bus = va_arg ( ap , int ) ;
lp = va_arg ( ap , fcportdb_t * ) ;
va_end ( ap ) ;
2009-12-04 03:34:12 +00:00
fc = ISP_FC_PC ( isp , bus ) ;
2015-07-13 15:11:05 +00:00
tgt = FC_PORTDB_TGT ( isp , bus , lp ) ;
isp_gen_role_str ( buf , sizeof ( buf ) , lp - > new_prli_word3 ) ;
Correct loop mode CRN resets to adhere to FCP-4 section 4.10
Prior to this change, the CRN (Command Reference Number) is reset on any
firmware LIP, LOOP DOWN, or LOOP RESET event in violation of FCP-4 which
specifies that the CRN should only be reset in response to a LIP Reset
(LIPyx) primitive. FCP-4 also indicates PLOGI/LOGO and PRLI/PRLO ELS
actions as conditions for resetting the CRN for the associated initiator
port.
These violations manifest themselves when the HBA is removed from the
loop, or a target device is removed (especially during an outstanding
command) without power cycling. If the HBA and and the target device
determine upon re-establishing the loop that no PLOGI or PRLI is
required, and the target does not issue a LIPxy to the initiator, the
CRN for the target will have been improperly reset by the isp driver. As
a result, the target port will silently ignore all FCP commands issued
during the device probe (which will time out) preventing the device from
attaching.
This change corrects thie CRN reset behavior in response to loop state
changes, also introduces CRN resets for the above mentioned ELS actions
as encountered through async PDB change events.
This change also adds cleanup of outstanding commands in isp_loop_dead()
that was previously missing.
sys/dev/isp/isp.c
Add the last login state to debug output when syncing the pdb
sys/dev/isp/isp_freebsd.c
Replace binary statement setting aborted ccb status in
isp_watchdog() with the XS_SETERR macro used elsewhere
In isp_loop_dead(), abort or complete pending commands as done
in isp_watchdog()
In isp_async(), segregate the ISPASYNC_LOOP_RESET action from
ISPASYNC_LIP, ISPASYNC_LOOP_DOWN, and ISPASYNC_LOOP_UP
fallthroughs, and only reset the CRN in the RESET case. Also add
checks to handle false LOOP RESET actions that do not have a
proper associated LIP primitive, and log the primitive in the
debug messages
In isp_async(), remove the goto from ISP_ASYNC_DEV_STAYED, and
only reset the CRN in the DEV_CHANGED action
In isp_async(), when processing an ISPASYNC_CHANGE_PDB status,
reset CRN(s) for the associated nphdl (or all ports) if the
change reason is some form of ELS login/logout. Also remove
assignment to fc since it is not used in the scope
sys/dev/isp/ispmbox.h
Add macro definition for the global N-Port handle, and correct a
macro typo 'PDB24XX_AE_PRLI_DONJE'
sys/dev/isp/ispvar.h
Add macros FCP_AL_DA_ALL, FCP_AL_PA, and FCP_IS_DEST_ALPD for
more legible code when determining if an AL_PD port matches the
portid for a given struct fcparam* by value or by virtue of the
AL_PD port being 0xFF
Submitted by: Reid Linnemann
Sponsored by: Spectra Logic
MFC after: 1 week
2017-05-03 13:17:01 +00:00
if ( cmd = = ISPASYNC_DEV_CHANGED )
isp_prt ( isp , ISP_LOGCONFIG , prom , bus , tgt , lp - > port_wwn , lp - > new_portid , lp - > handle , buf , " changed " ) ;
else
isp_prt ( isp , ISP_LOGCONFIG , prom , bus , tgt , lp - > port_wwn , lp - > portid , lp - > handle , buf , " stayed " ) ;
2015-07-13 15:11:05 +00:00
if ( lp - > is_target ! =
( ( FCPARAM ( isp , bus ) - > role & ISP_ROLE_INITIATOR ) & &
( lp - > new_prli_word3 & PRLI_WD3_TARGET_FUNCTION ) ) ) {
lp - > is_target = ! lp - > is_target ;
if ( lp - > is_target ) {
Correct loop mode CRN resets to adhere to FCP-4 section 4.10
Prior to this change, the CRN (Command Reference Number) is reset on any
firmware LIP, LOOP DOWN, or LOOP RESET event in violation of FCP-4 which
specifies that the CRN should only be reset in response to a LIP Reset
(LIPyx) primitive. FCP-4 also indicates PLOGI/LOGO and PRLI/PRLO ELS
actions as conditions for resetting the CRN for the associated initiator
port.
These violations manifest themselves when the HBA is removed from the
loop, or a target device is removed (especially during an outstanding
command) without power cycling. If the HBA and and the target device
determine upon re-establishing the loop that no PLOGI or PRLI is
required, and the target does not issue a LIPxy to the initiator, the
CRN for the target will have been improperly reset by the isp driver. As
a result, the target port will silently ignore all FCP commands issued
during the device probe (which will time out) preventing the device from
attaching.
This change corrects thie CRN reset behavior in response to loop state
changes, also introduces CRN resets for the above mentioned ELS actions
as encountered through async PDB change events.
This change also adds cleanup of outstanding commands in isp_loop_dead()
that was previously missing.
sys/dev/isp/isp.c
Add the last login state to debug output when syncing the pdb
sys/dev/isp/isp_freebsd.c
Replace binary statement setting aborted ccb status in
isp_watchdog() with the XS_SETERR macro used elsewhere
In isp_loop_dead(), abort or complete pending commands as done
in isp_watchdog()
In isp_async(), segregate the ISPASYNC_LOOP_RESET action from
ISPASYNC_LIP, ISPASYNC_LOOP_DOWN, and ISPASYNC_LOOP_UP
fallthroughs, and only reset the CRN in the RESET case. Also add
checks to handle false LOOP RESET actions that do not have a
proper associated LIP primitive, and log the primitive in the
debug messages
In isp_async(), remove the goto from ISP_ASYNC_DEV_STAYED, and
only reset the CRN in the DEV_CHANGED action
In isp_async(), when processing an ISPASYNC_CHANGE_PDB status,
reset CRN(s) for the associated nphdl (or all ports) if the
change reason is some form of ELS login/logout. Also remove
assignment to fc since it is not used in the scope
sys/dev/isp/ispmbox.h
Add macro definition for the global N-Port handle, and correct a
macro typo 'PDB24XX_AE_PRLI_DONJE'
sys/dev/isp/ispvar.h
Add macros FCP_AL_DA_ALL, FCP_AL_PA, and FCP_IS_DEST_ALPD for
more legible code when determining if an AL_PD port matches the
portid for a given struct fcparam* by value or by virtue of the
AL_PD port being 0xFF
Submitted by: Reid Linnemann
Sponsored by: Spectra Logic
MFC after: 1 week
2017-05-03 13:17:01 +00:00
if ( cmd = = ISPASYNC_DEV_CHANGED )
isp_fcp_reset_crn ( isp , bus , tgt , /*tgt_set*/ 1 ) ;
2015-07-13 15:11:05 +00:00
isp_make_here ( isp , lp , bus , tgt ) ;
2006-11-14 08:45:48 +00:00
} else {
2015-07-13 15:11:05 +00:00
isp_make_gone ( isp , lp , bus , tgt ) ;
Correct loop mode CRN resets to adhere to FCP-4 section 4.10
Prior to this change, the CRN (Command Reference Number) is reset on any
firmware LIP, LOOP DOWN, or LOOP RESET event in violation of FCP-4 which
specifies that the CRN should only be reset in response to a LIP Reset
(LIPyx) primitive. FCP-4 also indicates PLOGI/LOGO and PRLI/PRLO ELS
actions as conditions for resetting the CRN for the associated initiator
port.
These violations manifest themselves when the HBA is removed from the
loop, or a target device is removed (especially during an outstanding
command) without power cycling. If the HBA and and the target device
determine upon re-establishing the loop that no PLOGI or PRLI is
required, and the target does not issue a LIPxy to the initiator, the
CRN for the target will have been improperly reset by the isp driver. As
a result, the target port will silently ignore all FCP commands issued
during the device probe (which will time out) preventing the device from
attaching.
This change corrects thie CRN reset behavior in response to loop state
changes, also introduces CRN resets for the above mentioned ELS actions
as encountered through async PDB change events.
This change also adds cleanup of outstanding commands in isp_loop_dead()
that was previously missing.
sys/dev/isp/isp.c
Add the last login state to debug output when syncing the pdb
sys/dev/isp/isp_freebsd.c
Replace binary statement setting aborted ccb status in
isp_watchdog() with the XS_SETERR macro used elsewhere
In isp_loop_dead(), abort or complete pending commands as done
in isp_watchdog()
In isp_async(), segregate the ISPASYNC_LOOP_RESET action from
ISPASYNC_LIP, ISPASYNC_LOOP_DOWN, and ISPASYNC_LOOP_UP
fallthroughs, and only reset the CRN in the RESET case. Also add
checks to handle false LOOP RESET actions that do not have a
proper associated LIP primitive, and log the primitive in the
debug messages
In isp_async(), remove the goto from ISP_ASYNC_DEV_STAYED, and
only reset the CRN in the DEV_CHANGED action
In isp_async(), when processing an ISPASYNC_CHANGE_PDB status,
reset CRN(s) for the associated nphdl (or all ports) if the
change reason is some form of ELS login/logout. Also remove
assignment to fc since it is not used in the scope
sys/dev/isp/ispmbox.h
Add macro definition for the global N-Port handle, and correct a
macro typo 'PDB24XX_AE_PRLI_DONJE'
sys/dev/isp/ispvar.h
Add macros FCP_AL_DA_ALL, FCP_AL_PA, and FCP_IS_DEST_ALPD for
more legible code when determining if an AL_PD port matches the
portid for a given struct fcparam* by value or by virtue of the
AL_PD port being 0xFF
Submitted by: Reid Linnemann
Sponsored by: Spectra Logic
MFC after: 1 week
2017-05-03 13:17:01 +00:00
if ( cmd = = ISPASYNC_DEV_CHANGED )
isp_fcp_reset_crn ( isp , bus , tgt , /*tgt_set*/ 1 ) ;
2006-11-14 08:45:48 +00:00
}
2006-11-02 03:21:32 +00:00
}
2015-07-13 15:11:05 +00:00
if ( lp - > is_initiator ! =
( ( FCPARAM ( isp , bus ) - > role & ISP_ROLE_TARGET ) & &
( lp - > new_prli_word3 & PRLI_WD3_INITIATOR_FUNCTION ) ) ) {
lp - > is_initiator = ! lp - > is_initiator ;
ac . contract_number = AC_CONTRACT_DEV_CHG ;
adc = ( struct ac_device_changed * ) ac . contract_data ;
adc - > wwpn = lp - > port_wwn ;
adc - > port = lp - > portid ;
2015-07-13 21:01:24 +00:00
adc - > target = tgt ;
2015-07-13 15:11:05 +00:00
adc - > arrived = lp - > is_initiator ;
xpt_async ( AC_CONTRACT , fc - > path , & ac ) ;
}
2006-11-02 03:21:32 +00:00
break ;
case ISPASYNC_DEV_GONE :
2009-08-01 01:04:26 +00:00
va_start ( ap , cmd ) ;
bus = va_arg ( ap , int ) ;
lp = va_arg ( ap , fcportdb_t * ) ;
va_end ( ap ) ;
2009-12-04 03:34:12 +00:00
fc = ISP_FC_PC ( isp , bus ) ;
2015-07-13 15:11:05 +00:00
tgt = FC_PORTDB_TGT ( isp , bus , lp ) ;
2006-11-14 08:45:48 +00:00
/*
2015-07-13 15:11:05 +00:00
* If this has a virtual target or initiator set the isp_gdt
* timer running on it to delay its departure .
2006-11-14 08:45:48 +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
isp_gen_role_str ( buf , sizeof ( buf ) , lp - > prli_word3 ) ;
2015-07-13 15:11:05 +00:00
if ( lp - > is_target | | lp - > is_initiator ) {
2006-11-14 08:45:48 +00:00
lp - > state = FC_PORTDB_STATE_ZOMBIE ;
2015-07-13 15:11:05 +00:00
lp - > gone_timer = fc - > gone_device_time ;
isp_prt ( isp , ISP_LOGCONFIG , prom , bus , tgt , lp - > port_wwn , lp - > portid , lp - > handle , buf , " gone zombie " ) ;
2009-12-04 03:34:12 +00:00
if ( fc - > ready & & ! callout_active ( & fc - > gdt ) ) {
-----------
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_prt ( isp , ISP_LOG_SANCFG | ISP_LOGDEBUG0 , " Chan %d Starting Gone Device Timer with %u seconds time now %lu " , bus , lp - > gone_timer , ( unsigned long ) time_uptime ) ;
2009-12-04 03:34:12 +00:00
callout_reset ( & fc - > gdt , hz , isp_gdt , fc ) ;
2009-08-01 01:04:26 +00:00
}
2015-07-13 15:11:05 +00:00
break ;
2006-11-02 03:21:32 +00:00
}
2015-07-13 15:11:05 +00:00
isp_prt ( isp , ISP_LOGCONFIG , prom , bus , tgt , lp - > port_wwn , lp - > portid , lp - > handle , buf , " gone " ) ;
1999-03-17 05:04:39 +00:00
break ;
case ISPASYNC_CHANGE_NOTIFY :
2006-11-02 03:21:32 +00:00
{
char * msg ;
2015-11-19 17:43:47 +00:00
int evt , nphdl , nlstate , portid , reason ;
2009-08-01 01:04:26 +00:00
va_start ( ap , cmd ) ;
bus = va_arg ( ap , int ) ;
evt = va_arg ( ap , int ) ;
2015-11-19 17:43:47 +00:00
if ( evt = = ISPASYNC_CHANGE_PDB ) {
2009-08-01 01:04:26 +00:00
nphdl = va_arg ( ap , int ) ;
nlstate = va_arg ( ap , int ) ;
reason = va_arg ( ap , int ) ;
2015-11-19 17:43:47 +00:00
} else if ( evt = = ISPASYNC_CHANGE_SNS ) {
portid = va_arg ( ap , int ) ;
2009-08-01 01:04:26 +00:00
} else {
nphdl = NIL_HANDLE ;
nlstate = reason = 0 ;
}
va_end ( ap ) ;
if ( evt = = ISPASYNC_CHANGE_PDB ) {
Correct loop mode CRN resets to adhere to FCP-4 section 4.10
Prior to this change, the CRN (Command Reference Number) is reset on any
firmware LIP, LOOP DOWN, or LOOP RESET event in violation of FCP-4 which
specifies that the CRN should only be reset in response to a LIP Reset
(LIPyx) primitive. FCP-4 also indicates PLOGI/LOGO and PRLI/PRLO ELS
actions as conditions for resetting the CRN for the associated initiator
port.
These violations manifest themselves when the HBA is removed from the
loop, or a target device is removed (especially during an outstanding
command) without power cycling. If the HBA and and the target device
determine upon re-establishing the loop that no PLOGI or PRLI is
required, and the target does not issue a LIPxy to the initiator, the
CRN for the target will have been improperly reset by the isp driver. As
a result, the target port will silently ignore all FCP commands issued
during the device probe (which will time out) preventing the device from
attaching.
This change corrects thie CRN reset behavior in response to loop state
changes, also introduces CRN resets for the above mentioned ELS actions
as encountered through async PDB change events.
This change also adds cleanup of outstanding commands in isp_loop_dead()
that was previously missing.
sys/dev/isp/isp.c
Add the last login state to debug output when syncing the pdb
sys/dev/isp/isp_freebsd.c
Replace binary statement setting aborted ccb status in
isp_watchdog() with the XS_SETERR macro used elsewhere
In isp_loop_dead(), abort or complete pending commands as done
in isp_watchdog()
In isp_async(), segregate the ISPASYNC_LOOP_RESET action from
ISPASYNC_LIP, ISPASYNC_LOOP_DOWN, and ISPASYNC_LOOP_UP
fallthroughs, and only reset the CRN in the RESET case. Also add
checks to handle false LOOP RESET actions that do not have a
proper associated LIP primitive, and log the primitive in the
debug messages
In isp_async(), remove the goto from ISP_ASYNC_DEV_STAYED, and
only reset the CRN in the DEV_CHANGED action
In isp_async(), when processing an ISPASYNC_CHANGE_PDB status,
reset CRN(s) for the associated nphdl (or all ports) if the
change reason is some form of ELS login/logout. Also remove
assignment to fc since it is not used in the scope
sys/dev/isp/ispmbox.h
Add macro definition for the global N-Port handle, and correct a
macro typo 'PDB24XX_AE_PRLI_DONJE'
sys/dev/isp/ispvar.h
Add macros FCP_AL_DA_ALL, FCP_AL_PA, and FCP_IS_DEST_ALPD for
more legible code when determining if an AL_PD port matches the
portid for a given struct fcparam* by value or by virtue of the
AL_PD port being 0xFF
Submitted by: Reid Linnemann
Sponsored by: Spectra Logic
MFC after: 1 week
2017-05-03 13:17:01 +00:00
int tgt_set = 0 ;
2015-10-25 14:34:07 +00:00
msg = " Port Database Changed " ;
2015-11-19 17:43:47 +00:00
isp_prt ( isp , ISP_LOGINFO ,
" Chan %d %s (nphdl 0x%x state 0x%x reason 0x%x) " ,
bus , msg , nphdl , nlstate , reason ) ;
Correct loop mode CRN resets to adhere to FCP-4 section 4.10
Prior to this change, the CRN (Command Reference Number) is reset on any
firmware LIP, LOOP DOWN, or LOOP RESET event in violation of FCP-4 which
specifies that the CRN should only be reset in response to a LIP Reset
(LIPyx) primitive. FCP-4 also indicates PLOGI/LOGO and PRLI/PRLO ELS
actions as conditions for resetting the CRN for the associated initiator
port.
These violations manifest themselves when the HBA is removed from the
loop, or a target device is removed (especially during an outstanding
command) without power cycling. If the HBA and and the target device
determine upon re-establishing the loop that no PLOGI or PRLI is
required, and the target does not issue a LIPxy to the initiator, the
CRN for the target will have been improperly reset by the isp driver. As
a result, the target port will silently ignore all FCP commands issued
during the device probe (which will time out) preventing the device from
attaching.
This change corrects thie CRN reset behavior in response to loop state
changes, also introduces CRN resets for the above mentioned ELS actions
as encountered through async PDB change events.
This change also adds cleanup of outstanding commands in isp_loop_dead()
that was previously missing.
sys/dev/isp/isp.c
Add the last login state to debug output when syncing the pdb
sys/dev/isp/isp_freebsd.c
Replace binary statement setting aborted ccb status in
isp_watchdog() with the XS_SETERR macro used elsewhere
In isp_loop_dead(), abort or complete pending commands as done
in isp_watchdog()
In isp_async(), segregate the ISPASYNC_LOOP_RESET action from
ISPASYNC_LIP, ISPASYNC_LOOP_DOWN, and ISPASYNC_LOOP_UP
fallthroughs, and only reset the CRN in the RESET case. Also add
checks to handle false LOOP RESET actions that do not have a
proper associated LIP primitive, and log the primitive in the
debug messages
In isp_async(), remove the goto from ISP_ASYNC_DEV_STAYED, and
only reset the CRN in the DEV_CHANGED action
In isp_async(), when processing an ISPASYNC_CHANGE_PDB status,
reset CRN(s) for the associated nphdl (or all ports) if the
change reason is some form of ELS login/logout. Also remove
assignment to fc since it is not used in the scope
sys/dev/isp/ispmbox.h
Add macro definition for the global N-Port handle, and correct a
macro typo 'PDB24XX_AE_PRLI_DONJE'
sys/dev/isp/ispvar.h
Add macros FCP_AL_DA_ALL, FCP_AL_PA, and FCP_IS_DEST_ALPD for
more legible code when determining if an AL_PD port matches the
portid for a given struct fcparam* by value or by virtue of the
AL_PD port being 0xFF
Submitted by: Reid Linnemann
Sponsored by: Spectra Logic
MFC after: 1 week
2017-05-03 13:17:01 +00:00
/*
* Port database syncs are not sufficient for
* determining that logins or logouts are done on the
* loop , but this information is directly available from
* the reason code from the incoming mbox . We must reset
* the fcp crn on these events according to FCP - 4
*/
switch ( reason ) {
case PDB24XX_AE_IMPL_LOGO_1 :
case PDB24XX_AE_IMPL_LOGO_2 :
case PDB24XX_AE_IMPL_LOGO_3 :
case PDB24XX_AE_PLOGI_RCVD :
case PDB24XX_AE_PRLI_RCVD :
case PDB24XX_AE_PRLO_RCVD :
case PDB24XX_AE_LOGO_RCVD :
case PDB24XX_AE_PLOGI_DONE :
case PDB24XX_AE_PRLI_DONE :
/*
* If the event is not global , twiddle tgt and
* tgt_set to nominate only the target
* associated with the nphdl .
*/
if ( nphdl ! = PDB24XX_AE_GLOBAL ) {
/* Break if we don't yet have the pdb */
if ( ! isp_find_pdb_by_handle ( isp , bus , nphdl , & lp ) )
break ;
tgt = FC_PORTDB_TGT ( isp , bus , lp ) ;
tgt_set = 1 ;
}
isp_fcp_reset_crn ( isp , bus , tgt , tgt_set ) ;
break ;
default :
break ; /* NOP */
}
2009-08-01 01:04:26 +00:00
} else if ( evt = = ISPASYNC_CHANGE_SNS ) {
2015-10-25 14:34:07 +00:00
msg = " Name Server Database Changed " ;
2015-11-19 17:43:47 +00:00
isp_prt ( isp , ISP_LOGINFO , " Chan %d %s (PortID 0x%06x) " ,
bus , msg , portid ) ;
2006-11-02 03:21:32 +00:00
} else {
2015-10-25 14:34:07 +00:00
msg = " Other Change Notify " ;
2015-11-19 17:43:47 +00:00
isp_prt ( isp , ISP_LOGINFO , " Chan %d %s " , bus , msg ) ;
2001-01-09 02:47:15 +00:00
}
2015-11-26 13:04:58 +00:00
isp_loop_changed ( isp , bus ) ;
1999-03-17 05:04:39 +00:00
break ;
}
2000-01-03 23:55:30 +00:00
# ifdef ISP_TARGET_MODE
2006-01-23 06:23:37 +00:00
case ISPASYNC_TARGET_NOTIFY :
2000-01-03 23:55:30 +00:00
{
2009-08-01 01:04:26 +00:00
isp_notify_t * notify ;
va_start ( ap , cmd ) ;
notify = va_arg ( ap , isp_notify_t * ) ;
va_end ( ap ) ;
switch ( notify - > nt_ncode ) {
case NT_ABORT_TASK :
case NT_ABORT_TASK_SET :
case NT_CLEAR_ACA :
case NT_CLEAR_TASK_SET :
case NT_LUN_RESET :
case NT_TARGET_RESET :
2015-10-23 18:34:18 +00:00
case NT_QUERY_TASK_SET :
case NT_QUERY_ASYNC_EVENT :
2009-08-01 01:04:26 +00:00
/*
* These are task management functions .
*/
isp_handle_platform_target_tmf ( isp , notify ) ;
break ;
case NT_BUS_RESET :
case NT_LIP_RESET :
case NT_LINK_UP :
case NT_LINK_DOWN :
2015-07-13 15:11:05 +00:00
case NT_HBA_RESET :
2009-08-01 01:04:26 +00:00
/*
* No action need be taken here .
*/
break ;
-----------
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
case NT_GLOBAL_LOGOUT :
2009-08-01 01:04:26 +00:00
case NT_LOGOUT :
/*
* This is device arrival / departure notification
*/
2016-05-20 10:26:12 +00:00
isp_handle_platform_target_notify_ack ( isp , notify , 0 ) ;
2009-08-01 01:04:26 +00:00
break ;
2017-03-19 09:30:03 +00:00
case NT_SRR :
isp_handle_platform_srr ( isp , notify ) ;
break ;
2009-08-01 01:04:26 +00:00
default :
isp_prt ( isp , ISP_LOGALL , " target notify code 0x%x " , notify - > nt_ncode ) ;
2016-05-20 10:26:12 +00:00
isp_handle_platform_target_notify_ack ( isp , notify , 0 ) ;
2009-08-01 01:04:26 +00:00
break ;
}
2000-01-03 23:55:30 +00:00
break ;
}
-----------
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
case ISPASYNC_TARGET_NOTIFY_ACK :
{
void * inot ;
va_start ( ap , cmd ) ;
inot = va_arg ( ap , void * ) ;
va_end ( ap ) ;
if ( isp_notify_ack ( isp , inot ) ) {
isp_tna_t * tp = malloc ( sizeof ( * tp ) , M_DEVBUF , M_NOWAIT ) ;
if ( tp ) {
tp - > isp = isp ;
2017-03-18 10:34:29 +00:00
memcpy ( tp - > data , inot , sizeof ( tp - > data ) ) ;
tp - > not = tp - > data ;
2014-11-18 21:03:46 +00:00
callout_init_mtx ( & tp - > timer , & isp - > isp_lock , 0 ) ;
callout_reset ( & tp - > timer , 5 ,
isp_refire_notify_ack , tp ) ;
-----------
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
} else {
isp_prt ( isp , ISP_LOGERR , " you lose- cannot allocate a notify refire " ) ;
}
}
break ;
}
2000-01-03 23:55:30 +00:00
case ISPASYNC_TARGET_ACTION :
2009-08-01 01:04:26 +00:00
{
isphdr_t * hp ;
va_start ( ap , cmd ) ;
hp = va_arg ( ap , isphdr_t * ) ;
va_end ( ap ) ;
switch ( hp - > rqs_entry_type ) {
2000-01-03 23:55:30 +00:00
case RQSTYPE_ATIO :
2015-11-23 10:06:19 +00:00
isp_handle_platform_atio7 ( isp , ( at7_entry_t * ) hp ) ;
2000-01-03 23:55:30 +00:00
break ;
case RQSTYPE_ATIO2 :
2009-08-01 01:04:26 +00:00
isp_handle_platform_atio2 ( isp , ( at2_entry_t * ) hp ) ;
2000-01-03 23:55:30 +00:00
break ;
2009-08-01 01:04:26 +00:00
case RQSTYPE_CTIO7 :
2006-05-22 07:07:30 +00:00
case RQSTYPE_CTIO3 :
2000-01-03 23:55:30 +00:00
case RQSTYPE_CTIO2 :
case RQSTYPE_CTIO :
2009-08-01 01:04:26 +00:00
isp_handle_platform_ctio ( isp , hp ) ;
break ;
2017-03-19 09:30:03 +00:00
default :
isp_prt ( isp , ISP_LOGWARN , " %s: unhandled target action 0x%x " ,
__func__ , hp - > rqs_entry_type ) ;
break ;
2000-01-03 23:55:30 +00:00
}
break ;
2009-08-01 01:04:26 +00:00
}
1999-07-02 23:12:58 +00:00
# endif
2001-07-04 18:54:29 +00:00
case ISPASYNC_FW_CRASH :
{
2006-02-15 00:31:48 +00:00
uint16_t mbox1 , mbox6 ;
2001-07-04 18:54:29 +00:00
mbox1 = ISP_READ ( isp , OUTMAILBOX1 ) ;
if ( IS_DUALBUS ( isp ) ) {
mbox6 = ISP_READ ( isp , OUTMAILBOX6 ) ;
} else {
mbox6 = 0 ;
}
2009-08-01 01:04:26 +00:00
isp_prt ( isp , ISP_LOGERR , " Internal Firmware Error on bus %d @ RISC Address 0x%x " , mbox6 , mbox1 ) ;
2017-03-14 18:42:33 +00:00
#if 0
2007-05-05 20:17:23 +00:00
mbox1 = isp - > isp_osinfo . mbox_sleep_ok ;
isp - > isp_osinfo . mbox_sleep_ok = 0 ;
2009-08-01 01:04:26 +00:00
isp_reinit ( isp , 1 ) ;
2007-05-05 20:17:23 +00:00
isp - > isp_osinfo . mbox_sleep_ok = mbox1 ;
isp_async ( isp , ISPASYNC_FW_RESTARTED , NULL ) ;
2017-03-14 18:42:33 +00:00
# endif
2001-07-04 18:54:29 +00:00
break ;
}
1999-01-30 07:29:00 +00:00
default :
2000-08-01 06:31:44 +00:00
isp_prt ( isp , ISP_LOGERR , " unknown isp_async event %d " , cmd ) ;
1999-01-30 07:29:00 +00:00
break ;
}
}
1998-12-28 19:22:27 +00:00
2009-08-01 01:04:26 +00:00
uint64_t
isp_default_wwn ( ispsoftc_t * isp , int chan , int isactive , int iswwnn )
{
uint64_t seed ;
struct isp_fc * fc = ISP_FC_PC ( isp , chan ) ;
2015-12-05 21:38:04 +00:00
/* First try to use explicitly configured WWNs. */
seed = iswwnn ? fc - > def_wwnn : fc - > def_wwpn ;
if ( seed )
return ( seed ) ;
/* Otherwise try to use WWNs from NVRAM. */
2009-08-01 01:04:26 +00:00
if ( isactive ) {
2015-12-05 21:38:04 +00:00
seed = iswwnn ? FCPARAM ( isp , chan ) - > isp_wwnn_nvram :
FCPARAM ( isp , chan ) - > isp_wwpn_nvram ;
if ( seed )
2009-08-13 01:17:26 +00:00
return ( seed ) ;
2009-08-01 01:04:26 +00:00
}
2015-12-05 21:38:04 +00:00
/* If still no WWNs, try to steal them from the first channel. */
if ( chan > 0 ) {
seed = iswwnn ? ISP_FC_PC ( isp , 0 ) - > def_wwnn :
ISP_FC_PC ( isp , 0 ) - > def_wwpn ;
if ( seed = = 0 ) {
seed = iswwnn ? FCPARAM ( isp , 0 ) - > isp_wwnn_nvram :
FCPARAM ( isp , 0 ) - > isp_wwpn_nvram ;
}
2009-08-01 01:04:26 +00:00
}
2015-12-05 21:38:04 +00:00
/* If still nothing -- improvise. */
if ( seed = = 0 ) {
seed = 0x400000007F000000ull + device_get_unit ( isp - > isp_dev ) ;
if ( ! iswwnn )
seed ^ = 0x0100000000000000ULL ;
2009-08-01 01:04:26 +00:00
}
2015-12-05 21:38:04 +00:00
/* For additional channels we have to improvise even more. */
if ( ! iswwnn & & chan > 0 ) {
2009-08-01 01:04:26 +00:00
/*
* We ' ll stick our channel number plus one first into bits
* 57. .59 and thence into bits 52. .55 which allows for 8 bits
2015-12-05 21:38:04 +00:00
* of channel which is enough for our maximum of 255 channels .
2009-08-01 01:04:26 +00:00
*/
2015-12-05 21:38:04 +00:00
seed ^ = 0x0100000000000000ULL ;
seed ^ = ( ( uint64_t ) ( chan + 1 ) & 0xf ) < < 56 ;
seed ^ = ( ( uint64_t ) ( ( chan + 1 ) > > 4 ) & 0xf ) < < 52 ;
2009-08-01 01:04:26 +00:00
}
return ( seed ) ;
}
2000-08-01 06:31:44 +00:00
void
2006-04-21 18:30:01 +00:00
isp_prt ( ispsoftc_t * isp , int level , const char * fmt , . . . )
2000-08-01 06:31:44 +00:00
{
2011-08-12 19:51:28 +00:00
int loc ;
-----------
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
char lbuf [ 200 ] ;
2000-08-01 06:31:44 +00:00
va_list ap ;
2011-08-12 19:51:28 +00:00
2000-08-01 06:31:44 +00:00
if ( level ! = ISP_LOGALL & & ( level & isp - > isp_dblev ) = = 0 ) {
return ;
}
-----------
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
snprintf ( lbuf , sizeof ( lbuf ) , " %s: " , device_get_nameunit ( isp - > isp_dev ) ) ;
2011-08-12 19:51:28 +00:00
loc = strlen ( lbuf ) ;
2000-08-01 06:31:44 +00:00
va_start ( ap , fmt ) ;
2011-08-12 19:51:28 +00:00
vsnprintf ( & lbuf [ loc ] , sizeof ( lbuf ) - loc - 1 , fmt , ap ) ;
2000-08-01 06:31:44 +00:00
va_end ( ap ) ;
2011-08-12 19:51:28 +00:00
printf ( " %s \n " , lbuf ) ;
2000-08-01 06:31:44 +00:00
}
2006-11-14 08:45:48 +00:00
2010-03-26 15:13:31 +00:00
void
isp_xs_prt ( ispsoftc_t * isp , XS_T * xs , int level , const char * fmt , . . . )
{
va_list ap ;
if ( level ! = ISP_LOGALL & & ( level & isp - > isp_dblev ) = = 0 ) {
return ;
}
xpt_print_path ( xs - > ccb_h . path ) ;
va_start ( ap , fmt ) ;
vprintf ( fmt , ap ) ;
va_end ( ap ) ;
printf ( " \n " ) ;
}
2006-11-14 08:45:48 +00:00
uint64_t
isp_nanotime_sub ( struct timespec * b , struct timespec * a )
{
uint64_t elapsed ;
Make timespecadd(3) and friends public
The timespecadd(3) family of macros were imported from NetBSD back in
r35029. However, they were initially guarded by #ifdef _KERNEL. In the
meantime, we have grown at least 28 syscalls that use timespecs in some
way, leading many programs both inside and outside of the base system to
redefine those macros. It's better just to make the definitions public.
Our kernel currently defines two-argument versions of timespecadd and
timespecsub. NetBSD, OpenBSD, and FreeDesktop.org's libbsd, however, define
three-argument versions. Solaris also defines a three-argument version, but
only in its kernel. This revision changes our definition to match the
common three-argument version.
Bump _FreeBSD_version due to the breaking KPI change.
Discussed with: cem, jilles, ian, bde
Differential Revision: https://reviews.freebsd.org/D14725
2018-07-30 15:46:40 +00:00
struct timespec x ;
timespecsub ( b , a , & x ) ;
2006-11-14 08:45:48 +00:00
elapsed = GET_NANOSEC ( & x ) ;
if ( elapsed = = 0 )
elapsed + + ;
return ( elapsed ) ;
}
int
isp_mbox_acquire ( ispsoftc_t * isp )
{
if ( isp - > isp_osinfo . mboxbsy ) {
return ( 1 ) ;
} else {
isp - > isp_osinfo . mboxcmd_done = 0 ;
isp - > isp_osinfo . mboxbsy = 1 ;
return ( 0 ) ;
}
}
void
isp_mbox_wait_complete ( ispsoftc_t * isp , mbreg_t * mbp )
{
2017-03-14 17:34:44 +00:00
u_int t , to ;
2006-12-17 16:59:19 +00:00
2017-03-14 17:34:44 +00:00
to = ( mbp - > timeout = = 0 ) ? MBCMD_DEFAULT_TIMEOUT : mbp - > timeout ;
2006-11-14 08:45:48 +00:00
if ( isp - > isp_osinfo . mbox_sleep_ok ) {
isp - > isp_osinfo . mbox_sleep_ok = 0 ;
isp - > isp_osinfo . mbox_sleeping = 1 ;
2017-03-21 10:34:34 +00:00
msleep_sbt ( & isp - > isp_osinfo . mboxcmd_done , & isp - > isp_lock ,
2017-03-14 17:34:44 +00:00
PRIBIO , " ispmbx_sleep " , to * SBT_1US , 0 , 0 ) ;
2006-12-17 16:59:19 +00:00
isp - > isp_osinfo . mbox_sleep_ok = 1 ;
isp - > isp_osinfo . mbox_sleeping = 0 ;
} else {
2017-03-14 17:34:44 +00:00
for ( t = 0 ; t < to ; t + = 100 ) {
if ( isp - > isp_osinfo . mboxcmd_done )
2006-12-17 16:59:19 +00:00
break ;
2017-03-15 14:58:29 +00:00
ISP_RUN_ISR ( isp ) ;
if ( isp - > isp_osinfo . mboxcmd_done )
break ;
2017-03-14 17:34:44 +00:00
ISP_DELAY ( 100 ) ;
2006-11-14 08:45:48 +00:00
}
}
if ( isp - > isp_osinfo . mboxcmd_done = = 0 ) {
2017-03-14 17:34:44 +00:00
isp_prt ( isp , ISP_LOGWARN , " %s Mailbox Command (0x%x) Timeout (%uus) (%s:%d) " ,
isp - > isp_osinfo . mbox_sleep_ok ? " Interrupting " : " Polled " ,
isp - > isp_lastmbxcmd , to , mbp - > func , mbp - > lineno ) ;
2006-11-14 08:45:48 +00:00
mbp - > param [ 0 ] = MBOX_TIMEOUT ;
isp - > isp_osinfo . mboxcmd_done = 1 ;
}
}
void
isp_mbox_notify_done ( ispsoftc_t * isp )
{
isp - > isp_osinfo . mboxcmd_done = 1 ;
2017-03-14 17:34:44 +00:00
if ( isp - > isp_osinfo . mbox_sleeping )
wakeup ( & isp - > isp_osinfo . mboxcmd_done ) ;
2006-11-14 08:45:48 +00:00
}
void
isp_mbox_release ( ispsoftc_t * isp )
{
isp - > isp_osinfo . mboxbsy = 0 ;
}
2009-08-01 01:04:26 +00:00
int
isp_fc_scratch_acquire ( ispsoftc_t * isp , int chan )
{
int ret = 0 ;
if ( isp - > isp_osinfo . pc . fc [ chan ] . fcbsy ) {
ret = - 1 ;
} else {
isp - > isp_osinfo . pc . fc [ chan ] . fcbsy = 1 ;
}
return ( ret ) ;
}
2007-05-05 20:17:23 +00:00
void
isp_platform_intr ( void * arg )
{
ispsoftc_t * isp = arg ;
ISP_LOCK ( isp ) ;
2017-03-15 14:58:29 +00:00
ISP_RUN_ISR ( isp ) ;
2007-05-05 20:17:23 +00:00
ISP_UNLOCK ( isp ) ;
}
2017-03-19 19:11:40 +00:00
void
isp_platform_intr_resp ( void * arg )
{
ispsoftc_t * isp = arg ;
ISP_LOCK ( isp ) ;
isp_intr_respq ( isp ) ;
ISP_UNLOCK ( isp ) ;
/* We have handshake enabled, so explicitly complete interrupt */
ISP_WRITE ( isp , BIU2400_HCCR , HCCR_2400_CMD_CLEAR_RISC_INT ) ;
}
void
isp_platform_intr_atio ( void * arg )
{
ispsoftc_t * isp = arg ;
ISP_LOCK ( isp ) ;
# ifdef ISP_TARGET_MODE
isp_intr_atioq ( isp ) ;
# endif
ISP_UNLOCK ( isp ) ;
/* We have handshake enabled, so explicitly complete interrupt */
ISP_WRITE ( isp , BIU2400_HCCR , HCCR_2400_CMD_CLEAR_RISC_INT ) ;
}
2007-05-05 20:17:23 +00:00
void
isp_common_dmateardown ( ispsoftc_t * isp , struct ccb_scsiio * csio , uint32_t hdl )
{
if ( ( csio - > ccb_h . flags & CAM_DIR_MASK ) = = CAM_DIR_IN ) {
2009-08-01 01:04:26 +00:00
bus_dmamap_sync ( isp - > isp_osinfo . dmat , PISP_PCMD ( csio ) - > dmap , BUS_DMASYNC_POSTREAD ) ;
2007-05-05 20:17:23 +00:00
} else {
2009-08-01 01:04:26 +00:00
bus_dmamap_sync ( isp - > isp_osinfo . dmat , PISP_PCMD ( csio ) - > dmap , BUS_DMASYNC_POSTWRITE ) ;
2007-05-05 20:17:23 +00:00
}
bus_dmamap_unload ( isp - > isp_osinfo . dmat , PISP_PCMD ( csio ) - > dmap ) ;
}
2009-08-01 01:04:26 +00:00
Fix Fibre Channel Command Reference Number handling in the isp(4) driver.
The Command Reference Number is used for precise delivery of
commands, and is part of the FC-Tape functionality set. (This is
only enabled for devices that support precise delivery of commands.)
It is an 8-bit unsigned number that increments from 1 to 255. The
commands sent by the initiator must be processed by the target in
CRN order if the CRN is non-zero.
There are certain scenarios where the Command Reference Number
sequence needs to be reset. When the target is power cycled, for
instance, the initiator needs to reset the CRN to 1. The initiator
will know this because it will see a LIP (when directly connected)
or get a logout/login event (when connected to a switch).
The isp(4) driver was not resetting the CRN when a target
went away and came back. When it saw the target again after a
power cycle, it would continue the CRN sequence where it left off.
The target would ignore the command because the CRN sequence is
supposed to be reset to 1 after a power cycle or other similar
event.
The symptom that the user would see is that there would be lots of
aborted INQUIRY commands after a tape library was power cycled, and
the library would fail to probe. The INQUIRY commands were being
ignored by the tape drive due to the CRN issue mentioned above.
isp_freebsd.c:
Add a new function, isp_fcp_reset_crn(). This will reset
all of the CRNs for a given port, or the CRNs for all LUNs
on a target.
Reset the CRNs for all targets on a port when we get a LIP,
loop reset, or loop down event.
Reset the CRN for a particular target when it arrives, is changed
or departs. This is less precise behavior than the
clearing behavior specified in the FCP-4 spec (which says
that it should be reset for PRLI, PRLO, PLOGI and LOGO),
but this is the level of information we have here. If this
is insufficient, then we will need to add more precise
notification from the lower level isp(4) code.
isp_freebsd.h:
Add a prototype for isp_fcp_reset_crn().
Sponsored by: Spectra Logic
MFC after: 1 week
2015-01-08 17:41:28 +00:00
/*
* Reset the command reference number for all LUNs on a specific target
* ( needed when a target arrives again ) or for all targets on a port
* ( needed for events like a LIP ) .
*/
void
2015-11-14 19:47:17 +00:00
isp_fcp_reset_crn ( ispsoftc_t * isp , int chan , uint32_t tgt , int tgt_set )
Fix Fibre Channel Command Reference Number handling in the isp(4) driver.
The Command Reference Number is used for precise delivery of
commands, and is part of the FC-Tape functionality set. (This is
only enabled for devices that support precise delivery of commands.)
It is an 8-bit unsigned number that increments from 1 to 255. The
commands sent by the initiator must be processed by the target in
CRN order if the CRN is non-zero.
There are certain scenarios where the Command Reference Number
sequence needs to be reset. When the target is power cycled, for
instance, the initiator needs to reset the CRN to 1. The initiator
will know this because it will see a LIP (when directly connected)
or get a logout/login event (when connected to a switch).
The isp(4) driver was not resetting the CRN when a target
went away and came back. When it saw the target again after a
power cycle, it would continue the CRN sequence where it left off.
The target would ignore the command because the CRN sequence is
supposed to be reset to 1 after a power cycle or other similar
event.
The symptom that the user would see is that there would be lots of
aborted INQUIRY commands after a tape library was power cycled, and
the library would fail to probe. The INQUIRY commands were being
ignored by the tape drive due to the CRN issue mentioned above.
isp_freebsd.c:
Add a new function, isp_fcp_reset_crn(). This will reset
all of the CRNs for a given port, or the CRNs for all LUNs
on a target.
Reset the CRNs for all targets on a port when we get a LIP,
loop reset, or loop down event.
Reset the CRN for a particular target when it arrives, is changed
or departs. This is less precise behavior than the
clearing behavior specified in the FCP-4 spec (which says
that it should be reset for PRLI, PRLO, PLOGI and LOGO),
but this is the level of information we have here. If this
is insufficient, then we will need to add more precise
notification from the lower level isp(4) code.
isp_freebsd.h:
Add a prototype for isp_fcp_reset_crn().
Sponsored by: Spectra Logic
MFC after: 1 week
2015-01-08 17:41:28 +00:00
{
2015-11-14 19:47:17 +00:00
struct isp_fc * fc = ISP_FC_PC ( isp , chan ) ;
Fix Fibre Channel Command Reference Number handling in the isp(4) driver.
The Command Reference Number is used for precise delivery of
commands, and is part of the FC-Tape functionality set. (This is
only enabled for devices that support precise delivery of commands.)
It is an 8-bit unsigned number that increments from 1 to 255. The
commands sent by the initiator must be processed by the target in
CRN order if the CRN is non-zero.
There are certain scenarios where the Command Reference Number
sequence needs to be reset. When the target is power cycled, for
instance, the initiator needs to reset the CRN to 1. The initiator
will know this because it will see a LIP (when directly connected)
or get a logout/login event (when connected to a switch).
The isp(4) driver was not resetting the CRN when a target
went away and came back. When it saw the target again after a
power cycle, it would continue the CRN sequence where it left off.
The target would ignore the command because the CRN sequence is
supposed to be reset to 1 after a power cycle or other similar
event.
The symptom that the user would see is that there would be lots of
aborted INQUIRY commands after a tape library was power cycled, and
the library would fail to probe. The INQUIRY commands were being
ignored by the tape drive due to the CRN issue mentioned above.
isp_freebsd.c:
Add a new function, isp_fcp_reset_crn(). This will reset
all of the CRNs for a given port, or the CRNs for all LUNs
on a target.
Reset the CRNs for all targets on a port when we get a LIP,
loop reset, or loop down event.
Reset the CRN for a particular target when it arrives, is changed
or departs. This is less precise behavior than the
clearing behavior specified in the FCP-4 spec (which says
that it should be reset for PRLI, PRLO, PLOGI and LOGO),
but this is the level of information we have here. If this
is insufficient, then we will need to add more precise
notification from the lower level isp(4) code.
isp_freebsd.h:
Add a prototype for isp_fcp_reset_crn().
Sponsored by: Spectra Logic
MFC after: 1 week
2015-01-08 17:41:28 +00:00
struct isp_nexus * nxp ;
2015-11-14 19:47:17 +00:00
int i ;
Fix Fibre Channel Command Reference Number handling in the isp(4) driver.
The Command Reference Number is used for precise delivery of
commands, and is part of the FC-Tape functionality set. (This is
only enabled for devices that support precise delivery of commands.)
It is an 8-bit unsigned number that increments from 1 to 255. The
commands sent by the initiator must be processed by the target in
CRN order if the CRN is non-zero.
There are certain scenarios where the Command Reference Number
sequence needs to be reset. When the target is power cycled, for
instance, the initiator needs to reset the CRN to 1. The initiator
will know this because it will see a LIP (when directly connected)
or get a logout/login event (when connected to a switch).
The isp(4) driver was not resetting the CRN when a target
went away and came back. When it saw the target again after a
power cycle, it would continue the CRN sequence where it left off.
The target would ignore the command because the CRN sequence is
supposed to be reset to 1 after a power cycle or other similar
event.
The symptom that the user would see is that there would be lots of
aborted INQUIRY commands after a tape library was power cycled, and
the library would fail to probe. The INQUIRY commands were being
ignored by the tape drive due to the CRN issue mentioned above.
isp_freebsd.c:
Add a new function, isp_fcp_reset_crn(). This will reset
all of the CRNs for a given port, or the CRNs for all LUNs
on a target.
Reset the CRNs for all targets on a port when we get a LIP,
loop reset, or loop down event.
Reset the CRN for a particular target when it arrives, is changed
or departs. This is less precise behavior than the
clearing behavior specified in the FCP-4 spec (which says
that it should be reset for PRLI, PRLO, PLOGI and LOGO),
but this is the level of information we have here. If this
is insufficient, then we will need to add more precise
notification from the lower level isp(4) code.
isp_freebsd.h:
Add a prototype for isp_fcp_reset_crn().
Sponsored by: Spectra Logic
MFC after: 1 week
2015-01-08 17:41:28 +00:00
if ( tgt_set = = 0 )
2015-11-14 19:47:17 +00:00
isp_prt ( isp , ISP_LOGDEBUG0 ,
" Chan %d resetting CRN on all targets " , chan ) ;
Fix Fibre Channel Command Reference Number handling in the isp(4) driver.
The Command Reference Number is used for precise delivery of
commands, and is part of the FC-Tape functionality set. (This is
only enabled for devices that support precise delivery of commands.)
It is an 8-bit unsigned number that increments from 1 to 255. The
commands sent by the initiator must be processed by the target in
CRN order if the CRN is non-zero.
There are certain scenarios where the Command Reference Number
sequence needs to be reset. When the target is power cycled, for
instance, the initiator needs to reset the CRN to 1. The initiator
will know this because it will see a LIP (when directly connected)
or get a logout/login event (when connected to a switch).
The isp(4) driver was not resetting the CRN when a target
went away and came back. When it saw the target again after a
power cycle, it would continue the CRN sequence where it left off.
The target would ignore the command because the CRN sequence is
supposed to be reset to 1 after a power cycle or other similar
event.
The symptom that the user would see is that there would be lots of
aborted INQUIRY commands after a tape library was power cycled, and
the library would fail to probe. The INQUIRY commands were being
ignored by the tape drive due to the CRN issue mentioned above.
isp_freebsd.c:
Add a new function, isp_fcp_reset_crn(). This will reset
all of the CRNs for a given port, or the CRNs for all LUNs
on a target.
Reset the CRNs for all targets on a port when we get a LIP,
loop reset, or loop down event.
Reset the CRN for a particular target when it arrives, is changed
or departs. This is less precise behavior than the
clearing behavior specified in the FCP-4 spec (which says
that it should be reset for PRLI, PRLO, PLOGI and LOGO),
but this is the level of information we have here. If this
is insufficient, then we will need to add more precise
notification from the lower level isp(4) code.
isp_freebsd.h:
Add a prototype for isp_fcp_reset_crn().
Sponsored by: Spectra Logic
MFC after: 1 week
2015-01-08 17:41:28 +00:00
else
2015-11-14 19:47:17 +00:00
isp_prt ( isp , ISP_LOGDEBUG0 ,
" Chan %d resetting CRN on target %u " , chan , tgt ) ;
Fix Fibre Channel Command Reference Number handling in the isp(4) driver.
The Command Reference Number is used for precise delivery of
commands, and is part of the FC-Tape functionality set. (This is
only enabled for devices that support precise delivery of commands.)
It is an 8-bit unsigned number that increments from 1 to 255. The
commands sent by the initiator must be processed by the target in
CRN order if the CRN is non-zero.
There are certain scenarios where the Command Reference Number
sequence needs to be reset. When the target is power cycled, for
instance, the initiator needs to reset the CRN to 1. The initiator
will know this because it will see a LIP (when directly connected)
or get a logout/login event (when connected to a switch).
The isp(4) driver was not resetting the CRN when a target
went away and came back. When it saw the target again after a
power cycle, it would continue the CRN sequence where it left off.
The target would ignore the command because the CRN sequence is
supposed to be reset to 1 after a power cycle or other similar
event.
The symptom that the user would see is that there would be lots of
aborted INQUIRY commands after a tape library was power cycled, and
the library would fail to probe. The INQUIRY commands were being
ignored by the tape drive due to the CRN issue mentioned above.
isp_freebsd.c:
Add a new function, isp_fcp_reset_crn(). This will reset
all of the CRNs for a given port, or the CRNs for all LUNs
on a target.
Reset the CRNs for all targets on a port when we get a LIP,
loop reset, or loop down event.
Reset the CRN for a particular target when it arrives, is changed
or departs. This is less precise behavior than the
clearing behavior specified in the FCP-4 spec (which says
that it should be reset for PRLI, PRLO, PLOGI and LOGO),
but this is the level of information we have here. If this
is insufficient, then we will need to add more precise
notification from the lower level isp(4) code.
isp_freebsd.h:
Add a prototype for isp_fcp_reset_crn().
Sponsored by: Spectra Logic
MFC after: 1 week
2015-01-08 17:41:28 +00:00
for ( i = 0 ; i < NEXUS_HASH_WIDTH ; i + + ) {
2015-11-14 19:47:17 +00:00
for ( nxp = fc - > nexus_hash [ i ] ; nxp ! = NULL ; nxp = nxp - > next ) {
if ( tgt_set = = 0 | | tgt = = nxp - > tgt )
Fix Fibre Channel Command Reference Number handling in the isp(4) driver.
The Command Reference Number is used for precise delivery of
commands, and is part of the FC-Tape functionality set. (This is
only enabled for devices that support precise delivery of commands.)
It is an 8-bit unsigned number that increments from 1 to 255. The
commands sent by the initiator must be processed by the target in
CRN order if the CRN is non-zero.
There are certain scenarios where the Command Reference Number
sequence needs to be reset. When the target is power cycled, for
instance, the initiator needs to reset the CRN to 1. The initiator
will know this because it will see a LIP (when directly connected)
or get a logout/login event (when connected to a switch).
The isp(4) driver was not resetting the CRN when a target
went away and came back. When it saw the target again after a
power cycle, it would continue the CRN sequence where it left off.
The target would ignore the command because the CRN sequence is
supposed to be reset to 1 after a power cycle or other similar
event.
The symptom that the user would see is that there would be lots of
aborted INQUIRY commands after a tape library was power cycled, and
the library would fail to probe. The INQUIRY commands were being
ignored by the tape drive due to the CRN issue mentioned above.
isp_freebsd.c:
Add a new function, isp_fcp_reset_crn(). This will reset
all of the CRNs for a given port, or the CRNs for all LUNs
on a target.
Reset the CRNs for all targets on a port when we get a LIP,
loop reset, or loop down event.
Reset the CRN for a particular target when it arrives, is changed
or departs. This is less precise behavior than the
clearing behavior specified in the FCP-4 spec (which says
that it should be reset for PRLI, PRLO, PLOGI and LOGO),
but this is the level of information we have here. If this
is insufficient, then we will need to add more precise
notification from the lower level isp(4) code.
isp_freebsd.h:
Add a prototype for isp_fcp_reset_crn().
Sponsored by: Spectra Logic
MFC after: 1 week
2015-01-08 17:41:28 +00:00
nxp - > crnseed = 0 ;
}
}
}
-----------
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 * isp , uint8_t * crnp , XS_T * cmd )
{
2015-10-24 17:34:40 +00:00
lun_id_t lun ;
uint32_t chan , tgt ;
2012-08-12 20:45:47 +00:00
struct isp_fc * fc ;
struct isp_nexus * nxp ;
int idx ;
2015-11-23 15:49:50 +00:00
if ( IS_2100 ( isp ) )
2012-08-12 20:45:47 +00:00
return ( 0 ) ;
chan = XS_CHANNEL ( cmd ) ;
tgt = XS_TGT ( cmd ) ;
lun = XS_LUN ( cmd ) ;
fc = & isp - > isp_osinfo . pc . fc [ chan ] ;
idx = NEXUS_HASH ( tgt , lun ) ;
nxp = fc - > nexus_hash [ idx ] ;
-----------
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
while ( nxp ) {
if ( nxp - > tgt = = tgt & & nxp - > lun = = lun )
break ;
nxp = nxp - > next ;
}
if ( nxp = = NULL ) {
nxp = fc - > nexus_free_list ;
if ( nxp = = NULL ) {
nxp = malloc ( sizeof ( struct isp_nexus ) , M_DEVBUF , M_ZERO | M_NOWAIT ) ;
if ( nxp = = NULL ) {
return ( - 1 ) ;
}
} else {
fc - > nexus_free_list = nxp - > next ;
}
nxp - > tgt = tgt ;
nxp - > lun = lun ;
nxp - > next = fc - > nexus_hash [ idx ] ;
fc - > nexus_hash [ idx ] = nxp ;
}
2015-11-14 19:47:17 +00:00
if ( nxp - > crnseed = = 0 )
nxp - > crnseed = 1 ;
* crnp = nxp - > crnseed + + ;
return ( 0 ) ;
-----------
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
}
2012-08-08 18:24:33 +00:00
/*
* We enter with the lock held
*/
2009-08-01 01:04:26 +00:00
void
isp_timer ( void * arg )
{
ispsoftc_t * isp = arg ;
# ifdef ISP_TARGET_MODE
isp_tmcmd_restart ( isp ) ;
# endif
2012-08-08 18:24:33 +00:00
callout_reset ( & isp - > isp_osinfo . tmo , isp_timer_count , isp_timer , isp ) ;
2009-08-01 01:04:26 +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
isp_ecmd_t *
isp_get_ecmd ( ispsoftc_t * isp )
{
isp_ecmd_t * ecmd = isp - > isp_osinfo . ecmd_free ;
if ( ecmd ) {
isp - > isp_osinfo . ecmd_free = ecmd - > next ;
}
return ( ecmd ) ;
}
void
isp_put_ecmd ( ispsoftc_t * isp , isp_ecmd_t * ecmd )
{
ecmd - > next = isp - > isp_osinfo . ecmd_free ;
isp - > isp_osinfo . ecmd_free = ecmd ;
}