d/freebsd-dev
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
27a9392d54
freebsd-dev/sys/dev/isp/isp_freebsd.c

4328 lines
121 KiB
C
Raw Normal View History

Start each of the license/copyright comments with /*-, minor shuffle of lines
2005-01-06 01:43:34 +00:00
/*-
sys/dev: further adoption of SPDX licensing ID tags. Mainly focus on files that use BSD 2-Clause license, however the tool I was using misidentified many licenses so this was mostly a manual - error prone - task. The Software Package Data Exchange (SPDX) group provides a specification to make it easier for automated tools to detect and summarize well known opensource licenses. We are gradually adopting the specification, noting that the tags are considered only advisory and do not, in any way, superceed or replace the license texts.
2017-11-27 14:52:40 +00:00
* SPDX-License-Identifier: BSD-2-Clause-FreeBSD
*
Switch fabric scans from GID_FT to GID_PT+GFF_ID/GFT_ID. Instead of using GID_FT SNS request to get list of registered FCP ports, use GID_PT to get list of all Nx_Ports, and then use GFF_ID and/or GFT_ID requests to find whether they are FCP and target capable. The problem with old approach is that GID_FT does not report ports without FC-4 type registered. In particular it was impossible to boot OS from FreeBSD FC target using QLogic FC BIOS, since one does not register FC-4 type even on new cards and so ignored by old code as incompatible. As a side bonus this allows initiator to skip pointless logins to other initiators by fetching that information from SNS instead. In case some switches do not implement GFF_ID/GFT_ID correctly, add sysctls to disable that functionality. I handled broken GFF_ID of my Brocade 200E, but there may be other switches with different bugs. Linux also uses GID_PT, but GFF_ID is disabled by default there, and GFT_ID is not supported. Sponsored by: iXsystems, Inc.
2017-07-03 15:56:45 +00:00
* Copyright (c) 2009-2017 Alexander Motin <mav@FreeBSD.org>
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
* Copyright (c) 1997-2009 by Matthew Jacob
First of several commits as this driver is dusted off and maybe brought up to date. Principle changes for this reelase is to support 2K Port Login firmware. This allows us to support the 2322 (and 2422 4Gb) cards which only come with the 2K Port Login firmware. The 2322 should now work- but we don't have firmware sets for it in ispfw (as the change to load 2K Port Login f/w hasn't been made- that f/w is so big it has to be loaded in more than one chunk). Other changes are the beginnings of cleaning up some long standing target mode issues. The next changes here will incorporate a lot of bug fixes from others. Finally, some copyright cleanup and attempts to make the parts of the driver that are FreeBSD specific start conforming more to FreeBSD style. MFC after: 1 month
2006-01-23 06:23:37 +00:00
* All rights reserved.
Add support for the Qlogic ISP SCSI && FC/AL Adapters
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.
some copyright cleanups
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.
Add support for the Qlogic ISP SCSI && FC/AL Adapters
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.
*/
Use __FBSDID(). Also some minor style cleanups.
2003-08-24 17:55:58 +00:00
Some rearrangement of headers to minimize diffs with outside of FreeBSD repository and to clean up the license header so as to not pollute the license with file function. Zero all mailbox structures prior to use (just in case). Change the outgoing mailbox count for INIT_FIRMWARE to be correct.
2006-07-16 20:11:50 +00:00
/*
* Platform (FreeBSD) dependent common attachment code for Qlogic adapters.
*/
Use __FBSDID(). Also some minor style cleanups.
2003-08-24 17:55:58 +00:00
#include <sys/cdefs.h>
__FBSDID("$FreeBSD$");
Force commit to record the correct log for r277513. If the user sends an XPT_RESET_DEV CCB, make sure to reset the Fibre Channel Command Reference Number if we're running on a FC controller. We send a SCSI Target Reset when we get this CCB, and as a result need to reset the CRN to 1 on the next command. isp_freebsd.c: In the XPT_RESET_DEV implementation in isp_action(), reset the CRN if we're on a FC controller. Submitted by: ken MFC after: 1 week Sponsored by: Spectra Logic MFSpectraBSD: 1112787 on 2015/01/15
2015-01-21 20:27:11 +00:00
Add support for the Qlogic ISP SCSI && FC/AL Adapters
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>
Put MODULE_VERSION back here so that ispfw is happy.
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>
Fix compilation issues found in RELENG_4 port and merge the diffs back to -current to keep versions identical.
2007-03-12 04:54:30 +00:00
#include <sys/devicestat.h>
Push things closer to path failover by implementing loop down and gone device timers and zombie state entries. There are tunables that can be used to select a number of parameters. loop_down_limit - how long to wait for loop to come back up before declaring all devices dead (default 300 seconds) gone_device_time- how long to wait for a device that has appeared to leave the loop or fabric to reappear (default 30 seconds) Internal tunables include (which should be externalized): quick_boot_time- how long to wait when booting for loop to come up change_is_bad- whether or not to accept devices with the same WWNN/WWPN that reappear at a different PortID as being the 'same' device. Keen students of some of the subtle issues here will ask how one can keep devices from being re-accepted at all (the answer is to set a gone_device_time to zero- that effectively would be the same thing).
2006-11-14 08:45:48 +00:00
#include <cam/cam_periph.h>
MFP4: Move default setting to the end of isp_reset instead of the front of isp_init so we can read NVRAM even if we're role ISP_NONE. Prepare for reintroduction of channels (for FC) for N-Port Virtualization. Fix a botch in handle assignment that caused us to nuke one device when a new one arrives and end up with two devices with the same identity in the virtual target mapping table.
2007-01-20 04:00:21 +00:00
#include <cam/cam_xpt_periph.h>
Add support for the Qlogic ISP SCSI && FC/AL Adapters
1998-04-22 17:54:58 +00:00
Put MODULE_VERSION back here so that ispfw is happy.
2002-07-25 16:00:24 +00:00
MODULE_VERSION(isp, 1);
Add a module dependancy. Now CAM will autoload when you load this. OK'ed by: mdodd
2003-09-15 06:41:33 +00:00
MODULE_DEPEND(isp, cam, 1, 1, 1);
'Support' for ISP SBus cards. This code does not imply that SBus cards work yet. They hang for me. But I can't netboot the latest snapshot on my ultra1e, and things hang at bus_setup_intr time. Since I'm offline for a while, I thought I'd toss this in in case somebody else who has a bit better luck wants to fart around with it. Please try and wait until I get back to check things in.
2002-07-11 03:25:04 +00:00
int isp_announced = 0;
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
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 */
Push things closer to path failover by implementing loop down and gone device timers and zombie state entries. There are tunables that can be used to select a number of parameters. loop_down_limit - how long to wait for loop to come back up before declaring all devices dead (default 300 seconds) gone_device_time- how long to wait for a device that has appeared to leave the loop or fabric to reappear (default 30 seconds) Internal tunables include (which should be externalized): quick_boot_time- how long to wait when booting for loop to come up change_is_bad- whether or not to accept devices with the same WWNN/WWPN that reappear at a different PortID as being the 'same' device. Keen students of some of the subtle issues here will ask how one can keep devices from being re-accepted at all (the answer is to set a gone_device_time to zero- that effectively would be the same thing).
2006-11-14 08:45:48 +00:00
int isp_gone_device_time = 30; /* grace time before reporting device lost */
Unify port database use for target and initiator roles. Aside from cleaner and more consistent code, this allows ports to be both target and initiator same time, and easily switch from any role to any. Sponsored by: iXsystems, Inc.
2015-07-13 15:11:05 +00:00
static const char prom3[] = "Chan %d [%u] PortID 0x%06x Departed because of %s";
'Support' for ISP SBus cards. This code does not imply that SBus cards work yet. They hang for me. But I can't netboot the latest snapshot on my ultra1e, and things hang at bus_setup_intr time. Since I'm offline for a while, I thought I'd toss this in in case somebody else who has a bit better luck wants to fart around with it. Please try and wait until I get back to check things in.
2002-07-11 03:25:04 +00:00
One more round of port scanner rewrite. - Make scan aborted by event restart immediately and infinitely. - Improve handling of some loop events from firmware. - Remove loop down timer, adding its functionality to scanner thread. - Some more unification and simplification.
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;
a) clean up some declaration stuff (i.e., make more modern with respect to getting rid u_int for uint and so on). b) Turn back on 64 bit DAC support. Cheeze it a bit in that we have two DMA callback functions- one when we have bus_addr_t > 4 bits in width and the other which should be normal. Even Cheezier in that we turn off setting up DMA maps to be BUS_SPACE_MAXADDR if we're in ISP_TARGET_MODE. More work on this in a week or so. c) Tested under amd64 and 1MB DFLTPHYS, sparc64, i386 (PAE, but insufficient memory to really test > 4GB). LINT check under amd64. MFC after: 1 month
2006-02-15 00:31:48 +00:00
static void isp_cam_async(void *, uint32_t, struct cam_path *, void *);
Clarify and cleanup some CAM queueing breakages.
1999-08-16 20:11:45 +00:00
static void isp_poll(struct cam_sim *);
Use callout_func_t instead of the deprecated timeout_t. Reviewed by: kib, imp Differential Revision: https://reviews.freebsd.org/D22752
2019-12-10 22:06:53 +00:00
static callout_func_t isp_watchdog;
static callout_func_t isp_gdt;
Fixes zombie device and loop down timers so that they work more than once. Use taskqueues to do the actual work. Fix an offset line. Fix isp_prt so that prints from just one buffer, which makes it appear cleanly cleanly in logs on SMP systems. Approved by: re (kib) MFC after: 1 month
2011-08-12 19:51:28 +00:00
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 *);
Make a static chain of isp softcs- gdb usage becomes a lot easier. Add in a very large amount of target mode support code- this is just a first pass at this. It's a difficult thing because some of the code can be in platform independent areas (see isp_target.?) but a lot has to be in platform dependent areas because of not only the tight coupling of received commands/events and the specific OS subsystem but because the platform independent code has (deliberately) no event/wait mechanisms.
2000-01-03 23:55:30 +00:00
static void isp_action(struct cam_sim *, union ccb *);
More rototilling with target mode in an attemp to get multiple CCB at a time outstanding reliable. It's not there yet, but this is the direction to go in so might as well commit. So far, multiple at a time CCBs work (see ISP_INTERNAL_TARGET test mode), but it fails if there are more downstream than the SIM wants to handle and SRR is sort of confused when this happens, plus it is not entirely quite clear what one does if a CCB/CTIO fails and you have more in flight (that don't fail, say) and more queued up at the SIM level that haven't been started yet. Some of this is driven because there apparently is no flow control to requeue XPT_CONTINUE_IO requests like there are for XPT_SCSI_IO requests. It is also more driven in that the few target mode periph drivers there are are not really set up for handling pushback- heck most of them don't even check for errors (and what would they really do with them anyway? It's the initiator's problem, really....). The data transfer arithmetic has been worked over again to handle multiple outstanding commands, so you have a notion of what's been moved already as well as what's currently in flight. It turns that this led to uncovering a REPORT_LUNS bug in the ISP_INTERNAL_TARGET code which was sending back 24 bytes of rpl data instead of the specified 16. What happened furthermore here is that sending back 16 bytes and reporting an overrun of 8 bytes made the initiator (running FC-Tape aware f/w) mad enough to request, and keep requesting, another FCP response (I guess it didn't like the answer so kept asking for it again). Sponsored by: Spectralogic MFC after: 1 month
2012-08-08 18:24:33 +00:00
static int isp_timer_count;
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
static void isp_timer(void *);
Add in a watchdog routine to catch cases where we've dropped the command. Apparently the f/w has finished the command, but somehow an interrupt is being lost. So, we just plain wedge when booting alphas. This is a general routine we've needed for a while.
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 = {
Device megapatch 4/6: Introduce d_version field in struct cdevsw, this must always be initialized to D_VERSION. Flip sense of D_NOGIANT flag to D_NEEDGIANT, this involves removing four D_NOGIANT flags and adding 145 D_NEEDGIANT flags.
2004-02-21 21:10:55 +00:00
.d_version = D_VERSION,
Gigacommit to improve device-driver source compatibility between branches: Initialize struct cdevsw using C99 sparse initializtion and remove all initializations to default values. This patch is automatically generated and has been tested by compiling LINT with all the fields in struct cdevsw in reverse order on alpha, sparc64 and i386. Approved by: re(scottl)
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
};
Add dev.isp.X.role sysctl in addition to tunable. It (mostly) allows to enable/disable initiator mode in run time. Target mode control is blocked here to force coordination with CTL. While there, add separate tunables/sysctls for virtual channels.
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;
Make role sysctl handling from r284727 less strict.
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);
Add dev.isp.X.role sysctl in addition to tunable. It (mostly) allows to enable/disable initiator mode in run time. Target mode control is blocked here to force coordination with CTL. While there, add separate tunables/sysctls for virtual channels.
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. */
Drop discovered targets when initiator role is disabled.
2015-07-04 18:38:46 +00:00
error = isp_control(isp, ISPCTL_CHANGE_ROLE, chan, value);
Add dev.isp.X.role sysctl in addition to tunable. It (mostly) allows to enable/disable initiator mode in run time. Target mode control is blocked here to force coordination with CTL. While there, add separate tunables/sysctls for virtual channels.
2015-06-23 16:13:20 +00:00
ISP_UNLOCK(isp);
return (error);
}
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
static int
isp_attach_chan(ispsoftc_t *isp, struct cam_devq *devq, int chan)
Update QLogic ISP support for CAM. Add preliminary target mode support. Submitted by: Matthew Jacob <mjacob@feral.com>
1998-09-15 08:42:56 +00:00
{
struct ccb_setasync csa;
A large set of changes to handle dual bus adapters.
1999-05-11 05:10:06 +00:00
struct cam_sim *sim;
struct cam_path *path;
Fix multiple problems around LUN disable under load. - Move private data about ATIOs/INOTs from per-LUN to per-channel data. This allows active commands to continue operation after LUN destruction. This also simplifies lookup of the data by tag in some situations. - Unify three restart_queue processing implementations. - Complete all ATIOs from restart_queue on LUN disable. - Delete ATIO private data when command completed or aborted, not depending on the ATIO being requeued, that was ugly hack and could never happen. CAM should always call ether XPT_CONT_TARGET_IO with status or XPT_ABORT. - Implement XPT_ABORT for queued ATIOs/INOTs to allow CAM do graceful shutdown, not depending on LUN disable, as it is done in ahd(4)/targ(4). - Unify isp_endcmd() arguments to make it more usable in generic code. - Remove never really used LUN state reference counter. MFC after: 2 weeks
2017-02-22 06:43:49 +00:00
#ifdef ISP_TARGET_MODE
int i;
#endif
A large set of changes to handle dual bus adapters.
1999-05-11 05:10:06 +00:00
Clean/unify some macro usage. MFC after: 2 weeks
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)
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
return (ENOMEM);
Add in config_hook for catching when interrupts are safe- this allows us to not the ints are ok and also to (re)ENABLE isp interrupts. Remove all splcam()/splx() invocates and replace them with ISP_LOCK/ISP_UNLOCK macros.
2000-07-04 01:05:43 +00:00
Temp workaround for config_intrhook_establish running the hook right away.
2007-05-13 17:45:00 +00:00
ISP_LOCK(isp);
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
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);
Update QLogic ISP support for CAM. Add preliminary target mode support. Submitted by: Matthew Jacob <mjacob@feral.com>
1998-09-15 08:42:56 +00:00
}
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
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) {
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
ISP_LOCK(isp);
A large set of changes to handle dual bus adapters.
1999-05-11 05:10:06 +00:00
xpt_bus_deregister(cam_sim_path(sim));
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
ISP_UNLOCK(isp);
cam_sim_free(sim, FALSE);
return (ENXIO);
Update QLogic ISP support for CAM. Add preliminary target mode support. Submitted by: Matthew Jacob <mjacob@feral.com>
1998-09-15 08:42:56 +00:00
}
A large set of changes to handle dual bus adapters.
1999-05-11 05:10:06 +00:00
xpt_setup_ccb(&csa.ccb_h, path, 5);
Update QLogic ISP support for CAM. Add preliminary target mode support. Submitted by: Matthew Jacob <mjacob@feral.com>
1998-09-15 08:42:56 +00:00
csa.ccb_h.func_code = XPT_SASYNC_CB;
csa.event_enable = AC_LOST_DEVICE;
Implement and use Fast Posting for both parallel && fibre. Redo a bit of the startup code. Implement a call to outer framework function so that asynchronous events can be handled (e.g., speed negotiation, target mode). Roll internal release tags.
1999-01-30 07:29:00 +00:00
csa.callback = isp_cam_async;
A large set of changes to handle dual bus adapters.
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);
Update QLogic ISP support for CAM. Add preliminary target mode support. Submitted by: Matthew Jacob <mjacob@feral.com>
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);
Update QLogic ISP support for CAM. Add preliminary target mode support. Submitted by: Matthew Jacob <mjacob@feral.com>
1998-09-15 08:42:56 +00:00
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
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;
Missed addition to r313936. CTIO waitq present only in ISP_TARGET_MODE. MFC after: 2 weeks
2017-02-19 05:29:06 +00:00
#ifdef ISP_TARGET_MODE
Move CTIO waitq from per-LUN to per-channel. All resources lack of which may put CTIO into the queue are either per-channel or potentially per-queue, but none of them are per-LUN. This is a first step to fix live LUN disabling. Before this change any CTIOs held in a queue in time of disabling were just leaked. MFC after: 2 weeks
2017-02-19 05:07:02 +00:00
TAILQ_INIT(&spi->waitq);
Fix multiple problems around LUN disable under load. - Move private data about ATIOs/INOTs from per-LUN to per-channel data. This allows active commands to continue operation after LUN destruction. This also simplifies lookup of the data by tag in some situations. - Unify three restart_queue processing implementations. - Complete all ATIOs from restart_queue on LUN disable. - Delete ATIO private data when command completed or aborted, not depending on the ATIO being requeued, that was ugly hack and could never happen. CAM should always call ether XPT_CONT_TARGET_IO with status or XPT_ABORT. - Implement XPT_ABORT for queued ATIOs/INOTs to allow CAM do graceful shutdown, not depending on LUN disable, as it is done in ahd(4)/targ(4). - Unify isp_endcmd() arguments to make it more usable in generic code. - Remove never really used LUN state reference counter. MFC after: 2 weeks
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]);
Missed addition to r313936. CTIO waitq present only in ISP_TARGET_MODE. MFC after: 2 weeks
2017-02-19 05:29:06 +00:00
#endif
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
} else {
Fix cases where we've managed to get a Loop UP event prior to initializing the loop down counter, as well as other things. This was brought to my attention with a different fix, more for RELENG_7- this one covers the multiple channel case. PR: 140438 MFC after: 1 month
2009-12-04 03:34:12 +00:00
fcparam *fcp = FCPARAM(isp, chan);
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
struct isp_fc *fc = ISP_FC_PC(isp, chan);
Add dev.isp.X.role sysctl in addition to tunable. It (mostly) allows to enable/disable initiator mode in run time. Target mode control is blocked here to force coordination with CTL. While there, add separate tunables/sysctls for virtual channels.
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];
A large set of changes to handle dual bus adapters.
1999-05-11 05:10:06 +00:00
Fix cases where we've managed to get a Loop UP event prior to initializing the loop down counter, as well as other things. This was brought to my attention with a different fix, more for RELENG_7- this one covers the multiple channel case. PR: 140438 MFC after: 1 month
2009-12-04 03:34:12 +00:00
ISP_LOCK(isp);
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
fc->sim = sim;
fc->path = path;
fc->isp = isp;
Fix cases where we've managed to get a Loop UP event prior to initializing the loop down counter, as well as other things. This was brought to my attention with a different fix, more for RELENG_7- this one covers the multiple channel case. PR: 140438 MFC after: 1 month
2009-12-04 03:34:12 +00:00
fc->ready = 1;
Switch fabric scans from GID_FT to GID_PT+GFF_ID/GFT_ID. Instead of using GID_FT SNS request to get list of registered FCP ports, use GID_PT to get list of all Nx_Ports, and then use GFF_ID and/or GFT_ID requests to find whether they are FCP and target capable. The problem with old approach is that GID_FT does not report ports without FC-4 type registered. In particular it was impossible to boot OS from FreeBSD FC target using QLogic FC BIOS, since one does not register FC-4 type even on new cards and so ignored by old code as incompatible. As a side bonus this allows initiator to skip pointless logins to other initiators by fetching that information from SNS instead. In case some switches do not implement GFF_ID/GFT_ID correctly, add sysctls to disable that functionality. I handled broken GFF_ID of my Brocade 200E, but there may be other switches with different bugs. Linux also uses GID_PT, but GFF_ID is disabled by default there, and GFT_ID is not supported. Sponsored by: iXsystems, Inc.
2017-07-03 15:56:45 +00:00
fcp->isp_use_gft_id = 1;
fcp->isp_use_gff_id = 1;
Fixes zombie device and loop down timers so that they work more than once. Use taskqueues to do the actual work. Fix an offset line. Fix isp_prt so that prints from just one buffer, which makes it appear cleanly cleanly in logs on SMP systems. Approved by: re (kib) MFC after: 1 month
2011-08-12 19:51:28 +00:00
Clean/unify some macro usage. MFC after: 2 weeks
2017-03-21 10:34:34 +00:00
callout_init_mtx(&fc->gdt, &isp->isp_lock, 0);
Fixes zombie device and loop down timers so that they work more than once. Use taskqueues to do the actual work. Fix an offset line. Fix isp_prt so that prints from just one buffer, which makes it appear cleanly cleanly in logs on SMP systems. Approved by: re (kib) MFC after: 1 month
2011-08-12 19:51:28 +00:00
TASK_INIT(&fc->gtask, 1, isp_gdt_task, fc);
Missed addition to r313936. CTIO waitq present only in ISP_TARGET_MODE. MFC after: 2 weeks
2017-02-19 05:29:06 +00:00
#ifdef ISP_TARGET_MODE
Move CTIO waitq from per-LUN to per-channel. All resources lack of which may put CTIO into the queue are either per-channel or potentially per-queue, but none of them are per-LUN. This is a first step to fix live LUN disabling. Before this change any CTIOs held in a queue in time of disabling were just leaked. MFC after: 2 weeks
2017-02-19 05:07:02 +00:00
TAILQ_INIT(&fc->waitq);
Fix multiple problems around LUN disable under load. - Move private data about ATIOs/INOTs from per-LUN to per-channel data. This allows active commands to continue operation after LUN destruction. This also simplifies lookup of the data by tag in some situations. - Unify three restart_queue processing implementations. - Complete all ATIOs from restart_queue on LUN disable. - Delete ATIO private data when command completed or aborted, not depending on the ATIO being requeued, that was ugly hack and could never happen. CAM should always call ether XPT_CONT_TARGET_IO with status or XPT_ABORT. - Implement XPT_ABORT for queued ATIOs/INOTs to allow CAM do graceful shutdown, not depending on LUN disable, as it is done in ahd(4)/targ(4). - Unify isp_endcmd() arguments to make it more usable in generic code. - Remove never really used LUN state reference counter. MFC after: 2 weeks
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]);
Missed addition to r313936. CTIO waitq present only in ISP_TARGET_MODE. MFC after: 2 weeks
2017-02-19 05:29:06 +00:00
#endif
One more round of port scanner rewrite. - Make scan aborted by event restart immediately and infinitely. - Improve handling of some loop events from firmware. - Remove loop down timer, adding its functionality to scanner thread. - Some more unification and simplification.
2015-11-26 13:04:58 +00:00
isp_loop_changed(isp, chan);
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
ISP_UNLOCK(isp);
Remove ancient __FreeBSD_version checks. MFC after: 2 weeks
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)) {
Fix cases where we've managed to get a Loop UP event prior to initializing the loop down counter, as well as other things. This was brought to my attention with a different fix, more for RELENG_7- this one covers the multiple channel case. PR: 140438 MFC after: 1 month
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);
}
Export bunch of state variables as sysctls.
2015-10-13 11:02:56 +00:00
fc->num_threads += 1;
Add dev.isp.X.role sysctl in addition to tunable. It (mostly) allows to enable/disable initiator mode in run time. Target mode control is blocked here to force coordination with CTL. While there, add separate tunables/sysctls for virtual channels.
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),
Mark more nodes as CTLFLAG_MPSAFE or CTLFLAG_NEEDGIANT (17 of many) r357614 added CTLFLAG_NEEDGIANT to make it easier to find nodes that are still not MPSAFE (or already are but aren’t properly marked). Use it in preparation for a general review of all nodes. This is non-functional change that adds annotations to SYSCTL_NODE and SYSCTL_PROC nodes using one of the soon-to-be-required flags. Mark all obvious cases as MPSAFE. All entries that haven't been marked as MPSAFE before are by default marked as NEEDGIANT Approved by: kib (mentor, blanket) Commented by: kib, gallatin, melifaro Differential Revision: https://reviews.freebsd.org/D23718
2020-02-26 14:26:36 +00:00
OID_AUTO, name, CTLFLAG_RW | CTLFLAG_MPSAFE, 0,
"Virtual channel");
Add dev.isp.X.role sysctl in addition to tunable. It (mostly) allows to enable/disable initiator mode in run time. Target mode control is blocked here to force coordination with CTL. While there, add separate tunables/sysctls for virtual channels.
2015-06-23 16:13:20 +00:00
}
Export bunch of state variables as sysctls.
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)
Export bunch of state variables as sysctls.
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
Add dev.isp.X.role sysctl in addition to tunable. It (mostly) allows to enable/disable initiator mode in run time. Target mode control is blocked here to force coordination with CTL. While there, add separate tunables/sysctls for virtual channels.
2015-06-23 16:13:20 +00:00
SYSCTL_ADD_PROC(ctx, SYSCTL_CHILDREN(tree), OID_AUTO,
Mark more nodes as CTLFLAG_MPSAFE or CTLFLAG_NEEDGIANT (17 of many) r357614 added CTLFLAG_NEEDGIANT to make it easier to find nodes that are still not MPSAFE (or already are but aren’t properly marked). Use it in preparation for a general review of all nodes. This is non-functional change that adds annotations to SYSCTL_NODE and SYSCTL_PROC nodes using one of the soon-to-be-required flags. Mark all obvious cases as MPSAFE. All entries that haven't been marked as MPSAFE before are by default marked as NEEDGIANT Approved by: kib (mentor, blanket) Commented by: kib, gallatin, melifaro Differential Revision: https://reviews.freebsd.org/D23718
2020-02-26 14:26:36 +00:00
"role", CTLTYPE_INT | CTLFLAG_RW | CTLFLAG_NEEDGIANT,
isp, chan, isp_role_sysctl, "I", "Current role");
Export bunch of state variables as sysctls.
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");
Switch fabric scans from GID_FT to GID_PT+GFF_ID/GFT_ID. Instead of using GID_FT SNS request to get list of registered FCP ports, use GID_PT to get list of all Nx_Ports, and then use GFF_ID and/or GFT_ID requests to find whether they are FCP and target capable. The problem with old approach is that GID_FT does not report ports without FC-4 type registered. In particular it was impossible to boot OS from FreeBSD FC target using QLogic FC BIOS, since one does not register FC-4 type even on new cards and so ignored by old code as incompatible. As a side bonus this allows initiator to skip pointless logins to other initiators by fetching that information from SNS instead. In case some switches do not implement GFF_ID/GFT_ID correctly, add sysctls to disable that functionality. I handled broken GFF_ID of my Brocade 200E, but there may be other switches with different bugs. Linux also uses GID_PT, but GFF_ID is disabled by default there, and GFT_ID is not supported. Sponsored by: iXsystems, Inc.
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");
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
}
return (0);
}
Fix a kernel panic when unloading isp(4). In the current implementation, the isp_kthread() threads never exit. The target threads do have an exit mode from isp_attach(), but it is not invoked from isp_detach(). Ensure isp_detach() notifies threads started for each channel, such that they exit before their parent device softc detaches, and thus before the module does. Otherwise, a page fault panic occurs later in: sysctl_kern_proc sysctl_out_proc kern_proc_out fill_kinfo_proc fill_kinfo_thread strlcpy(kp->ki_wmesg, td->td_wmesg, sizeof(kp->ki_wmesg)); For isp_kthread() (and isp(4) target threads), td->td_wmesg references now-unmapped memory after the module has been unloaded. These threads are typically msleep()ing at the time of unload, but they could also attempt to execute now-unmapped code segments. MFC after: 1 month Sponsored by: Spectra Logic MFSpectraBSD: r1070921 on 2014/06/22 13:01:17
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)
Clean/unify some macro usage. MFC after: 2 weeks
2017-03-21 10:34:34 +00:00
mtx_sleep(isp, &isp->isp_lock, PRIBIO, "isp_reap", 100);
Fix a kernel panic when unloading isp(4). In the current implementation, the isp_kthread() threads never exit. The target threads do have an exit mode from isp_attach(), but it is not invoked from isp_detach(). Ensure isp_detach() notifies threads started for each channel, such that they exit before their parent device softc detaches, and thus before the module does. Otherwise, a page fault panic occurs later in: sysctl_kern_proc sysctl_out_proc kern_proc_out fill_kinfo_proc fill_kinfo_thread strlcpy(kp->ki_wmesg, td->td_wmesg, sizeof(kp->ki_wmesg)); For isp_kthread() (and isp(4) target threads), td->td_wmesg references now-unmapped memory after the module has been unloaded. These threads are typically msleep()ing at the time of unload, but they could also attempt to execute now-unmapped code segments. MFC after: 1 month Sponsored by: Spectra Logic MFSpectraBSD: r1070921 on 2014/06/22 13:01:17
2014-09-18 02:01:36 +00:00
}
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
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;
A large set of changes to handle dual bus adapters.
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
/*
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
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
*/
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
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);
Do some cleanup based upon adapter role- mainly not enabling interrupts if we're ISP_ROLE_NONE. Change ISPASYNC_LOGGED_INOUT to ISPASYNC_PROMENADE. Make sure we note if something is a fabric device. Target mode: Finally fix (to a first approximation) SCSI Target Mode again- we needed to correctly check against CAM_TARGET_WILDCARD and CAM_LUN_WILDCARD so that targbh won't confuse us. Comment out the drainqueue stuff for now. Use isp_fc_runstate instead if isp_control/ISPCTL_FCLINK_TEST.
2001-02-11 03:47:39 +00:00
}
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
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;
Make a static chain of isp softcs- gdb usage becomes a lot easier. Add in a very large amount of target mode support code- this is just a first pass at this. It's a difficult thing because some of the code can be in platform independent areas (see isp_target.?) but a lot has to be in platform dependent areas because of not only the tight coupling of received commands/events and the specific OS subsystem but because the platform independent code has (deliberately) no event/wait mechanisms.
2000-01-03 23:55:30 +00:00
}
}
Make this an MP safe driver but also still be multi-release. Seems to work on RELENG_4 through -current and also on sparc64 now. There may still be some issues with the auto attach/detach code to sort out. MFC after: 3 days
2007-05-05 20:17:23 +00:00
Clean/unify some macro usage. MFC after: 2 weeks
2017-03-21 10:34:34 +00:00
callout_init_mtx(&isp->isp_osinfo.tmo, &isp->isp_lock, 0);
More rototilling with target mode in an attemp to get multiple CCB at a time outstanding reliable. It's not there yet, but this is the direction to go in so might as well commit. So far, multiple at a time CCBs work (see ISP_INTERNAL_TARGET test mode), but it fails if there are more downstream than the SIM wants to handle and SRR is sort of confused when this happens, plus it is not entirely quite clear what one does if a CCB/CTIO fails and you have more in flight (that don't fail, say) and more queued up at the SIM level that haven't been started yet. Some of this is driven because there apparently is no flow control to requeue XPT_CONTINUE_IO requests like there are for XPT_SCSI_IO requests. It is also more driven in that the few target mode periph drivers there are are not really set up for handling pushback- heck most of them don't even check for errors (and what would they really do with them anyway? It's the initiator's problem, really....). The data transfer arithmetic has been worked over again to handle multiple outstanding commands, so you have a notion of what's been moved already as well as what's currently in flight. It turns that this led to uncovering a REPORT_LUNS bug in the ISP_INTERNAL_TARGET code which was sending back 24 bytes of rpl data instead of the specified 16. What happened furthermore here is that sending back 16 bytes and reporting an overrun of 8 bytes made the initiator (running FC-Tape aware f/w) mad enough to request, and keep requesting, another FCP response (I guess it didn't like the answer so kept asking for it again). Sponsored by: Spectralogic MFC after: 1 month
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);
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
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;
Fix a kernel panic when unloading isp(4). In the current implementation, the isp_kthread() threads never exit. The target threads do have an exit mode from isp_attach(), but it is not invoked from isp_detach(). Ensure isp_detach() notifies threads started for each channel, such that they exit before their parent device softc detaches, and thus before the module does. Otherwise, a page fault panic occurs later in: sysctl_kern_proc sysctl_out_proc kern_proc_out fill_kinfo_proc fill_kinfo_thread strlcpy(kp->ki_wmesg, td->td_wmesg, sizeof(kp->ki_wmesg)); For isp_kthread() (and isp(4) target threads), td->td_wmesg references now-unmapped memory after the module has been unloaded. These threads are typically msleep()ing at the time of unload, but they could also attempt to execute now-unmapped code segments. MFC after: 1 month Sponsored by: Spectra Logic MFSpectraBSD: r1070921 on 2014/06/22 13:01:17
2014-09-18 02:01:36 +00:00
ISP_GET_PC(isp, chan, sim, sim);
ISP_GET_PC(isp, chan, path, path);
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
xpt_free_path(path);
Make this an MP safe driver but also still be multi-release. Seems to work on RELENG_4 through -current and also on sparc64 now. There may still be some issues with the auto attach/detach code to sort out. MFC after: 3 days
2007-05-05 20:17:23 +00:00
ISP_LOCK(isp);
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
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);
}
Most of these changes to isp are to allow for isp.ko unloading. We also revive loop down freezes. We also externaliz within isp isp_prt_endcmd so something outside the core module can print something about a command completing. Also some work in progress to assist in handling timed out commands better. Partially Sponsored by: Panasas Approved by: re (kib) MFC after: 1 month
2011-08-13 23:34:17 +00:00
int
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
isp_detach(ispsoftc_t *isp)
{
int chan;
Remove some more dead code. MFC after: 2 weeks
2017-03-20 20:44:14 +00:00
if (isp->isp_osinfo.cdev) {
destroy_dev(isp->isp_osinfo.cdev);
isp->isp_osinfo.cdev = NULL;
Most of these changes to isp are to allow for isp.ko unloading. We also revive loop down freezes. We also externaliz within isp isp_prt_endcmd so something outside the core module can print something about a command completing. Also some work in progress to assist in handling timed out commands better. Partially Sponsored by: Panasas Approved by: re (kib) MFC after: 1 month
2011-08-13 23:34:17 +00:00
}
Remove some more dead code. MFC after: 2 weeks
2017-03-20 20:44:14 +00:00
ISP_LOCK(isp);
Fix a kernel panic when unloading isp(4). In the current implementation, the isp_kthread() threads never exit. The target threads do have an exit mode from isp_attach(), but it is not invoked from isp_detach(). Ensure isp_detach() notifies threads started for each channel, such that they exit before their parent device softc detaches, and thus before the module does. Otherwise, a page fault panic occurs later in: sysctl_kern_proc sysctl_out_proc kern_proc_out fill_kinfo_proc fill_kinfo_thread strlcpy(kp->ki_wmesg, td->td_wmesg, sizeof(kp->ki_wmesg)); For isp_kthread() (and isp(4) target threads), td->td_wmesg references now-unmapped memory after the module has been unloaded. These threads are typically msleep()ing at the time of unload, but they could also attempt to execute now-unmapped code segments. MFC after: 1 month Sponsored by: Spectra Logic MFSpectraBSD: r1070921 on 2014/06/22 13:01:17
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);
Most of these changes to isp are to allow for isp.ko unloading. We also revive loop down freezes. We also externaliz within isp isp_prt_endcmd so something outside the core module can print something about a command completing. Also some work in progress to assist in handling timed out commands better. Partially Sponsored by: Panasas Approved by: re (kib) MFC after: 1 month
2011-08-13 23:34:17 +00:00
ISP_UNLOCK(isp);
Remove some more dead code. MFC after: 2 weeks
2017-03-20 20:44:14 +00:00
callout_drain(&isp->isp_osinfo.tmo);
cam_simq_free(isp->isp_osinfo.devq);
Most of these changes to isp are to allow for isp.ko unloading. We also revive loop down freezes. We also externaliz within isp isp_prt_endcmd so something outside the core module can print something about a command completing. Also some work in progress to assist in handling timed out commands better. Partially Sponsored by: Panasas Approved by: re (kib) MFC after: 1 month
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
}
Push things closer to path failover by implementing loop down and gone device timers and zombie state entries. There are tunables that can be used to select a number of parameters. loop_down_limit - how long to wait for loop to come back up before declaring all devices dead (default 300 seconds) gone_device_time- how long to wait for a device that has appeared to leave the loop or fabric to reappear (default 30 seconds) Internal tunables include (which should be externalized): quick_boot_time- how long to wait when booting for loop to come up change_is_bad- whether or not to accept devices with the same WWNN/WWPN that reappear at a different PortID as being the 'same' device. Keen students of some of the subtle issues here will ask how one can keep devices from being re-accepted at all (the answer is to set a gone_device_time to zero- that effectively would be the same thing).
2006-11-14 08:45:48 +00:00
static void
One more round of port scanner rewrite. - Make scan aborted by event restart immediately and infinitely. - Improve handling of some loop events from firmware. - Remove loop down timer, adding its functionality to scanner thread. - Some more unification and simplification.
2015-11-26 13:04:58 +00:00
isp_freeze_loopdown(ispsoftc_t *isp, int chan)
Add get/set param ioctl support. Remove sim queue freezes for resource shortages. I've had too many strange race conditions where I freeze on a resource shortage but never get unfrozen. Consolidate the remaining sim queue freeze condition (for loopdown) into an inline with debug messages that allows us to track problems at ISP_LOGDEBUG0 level easier. Change a bunch of debug messages about loop down/up conditions to ISP_LOGDEBUG0 level. Remove dead isp_relsim code. Change some internal flag stuff for efficiency. Complain vociferously if we try and use our FC scratch area while it's busy being used already (I mean, if we don't have solaris' ability to sleep as an interrupt thread which would allow us to just use a p/v semaphore, at least *say* when you've just borked yourself). Add infrastructure to allow overrides of hard loopid && initiator id from boot variables. Fix the usual quota of silly bugs: + 'ktmature' needs to be per-instance. Argh. + When entering isp_watchdog, set intsok to zero, preserving old value to restore later. It's not nice to try and sleep from splsoftclock. + Fix tick overflow buglet in checking timeout value. MFC after: 1 week
2002-07-08 17:42:47 +00:00
{
Fix panic when SIM dereferenced before allocation. MFC after: 2 weeks
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;
Add get/set param ioctl support. Remove sim queue freezes for resource shortages. I've had too many strange race conditions where I freeze on a resource shortage but never get unfrozen. Consolidate the remaining sim queue freeze condition (for loopdown) into an inline with debug messages that allows us to track problems at ISP_LOGDEBUG0 level easier. Change a bunch of debug messages about loop down/up conditions to ISP_LOGDEBUG0 level. Remove dead isp_relsim code. Change some internal flag stuff for efficiency. Complain vociferously if we try and use our FC scratch area while it's busy being used already (I mean, if we don't have solaris' ability to sleep as an interrupt thread which would allow us to just use a p/v semaphore, at least *say* when you've just borked yourself). Add infrastructure to allow overrides of hard loopid && initiator id from boot variables. Fix the usual quota of silly bugs: + 'ktmature' needs to be per-instance. Argh. + When entering isp_watchdog, set intsok to zero, preserving old value to restore later. It's not nice to try and sleep from splsoftclock. + Fix tick overflow buglet in checking timeout value. MFC after: 1 week
2002-07-08 17:42:47 +00:00
}
}
Most of these changes to isp are to allow for isp.ko unloading. We also revive loop down freezes. We also externaliz within isp isp_prt_endcmd so something outside the core module can print something about a command completing. Also some work in progress to assist in handling timed out commands better. Partially Sponsored by: Panasas Approved by: re (kib) MFC after: 1 month
2011-08-13 23:34:17 +00:00
static void
isp_unfreeze_loopdown(ispsoftc_t *isp, int chan)
{
Fix panic when SIM dereferenced before allocation. MFC after: 2 weeks
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();
Most of these changes to isp are to allow for isp.ko unloading. We also revive loop down freezes. We also externaliz within isp isp_prt_endcmd so something outside the core module can print something about a command completing. Also some work in progress to assist in handling timed out commands better. Partially Sponsored by: Panasas Approved by: re (kib) MFC after: 1 month
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
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
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
{
Some more gratuitous format and name changes. Pull in some target mode changes from a private branch. Pull in some more RELENG_4 compilation changes. A lot of lines changed, but not much content change yet.
2006-04-21 18:30:01 +00:00
ispsoftc_t *isp;
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
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
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
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
micro fix from justin
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;
}
Checkpoint of work in progress in cleaning up target mode. It actually seems to work well in RELENG_4. However, 5.X locking foo means that I'll have to do some quick redesign. Add ioctl handlers for ISP_GETROLE and ISP_SETROLE ioctls.
2004-02-07 03:47:33 +00:00
case ISP_GETROLE:
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
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 {
Rip off target mode support for parallel SCSI QLogic adapters. Hacks to enable target mode there complicated code, while didn't really work. And for outdated hardware fixing it is not really interesting. Initiator mode tested with Qlogic 1080 adapter is still working fine.
2015-11-23 10:06:19 +00:00
*(int *)addr = ISP_ROLE_INITIATOR;
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
}
Checkpoint of work in progress in cleaning up target mode. It actually seems to work well in RELENG_4. However, 5.X locking foo means that I'll have to do some quick redesign. Add ioctl handlers for ISP_GETROLE and ISP_SETROLE ioctls.
2004-02-07 03:47:33 +00:00
retval = 0;
break;
case ISP_SETROLE:
Rip off target mode support for parallel SCSI QLogic adapters. Hacks to enable target mode there complicated code, while didn't really work. And for outdated hardware fixing it is not really interesting. Initiator mode tested with Qlogic 1080 adapter is still working fine.
2015-11-23 10:06:19 +00:00
if (IS_SCSI(isp))
break;
Checkpoint of work in progress in cleaning up target mode. It actually seems to work well in RELENG_4. However, 5.X locking foo means that I'll have to do some quick redesign. Add ioctl handlers for ISP_GETROLE and ISP_SETROLE ioctls.
2004-02-07 03:47:33 +00:00
nr = *(int *)addr;
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
chan = nr >> 8;
if (chan < 0 || chan >= isp->isp_nchan) {
retval = -ENXIO;
break;
}
nr &= 0xff;
Checkpoint of work in progress in cleaning up target mode. It actually seems to work well in RELENG_4. However, 5.X locking foo means that I'll have to do some quick redesign. Add ioctl handlers for ISP_GETROLE and ISP_SETROLE ioctls.
2004-02-07 03:47:33 +00:00
if (nr & ~(ISP_ROLE_INITIATOR|ISP_ROLE_TARGET)) {
retval = EINVAL;
break;
}
Make first step toward supporting target and initiator roles same time. To avoid conflicts between target and initiator devices in CAM, make CTL use target ID reported by HBA as its initiator_id in XPT_PATH_INQ. That target ID is known to never be used for initiator role, so it won't conflict. For Fibre Channel and FireWire HBAs this specific ID choice is irrelevant since all target IDs there are virtual. Same time for SPI HBAs it seems could be even requirement to use same target ID for both initiator and target roles. While there are some more things to polish in isp(4) driver, first tests of using both roles same time on the same port appeared successfull: # camcontrol devlist -v scbus0 on isp0 bus 0: <FREEBSD CTLDISK 0001> at scbus0 target 1 lun 0 (da20,pass21) <> at scbus0 target 256 lun 0 (ctl0) <> at scbus0 target -1 lun ffffffff (ctl1)
2015-07-05 03:38:58 +00:00
ISP_LOCK(isp);
Rip off target mode support for parallel SCSI QLogic adapters. Hacks to enable target mode there complicated code, while didn't really work. And for outdated hardware fixing it is not really interesting. Initiator mode tested with Qlogic 1080 adapter is still working fine.
2015-11-23 10:06:19 +00:00
*(int *)addr = FCPARAM(isp, chan)->role;
Drop discovered targets when initiator role is disabled.
2015-07-04 18:38:46 +00:00
retval = isp_control(isp, ISPCTL_CHANGE_ROLE, chan, nr);
ISP_UNLOCK(isp);
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
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:
Remove some ioctls that were ill-thought out. There is no user impact as no softwware using these ioctls was ever committed. Redo locking for ispioctl.
2007-06-11 19:15:49 +00:00
ISP_LOCK(isp);
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
isp_reinit(isp, 0);
Remove some ioctls that were ill-thought out. There is no user impact as no softwware using these ioctls was ever committed. Redo locking for ispioctl.
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;
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
Reorder some of the ioctls and add a few new ones. MFC after: 1 day
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)) {
Fix ISP_FC_LIP and ISP_RESCAN on big-endian 64-bit systems. For _IO() ioctls, addr is a pointer to uap->data which is a caddr_t. When the caddr_t stores an int, dereferencing addr as an (int *) results in truncation on little-endian 64-bit systems and corruption (owing to extracting top bits) on big-endian 64-bit systems. In practice the value of chan was probably always zero on systems of the latter type as all such FreeBSD platforms use a register-based calling convention. Reviewed by: mav Obtained from: CheriBSD MFC after: 1 week Sponsored by: DARPA, AFRL Differential Revision: https://reviews.freebsd.org/D14673
2018-03-13 19:56:10 +00:00
chan = *(intptr_t *)addr;
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
if (chan < 0 || chan >= isp->isp_nchan) {
retval = -ENXIO;
break;
}
Remove some ioctls that were ill-thought out. There is no user impact as no softwware using these ioctls was ever committed. Redo locking for ispioctl.
2007-06-11 19:15:49 +00:00
ISP_LOCK(isp);
One more round of port scanner rewrite. - Make scan aborted by event restart immediately and infinitely. - Improve handling of some loop events from firmware. - Remove loop down timer, adding its functionality to scanner thread. - Some more unification and simplification.
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;
}
Remove some ioctls that were ill-thought out. There is no user impact as no softwware using these ioctls was ever committed. Redo locking for ispioctl.
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;
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
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)) {
Fix ISP_FC_LIP and ISP_RESCAN on big-endian 64-bit systems. For _IO() ioctls, addr is a pointer to uap->data which is a caddr_t. When the caddr_t stores an int, dereferencing addr as an (int *) results in truncation on little-endian 64-bit systems and corruption (owing to extracting top bits) on big-endian 64-bit systems. In practice the value of chan was probably always zero on systems of the latter type as all such FreeBSD platforms use a register-based calling convention. Reviewed by: mav Obtained from: CheriBSD MFC after: 1 week Sponsored by: DARPA, AFRL Differential Revision: https://reviews.freebsd.org/D14673
2018-03-13 19:56:10 +00:00
chan = *(intptr_t *)addr;
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
if (chan < 0 || chan >= isp->isp_nchan) {
retval = -ENXIO;
break;
}
Remove some ioctls that were ill-thought out. There is no user impact as no softwware using these ioctls was ever committed. Redo locking for ispioctl.
2007-06-11 19:15:49 +00:00
ISP_LOCK(isp);
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
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;
}
Remove some ioctls that were ill-thought out. There is no user impact as no softwware using these ioctls was ever committed. Redo locking for ispioctl.
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;
Add 4Gb (24XX) support and lay the foundation for a lot of new stuff.
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
Clean up the ioctl to not process nonsense on SCSI isp cards. MFC after: 1 month
2006-07-10 22:39:32 +00:00
if (IS_SCSI(isp)) {
break;
}
Get rid of a couple of Coverity found sign comparison errors. Approved by: re (Ken) MFC after: 3 days
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;
}
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
lp = &FCPARAM(isp, ifc->chan)->portdb[ifc->loopid];
Unify port database use for target and initiator roles. Aside from cleaner and more consistent code, this allows ports to be both target and initiator same time, and easily switch from any role to any. Sponsored by: iXsystems, Inc.
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;
Add 4Gb (24XX) support and lay the foundation for a lot of new stuff.
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;
}
Add support for ISP_FC_GETHINFO, which returns current connection topology, speed, loopid, WWPN/WWNN, etc. Beef up target mode. Add isp_handle_platform_notify_scsi and isp_handle_platform_notify_fc platform handlers to handle immediate notifies (isp_handle_platform_notify_scsi is still stubbed out). In implementation of isp_handle_platform_notify_fc, for IN_ABORT_TASK, peel off a pending XPT_IMMED_NOTIFY and call xpt_done on it and hope that somebody upstream is listening. Make sure on final CTIO2s that we set residual correctly. These are absolutely crucial. Make sure we set relative offset for each CTIO2 based upon bytes we've already xferred. This is what the private adjunct datat to the original ATIO is. Note state of command so we can figure out where to find it if we get an ABORT from the firmware. Make sure we *always* set CAM_TAG_ACTION_VALID for ATIO2s. Make sure we keep track of the original lun. If se sent status (or we're otherwise done with the command), don't forget to free the adjunct structure.
2002-06-16 05:08:02 +00:00
case ISP_FC_GETHINFO:
{
struct isp_hba_device *hba = (struct isp_hba_device *) addr;
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
int chan = hba->fc_channel;
Clean up the ioctl to not process nonsense on SCSI isp cards. MFC after: 1 month
2006-07-10 22:39:32 +00:00
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
if (chan < 0 || chan >= isp->isp_nchan) {
retval = ENXIO;
break;
}
Add firmware major, minor and micro revsions to the ISP_FC_GETHINFO ioctl structure.
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);
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
hba->fc_nchannels = isp->isp_nchan;
Clean up the ioctl to not process nonsense on SCSI isp cards. MFC after: 1 month
2006-07-10 22:39:32 +00:00
if (IS_FC(isp)) {
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
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;
Clean up the ioctl to not process nonsense on SCSI isp cards. MFC after: 1 month
2006-07-10 22:39:32 +00:00
}
Add support for ISP_FC_GETHINFO, which returns current connection topology, speed, loopid, WWPN/WWNN, etc. Beef up target mode. Add isp_handle_platform_notify_scsi and isp_handle_platform_notify_fc platform handlers to handle immediate notifies (isp_handle_platform_notify_scsi is still stubbed out). In implementation of isp_handle_platform_notify_fc, for IN_ABORT_TASK, peel off a pending XPT_IMMED_NOTIFY and call xpt_done on it and hope that somebody upstream is listening. Make sure on final CTIO2s that we set residual correctly. These are absolutely crucial. Make sure we set relative offset for each CTIO2 based upon bytes we've already xferred. This is what the private adjunct datat to the original ATIO is. Note state of command so we can figure out where to find it if we get an ABORT from the firmware. Make sure we *always* set CAM_TAG_ACTION_VALID for ATIO2s. Make sure we keep track of the original lun. If se sent status (or we're otherwise done with the command), don't forget to free the adjunct structure.
2002-06-16 05:08:02 +00:00
retval = 0;
break;
}
Add an ioctl framework for doing FC task management functions from a user space tool- useful for doing FC target mode certification.
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;
Remove some confusions between loopid and nphdl. Modern cards in most cases operate abstract port handles, that have no any relation to real loop IDs. Leave loopid used only where it really goes about local loop IDs. While there, fix few more cases where LUNs were still printed in decimal.
2015-11-18 11:14:59 +00:00
uint16_t nphdl;
Add an ioctl framework for doing FC task management functions from a user space tool- useful for doing FC target mode certification.
2005-10-29 02:46:59 +00:00
mbreg_t mbs;
if (IS_SCSI(isp)) {
break;
}
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
chan = fct->chan;
if (chan < 0 || chan >= isp->isp_nchan) {
retval = -ENXIO;
Add an ioctl framework for doing FC task management functions from a user space tool- useful for doing FC target mode certification.
2005-10-29 02:46:59 +00:00
break;
}
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
needmarker = retval = 0;
Remove some confusions between loopid and nphdl. Modern cards in most cases operate abstract port handles, that have no any relation to real loop IDs. Leave loopid used only where it really goes about local loop IDs. While there, fix few more cases where LUNs were still printed in decimal.
2015-11-18 11:14:59 +00:00
nphdl = fct->loopid;
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
ISP_LOCK(isp);
if (IS_24XX(isp)) {
Reimplement ISP_TSK_MGMT IOCTL via asynchronous request. I am not sure this code is not completely dead, but it used DMA scratch are without good reason and asked to be refactored.
2016-04-12 12:31:41 +00:00
void *reqp;
uint8_t resp[QENTRY_LEN];
isp24xx_tmf_t tmf;
isp24xx_statusreq_t sp;
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
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];
Remove some confusions between loopid and nphdl. Modern cards in most cases operate abstract port handles, that have no any relation to real loop IDs. Leave loopid used only where it really goes about local loop IDs. While there, fix few more cases where LUNs were still printed in decimal.
2015-11-18 11:14:59 +00:00
if (lp->handle == nphdl) {
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
break;
}
Add an ioctl framework for doing FC task management functions from a user space tool- useful for doing FC target mode certification.
2005-10-29 02:46:59 +00:00
}
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
if (i == MAX_FC_TARG) {
retval = ENXIO;
ISP_UNLOCK(isp);
break;
}
Reimplement ISP_TSK_MGMT IOCTL via asynchronous request. I am not sure this code is not completely dead, but it used DMA scratch are without good reason and asked to be refactored.
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;
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
if (fct->lun >= 256) {
Reimplement ISP_TSK_MGMT IOCTL via asynchronous request. I am not sure this code is not completely dead, but it used DMA scratch are without good reason and asked to be refactored.
2016-04-12 12:31:41 +00:00
tmf.tmf_lun[0] = 0x40 | (fct->lun >> 8);
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
}
switch (fct->action) {
case IPT_CLEAR_ACA:
Reimplement ISP_TSK_MGMT IOCTL via asynchronous request. I am not sure this code is not completely dead, but it used DMA scratch are without good reason and asked to be refactored.
2016-04-12 12:31:41 +00:00
tmf.tmf_flags = ISP24XX_TMF_CLEAR_ACA;
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
break;
case IPT_TARGET_RESET:
Reimplement ISP_TSK_MGMT IOCTL via asynchronous request. I am not sure this code is not completely dead, but it used DMA scratch are without good reason and asked to be refactored.
2016-04-12 12:31:41 +00:00
tmf.tmf_flags = ISP24XX_TMF_TARGET_RESET;
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
needmarker = 1;
break;
case IPT_LUN_RESET:
Reimplement ISP_TSK_MGMT IOCTL via asynchronous request. I am not sure this code is not completely dead, but it used DMA scratch are without good reason and asked to be refactored.
2016-04-12 12:31:41 +00:00
tmf.tmf_flags = ISP24XX_TMF_LUN_RESET;
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
needmarker = 1;
break;
case IPT_CLEAR_TASK_SET:
Reimplement ISP_TSK_MGMT IOCTL via asynchronous request. I am not sure this code is not completely dead, but it used DMA scratch are without good reason and asked to be refactored.
2016-04-12 12:31:41 +00:00
tmf.tmf_flags = ISP24XX_TMF_CLEAR_TASK_SET;
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
needmarker = 1;
break;
case IPT_ABORT_TASK_SET:
Reimplement ISP_TSK_MGMT IOCTL via asynchronous request. I am not sure this code is not completely dead, but it used DMA scratch are without good reason and asked to be refactored.
2016-04-12 12:31:41 +00:00
tmf.tmf_flags = ISP24XX_TMF_ABORT_TASK_SET;
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
needmarker = 1;
break;
default:
retval = EINVAL;
break;
}
if (retval) {
ISP_UNLOCK(isp);
break;
}
Reimplement ISP_TSK_MGMT IOCTL via asynchronous request. I am not sure this code is not completely dead, but it used DMA scratch are without good reason and asked to be refactored.
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);
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
ISP_UNLOCK(isp);
retval = ENOMEM;
break;
}
Reimplement ISP_TSK_MGMT IOCTL via asynchronous request. I am not sure this code is not completely dead, but it used DMA scratch are without good reason and asked to be refactored.
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);
Add an ioctl framework for doing FC task management functions from a user space tool- useful for doing FC target mode certification.
2005-10-29 02:46:59 +00:00
retval = EIO;
Reimplement ISP_TSK_MGMT IOCTL via asynchronous request. I am not sure this code is not completely dead, but it used DMA scratch are without good reason and asked to be refactored.
2016-04-12 12:31:41 +00:00
break;
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
}
Reimplement ISP_TSK_MGMT IOCTL via asynchronous request. I am not sure this code is not completely dead, but it used DMA scratch are without good reason and asked to be refactored.
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;
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
}
Reimplement ISP_TSK_MGMT IOCTL via asynchronous request. I am not sure this code is not completely dead, but it used DMA scratch are without good reason and asked to be refactored.
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;
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
} else {
MBSINIT(&mbs, 0, MBLOGALL, 0);
if (ISP_CAP_2KLOGIN(isp) == 0) {
Remove some confusions between loopid and nphdl. Modern cards in most cases operate abstract port handles, that have no any relation to real loop IDs. Leave loopid used only where it really goes about local loop IDs. While there, fix few more cases where LUNs were still printed in decimal.
2015-11-18 11:14:59 +00:00
nphdl <<= 8;
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
}
switch (fct->action) {
case IPT_CLEAR_ACA:
mbs.param[0] = MBOX_CLEAR_ACA;
Remove some confusions between loopid and nphdl. Modern cards in most cases operate abstract port handles, that have no any relation to real loop IDs. Leave loopid used only where it really goes about local loop IDs. While there, fix few more cases where LUNs were still printed in decimal.
2015-11-18 11:14:59 +00:00
mbs.param[1] = nphdl;
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
mbs.param[2] = fct->lun;
break;
case IPT_TARGET_RESET:
mbs.param[0] = MBOX_TARGET_RESET;
Remove some confusions between loopid and nphdl. Modern cards in most cases operate abstract port handles, that have no any relation to real loop IDs. Leave loopid used only where it really goes about local loop IDs. While there, fix few more cases where LUNs were still printed in decimal.
2015-11-18 11:14:59 +00:00
mbs.param[1] = nphdl;
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
needmarker = 1;
break;
case IPT_LUN_RESET:
mbs.param[0] = MBOX_LUN_RESET;
Remove some confusions between loopid and nphdl. Modern cards in most cases operate abstract port handles, that have no any relation to real loop IDs. Leave loopid used only where it really goes about local loop IDs. While there, fix few more cases where LUNs were still printed in decimal.
2015-11-18 11:14:59 +00:00
mbs.param[1] = nphdl;
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
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;
Remove some confusions between loopid and nphdl. Modern cards in most cases operate abstract port handles, that have no any relation to real loop IDs. Leave loopid used only where it really goes about local loop IDs. While there, fix few more cases where LUNs were still printed in decimal.
2015-11-18 11:14:59 +00:00
mbs.param[1] = nphdl;
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
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;
Remove some confusions between loopid and nphdl. Modern cards in most cases operate abstract port handles, that have no any relation to real loop IDs. Leave loopid used only where it really goes about local loop IDs. While there, fix few more cases where LUNs were still printed in decimal.
2015-11-18 11:14:59 +00:00
mbs.param[1] = nphdl;
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
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;
}
}
Add an ioctl framework for doing FC task management functions from a user space tool- useful for doing FC target mode certification.
2005-10-29 02:46:59 +00:00
}
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
ISP_UNLOCK(isp);
Add an ioctl framework for doing FC task management functions from a user space tool- useful for doing FC target mode certification.
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);
Make a static chain of isp softcs- gdb usage becomes a lot easier. Add in a very large amount of target mode support code- this is just a first pass at this. It's a difficult thing because some of the code can be in platform independent areas (see isp_target.?) but a lot has to be in platform dependent areas because of not only the tight coupling of received commands/events and the specific OS subsystem but because the platform independent code has (deliberately) no event/wait mechanisms.
2000-01-03 23:55:30 +00:00
}
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
/*
* Local Inlines
*/
Push things closer to path failover by implementing loop down and gone device timers and zombie state entries. There are tunables that can be used to select a number of parameters. loop_down_limit - how long to wait for loop to come back up before declaring all devices dead (default 300 seconds) gone_device_time- how long to wait for a device that has appeared to leave the loop or fabric to reappear (default 30 seconds) Internal tunables include (which should be externalized): quick_boot_time- how long to wait when booting for loop to come up change_is_bad- whether or not to accept devices with the same WWNN/WWPN that reappear at a different PortID as being the 'same' device. Keen students of some of the subtle issues here will ask how one can keep devices from being re-accepted at all (the answer is to set a gone_device_time to zero- that effectively would be the same thing).
2006-11-14 08:45:48 +00:00
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
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 *);
Push things closer to path failover by implementing loop down and gone device timers and zombie state entries. There are tunables that can be used to select a number of parameters. loop_down_limit - how long to wait for loop to come back up before declaring all devices dead (default 300 seconds) gone_device_time- how long to wait for a device that has appeared to leave the loop or fabric to reappear (default 30 seconds) Internal tunables include (which should be externalized): quick_boot_time- how long to wait when booting for loop to come up change_is_bad- whether or not to accept devices with the same WWNN/WWPN that reappear at a different PortID as being the 'same' device. Keen students of some of the subtle issues here will ask how one can keep devices from being re-accepted at all (the answer is to set a gone_device_time to zero- that effectively would be the same thing).
2006-11-14 08:45:48 +00:00
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
static ISP_INLINE int
isp_get_pcmd(ispsoftc_t *isp, union ccb *ccb)
Add in config_hook for catching when interrupts are safe- this allows us to not the ints are ok and also to (re)ENABLE isp interrupts. Remove all splcam()/splx() invocates and replace them with ISP_LOCK/ISP_UNLOCK macros.
2000-07-04 01:05:43 +00:00
{
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
ISP_PCMD(ccb) = isp->isp_osinfo.pcmd_free;
if (ISP_PCMD(ccb) == NULL) {
return (-1);
Do some cleanup based upon adapter role- mainly not enabling interrupts if we're ISP_ROLE_NONE. Change ISPASYNC_LOGGED_INOUT to ISPASYNC_PROMENADE. Make sure we note if something is a fabric device. Target mode: Finally fix (to a first approximation) SCSI Target Mode again- we needed to correctly check against CAM_TARGET_WILDCARD and CAM_LUN_WILDCARD so that targbh won't confuse us. Comment out the drainqueue stuff for now. Use isp_fc_runstate instead if isp_control/ISPCTL_FCLINK_TEST.
2001-02-11 03:47:39 +00:00
}
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
isp->isp_osinfo.pcmd_free = ((struct isp_pcmd *)ISP_PCMD(ccb))->next;
return (0);
Add in config_hook for catching when interrupts are safe- this allows us to not the ints are ok and also to (re)ENABLE isp interrupts. Remove all splcam()/splx() invocates and replace them with ISP_LOCK/ISP_UNLOCK macros.
2000-07-04 01:05:43 +00:00
}
Make a static chain of isp softcs- gdb usage becomes a lot easier. Add in a very large amount of target mode support code- this is just a first pass at this. It's a difficult thing because some of the code can be in platform independent areas (see isp_target.?) but a lot has to be in platform dependent areas because of not only the tight coupling of received commands/events and the specific OS subsystem but because the platform independent code has (deliberately) no event/wait mechanisms.
2000-01-03 23:55:30 +00:00
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
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)) {
Fix an oops where we wiped out DMA maps. Don't allocate extended command space for anything less than a 2300. MFC after: 1 month X-MFC: 238869
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;
}
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
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
Make a static chain of isp softcs- gdb usage becomes a lot easier. Add in a very large amount of target mode support code- this is just a first pass at this. It's a difficult thing because some of the code can be in platform independent areas (see isp_target.?) but a lot has to be in platform dependent areas because of not only the tight coupling of received commands/events and the specific OS subsystem but because the platform independent code has (deliberately) no event/wait mechanisms.
2000-01-03 23:55:30 +00:00
/*
* Put the target mode functions here, because some are inlines
*/
#ifdef ISP_TARGET_MODE
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
static ISP_INLINE tstate_t *get_lun_statep(ispsoftc_t *, int, lun_id_t);
Fix multiple problems around LUN disable under load. - Move private data about ATIOs/INOTs from per-LUN to per-channel data. This allows active commands to continue operation after LUN destruction. This also simplifies lookup of the data by tag in some situations. - Unify three restart_queue processing implementations. - Complete all ATIOs from restart_queue on LUN disable. - Delete ATIO private data when command completed or aborted, not depending on the ATIO being requeued, that was ugly hack and could never happen. CAM should always call ether XPT_CONT_TARGET_IO with status or XPT_ABORT. - Implement XPT_ABORT for queued ATIOs/INOTs to allow CAM do graceful shutdown, not depending on LUN disable, as it is done in ahd(4)/targ(4). - Unify isp_endcmd() arguments to make it more usable in generic code. - Remove never really used LUN state reference counter. MFC after: 2 weeks
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 *);
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
static cam_status create_lun_state(ispsoftc_t *, int, struct cam_path *, tstate_t **);
Fix multiple problems around LUN disable under load. - Move private data about ATIOs/INOTs from per-LUN to per-channel data. This allows active commands to continue operation after LUN destruction. This also simplifies lookup of the data by tag in some situations. - Unify three restart_queue processing implementations. - Complete all ATIOs from restart_queue on LUN disable. - Delete ATIO private data when command completed or aborted, not depending on the ATIO being requeued, that was ugly hack and could never happen. CAM should always call ether XPT_CONT_TARGET_IO with status or XPT_ABORT. - Implement XPT_ABORT for queued ATIOs/INOTs to allow CAM do graceful shutdown, not depending on LUN disable, as it is done in ahd(4)/targ(4). - Unify isp_endcmd() arguments to make it more usable in generic code. - Remove never really used LUN state reference counter. MFC after: 2 weeks
2017-02-22 06:43:49 +00:00
static void destroy_lun_state(ispsoftc_t *, int, tstate_t *);
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
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 *);
Use callout_func_t instead of the deprecated timeout_t. Reviewed by: kib, imp Differential Revision: https://reviews.freebsd.org/D22752
2019-12-10 22:06:53 +00:00
static callout_func_t isp_refire_putback_atio;
static callout_func_t isp_refire_notify_ack;
Redo a lot of the target mode infrastructure to be cognizant of Dual Bus cards like the 1280 && the 12160. Cleanup isp_target_putback_atio. Make sure bus and correct tag ids and firmware handles get propagated as needed.
2001-04-04 21:58:29 +00:00
static void isp_complete_ctio(union ccb *);
static void isp_target_putback_atio(union ccb *);
More rototilling with target mode in an attemp to get multiple CCB at a time outstanding reliable. It's not there yet, but this is the direction to go in so might as well commit. So far, multiple at a time CCBs work (see ISP_INTERNAL_TARGET test mode), but it fails if there are more downstream than the SIM wants to handle and SRR is sort of confused when this happens, plus it is not entirely quite clear what one does if a CCB/CTIO fails and you have more in flight (that don't fail, say) and more queued up at the SIM level that haven't been started yet. Some of this is driven because there apparently is no flow control to requeue XPT_CONTINUE_IO requests like there are for XPT_SCSI_IO requests. It is also more driven in that the few target mode periph drivers there are are not really set up for handling pushback- heck most of them don't even check for errors (and what would they really do with them anyway? It's the initiator's problem, really....). The data transfer arithmetic has been worked over again to handle multiple outstanding commands, so you have a notion of what's been moved already as well as what's currently in flight. It turns that this led to uncovering a REPORT_LUNS bug in the ISP_INTERNAL_TARGET code which was sending back 24 bytes of rpl data instead of the specified 16. What happened furthermore here is that sending back 16 bytes and reporting an overrun of 8 bytes made the initiator (running FC-Tape aware f/w) mad enough to request, and keep requesting, another FCP response (I guess it didn't like the answer so kept asking for it again). Sponsored by: Spectralogic MFC after: 1 month
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);
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
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 *);
Pass task management response information from CTL through CAM to isp(4), utilizing previously unused arg field of struct ccb_notify_acknowledge. This makes new QUERY TASK, QUERY TASK SET and QUERY ASYNC EVENT requests really functional for CAM target mode drivers.
2016-05-20 10:26:12 +00:00
static int isp_handle_platform_target_notify_ack(ispsoftc_t *, isp_notify_t *, uint32_t rsp);
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
static void isp_handle_platform_target_tmf(ispsoftc_t *, isp_notify_t *);
Fix multiple problems around LUN disable under load. - Move private data about ATIOs/INOTs from per-LUN to per-channel data. This allows active commands to continue operation after LUN destruction. This also simplifies lookup of the data by tag in some situations. - Unify three restart_queue processing implementations. - Complete all ATIOs from restart_queue on LUN disable. - Delete ATIO private data when command completed or aborted, not depending on the ATIO being requeued, that was ugly hack and could never happen. CAM should always call ether XPT_CONT_TARGET_IO with status or XPT_ABORT. - Implement XPT_ABORT for queued ATIOs/INOTs to allow CAM do graceful shutdown, not depending on LUN disable, as it is done in ahd(4)/targ(4). - Unify isp_endcmd() arguments to make it more usable in generic code. - Remove never really used LUN state reference counter. MFC after: 2 weeks
2017-02-22 06:43:49 +00:00
static void isp_target_mark_aborted_early(ispsoftc_t *, int chan, tstate_t *, uint32_t);
Make a static chain of isp softcs- gdb usage becomes a lot easier. Add in a very large amount of target mode support code- this is just a first pass at this. It's a difficult thing because some of the code can be in platform independent areas (see isp_target.?) but a lot has to be in platform dependent areas because of not only the tight coupling of received commands/events and the specific OS subsystem but because the platform independent code has (deliberately) no event/wait mechanisms.
2000-01-03 23:55:30 +00:00
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
static ISP_INLINE tstate_t *
Some more gratuitous format and name changes. Pull in some target mode changes from a private branch. Pull in some more RELENG_4 compilation changes. A lot of lines changed, but not much content change yet.
2006-04-21 18:30:01 +00:00
get_lun_statep(ispsoftc_t *isp, int bus, lun_id_t lun)
Make a static chain of isp softcs- gdb usage becomes a lot easier. Add in a very large amount of target mode support code- this is just a first pass at this. It's a difficult thing because some of the code can be in platform independent areas (see isp_target.?) but a lot has to be in platform dependent areas because of not only the tight coupling of received commands/events and the specific OS subsystem but because the platform independent code has (deliberately) no event/wait mechanisms.
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;
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
struct tslist *lhp;
if (bus < isp->isp_nchan) {
Some microoptimizations. MFC after: 1 month
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) {
Fix multiple problems around LUN disable under load. - Move private data about ATIOs/INOTs from per-LUN to per-channel data. This allows active commands to continue operation after LUN destruction. This also simplifies lookup of the data by tag in some situations. - Unify three restart_queue processing implementations. - Complete all ATIOs from restart_queue on LUN disable. - Delete ATIO private data when command completed or aborted, not depending on the ATIO being requeued, that was ugly hack and could never happen. CAM should always call ether XPT_CONT_TARGET_IO with status or XPT_ABORT. - Implement XPT_ABORT for queued ATIOs/INOTs to allow CAM do graceful shutdown, not depending on LUN disable, as it is done in ahd(4)/targ(4). - Unify isp_endcmd() arguments to make it more usable in generic code. - Remove never really used LUN state reference counter. MFC after: 2 weeks
2017-02-22 06:43:49 +00:00
if (tptr->ts_lun == lun)
Some microoptimizations. MFC after: 1 month
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
}
Make a static chain of isp softcs- gdb usage becomes a lot easier. Add in a very large amount of target mode support code- this is just a first pass at this. It's a difficult thing because some of the code can be in platform independent areas (see isp_target.?) but a lot has to be in platform dependent areas because of not only the tight coupling of received commands/events and the specific OS subsystem but because the platform independent code has (deliberately) no event/wait mechanisms.
2000-01-03 23:55:30 +00:00
}
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
return (NULL);
}
Make a static chain of isp softcs- gdb usage becomes a lot easier. Add in a very large amount of target mode support code- this is just a first pass at this. It's a difficult thing because some of the code can be in platform independent areas (see isp_target.?) but a lot has to be in platform dependent areas because of not only the tight coupling of received commands/events and the specific OS subsystem but because the platform independent code has (deliberately) no event/wait mechanisms.
2000-01-03 23:55:30 +00:00
Fix multiple problems around LUN disable under load. - Move private data about ATIOs/INOTs from per-LUN to per-channel data. This allows active commands to continue operation after LUN destruction. This also simplifies lookup of the data by tag in some situations. - Unify three restart_queue processing implementations. - Complete all ATIOs from restart_queue on LUN disable. - Delete ATIO private data when command completed or aborted, not depending on the ATIO being requeued, that was ugly hack and could never happen. CAM should always call ether XPT_CONT_TARGET_IO with status or XPT_ABORT. - Implement XPT_ABORT for queued ATIOs/INOTs to allow CAM do graceful shutdown, not depending on LUN disable, as it is done in ahd(4)/targ(4). - Unify isp_endcmd() arguments to make it more usable in generic code. - Remove never really used LUN state reference counter. MFC after: 2 weeks
2017-02-22 06:43:49 +00:00
static int
isp_atio_restart(ispsoftc_t *isp, int bus, tstate_t *tptr)
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
{
inot_private_data_t *ntp;
Fix multiple problems around LUN disable under load. - Move private data about ATIOs/INOTs from per-LUN to per-channel data. This allows active commands to continue operation after LUN destruction. This also simplifies lookup of the data by tag in some situations. - Unify three restart_queue processing implementations. - Complete all ATIOs from restart_queue on LUN disable. - Delete ATIO private data when command completed or aborted, not depending on the ATIO being requeued, that was ugly hack and could never happen. CAM should always call ether XPT_CONT_TARGET_IO with status or XPT_ABORT. - Implement XPT_ABORT for queued ATIOs/INOTs to allow CAM do graceful shutdown, not depending on LUN disable, as it is done in ahd(4)/targ(4). - Unify isp_endcmd() arguments to make it more usable in generic code. - Remove never really used LUN state reference counter. MFC after: 2 weeks
2017-02-22 06:43:49 +00:00
struct ntpdlist rq;
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
Fix multiple problems around LUN disable under load. - Move private data about ATIOs/INOTs from per-LUN to per-channel data. This allows active commands to continue operation after LUN destruction. This also simplifies lookup of the data by tag in some situations. - Unify three restart_queue processing implementations. - Complete all ATIOs from restart_queue on LUN disable. - Delete ATIO private data when command completed or aborted, not depending on the ATIO being requeued, that was ugly hack and could never happen. CAM should always call ether XPT_CONT_TARGET_IO with status or XPT_ABORT. - Implement XPT_ABORT for queued ATIOs/INOTs to allow CAM do graceful shutdown, not depending on LUN disable, as it is done in ahd(4)/targ(4). - Unify isp_endcmd() arguments to make it more usable in generic code. - Remove never really used LUN state reference counter. MFC after: 2 weeks
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);
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
}
Fix multiple problems around LUN disable under load. - Move private data about ATIOs/INOTs from per-LUN to per-channel data. This allows active commands to continue operation after LUN destruction. This also simplifies lookup of the data by tag in some situations. - Unify three restart_queue processing implementations. - Complete all ATIOs from restart_queue on LUN disable. - Delete ATIO private data when command completed or aborted, not depending on the ATIO being requeued, that was ugly hack and could never happen. CAM should always call ether XPT_CONT_TARGET_IO with status or XPT_ABORT. - Implement XPT_ABORT for queued ATIOs/INOTs to allow CAM do graceful shutdown, not depending on LUN disable, as it is done in ahd(4)/targ(4). - Unify isp_endcmd() arguments to make it more usable in generic code. - Remove never really used LUN state reference counter. MFC after: 2 weeks
2017-02-22 06:43:49 +00:00
isp_put_ntpd(isp, bus, ntp);
if (!STAILQ_EMPTY(&tptr->restart_queue))
break;
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
}
Fix multiple problems around LUN disable under load. - Move private data about ATIOs/INOTs from per-LUN to per-channel data. This allows active commands to continue operation after LUN destruction. This also simplifies lookup of the data by tag in some situations. - Unify three restart_queue processing implementations. - Complete all ATIOs from restart_queue on LUN disable. - Delete ATIO private data when command completed or aborted, not depending on the ATIO being requeued, that was ugly hack and could never happen. CAM should always call ether XPT_CONT_TARGET_IO with status or XPT_ABORT. - Implement XPT_ABORT for queued ATIOs/INOTs to allow CAM do graceful shutdown, not depending on LUN disable, as it is done in ahd(4)/targ(4). - Unify isp_endcmd() arguments to make it more usable in generic code. - Remove never really used LUN state reference counter. MFC after: 2 weeks
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));
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
}
static void
isp_tmcmd_restart(ispsoftc_t *isp)
{
tstate_t *tptr;
More rototilling with target mode in an attemp to get multiple CCB at a time outstanding reliable. It's not there yet, but this is the direction to go in so might as well commit. So far, multiple at a time CCBs work (see ISP_INTERNAL_TARGET test mode), but it fails if there are more downstream than the SIM wants to handle and SRR is sort of confused when this happens, plus it is not entirely quite clear what one does if a CCB/CTIO fails and you have more in flight (that don't fail, say) and more queued up at the SIM level that haven't been started yet. Some of this is driven because there apparently is no flow control to requeue XPT_CONTINUE_IO requests like there are for XPT_SCSI_IO requests. It is also more driven in that the few target mode periph drivers there are are not really set up for handling pushback- heck most of them don't even check for errors (and what would they really do with them anyway? It's the initiator's problem, really....). The data transfer arithmetic has been worked over again to handle multiple outstanding commands, so you have a notion of what's been moved already as well as what's currently in flight. It turns that this led to uncovering a REPORT_LUNS bug in the ISP_INTERNAL_TARGET code which was sending back 24 bytes of rpl data instead of the specified 16. What happened furthermore here is that sending back 16 bytes and reporting an overrun of 8 bytes made the initiator (running FC-Tape aware f/w) mad enough to request, and keep requesting, another FCP response (I guess it didn't like the answer so kept asking for it again). Sponsored by: Spectralogic MFC after: 1 month
2012-08-08 18:24:33 +00:00
union ccb *ccb;
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
struct tslist *lhp;
Move CTIO waitq from per-LUN to per-channel. All resources lack of which may put CTIO into the queue are either per-channel or potentially per-queue, but none of them are per-LUN. This is a first step to fix live LUN disabling. Before this change any CTIOs held in a queue in time of disabling were just leaked. MFC after: 2 weeks
2017-02-19 05:07:02 +00:00
struct isp_ccbq *waitq;
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
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);
Fix multiple problems around LUN disable under load. - Move private data about ATIOs/INOTs from per-LUN to per-channel data. This allows active commands to continue operation after LUN destruction. This also simplifies lookup of the data by tag in some situations. - Unify three restart_queue processing implementations. - Complete all ATIOs from restart_queue on LUN disable. - Delete ATIO private data when command completed or aborted, not depending on the ATIO being requeued, that was ugly hack and could never happen. CAM should always call ether XPT_CONT_TARGET_IO with status or XPT_ABORT. - Implement XPT_ABORT for queued ATIOs/INOTs to allow CAM do graceful shutdown, not depending on LUN disable, as it is done in ahd(4)/targ(4). - Unify isp_endcmd() arguments to make it more usable in generic code. - Remove never really used LUN state reference counter. MFC after: 2 weeks
2017-02-22 06:43:49 +00:00
SLIST_FOREACH(tptr, lhp, next)
isp_atio_restart(isp, bus, tptr);
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
}
Move CTIO waitq from per-LUN to per-channel. All resources lack of which may put CTIO into the queue are either per-channel or potentially per-queue, but none of them are per-LUN. This is a first step to fix live LUN disabling. Before this change any CTIOs held in a queue in time of disabling were just leaked. MFC after: 2 weeks
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) {
Switch from using periph_links to sim_links. periph_links field belongs to periph drivers and must not be used here. MFC after: 2 weeks
2017-03-22 11:06:33 +00:00
TAILQ_REMOVE(waitq, &ccb->ccb_h, sim_links.tqe);
Move CTIO waitq from per-LUN to per-channel. All resources lack of which may put CTIO into the queue are either per-channel or potentially per-queue, but none of them are per-LUN. This is a first step to fix live LUN disabling. Before this change any CTIOs held in a queue in time of disabling were just leaked. MFC after: 2 weeks
2017-02-19 05:07:02 +00:00
isp_target_start_ctio(isp, ccb, FROM_TIMER);
}
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
}
Make a static chain of isp softcs- gdb usage becomes a lot easier. Add in a very large amount of target mode support code- this is just a first pass at this. It's a difficult thing because some of the code can be in platform independent areas (see isp_target.?) but a lot has to be in platform dependent areas because of not only the tight coupling of received commands/events and the specific OS subsystem but because the platform independent code has (deliberately) no event/wait mechanisms.
2000-01-03 23:55:30 +00:00
}
Fix multiple problems around LUN disable under load. - Move private data about ATIOs/INOTs from per-LUN to per-channel data. This allows active commands to continue operation after LUN destruction. This also simplifies lookup of the data by tag in some situations. - Unify three restart_queue processing implementations. - Complete all ATIOs from restart_queue on LUN disable. - Delete ATIO private data when command completed or aborted, not depending on the ATIO being requeued, that was ugly hack and could never happen. CAM should always call ether XPT_CONT_TARGET_IO with status or XPT_ABORT. - Implement XPT_ABORT for queued ATIOs/INOTs to allow CAM do graceful shutdown, not depending on LUN disable, as it is done in ahd(4)/targ(4). - Unify isp_endcmd() arguments to make it more usable in generic code. - Remove never really used LUN state reference counter. MFC after: 2 weeks
2017-02-22 06:43:49 +00:00
static atio_private_data_t *
isp_get_atpd(ispsoftc_t *isp, int chan, uint32_t tag)
Begin to implement target mode that for Fibre Channel has a private per-command component that we *don't* try and pass thru CAM. CAM just is too risky and too much of a pain- structures get copied, but not all info of interest can be considered safely transported thru all consumers (including user space) from the incoming ATIO to the outgoing CTIO- it's just much safer to have a buddy structure, identified by the command's tag which *does* make it thru safely. Pay attention to link speed and report 200MB/s xfer speed for a 23XX card in 2GPs mode. MFC after: 1 week
2001-10-01 03:48:42 +00:00
{
Fix multiple problems around LUN disable under load. - Move private data about ATIOs/INOTs from per-LUN to per-channel data. This allows active commands to continue operation after LUN destruction. This also simplifies lookup of the data by tag in some situations. - Unify three restart_queue processing implementations. - Complete all ATIOs from restart_queue on LUN disable. - Delete ATIO private data when command completed or aborted, not depending on the ATIO being requeued, that was ugly hack and could never happen. CAM should always call ether XPT_CONT_TARGET_IO with status or XPT_ABORT. - Implement XPT_ABORT for queued ATIOs/INOTs to allow CAM do graceful shutdown, not depending on LUN disable, as it is done in ahd(4)/targ(4). - Unify isp_endcmd() arguments to make it more usable in generic code. - Remove never really used LUN state reference counter. MFC after: 2 weeks
2017-02-22 06:43:49 +00:00
struct atpdlist *atfree;
struct atpdlist *atused;
Begin to implement target mode that for Fibre Channel has a private per-command component that we *don't* try and pass thru CAM. CAM just is too risky and too much of a pain- structures get copied, but not all info of interest can be considered safely transported thru all consumers (including user space) from the incoming ATIO to the outgoing CTIO- it's just much safer to have a buddy structure, identified by the command's tag which *does* make it thru safely. Pay attention to link speed and report 200MB/s xfer speed for a 23XX card in 2GPs mode. MFC after: 1 week
2001-10-01 03:48:42 +00:00
atio_private_data_t *atp;
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
Fix multiple problems around LUN disable under load. - Move private data about ATIOs/INOTs from per-LUN to per-channel data. This allows active commands to continue operation after LUN destruction. This also simplifies lookup of the data by tag in some situations. - Unify three restart_queue processing implementations. - Complete all ATIOs from restart_queue on LUN disable. - Delete ATIO private data when command completed or aborted, not depending on the ATIO being requeued, that was ugly hack and could never happen. CAM should always call ether XPT_CONT_TARGET_IO with status or XPT_ABORT. - Implement XPT_ABORT for queued ATIOs/INOTs to allow CAM do graceful shutdown, not depending on LUN disable, as it is done in ahd(4)/targ(4). - Unify isp_endcmd() arguments to make it more usable in generic code. - Remove never really used LUN state reference counter. MFC after: 2 weeks
2017-02-22 06:43:49 +00:00
ISP_GET_PC_ADDR(isp, chan, atfree, atfree);
atp = LIST_FIRST(atfree);
Optimize isp(4) to reduce CPU usage, especially in target mode: - Remove two excessive and slow register reads from isp_intr(). Instead of rereading value every time, assume that registers contain what we have written there. - Avoid sequential search through 4096 array elements when looking for command tag. Use hash of lists to store active tags separately from free ones and so greatly speedup the searches. Reviewed by: mjacob
2013-10-17 20:19:15 +00:00
if (atp) {
LIST_REMOVE(atp, next);
atp->tag = tag;
Fix multiple problems around LUN disable under load. - Move private data about ATIOs/INOTs from per-LUN to per-channel data. This allows active commands to continue operation after LUN destruction. This also simplifies lookup of the data by tag in some situations. - Unify three restart_queue processing implementations. - Complete all ATIOs from restart_queue on LUN disable. - Delete ATIO private data when command completed or aborted, not depending on the ATIO being requeued, that was ugly hack and could never happen. CAM should always call ether XPT_CONT_TARGET_IO with status or XPT_ABORT. - Implement XPT_ABORT for queued ATIOs/INOTs to allow CAM do graceful shutdown, not depending on LUN disable, as it is done in ahd(4)/targ(4). - Unify isp_endcmd() arguments to make it more usable in generic code. - Remove never really used LUN state reference counter. MFC after: 2 weeks
2017-02-22 06:43:49 +00:00
ISP_GET_PC(isp, chan, atused, atused);
LIST_INSERT_HEAD(&atused[ATPDPHASH(tag)], atp, next);
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
}
Optimize isp(4) to reduce CPU usage, especially in target mode: - Remove two excessive and slow register reads from isp_intr(). Instead of rereading value every time, assume that registers contain what we have written there. - Avoid sequential search through 4096 array elements when looking for command tag. Use hash of lists to store active tags separately from free ones and so greatly speedup the searches. Reviewed by: mjacob
2013-10-17 20:19:15 +00:00
return (atp);
}
Fix multiple problems around LUN disable under load. - Move private data about ATIOs/INOTs from per-LUN to per-channel data. This allows active commands to continue operation after LUN destruction. This also simplifies lookup of the data by tag in some situations. - Unify three restart_queue processing implementations. - Complete all ATIOs from restart_queue on LUN disable. - Delete ATIO private data when command completed or aborted, not depending on the ATIO being requeued, that was ugly hack and could never happen. CAM should always call ether XPT_CONT_TARGET_IO with status or XPT_ABORT. - Implement XPT_ABORT for queued ATIOs/INOTs to allow CAM do graceful shutdown, not depending on LUN disable, as it is done in ahd(4)/targ(4). - Unify isp_endcmd() arguments to make it more usable in generic code. - Remove never really used LUN state reference counter. MFC after: 2 weeks
2017-02-22 06:43:49 +00:00
static atio_private_data_t *
isp_find_atpd(ispsoftc_t *isp, int chan, uint32_t tag)
Optimize isp(4) to reduce CPU usage, especially in target mode: - Remove two excessive and slow register reads from isp_intr(). Instead of rereading value every time, assume that registers contain what we have written there. - Avoid sequential search through 4096 array elements when looking for command tag. Use hash of lists to store active tags separately from free ones and so greatly speedup the searches. Reviewed by: mjacob
2013-10-17 20:19:15 +00:00
{
Fix multiple problems around LUN disable under load. - Move private data about ATIOs/INOTs from per-LUN to per-channel data. This allows active commands to continue operation after LUN destruction. This also simplifies lookup of the data by tag in some situations. - Unify three restart_queue processing implementations. - Complete all ATIOs from restart_queue on LUN disable. - Delete ATIO private data when command completed or aborted, not depending on the ATIO being requeued, that was ugly hack and could never happen. CAM should always call ether XPT_CONT_TARGET_IO with status or XPT_ABORT. - Implement XPT_ABORT for queued ATIOs/INOTs to allow CAM do graceful shutdown, not depending on LUN disable, as it is done in ahd(4)/targ(4). - Unify isp_endcmd() arguments to make it more usable in generic code. - Remove never really used LUN state reference counter. MFC after: 2 weeks
2017-02-22 06:43:49 +00:00
struct atpdlist *atused;
Optimize isp(4) to reduce CPU usage, especially in target mode: - Remove two excessive and slow register reads from isp_intr(). Instead of rereading value every time, assume that registers contain what we have written there. - Avoid sequential search through 4096 array elements when looking for command tag. Use hash of lists to store active tags separately from free ones and so greatly speedup the searches. Reviewed by: mjacob
2013-10-17 20:19:15 +00:00
atio_private_data_t *atp;
Fix multiple problems around LUN disable under load. - Move private data about ATIOs/INOTs from per-LUN to per-channel data. This allows active commands to continue operation after LUN destruction. This also simplifies lookup of the data by tag in some situations. - Unify three restart_queue processing implementations. - Complete all ATIOs from restart_queue on LUN disable. - Delete ATIO private data when command completed or aborted, not depending on the ATIO being requeued, that was ugly hack and could never happen. CAM should always call ether XPT_CONT_TARGET_IO with status or XPT_ABORT. - Implement XPT_ABORT for queued ATIOs/INOTs to allow CAM do graceful shutdown, not depending on LUN disable, as it is done in ahd(4)/targ(4). - Unify isp_endcmd() arguments to make it more usable in generic code. - Remove never really used LUN state reference counter. MFC after: 2 weeks
2017-02-22 06:43:49 +00:00
ISP_GET_PC(isp, chan, atused, atused);
LIST_FOREACH(atp, &atused[ATPDPHASH(tag)], next) {
Optimize isp(4) to reduce CPU usage, especially in target mode: - Remove two excessive and slow register reads from isp_intr(). Instead of rereading value every time, assume that registers contain what we have written there. - Avoid sequential search through 4096 array elements when looking for command tag. Use hash of lists to store active tags separately from free ones and so greatly speedup the searches. Reviewed by: mjacob
2013-10-17 20:19:15 +00:00
if (atp->tag == tag)
Begin to implement target mode that for Fibre Channel has a private per-command component that we *don't* try and pass thru CAM. CAM just is too risky and too much of a pain- structures get copied, but not all info of interest can be considered safely transported thru all consumers (including user space) from the incoming ATIO to the outgoing CTIO- it's just much safer to have a buddy structure, identified by the command's tag which *does* make it thru safely. Pay attention to link speed and report 200MB/s xfer speed for a 23XX card in 2GPs mode. MFC after: 1 week
2001-10-01 03:48:42 +00:00
return (atp);
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
}
return (NULL);
}
Fix multiple problems around LUN disable under load. - Move private data about ATIOs/INOTs from per-LUN to per-channel data. This allows active commands to continue operation after LUN destruction. This also simplifies lookup of the data by tag in some situations. - Unify three restart_queue processing implementations. - Complete all ATIOs from restart_queue on LUN disable. - Delete ATIO private data when command completed or aborted, not depending on the ATIO being requeued, that was ugly hack and could never happen. CAM should always call ether XPT_CONT_TARGET_IO with status or XPT_ABORT. - Implement XPT_ABORT for queued ATIOs/INOTs to allow CAM do graceful shutdown, not depending on LUN disable, as it is done in ahd(4)/targ(4). - Unify isp_endcmd() arguments to make it more usable in generic code. - Remove never really used LUN state reference counter. MFC after: 2 weeks
2017-02-22 06:43:49 +00:00
static void
isp_put_atpd(ispsoftc_t *isp, int chan, atio_private_data_t *atp)
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
{
Fix multiple problems around LUN disable under load. - Move private data about ATIOs/INOTs from per-LUN to per-channel data. This allows active commands to continue operation after LUN destruction. This also simplifies lookup of the data by tag in some situations. - Unify three restart_queue processing implementations. - Complete all ATIOs from restart_queue on LUN disable. - Delete ATIO private data when command completed or aborted, not depending on the ATIO being requeued, that was ugly hack and could never happen. CAM should always call ether XPT_CONT_TARGET_IO with status or XPT_ABORT. - Implement XPT_ABORT for queued ATIOs/INOTs to allow CAM do graceful shutdown, not depending on LUN disable, as it is done in ahd(4)/targ(4). - Unify isp_endcmd() arguments to make it more usable in generic code. - Remove never really used LUN state reference counter. MFC after: 2 weeks
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);
}
Optimize isp(4) to reduce CPU usage, especially in target mode: - Remove two excessive and slow register reads from isp_intr(). Instead of rereading value every time, assume that registers contain what we have written there. - Avoid sequential search through 4096 array elements when looking for command tag. Use hash of lists to store active tags separately from free ones and so greatly speedup the searches. Reviewed by: mjacob
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));
Fix multiple problems around LUN disable under load. - Move private data about ATIOs/INOTs from per-LUN to per-channel data. This allows active commands to continue operation after LUN destruction. This also simplifies lookup of the data by tag in some situations. - Unify three restart_queue processing implementations. - Complete all ATIOs from restart_queue on LUN disable. - Delete ATIO private data when command completed or aborted, not depending on the ATIO being requeued, that was ugly hack and could never happen. CAM should always call ether XPT_CONT_TARGET_IO with status or XPT_ABORT. - Implement XPT_ABORT for queued ATIOs/INOTs to allow CAM do graceful shutdown, not depending on LUN disable, as it is done in ahd(4)/targ(4). - Unify isp_endcmd() arguments to make it more usable in generic code. - Remove never really used LUN state reference counter. MFC after: 2 weeks
2017-02-22 06:43:49 +00:00
ISP_GET_PC_ADDR(isp, chan, atfree, atfree);
LIST_INSERT_HEAD(atfree, atp, next);
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
}
static void
Fix multiple problems around LUN disable under load. - Move private data about ATIOs/INOTs from per-LUN to per-channel data. This allows active commands to continue operation after LUN destruction. This also simplifies lookup of the data by tag in some situations. - Unify three restart_queue processing implementations. - Complete all ATIOs from restart_queue on LUN disable. - Delete ATIO private data when command completed or aborted, not depending on the ATIO being requeued, that was ugly hack and could never happen. CAM should always call ether XPT_CONT_TARGET_IO with status or XPT_ABORT. - Implement XPT_ABORT for queued ATIOs/INOTs to allow CAM do graceful shutdown, not depending on LUN disable, as it is done in ahd(4)/targ(4). - Unify isp_endcmd() arguments to make it more usable in generic code. - Remove never really used LUN state reference counter. MFC after: 2 weeks
2017-02-22 06:43:49 +00:00
isp_dump_atpd(ispsoftc_t *isp, int chan)
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
{
Fix multiple problems around LUN disable under load. - Move private data about ATIOs/INOTs from per-LUN to per-channel data. This allows active commands to continue operation after LUN destruction. This also simplifies lookup of the data by tag in some situations. - Unify three restart_queue processing implementations. - Complete all ATIOs from restart_queue on LUN disable. - Delete ATIO private data when command completed or aborted, not depending on the ATIO being requeued, that was ugly hack and could never happen. CAM should always call ether XPT_CONT_TARGET_IO with status or XPT_ABORT. - Implement XPT_ABORT for queued ATIOs/INOTs to allow CAM do graceful shutdown, not depending on LUN disable, as it is done in ahd(4)/targ(4). - Unify isp_endcmd() arguments to make it more usable in generic code. - Remove never really used LUN state reference counter. MFC after: 2 weeks
2017-02-22 06:43:49 +00:00
atio_private_data_t *atp, *atpool;
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
const char *states[8] = { "Free", "ATIO", "CAM", "CTIO", "LAST_CTIO", "PDON", "?6", "7" };
Fix multiple problems around LUN disable under load. - Move private data about ATIOs/INOTs from per-LUN to per-channel data. This allows active commands to continue operation after LUN destruction. This also simplifies lookup of the data by tag in some situations. - Unify three restart_queue processing implementations. - Complete all ATIOs from restart_queue on LUN disable. - Delete ATIO private data when command completed or aborted, not depending on the ATIO being requeued, that was ugly hack and could never happen. CAM should always call ether XPT_CONT_TARGET_IO with status or XPT_ABORT. - Implement XPT_ABORT for queued ATIOs/INOTs to allow CAM do graceful shutdown, not depending on LUN disable, as it is done in ahd(4)/targ(4). - Unify isp_endcmd() arguments to make it more usable in generic code. - Remove never really used LUN state reference counter. MFC after: 2 weeks
2017-02-22 06:43:49 +00:00
ISP_GET_PC(isp, chan, atpool, atpool);
for (atp = atpool; atp < &atpool[ATPDPSIZE]; atp++) {
Slightly polish isp_dump_atpd(). MFC after: 2 weeks
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",
Send TERMINATE to firmware when aborting active ATIO. MFC after: 2 weeks
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]);
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
}
}
Fix multiple problems around LUN disable under load. - Move private data about ATIOs/INOTs from per-LUN to per-channel data. This allows active commands to continue operation after LUN destruction. This also simplifies lookup of the data by tag in some situations. - Unify three restart_queue processing implementations. - Complete all ATIOs from restart_queue on LUN disable. - Delete ATIO private data when command completed or aborted, not depending on the ATIO being requeued, that was ugly hack and could never happen. CAM should always call ether XPT_CONT_TARGET_IO with status or XPT_ABORT. - Implement XPT_ABORT for queued ATIOs/INOTs to allow CAM do graceful shutdown, not depending on LUN disable, as it is done in ahd(4)/targ(4). - Unify isp_endcmd() arguments to make it more usable in generic code. - Remove never really used LUN state reference counter. MFC after: 2 weeks
2017-02-22 06:43:49 +00:00
static inot_private_data_t *
isp_get_ntpd(ispsoftc_t *isp, int chan)
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
{
Fix multiple problems around LUN disable under load. - Move private data about ATIOs/INOTs from per-LUN to per-channel data. This allows active commands to continue operation after LUN destruction. This also simplifies lookup of the data by tag in some situations. - Unify three restart_queue processing implementations. - Complete all ATIOs from restart_queue on LUN disable. - Delete ATIO private data when command completed or aborted, not depending on the ATIO being requeued, that was ugly hack and could never happen. CAM should always call ether XPT_CONT_TARGET_IO with status or XPT_ABORT. - Implement XPT_ABORT for queued ATIOs/INOTs to allow CAM do graceful shutdown, not depending on LUN disable, as it is done in ahd(4)/targ(4). - Unify isp_endcmd() arguments to make it more usable in generic code. - Remove never really used LUN state reference counter. MFC after: 2 weeks
2017-02-22 06:43:49 +00:00
struct ntpdlist *ntfree;
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
inot_private_data_t *ntp;
Fix multiple problems around LUN disable under load. - Move private data about ATIOs/INOTs from per-LUN to per-channel data. This allows active commands to continue operation after LUN destruction. This also simplifies lookup of the data by tag in some situations. - Unify three restart_queue processing implementations. - Complete all ATIOs from restart_queue on LUN disable. - Delete ATIO private data when command completed or aborted, not depending on the ATIO being requeued, that was ugly hack and could never happen. CAM should always call ether XPT_CONT_TARGET_IO with status or XPT_ABORT. - Implement XPT_ABORT for queued ATIOs/INOTs to allow CAM do graceful shutdown, not depending on LUN disable, as it is done in ahd(4)/targ(4). - Unify isp_endcmd() arguments to make it more usable in generic code. - Remove never really used LUN state reference counter. MFC after: 2 weeks
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);
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
return (ntp);
}
Fix multiple problems around LUN disable under load. - Move private data about ATIOs/INOTs from per-LUN to per-channel data. This allows active commands to continue operation after LUN destruction. This also simplifies lookup of the data by tag in some situations. - Unify three restart_queue processing implementations. - Complete all ATIOs from restart_queue on LUN disable. - Delete ATIO private data when command completed or aborted, not depending on the ATIO being requeued, that was ugly hack and could never happen. CAM should always call ether XPT_CONT_TARGET_IO with status or XPT_ABORT. - Implement XPT_ABORT for queued ATIOs/INOTs to allow CAM do graceful shutdown, not depending on LUN disable, as it is done in ahd(4)/targ(4). - Unify isp_endcmd() arguments to make it more usable in generic code. - Remove never really used LUN state reference counter. MFC after: 2 weeks
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)
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
{
Fix multiple problems around LUN disable under load. - Move private data about ATIOs/INOTs from per-LUN to per-channel data. This allows active commands to continue operation after LUN destruction. This also simplifies lookup of the data by tag in some situations. - Unify three restart_queue processing implementations. - Complete all ATIOs from restart_queue on LUN disable. - Delete ATIO private data when command completed or aborted, not depending on the ATIO being requeued, that was ugly hack and could never happen. CAM should always call ether XPT_CONT_TARGET_IO with status or XPT_ABORT. - Implement XPT_ABORT for queued ATIOs/INOTs to allow CAM do graceful shutdown, not depending on LUN disable, as it is done in ahd(4)/targ(4). - Unify isp_endcmd() arguments to make it more usable in generic code. - Remove never really used LUN state reference counter. MFC after: 2 weeks
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)
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
return (ntp);
Begin to implement target mode that for Fibre Channel has a private per-command component that we *don't* try and pass thru CAM. CAM just is too risky and too much of a pain- structures get copied, but not all info of interest can be considered safely transported thru all consumers (including user space) from the incoming ATIO to the outgoing CTIO- it's just much safer to have a buddy structure, identified by the command's tag which *does* make it thru safely. Pay attention to link speed and report 200MB/s xfer speed for a 23XX card in 2GPs mode. MFC after: 1 week
2001-10-01 03:48:42 +00:00
}
return (NULL);
}
Fix multiple problems around LUN disable under load. - Move private data about ATIOs/INOTs from per-LUN to per-channel data. This allows active commands to continue operation after LUN destruction. This also simplifies lookup of the data by tag in some situations. - Unify three restart_queue processing implementations. - Complete all ATIOs from restart_queue on LUN disable. - Delete ATIO private data when command completed or aborted, not depending on the ATIO being requeued, that was ugly hack and could never happen. CAM should always call ether XPT_CONT_TARGET_IO with status or XPT_ABORT. - Implement XPT_ABORT for queued ATIOs/INOTs to allow CAM do graceful shutdown, not depending on LUN disable, as it is done in ahd(4)/targ(4). - Unify isp_endcmd() arguments to make it more usable in generic code. - Remove never really used LUN state reference counter. MFC after: 2 weeks
2017-02-22 06:43:49 +00:00
static void
isp_put_ntpd(ispsoftc_t *isp, int chan, inot_private_data_t *ntp)
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
{
Fix multiple problems around LUN disable under load. - Move private data about ATIOs/INOTs from per-LUN to per-channel data. This allows active commands to continue operation after LUN destruction. This also simplifies lookup of the data by tag in some situations. - Unify three restart_queue processing implementations. - Complete all ATIOs from restart_queue on LUN disable. - Delete ATIO private data when command completed or aborted, not depending on the ATIO being requeued, that was ugly hack and could never happen. CAM should always call ether XPT_CONT_TARGET_IO with status or XPT_ABORT. - Implement XPT_ABORT for queued ATIOs/INOTs to allow CAM do graceful shutdown, not depending on LUN disable, as it is done in ahd(4)/targ(4). - Unify isp_endcmd() arguments to make it more usable in generic code. - Remove never really used LUN state reference counter. MFC after: 2 weeks
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);
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
}
Make a static chain of isp softcs- gdb usage becomes a lot easier. Add in a very large amount of target mode support code- this is just a first pass at this. It's a difficult thing because some of the code can be in platform independent areas (see isp_target.?) but a lot has to be in platform dependent areas because of not only the tight coupling of received commands/events and the specific OS subsystem but because the platform independent code has (deliberately) no event/wait mechanisms.
2000-01-03 23:55:30 +00:00
static cam_status
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
create_lun_state(ispsoftc_t *isp, int bus, struct cam_path *path, tstate_t **rslt)
Make a static chain of isp softcs- gdb usage becomes a lot easier. Add in a very large amount of target mode support code- this is just a first pass at this. It's a difficult thing because some of the code can be in platform independent areas (see isp_target.?) but a lot has to be in platform dependent areas because of not only the tight coupling of received commands/events and the specific OS subsystem but because the platform independent code has (deliberately) no event/wait mechanisms.
2000-01-03 23:55:30 +00:00
{
lun_id_t lun;
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
struct tslist *lhp;
tstate_t *tptr;
Make a static chain of isp softcs- gdb usage becomes a lot easier. Add in a very large amount of target mode support code- this is just a first pass at this. It's a difficult thing because some of the code can be in platform independent areas (see isp_target.?) but a lot has to be in platform dependent areas because of not only the tight coupling of received commands/events and the specific OS subsystem but because the platform independent code has (deliberately) no event/wait mechanisms.
2000-01-03 23:55:30 +00:00
lun = xpt_path_lun_id(path);
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
if (lun != CAM_LUN_WILDCARD) {
Add PIM_EXTLUNS support to isp(4) driver. Now 24xx and above chips support full 8-byte LUN address space. Older FC chips may support up to 16K LUNs when firmware allows. Tested in both initiator and target modes for 23xx, 24xx and 25xx.
2015-10-24 17:34:40 +00:00
if (ISP_MAX_LUNS(isp) > 0 && lun >= ISP_MAX_LUNS(isp)) {
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
return (CAM_LUN_INVALID);
}
Make a static chain of isp softcs- gdb usage becomes a lot easier. Add in a very large amount of target mode support code- this is just a first pass at this. It's a difficult thing because some of the code can be in platform independent areas (see isp_target.?) but a lot has to be in platform dependent areas because of not only the tight coupling of received commands/events and the specific OS subsystem but because the platform independent code has (deliberately) no event/wait mechanisms.
2000-01-03 23:55:30 +00:00
}
Clean up and complete the incomplete deferred enable code. Make the default role NONE if target mode is selected. This allows ctl(8) to switch to/from target mode via knob settings. If we default to role 'none', this causes a reset of the 24XX f/w which then causes initiators to wake up and notice when we come online. Reviewed by: kdm MFC after: 2 weeks Sponsored by: Spectralogic
2012-06-01 23:29:48 +00:00
tptr = malloc(sizeof (tstate_t), M_DEVBUF, M_NOWAIT|M_ZERO);
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
if (tptr == NULL) {
Make a static chain of isp softcs- gdb usage becomes a lot easier. Add in a very large amount of target mode support code- this is just a first pass at this. It's a difficult thing because some of the code can be in platform independent areas (see isp_target.?) but a lot has to be in platform dependent areas because of not only the tight coupling of received commands/events and the specific OS subsystem but because the platform independent code has (deliberately) no event/wait mechanisms.
2000-01-03 23:55:30 +00:00
return (CAM_RESRC_UNAVAIL);
}
Some microoptimizations. MFC after: 1 month
2014-11-26 13:56:54 +00:00
tptr->ts_lun = lun;
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
SLIST_INIT(&tptr->atios);
SLIST_INIT(&tptr->inots);
Add missing restart_queue initialization. MFC after: 1 week
2017-08-23 19:00:06 +00:00
STAILQ_INIT(&tptr->restart_queue);
Some microoptimizations. MFC after: 1 month
2014-11-26 13:56:54 +00:00
ISP_GET_PC_ADDR(isp, bus, lun_hash[LUN_HASH_FUNC(lun)], lhp);
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
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");
Make a static chain of isp softcs- gdb usage becomes a lot easier. Add in a very large amount of target mode support code- this is just a first pass at this. It's a difficult thing because some of the code can be in platform independent areas (see isp_target.?) but a lot has to be in platform dependent areas because of not only the tight coupling of received commands/events and the specific OS subsystem but because the platform independent code has (deliberately) no event/wait mechanisms.
2000-01-03 23:55:30 +00:00
return (CAM_REQ_CMP);
}
Fix multiple problems around LUN disable under load. - Move private data about ATIOs/INOTs from per-LUN to per-channel data. This allows active commands to continue operation after LUN destruction. This also simplifies lookup of the data by tag in some situations. - Unify three restart_queue processing implementations. - Complete all ATIOs from restart_queue on LUN disable. - Delete ATIO private data when command completed or aborted, not depending on the ATIO being requeued, that was ugly hack and could never happen. CAM should always call ether XPT_CONT_TARGET_IO with status or XPT_ABORT. - Implement XPT_ABORT for queued ATIOs/INOTs to allow CAM do graceful shutdown, not depending on LUN disable, as it is done in ahd(4)/targ(4). - Unify isp_endcmd() arguments to make it more usable in generic code. - Remove never really used LUN state reference counter. MFC after: 2 weeks
2017-02-22 06:43:49 +00:00
static void
destroy_lun_state(ispsoftc_t *isp, int bus, tstate_t *tptr)
Make a static chain of isp softcs- gdb usage becomes a lot easier. Add in a very large amount of target mode support code- this is just a first pass at this. It's a difficult thing because some of the code can be in platform independent areas (see isp_target.?) but a lot has to be in platform dependent areas because of not only the tight coupling of received commands/events and the specific OS subsystem but because the platform independent code has (deliberately) no event/wait mechanisms.
2000-01-03 23:55:30 +00:00
{
On lun disable, complete all INOTs and ATIOs with CAM_REQ_ABORTED. Reviewed by: ken (silently), chuck MFC after: 3 weeks
2012-08-16 15:32:16 +00:00
union ccb *ccb;
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
struct tslist *lhp;
Fix multiple problems around LUN disable under load. - Move private data about ATIOs/INOTs from per-LUN to per-channel data. This allows active commands to continue operation after LUN destruction. This also simplifies lookup of the data by tag in some situations. - Unify three restart_queue processing implementations. - Complete all ATIOs from restart_queue on LUN disable. - Delete ATIO private data when command completed or aborted, not depending on the ATIO being requeued, that was ugly hack and could never happen. CAM should always call ether XPT_CONT_TARGET_IO with status or XPT_ABORT. - Implement XPT_ABORT for queued ATIOs/INOTs to allow CAM do graceful shutdown, not depending on LUN disable, as it is done in ahd(4)/targ(4). - Unify isp_endcmd() arguments to make it more usable in generic code. - Remove never really used LUN state reference counter. MFC after: 2 weeks
2017-02-22 06:43:49 +00:00
inot_private_data_t *ntp;
Clean up and complete the incomplete deferred enable code. Make the default role NONE if target mode is selected. This allows ctl(8) to switch to/from target mode via knob settings. If we default to role 'none', this causes a reset of the 24XX f/w which then causes initiators to wake up and notice when we come online. Reviewed by: kdm MFC after: 2 weeks Sponsored by: Spectralogic
2012-06-01 23:29:48 +00:00
Fix multiple problems around LUN disable under load. - Move private data about ATIOs/INOTs from per-LUN to per-channel data. This allows active commands to continue operation after LUN destruction. This also simplifies lookup of the data by tag in some situations. - Unify three restart_queue processing implementations. - Complete all ATIOs from restart_queue on LUN disable. - Delete ATIO private data when command completed or aborted, not depending on the ATIO being requeued, that was ugly hack and could never happen. CAM should always call ether XPT_CONT_TARGET_IO with status or XPT_ABORT. - Implement XPT_ABORT for queued ATIOs/INOTs to allow CAM do graceful shutdown, not depending on LUN disable, as it is done in ahd(4)/targ(4). - Unify isp_endcmd() arguments to make it more usable in generic code. - Remove never really used LUN state reference counter. MFC after: 2 weeks
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);
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
SLIST_REMOVE(lhp, tptr, tstate, next);
Make a static chain of isp softcs- gdb usage becomes a lot easier. Add in a very large amount of target mode support code- this is just a first pass at this. It's a difficult thing because some of the code can be in platform independent areas (see isp_target.?) but a lot has to be in platform dependent areas because of not only the tight coupling of received commands/events and the specific OS subsystem but because the platform independent code has (deliberately) no event/wait mechanisms.
2000-01-03 23:55:30 +00:00
free(tptr, M_DEVBUF);
Update QLogic ISP support for CAM. Add preliminary target mode support. Submitted by: Matthew Jacob <mjacob@feral.com>
1998-09-15 08:42:56 +00:00
}
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
static void
isp_enable_lun(ispsoftc_t *isp, union ccb *ccb)
Make a static chain of isp softcs- gdb usage becomes a lot easier. Add in a very large amount of target mode support code- this is just a first pass at this. It's a difficult thing because some of the code can be in platform independent areas (see isp_target.?) but a lot has to be in platform dependent areas because of not only the tight coupling of received commands/events and the specific OS subsystem but because the platform independent code has (deliberately) no event/wait mechanisms.
2000-01-03 23:55:30 +00:00
{
Rip off target mode support for parallel SCSI QLogic adapters. Hacks to enable target mode there complicated code, while didn't really work. And for outdated hardware fixing it is not really interesting. Initiator mode tested with Qlogic 1080 adapter is still working fine.
2015-11-23 10:06:19 +00:00
tstate_t *tptr;
int bus;
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
target_id_t target;
Make a static chain of isp softcs- gdb usage becomes a lot easier. Add in a very large amount of target mode support code- this is just a first pass at this. It's a difficult thing because some of the code can be in platform independent areas (see isp_target.?) but a lot has to be in platform dependent areas because of not only the tight coupling of received commands/events and the specific OS subsystem but because the platform independent code has (deliberately) no event/wait mechanisms.
2000-01-03 23:55:30 +00:00
lun_id_t lun;
Rip off target mode support for parallel SCSI QLogic adapters. Hacks to enable target mode there complicated code, while didn't really work. And for outdated hardware fixing it is not really interesting. Initiator mode tested with Qlogic 1080 adapter is still working fine.
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;
}
Clean up and complete the incomplete deferred enable code. Make the default role NONE if target mode is selected. This allows ctl(8) to switch to/from target mode via knob settings. If we default to role 'none', this causes a reset of the 24XX f/w which then causes initiators to wake up and notice when we come online. Reviewed by: kdm MFC after: 2 weeks Sponsored by: Spectralogic
2012-06-01 23:29:48 +00:00
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
/*
Rip off target mode support for parallel SCSI QLogic adapters. Hacks to enable target mode there complicated code, while didn't really work. And for outdated hardware fixing it is not really interesting. Initiator mode tested with Qlogic 1080 adapter is still working fine.
2015-11-23 10:06:19 +00:00
* We only support either target and lun both wildcard
* or target and lun both non-wildcard.
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
*/
Remove condition variables and status associated with target mode enabling. Instead, go to an interrupt/polled model. Fix get_lun_statep so we don't panic if there are no wildcard luns enabled. MFC after: 6 days
2004-02-08 19:17:56 +00:00
bus = XS_CHANNEL(ccb);
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
target = ccb->ccb_h.target_id;
Make a static chain of isp softcs- gdb usage becomes a lot easier. Add in a very large amount of target mode support code- this is just a first pass at this. It's a difficult thing because some of the code can be in platform independent areas (see isp_target.?) but a lot has to be in platform dependent areas because of not only the tight coupling of received commands/events and the specific OS subsystem but because the platform independent code has (deliberately) no event/wait mechanisms.
2000-01-03 23:55:30 +00:00
lun = ccb->ccb_h.target_lun;
Add PIM_EXTLUNS support to isp(4) driver. Now 24xx and above chips support full 8-byte LUN address space. Older FC chips may support up to 16K LUNs when firmware allows. Tested in both initiator and target modes for 23xx, 24xx and 25xx.
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);
Rip off target mode support for parallel SCSI QLogic adapters. Hacks to enable target mode there complicated code, while didn't really work. And for outdated hardware fixing it is not really interesting. Initiator mode tested with Qlogic 1080 adapter is still working fine.
2015-11-23 10:06:19 +00:00
if ((target == CAM_TARGET_WILDCARD) != (lun == CAM_LUN_WILDCARD)) {
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
ccb->ccb_h.status = CAM_LUN_INVALID;
xpt_done(ccb);
return;
}
Rip off target mode support for parallel SCSI QLogic adapters. Hacks to enable target mode there complicated code, while didn't really work. And for outdated hardware fixing it is not really interesting. Initiator mode tested with Qlogic 1080 adapter is still working fine.
2015-11-23 10:06:19 +00:00
/* Create the state pointer. It should not already exist. */
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
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;
Rip off target mode support for parallel SCSI QLogic adapters. Hacks to enable target mode there complicated code, while didn't really work. And for outdated hardware fixing it is not really interesting. Initiator mode tested with Qlogic 1080 adapter is still working fine.
2015-11-23 10:06:19 +00:00
xpt_done(ccb);
return;
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
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) {
Rip off target mode support for parallel SCSI QLogic adapters. Hacks to enable target mode there complicated code, while didn't really work. And for outdated hardware fixing it is not really interesting. Initiator mode tested with Qlogic 1080 adapter is still working fine.
2015-11-23 10:06:19 +00:00
xpt_done(ccb);
return;
Remove condition variables and status associated with target mode enabling. Instead, go to an interrupt/polled model. Fix get_lun_statep so we don't panic if there are no wildcard luns enabled. MFC after: 6 days
2004-02-08 19:17:56 +00:00
}
Clean up and complete the incomplete deferred enable code. Make the default role NONE if target mode is selected. This allows ctl(8) to switch to/from target mode via knob settings. If we default to role 'none', this causes a reset of the 24XX f/w which then causes initiators to wake up and notice when we come online. Reviewed by: kdm MFC after: 2 weeks Sponsored by: Spectralogic
2012-06-01 23:29:48 +00:00
Rip off target mode support for parallel SCSI QLogic adapters. Hacks to enable target mode there complicated code, while didn't really work. And for outdated hardware fixing it is not really interesting. Initiator mode tested with Qlogic 1080 adapter is still working fine.
2015-11-23 10:06:19 +00:00
ccb->ccb_h.status = CAM_REQ_CMP;
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
xpt_done(ccb);
}
Make a static chain of isp softcs- gdb usage becomes a lot easier. Add in a very large amount of target mode support code- this is just a first pass at this. It's a difficult thing because some of the code can be in platform independent areas (see isp_target.?) but a lot has to be in platform dependent areas because of not only the tight coupling of received commands/events and the specific OS subsystem but because the platform independent code has (deliberately) no event/wait mechanisms.
2000-01-03 23:55:30 +00:00
Remove condition variables and status associated with target mode enabling. Instead, go to an interrupt/polled model. Fix get_lun_statep so we don't panic if there are no wildcard luns enabled. MFC after: 6 days
2004-02-08 19:17:56 +00:00
static void
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
isp_disable_lun(ispsoftc_t *isp, union ccb *ccb)
Remove condition variables and status associated with target mode enabling. Instead, go to an interrupt/polled model. Fix get_lun_statep so we don't panic if there are no wildcard luns enabled. MFC after: 6 days
2004-02-08 19:17:56 +00:00
{
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
tstate_t *tptr = NULL;
int bus;
target_id_t target;
lun_id_t lun;
Make a static chain of isp softcs- gdb usage becomes a lot easier. Add in a very large amount of target mode support code- this is just a first pass at this. It's a difficult thing because some of the code can be in platform independent areas (see isp_target.?) but a lot has to be in platform dependent areas because of not only the tight coupling of received commands/events and the specific OS subsystem but because the platform independent code has (deliberately) no event/wait mechanisms.
2000-01-03 23:55:30 +00:00
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
bus = XS_CHANNEL(ccb);
target = ccb->ccb_h.target_id;
lun = ccb->ccb_h.target_lun;
Add PIM_EXTLUNS support to isp(4) driver. Now 24xx and above chips support full 8-byte LUN address space. Older FC chips may support up to 16K LUNs when firmware allows. Tested in both initiator and target modes for 23xx, 24xx and 25xx.
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);
Rip off target mode support for parallel SCSI QLogic adapters. Hacks to enable target mode there complicated code, while didn't really work. And for outdated hardware fixing it is not really interesting. Initiator mode tested with Qlogic 1080 adapter is still working fine.
2015-11-23 10:06:19 +00:00
if ((target == CAM_TARGET_WILDCARD) != (lun == CAM_LUN_WILDCARD)) {
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
ccb->ccb_h.status = CAM_LUN_INVALID;
xpt_done(ccb);
Remove condition variables and status associated with target mode enabling. Instead, go to an interrupt/polled model. Fix get_lun_statep so we don't panic if there are no wildcard luns enabled. MFC after: 6 days
2004-02-08 19:17:56 +00:00
return;
Make a static chain of isp softcs- gdb usage becomes a lot easier. Add in a very large amount of target mode support code- this is just a first pass at this. It's a difficult thing because some of the code can be in platform independent areas (see isp_target.?) but a lot has to be in platform dependent areas because of not only the tight coupling of received commands/events and the specific OS subsystem but because the platform independent code has (deliberately) no event/wait mechanisms.
2000-01-03 23:55:30 +00:00
}
Add 2 Gigabit Fibre Channel support (2300 && 2312 cards). This required some reworking (and consequent cleanup) of the interrupt service code. Also begin to start a cleanup of target mode support that will (eventually) not require more inforamtion routed with the ATIO to come back with the CTIO other than tag. MFC after: 4 weeks
2001-08-31 21:39:04 +00:00
Rip off target mode support for parallel SCSI QLogic adapters. Hacks to enable target mode there complicated code, while didn't really work. And for outdated hardware fixing it is not really interesting. Initiator mode tested with Qlogic 1080 adapter is still working fine.
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;
Remove condition variables and status associated with target mode enabling. Instead, go to an interrupt/polled model. Fix get_lun_statep so we don't panic if there are no wildcard luns enabled. MFC after: 6 days
2004-02-08 19:17:56 +00:00
xpt_done(ccb);
return;
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
}
Remove condition variables and status associated with target mode enabling. Instead, go to an interrupt/polled model. Fix get_lun_statep so we don't panic if there are no wildcard luns enabled. MFC after: 6 days
2004-02-08 19:17:56 +00:00
Fix multiple problems around LUN disable under load. - Move private data about ATIOs/INOTs from per-LUN to per-channel data. This allows active commands to continue operation after LUN destruction. This also simplifies lookup of the data by tag in some situations. - Unify three restart_queue processing implementations. - Complete all ATIOs from restart_queue on LUN disable. - Delete ATIO private data when command completed or aborted, not depending on the ATIO being requeued, that was ugly hack and could never happen. CAM should always call ether XPT_CONT_TARGET_IO with status or XPT_ABORT. - Implement XPT_ABORT for queued ATIOs/INOTs to allow CAM do graceful shutdown, not depending on LUN disable, as it is done in ahd(4)/targ(4). - Unify isp_endcmd() arguments to make it more usable in generic code. - Remove never really used LUN state reference counter. MFC after: 2 weeks
2017-02-22 06:43:49 +00:00
destroy_lun_state(isp, bus, tptr);
Rip off target mode support for parallel SCSI QLogic adapters. Hacks to enable target mode there complicated code, while didn't really work. And for outdated hardware fixing it is not really interesting. Initiator mode tested with Qlogic 1080 adapter is still working fine.
2015-11-23 10:06:19 +00:00
ccb->ccb_h.status = CAM_REQ_CMP;
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
xpt_done(ccb);
}
Some more gratuitous format and name changes. Pull in some target mode changes from a private branch. Pull in some more RELENG_4 compilation changes. A lot of lines changed, but not much content change yet.
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)
Make a static chain of isp softcs- gdb usage becomes a lot easier. Add in a very large amount of target mode support code- this is just a first pass at this. It's a difficult thing because some of the code can be in platform independent areas (see isp_target.?) but a lot has to be in platform dependent areas because of not only the tight coupling of received commands/events and the specific OS subsystem but because the platform independent code has (deliberately) no event/wait mechanisms.
2000-01-03 23:55:30 +00:00
{
More rototilling with target mode in an attemp to get multiple CCB at a time outstanding reliable. It's not there yet, but this is the direction to go in so might as well commit. So far, multiple at a time CCBs work (see ISP_INTERNAL_TARGET test mode), but it fails if there are more downstream than the SIM wants to handle and SRR is sort of confused when this happens, plus it is not entirely quite clear what one does if a CCB/CTIO fails and you have more in flight (that don't fail, say) and more queued up at the SIM level that haven't been started yet. Some of this is driven because there apparently is no flow control to requeue XPT_CONTINUE_IO requests like there are for XPT_SCSI_IO requests. It is also more driven in that the few target mode periph drivers there are are not really set up for handling pushback- heck most of them don't even check for errors (and what would they really do with them anyway? It's the initiator's problem, really....). The data transfer arithmetic has been worked over again to handle multiple outstanding commands, so you have a notion of what's been moved already as well as what's currently in flight. It turns that this led to uncovering a REPORT_LUNS bug in the ISP_INTERNAL_TARGET code which was sending back 24 bytes of rpl data instead of the specified 16. What happened furthermore here is that sending back 16 bytes and reporting an overrun of 8 bytes made the initiator (running FC-Tape aware f/w) mad enough to request, and keep requesting, another FCP response (I guess it didn't like the answer so kept asking for it again). Sponsored by: Spectralogic MFC after: 1 month
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;
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
atio_private_data_t *atp;
More rototilling with target mode in an attemp to get multiple CCB at a time outstanding reliable. It's not there yet, but this is the direction to go in so might as well commit. So far, multiple at a time CCBs work (see ISP_INTERNAL_TARGET test mode), but it fails if there are more downstream than the SIM wants to handle and SRR is sort of confused when this happens, plus it is not entirely quite clear what one does if a CCB/CTIO fails and you have more in flight (that don't fail, say) and more queued up at the SIM level that haven't been started yet. Some of this is driven because there apparently is no flow control to requeue XPT_CONTINUE_IO requests like there are for XPT_SCSI_IO requests. It is also more driven in that the few target mode periph drivers there are are not really set up for handling pushback- heck most of them don't even check for errors (and what would they really do with them anyway? It's the initiator's problem, really....). The data transfer arithmetic has been worked over again to handle multiple outstanding commands, so you have a notion of what's been moved already as well as what's currently in flight. It turns that this led to uncovering a REPORT_LUNS bug in the ISP_INTERNAL_TARGET code which was sending back 24 bytes of rpl data instead of the specified 16. What happened furthermore here is that sending back 16 bytes and reporting an overrun of 8 bytes made the initiator (running FC-Tape aware f/w) mad enough to request, and keep requesting, another FCP response (I guess it didn't like the answer so kept asking for it again). Sponsored by: Spectralogic MFC after: 1 month
2012-08-08 18:24:33 +00:00
struct ccb_scsiio *cso;
Move CTIO waitq from per-LUN to per-channel. All resources lack of which may put CTIO into the queue are either per-channel or potentially per-queue, but none of them are per-LUN. This is a first step to fix live LUN disabling. Before this change any CTIOs held in a queue in time of disabling were just leaked. MFC after: 2 weeks
2017-02-19 05:07:02 +00:00
struct isp_ccbq *waitq;
More rototilling with target mode in an attemp to get multiple CCB at a time outstanding reliable. It's not there yet, but this is the direction to go in so might as well commit. So far, multiple at a time CCBs work (see ISP_INTERNAL_TARGET test mode), but it fails if there are more downstream than the SIM wants to handle and SRR is sort of confused when this happens, plus it is not entirely quite clear what one does if a CCB/CTIO fails and you have more in flight (that don't fail, say) and more queued up at the SIM level that haven't been started yet. Some of this is driven because there apparently is no flow control to requeue XPT_CONTINUE_IO requests like there are for XPT_SCSI_IO requests. It is also more driven in that the few target mode periph drivers there are are not really set up for handling pushback- heck most of them don't even check for errors (and what would they really do with them anyway? It's the initiator's problem, really....). The data transfer arithmetic has been worked over again to handle multiple outstanding commands, so you have a notion of what's been moved already as well as what's currently in flight. It turns that this led to uncovering a REPORT_LUNS bug in the ISP_INTERNAL_TARGET code which was sending back 24 bytes of rpl data instead of the specified 16. What happened furthermore here is that sending back 16 bytes and reporting an overrun of 8 bytes made the initiator (running FC-Tape aware f/w) mad enough to request, and keep requesting, another FCP response (I guess it didn't like the answer so kept asking for it again). Sponsored by: Spectralogic MFC after: 1 month
2012-08-08 18:24:33 +00:00
uint32_t dmaresult, handle, xfrlen, sense_length, tmp;
a) clean up some declaration stuff (i.e., make more modern with respect to getting rid u_int for uint and so on). b) Turn back on 64 bit DAC support. Cheeze it a bit in that we have two DMA callback functions- one when we have bus_addr_t > 4 bits in width and the other which should be normal. Even Cheezier in that we turn off setting up DMA maps to be BUS_SPACE_MAXADDR if we're in ISP_TARGET_MODE. More work on this in a week or so. c) Tested under amd64 and 1MB DFLTPHYS, sparc64, i386 (PAE, but insufficient memory to really test > 4GB). LINT check under amd64. MFC after: 1 month
2006-02-15 00:31:48 +00:00
uint8_t local[QENTRY_LEN];
Make a static chain of isp softcs- gdb usage becomes a lot easier. Add in a very large amount of target mode support code- this is just a first pass at this. It's a difficult thing because some of the code can be in platform independent areas (see isp_target.?) but a lot has to be in platform dependent areas because of not only the tight coupling of received commands/events and the specific OS subsystem but because the platform independent code has (deliberately) no event/wait mechanisms.
2000-01-03 23:55:30 +00:00
More rototilling with target mode in an attemp to get multiple CCB at a time outstanding reliable. It's not there yet, but this is the direction to go in so might as well commit. So far, multiple at a time CCBs work (see ISP_INTERNAL_TARGET test mode), but it fails if there are more downstream than the SIM wants to handle and SRR is sort of confused when this happens, plus it is not entirely quite clear what one does if a CCB/CTIO fails and you have more in flight (that don't fail, say) and more queued up at the SIM level that haven't been started yet. Some of this is driven because there apparently is no flow control to requeue XPT_CONTINUE_IO requests like there are for XPT_SCSI_IO requests. It is also more driven in that the few target mode periph drivers there are are not really set up for handling pushback- heck most of them don't even check for errors (and what would they really do with them anyway? It's the initiator's problem, really....). The data transfer arithmetic has been worked over again to handle multiple outstanding commands, so you have a notion of what's been moved already as well as what's currently in flight. It turns that this led to uncovering a REPORT_LUNS bug in the ISP_INTERNAL_TARGET code which was sending back 24 bytes of rpl data instead of the specified 16. What happened furthermore here is that sending back 16 bytes and reporting an overrun of 8 bytes made the initiator (running FC-Tape aware f/w) mad enough to request, and keep requesting, another FCP response (I guess it didn't like the answer so kept asking for it again). Sponsored by: Spectralogic MFC after: 1 month
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));
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
Move CTIO waitq from per-LUN to per-channel. All resources lack of which may put CTIO into the queue are either per-channel or potentially per-queue, but none of them are per-LUN. This is a first step to fix live LUN disabling. Before this change any CTIOs held in a queue in time of disabling were just leaked. MFC after: 2 weeks
2017-02-19 05:07:02 +00:00
ISP_GET_PC_ADDR(isp, XS_CHANNEL(ccb), waitq, waitq);
More rototilling with target mode in an attemp to get multiple CCB at a time outstanding reliable. It's not there yet, but this is the direction to go in so might as well commit. So far, multiple at a time CCBs work (see ISP_INTERNAL_TARGET test mode), but it fails if there are more downstream than the SIM wants to handle and SRR is sort of confused when this happens, plus it is not entirely quite clear what one does if a CCB/CTIO fails and you have more in flight (that don't fail, say) and more queued up at the SIM level that haven't been started yet. Some of this is driven because there apparently is no flow control to requeue XPT_CONTINUE_IO requests like there are for XPT_SCSI_IO requests. It is also more driven in that the few target mode periph drivers there are are not really set up for handling pushback- heck most of them don't even check for errors (and what would they really do with them anyway? It's the initiator's problem, really....). The data transfer arithmetic has been worked over again to handle multiple outstanding commands, so you have a notion of what's been moved already as well as what's currently in flight. It turns that this led to uncovering a REPORT_LUNS bug in the ISP_INTERNAL_TARGET code which was sending back 24 bytes of rpl data instead of the specified 16. What happened furthermore here is that sending back 16 bytes and reporting an overrun of 8 bytes made the initiator (running FC-Tape aware f/w) mad enough to request, and keep requesting, another FCP response (I guess it didn't like the answer so kept asking for it again). Sponsored by: Spectralogic MFC after: 1 month
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
*/
Switch from using periph_links to sim_links. periph_links field belongs to periph drivers and must not be used here. MFC after: 2 weeks
2017-03-22 11:06:33 +00:00
TAILQ_INSERT_TAIL(waitq, &ccb->ccb_h, sim_links.tqe);
More rototilling with target mode in an attemp to get multiple CCB at a time outstanding reliable. It's not there yet, but this is the direction to go in so might as well commit. So far, multiple at a time CCBs work (see ISP_INTERNAL_TARGET test mode), but it fails if there are more downstream than the SIM wants to handle and SRR is sort of confused when this happens, plus it is not entirely quite clear what one does if a CCB/CTIO fails and you have more in flight (that don't fail, say) and more queued up at the SIM level that haven't been started yet. Some of this is driven because there apparently is no flow control to requeue XPT_CONTINUE_IO requests like there are for XPT_SCSI_IO requests. It is also more driven in that the few target mode periph drivers there are are not really set up for handling pushback- heck most of them don't even check for errors (and what would they really do with them anyway? It's the initiator's problem, really....). The data transfer arithmetic has been worked over again to handle multiple outstanding commands, so you have a notion of what's been moved already as well as what's currently in flight. It turns that this led to uncovering a REPORT_LUNS bug in the ISP_INTERNAL_TARGET code which was sending back 24 bytes of rpl data instead of the specified 16. What happened furthermore here is that sending back 16 bytes and reporting an overrun of 8 bytes made the initiator (running FC-Tape aware f/w) mad enough to request, and keep requesting, another FCP response (I guess it didn't like the answer so kept asking for it again). Sponsored by: Spectralogic MFC after: 1 month
2012-08-08 18:24:33 +00:00
break;
Move CTIO waitq from per-LUN to per-channel. All resources lack of which may put CTIO into the queue are either per-channel or potentially per-queue, but none of them are per-LUN. This is a first step to fix live LUN disabling. Before this change any CTIOs held in a queue in time of disabling were just leaked. MFC after: 2 weeks
2017-02-19 05:07:02 +00:00
case FROM_TIMER:
More rototilling with target mode in an attemp to get multiple CCB at a time outstanding reliable. It's not there yet, but this is the direction to go in so might as well commit. So far, multiple at a time CCBs work (see ISP_INTERNAL_TARGET test mode), but it fails if there are more downstream than the SIM wants to handle and SRR is sort of confused when this happens, plus it is not entirely quite clear what one does if a CCB/CTIO fails and you have more in flight (that don't fail, say) and more queued up at the SIM level that haven't been started yet. Some of this is driven because there apparently is no flow control to requeue XPT_CONTINUE_IO requests like there are for XPT_SCSI_IO requests. It is also more driven in that the few target mode periph drivers there are are not really set up for handling pushback- heck most of them don't even check for errors (and what would they really do with them anyway? It's the initiator's problem, really....). The data transfer arithmetic has been worked over again to handle multiple outstanding commands, so you have a notion of what's been moved already as well as what's currently in flight. It turns that this led to uncovering a REPORT_LUNS bug in the ISP_INTERNAL_TARGET code which was sending back 24 bytes of rpl data instead of the specified 16. What happened furthermore here is that sending back 16 bytes and reporting an overrun of 8 bytes made the initiator (running FC-Tape aware f/w) mad enough to request, and keep requesting, another FCP response (I guess it didn't like the answer so kept asking for it again). Sponsored by: Spectralogic MFC after: 1 month
2012-08-08 18:24:33 +00:00
case FROM_SRR:
case FROM_CTIO_DONE:
Switch from using periph_links to sim_links. periph_links field belongs to periph drivers and must not be used here. MFC after: 2 weeks
2017-03-22 11:06:33 +00:00
TAILQ_INSERT_HEAD(waitq, &ccb->ccb_h, sim_links.tqe);
More rototilling with target mode in an attemp to get multiple CCB at a time outstanding reliable. It's not there yet, but this is the direction to go in so might as well commit. So far, multiple at a time CCBs work (see ISP_INTERNAL_TARGET test mode), but it fails if there are more downstream than the SIM wants to handle and SRR is sort of confused when this happens, plus it is not entirely quite clear what one does if a CCB/CTIO fails and you have more in flight (that don't fail, say) and more queued up at the SIM level that haven't been started yet. Some of this is driven because there apparently is no flow control to requeue XPT_CONTINUE_IO requests like there are for XPT_SCSI_IO requests. It is also more driven in that the few target mode periph drivers there are are not really set up for handling pushback- heck most of them don't even check for errors (and what would they really do with them anyway? It's the initiator's problem, really....). The data transfer arithmetic has been worked over again to handle multiple outstanding commands, so you have a notion of what's been moved already as well as what's currently in flight. It turns that this led to uncovering a REPORT_LUNS bug in the ISP_INTERNAL_TARGET code which was sending back 24 bytes of rpl data instead of the specified 16. What happened furthermore here is that sending back 16 bytes and reporting an overrun of 8 bytes made the initiator (running FC-Tape aware f/w) mad enough to request, and keep requesting, another FCP response (I guess it didn't like the answer so kept asking for it again). Sponsored by: Spectralogic MFC after: 1 month
2012-08-08 18:24:33 +00:00
break;
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
}
Move CTIO waitq from per-LUN to per-channel. All resources lack of which may put CTIO into the queue are either per-channel or potentially per-queue, but none of them are per-LUN. This is a first step to fix live LUN disabling. Before this change any CTIOs held in a queue in time of disabling were just leaked. MFC after: 2 weeks
2017-02-19 05:07:02 +00:00
while ((ccb = (union ccb *) TAILQ_FIRST(waitq)) != NULL) {
Switch from using periph_links to sim_links. periph_links field belongs to periph drivers and must not be used here. MFC after: 2 weeks
2017-03-22 11:06:33 +00:00
TAILQ_REMOVE(waitq, &ccb->ccb_h, sim_links.tqe);
Add a isp_target_putback_atio- we aren't using CCINCR at this time, so we need a function that tells the Qlogic f/w that a target mode command is done, so increase the resource count for that lun. Add in a timeout function to kick the putback again if we fail to do it the first time (we may not have the request queue space for ATIO push). Split the function isp_handle_platform_ctio into two parts so that the timeout function for the ATIO push or isp_handle_platform_ctio can inform CAM that the requested CTIO(s) are now done. Clean up (cough) residual handling. What we need for Fibre Channel is to preserve the at_datalen field from the original incoming ATIO so we can calculate a 'true' residual. Unfortunately, we're not guaranteed to get that back from CAM. We'll *try* to find it hiding in the periph_priv field (layering violation)- but if an ATIO was passed in from user land- forget it. This means that we'll probably get residuals wrong for Fibre Channel commands we're completing with an error. It's too late to 4.1 release to fix this- too bad. Luckily the only device we'd really care about this occurring on is a tape device and they're still so rare as FC attached devices that this can be considered an untested combination anyway. Remove all CCINCR usage (resource autoreplenish). When we've proved to ourself that things are working properly, we can add it back in. Make sure we propage 'suggested' sense data from the incoming ATIO into the created system ATIO- and set sense_len appropriately. Correctly propagate tag values. Fall back to the model of generating (well, the functions in isp_pci.c do the work) multiple CTIOs based upon what we get from XPT. Instead of being able to pair Qlogic generated ATIOs with CAM ATIOs, and then to pair CAM CTIOs with Qlogic CTIOs, we have to take the CTIO passed to us from XPT, and if it implies that we have to generate extra Qlogic CTIOs, so be it. This means that we have to wait until the last CTIO in a sequence we generated completes before calling xpt_done. Executive summary- target mode actually now pretty much works well enough to tell folks about.
2000-07-18 06:58:28 +00:00
More rototilling with target mode in an attemp to get multiple CCB at a time outstanding reliable. It's not there yet, but this is the direction to go in so might as well commit. So far, multiple at a time CCBs work (see ISP_INTERNAL_TARGET test mode), but it fails if there are more downstream than the SIM wants to handle and SRR is sort of confused when this happens, plus it is not entirely quite clear what one does if a CCB/CTIO fails and you have more in flight (that don't fail, say) and more queued up at the SIM level that haven't been started yet. Some of this is driven because there apparently is no flow control to requeue XPT_CONTINUE_IO requests like there are for XPT_SCSI_IO requests. It is also more driven in that the few target mode periph drivers there are are not really set up for handling pushback- heck most of them don't even check for errors (and what would they really do with them anyway? It's the initiator's problem, really....). The data transfer arithmetic has been worked over again to handle multiple outstanding commands, so you have a notion of what's been moved already as well as what's currently in flight. It turns that this led to uncovering a REPORT_LUNS bug in the ISP_INTERNAL_TARGET code which was sending back 24 bytes of rpl data instead of the specified 16. What happened furthermore here is that sending back 16 bytes and reporting an overrun of 8 bytes made the initiator (running FC-Tape aware f/w) mad enough to request, and keep requesting, another FCP response (I guess it didn't like the answer so kept asking for it again). Sponsored by: Spectralogic MFC after: 1 month
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
Fix multiple problems around LUN disable under load. - Move private data about ATIOs/INOTs from per-LUN to per-channel data. This allows active commands to continue operation after LUN destruction. This also simplifies lookup of the data by tag in some situations. - Unify three restart_queue processing implementations. - Complete all ATIOs from restart_queue on LUN disable. - Delete ATIO private data when command completed or aborted, not depending on the ATIO being requeued, that was ugly hack and could never happen. CAM should always call ether XPT_CONT_TARGET_IO with status or XPT_ABORT. - Implement XPT_ABORT for queued ATIOs/INOTs to allow CAM do graceful shutdown, not depending on LUN disable, as it is done in ahd(4)/targ(4). - Unify isp_endcmd() arguments to make it more usable in generic code. - Remove never really used LUN state reference counter. MFC after: 2 weeks
2017-02-22 06:43:49 +00:00
atp = isp_find_atpd(isp, XS_CHANNEL(ccb), cso->tag_id);
More rototilling with target mode in an attemp to get multiple CCB at a time outstanding reliable. It's not there yet, but this is the direction to go in so might as well commit. So far, multiple at a time CCBs work (see ISP_INTERNAL_TARGET test mode), but it fails if there are more downstream than the SIM wants to handle and SRR is sort of confused when this happens, plus it is not entirely quite clear what one does if a CCB/CTIO fails and you have more in flight (that don't fail, say) and more queued up at the SIM level that haven't been started yet. Some of this is driven because there apparently is no flow control to requeue XPT_CONTINUE_IO requests like there are for XPT_SCSI_IO requests. It is also more driven in that the few target mode periph drivers there are are not really set up for handling pushback- heck most of them don't even check for errors (and what would they really do with them anyway? It's the initiator's problem, really....). The data transfer arithmetic has been worked over again to handle multiple outstanding commands, so you have a notion of what's been moved already as well as what's currently in flight. It turns that this led to uncovering a REPORT_LUNS bug in the ISP_INTERNAL_TARGET code which was sending back 24 bytes of rpl data instead of the specified 16. What happened furthermore here is that sending back 16 bytes and reporting an overrun of 8 bytes made the initiator (running FC-Tape aware f/w) mad enough to request, and keep requesting, another FCP response (I guess it didn't like the answer so kept asking for it again). Sponsored by: Spectralogic MFC after: 1 month
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__);
Fix multiple problems around LUN disable under load. - Move private data about ATIOs/INOTs from per-LUN to per-channel data. This allows active commands to continue operation after LUN destruction. This also simplifies lookup of the data by tag in some situations. - Unify three restart_queue processing implementations. - Complete all ATIOs from restart_queue on LUN disable. - Delete ATIO private data when command completed or aborted, not depending on the ATIO being requeued, that was ugly hack and could never happen. CAM should always call ether XPT_CONT_TARGET_IO with status or XPT_ABORT. - Implement XPT_ABORT for queued ATIOs/INOTs to allow CAM do graceful shutdown, not depending on LUN disable, as it is done in ahd(4)/targ(4). - Unify isp_endcmd() arguments to make it more usable in generic code. - Remove never really used LUN state reference counter. MFC after: 2 weeks
2017-02-22 06:43:49 +00:00
isp_dump_atpd(isp, XS_CHANNEL(ccb));
More rototilling with target mode in an attemp to get multiple CCB at a time outstanding reliable. It's not there yet, but this is the direction to go in so might as well commit. So far, multiple at a time CCBs work (see ISP_INTERNAL_TARGET test mode), but it fails if there are more downstream than the SIM wants to handle and SRR is sort of confused when this happens, plus it is not entirely quite clear what one does if a CCB/CTIO fails and you have more in flight (that don't fail, say) and more queued up at the SIM level that haven't been started yet. Some of this is driven because there apparently is no flow control to requeue XPT_CONTINUE_IO requests like there are for XPT_SCSI_IO requests. It is also more driven in that the few target mode periph drivers there are are not really set up for handling pushback- heck most of them don't even check for errors (and what would they really do with them anyway? It's the initiator's problem, really....). The data transfer arithmetic has been worked over again to handle multiple outstanding commands, so you have a notion of what's been moved already as well as what's currently in flight. It turns that this led to uncovering a REPORT_LUNS bug in the ISP_INTERNAL_TARGET code which was sending back 24 bytes of rpl data instead of the specified 16. What happened furthermore here is that sending back 16 bytes and reporting an overrun of 8 bytes made the initiator (running FC-Tape aware f/w) mad enough to request, and keep requesting, another FCP response (I guess it didn't like the answer so kept asking for it again). Sponsored by: Spectralogic MFC after: 1 month
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
More rototilling with target mode in an attemp to get multiple CCB at a time outstanding reliable. It's not there yet, but this is the direction to go in so might as well commit. So far, multiple at a time CCBs work (see ISP_INTERNAL_TARGET test mode), but it fails if there are more downstream than the SIM wants to handle and SRR is sort of confused when this happens, plus it is not entirely quite clear what one does if a CCB/CTIO fails and you have more in flight (that don't fail, say) and more queued up at the SIM level that haven't been started yet. Some of this is driven because there apparently is no flow control to requeue XPT_CONTINUE_IO requests like there are for XPT_SCSI_IO requests. It is also more driven in that the few target mode periph drivers there are are not really set up for handling pushback- heck most of them don't even check for errors (and what would they really do with them anyway? It's the initiator's problem, really....). The data transfer arithmetic has been worked over again to handle multiple outstanding commands, so you have a notion of what's been moved already as well as what's currently in flight. It turns that this led to uncovering a REPORT_LUNS bug in the ISP_INTERNAL_TARGET code which was sending back 24 bytes of rpl data instead of the specified 16. What happened furthermore here is that sending back 16 bytes and reporting an overrun of 8 bytes made the initiator (running FC-Tape aware f/w) mad enough to request, and keep requesting, another FCP response (I guess it didn't like the answer so kept asking for it again). Sponsored by: Spectralogic MFC after: 1 month
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;
}
Make a static chain of isp softcs- gdb usage becomes a lot easier. Add in a very large amount of target mode support code- this is just a first pass at this. It's a difficult thing because some of the code can be in platform independent areas (see isp_target.?) but a lot has to be in platform dependent areas because of not only the tight coupling of received commands/events and the specific OS subsystem but because the platform independent code has (deliberately) no event/wait mechanisms.
2000-01-03 23:55:30 +00:00
More rototilling with target mode in an attemp to get multiple CCB at a time outstanding reliable. It's not there yet, but this is the direction to go in so might as well commit. So far, multiple at a time CCBs work (see ISP_INTERNAL_TARGET test mode), but it fails if there are more downstream than the SIM wants to handle and SRR is sort of confused when this happens, plus it is not entirely quite clear what one does if a CCB/CTIO fails and you have more in flight (that don't fail, say) and more queued up at the SIM level that haven't been started yet. Some of this is driven because there apparently is no flow control to requeue XPT_CONTINUE_IO requests like there are for XPT_SCSI_IO requests. It is also more driven in that the few target mode periph drivers there are are not really set up for handling pushback- heck most of them don't even check for errors (and what would they really do with them anyway? It's the initiator's problem, really....). The data transfer arithmetic has been worked over again to handle multiple outstanding commands, so you have a notion of what's been moved already as well as what's currently in flight. It turns that this led to uncovering a REPORT_LUNS bug in the ISP_INTERNAL_TARGET code which was sending back 24 bytes of rpl data instead of the specified 16. What happened furthermore here is that sending back 16 bytes and reporting an overrun of 8 bytes made the initiator (running FC-Tape aware f/w) mad enough to request, and keep requesting, another FCP response (I guess it didn't like the answer so kept asking for it again). Sponsored by: Spectralogic MFC after: 1 month
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
More rototilling with target mode in an attemp to get multiple CCB at a time outstanding reliable. It's not there yet, but this is the direction to go in so might as well commit. So far, multiple at a time CCBs work (see ISP_INTERNAL_TARGET test mode), but it fails if there are more downstream than the SIM wants to handle and SRR is sort of confused when this happens, plus it is not entirely quite clear what one does if a CCB/CTIO fails and you have more in flight (that don't fail, say) and more queued up at the SIM level that haven't been started yet. Some of this is driven because there apparently is no flow control to requeue XPT_CONTINUE_IO requests like there are for XPT_SCSI_IO requests. It is also more driven in that the few target mode periph drivers there are are not really set up for handling pushback- heck most of them don't even check for errors (and what would they really do with them anyway? It's the initiator's problem, really....). The data transfer arithmetic has been worked over again to handle multiple outstanding commands, so you have a notion of what's been moved already as well as what's currently in flight. It turns that this led to uncovering a REPORT_LUNS bug in the ISP_INTERNAL_TARGET code which was sending back 24 bytes of rpl data instead of the specified 16. What happened furthermore here is that sending back 16 bytes and reporting an overrun of 8 bytes made the initiator (running FC-Tape aware f/w) mad enough to request, and keep requesting, another FCP response (I guess it didn't like the answer so kept asking for it again). Sponsored by: Spectralogic MFC after: 1 month
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);
Switch from using periph_links to sim_links. periph_links field belongs to periph drivers and must not be used here. MFC after: 2 weeks
2017-03-22 11:06:33 +00:00
TAILQ_INSERT_HEAD(waitq, &ccb->ccb_h, sim_links.tqe);
More rototilling with target mode in an attemp to get multiple CCB at a time outstanding reliable. It's not there yet, but this is the direction to go in so might as well commit. So far, multiple at a time CCBs work (see ISP_INTERNAL_TARGET test mode), but it fails if there are more downstream than the SIM wants to handle and SRR is sort of confused when this happens, plus it is not entirely quite clear what one does if a CCB/CTIO fails and you have more in flight (that don't fail, say) and more queued up at the SIM level that haven't been started yet. Some of this is driven because there apparently is no flow control to requeue XPT_CONTINUE_IO requests like there are for XPT_SCSI_IO requests. It is also more driven in that the few target mode periph drivers there are are not really set up for handling pushback- heck most of them don't even check for errors (and what would they really do with them anyway? It's the initiator's problem, really....). The data transfer arithmetic has been worked over again to handle multiple outstanding commands, so you have a notion of what's been moved already as well as what's currently in flight. It turns that this led to uncovering a REPORT_LUNS bug in the ISP_INTERNAL_TARGET code which was sending back 24 bytes of rpl data instead of the specified 16. What happened furthermore here is that sending back 16 bytes and reporting an overrun of 8 bytes made the initiator (running FC-Tape aware f/w) mad enough to request, and keep requesting, another FCP response (I guess it didn't like the answer so kept asking for it again). Sponsored by: Spectralogic MFC after: 1 month
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
/*
More rototilling with target mode in an attemp to get multiple CCB at a time outstanding reliable. It's not there yet, but this is the direction to go in so might as well commit. So far, multiple at a time CCBs work (see ISP_INTERNAL_TARGET test mode), but it fails if there are more downstream than the SIM wants to handle and SRR is sort of confused when this happens, plus it is not entirely quite clear what one does if a CCB/CTIO fails and you have more in flight (that don't fail, say) and more queued up at the SIM level that haven't been started yet. Some of this is driven because there apparently is no flow control to requeue XPT_CONTINUE_IO requests like there are for XPT_SCSI_IO requests. It is also more driven in that the few target mode periph drivers there are are not really set up for handling pushback- heck most of them don't even check for errors (and what would they really do with them anyway? It's the initiator's problem, really....). The data transfer arithmetic has been worked over again to handle multiple outstanding commands, so you have a notion of what's been moved already as well as what's currently in flight. It turns that this led to uncovering a REPORT_LUNS bug in the ISP_INTERNAL_TARGET code which was sending back 24 bytes of rpl data instead of the specified 16. What happened furthermore here is that sending back 16 bytes and reporting an overrun of 8 bytes made the initiator (running FC-Tape aware f/w) mad enough to request, and keep requesting, another FCP response (I guess it didn't like the answer so kept asking for it again). Sponsored by: Spectralogic MFC after: 1 month
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
*/
More rototilling with target mode in an attemp to get multiple CCB at a time outstanding reliable. It's not there yet, but this is the direction to go in so might as well commit. So far, multiple at a time CCBs work (see ISP_INTERNAL_TARGET test mode), but it fails if there are more downstream than the SIM wants to handle and SRR is sort of confused when this happens, plus it is not entirely quite clear what one does if a CCB/CTIO fails and you have more in flight (that don't fail, say) and more queued up at the SIM level that haven't been started yet. Some of this is driven because there apparently is no flow control to requeue XPT_CONTINUE_IO requests like there are for XPT_SCSI_IO requests. It is also more driven in that the few target mode periph drivers there are are not really set up for handling pushback- heck most of them don't even check for errors (and what would they really do with them anyway? It's the initiator's problem, really....). The data transfer arithmetic has been worked over again to handle multiple outstanding commands, so you have a notion of what's been moved already as well as what's currently in flight. It turns that this led to uncovering a REPORT_LUNS bug in the ISP_INTERNAL_TARGET code which was sending back 24 bytes of rpl data instead of the specified 16. What happened furthermore here is that sending back 16 bytes and reporting an overrun of 8 bytes made the initiator (running FC-Tape aware f/w) mad enough to request, and keep requesting, another FCP response (I guess it didn't like the answer so kept asking for it again). Sponsored by: Spectralogic MFC after: 1 month
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
/*
More rototilling with target mode in an attemp to get multiple CCB at a time outstanding reliable. It's not there yet, but this is the direction to go in so might as well commit. So far, multiple at a time CCBs work (see ISP_INTERNAL_TARGET test mode), but it fails if there are more downstream than the SIM wants to handle and SRR is sort of confused when this happens, plus it is not entirely quite clear what one does if a CCB/CTIO fails and you have more in flight (that don't fail, say) and more queued up at the SIM level that haven't been started yet. Some of this is driven because there apparently is no flow control to requeue XPT_CONTINUE_IO requests like there are for XPT_SCSI_IO requests. It is also more driven in that the few target mode periph drivers there are are not really set up for handling pushback- heck most of them don't even check for errors (and what would they really do with them anyway? It's the initiator's problem, really....). The data transfer arithmetic has been worked over again to handle multiple outstanding commands, so you have a notion of what's been moved already as well as what's currently in flight. It turns that this led to uncovering a REPORT_LUNS bug in the ISP_INTERNAL_TARGET code which was sending back 24 bytes of rpl data instead of the specified 16. What happened furthermore here is that sending back 16 bytes and reporting an overrun of 8 bytes made the initiator (running FC-Tape aware f/w) mad enough to request, and keep requesting, another FCP response (I guess it didn't like the answer so kept asking for it again). Sponsored by: Spectralogic MFC after: 1 month
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
*/
More rototilling with target mode in an attemp to get multiple CCB at a time outstanding reliable. It's not there yet, but this is the direction to go in so might as well commit. So far, multiple at a time CCBs work (see ISP_INTERNAL_TARGET test mode), but it fails if there are more downstream than the SIM wants to handle and SRR is sort of confused when this happens, plus it is not entirely quite clear what one does if a CCB/CTIO fails and you have more in flight (that don't fail, say) and more queued up at the SIM level that haven't been started yet. Some of this is driven because there apparently is no flow control to requeue XPT_CONTINUE_IO requests like there are for XPT_SCSI_IO requests. It is also more driven in that the few target mode periph drivers there are are not really set up for handling pushback- heck most of them don't even check for errors (and what would they really do with them anyway? It's the initiator's problem, really....). The data transfer arithmetic has been worked over again to handle multiple outstanding commands, so you have a notion of what's been moved already as well as what's currently in flight. It turns that this led to uncovering a REPORT_LUNS bug in the ISP_INTERNAL_TARGET code which was sending back 24 bytes of rpl data instead of the specified 16. What happened furthermore here is that sending back 16 bytes and reporting an overrun of 8 bytes made the initiator (running FC-Tape aware f/w) mad enough to request, and keep requesting, another FCP response (I guess it didn't like the answer so kept asking for it again). Sponsored by: Spectralogic MFC after: 1 month
2012-08-08 18:24:33 +00:00
if (atp->sendst) {
Reduce verbosity of "now sending synthesized status" message. MFC after: 1 week
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",
More rototilling with target mode in an attemp to get multiple CCB at a time outstanding reliable. It's not there yet, but this is the direction to go in so might as well commit. So far, multiple at a time CCBs work (see ISP_INTERNAL_TARGET test mode), but it fails if there are more downstream than the SIM wants to handle and SRR is sort of confused when this happens, plus it is not entirely quite clear what one does if a CCB/CTIO fails and you have more in flight (that don't fail, say) and more queued up at the SIM level that haven't been started yet. Some of this is driven because there apparently is no flow control to requeue XPT_CONTINUE_IO requests like there are for XPT_SCSI_IO requests. It is also more driven in that the few target mode periph drivers there are are not really set up for handling pushback- heck most of them don't even check for errors (and what would they really do with them anyway? It's the initiator's problem, really....). The data transfer arithmetic has been worked over again to handle multiple outstanding commands, so you have a notion of what's been moved already as well as what's currently in flight. It turns that this led to uncovering a REPORT_LUNS bug in the ISP_INTERNAL_TARGET code which was sending back 24 bytes of rpl data instead of the specified 16. What happened furthermore here is that sending back 16 bytes and reporting an overrun of 8 bytes made the initiator (running FC-Tape aware f/w) mad enough to request, and keep requesting, another FCP response (I guess it didn't like the answer so kept asking for it again). Sponsored by: Spectralogic MFC after: 1 month
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
}
More rototilling with target mode in an attemp to get multiple CCB at a time outstanding reliable. It's not there yet, but this is the direction to go in so might as well commit. So far, multiple at a time CCBs work (see ISP_INTERNAL_TARGET test mode), but it fails if there are more downstream than the SIM wants to handle and SRR is sort of confused when this happens, plus it is not entirely quite clear what one does if a CCB/CTIO fails and you have more in flight (that don't fail, say) and more queued up at the SIM level that haven't been started yet. Some of this is driven because there apparently is no flow control to requeue XPT_CONTINUE_IO requests like there are for XPT_SCSI_IO requests. It is also more driven in that the few target mode periph drivers there are are not really set up for handling pushback- heck most of them don't even check for errors (and what would they really do with them anyway? It's the initiator's problem, really....). The data transfer arithmetic has been worked over again to handle multiple outstanding commands, so you have a notion of what's been moved already as well as what's currently in flight. It turns that this led to uncovering a REPORT_LUNS bug in the ISP_INTERNAL_TARGET code which was sending back 24 bytes of rpl data instead of the specified 16. What happened furthermore here is that sending back 16 bytes and reporting an overrun of 8 bytes made the initiator (running FC-Tape aware f/w) mad enough to request, and keep requesting, another FCP response (I guess it didn't like the answer so kept asking for it again). Sponsored by: Spectralogic MFC after: 1 month
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
More rototilling with target mode in an attemp to get multiple CCB at a time outstanding reliable. It's not there yet, but this is the direction to go in so might as well commit. So far, multiple at a time CCBs work (see ISP_INTERNAL_TARGET test mode), but it fails if there are more downstream than the SIM wants to handle and SRR is sort of confused when this happens, plus it is not entirely quite clear what one does if a CCB/CTIO fails and you have more in flight (that don't fail, say) and more queued up at the SIM level that haven't been started yet. Some of this is driven because there apparently is no flow control to requeue XPT_CONTINUE_IO requests like there are for XPT_SCSI_IO requests. It is also more driven in that the few target mode periph drivers there are are not really set up for handling pushback- heck most of them don't even check for errors (and what would they really do with them anyway? It's the initiator's problem, really....). The data transfer arithmetic has been worked over again to handle multiple outstanding commands, so you have a notion of what's been moved already as well as what's currently in flight. It turns that this led to uncovering a REPORT_LUNS bug in the ISP_INTERNAL_TARGET code which was sending back 24 bytes of rpl data instead of the specified 16. What happened furthermore here is that sending back 16 bytes and reporting an overrun of 8 bytes made the initiator (running FC-Tape aware f/w) mad enough to request, and keep requesting, another FCP response (I guess it didn't like the answer so kept asking for it again). Sponsored by: Spectralogic MFC after: 1 month
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;
}
Make a static chain of isp softcs- gdb usage becomes a lot easier. Add in a very large amount of target mode support code- this is just a first pass at this. It's a difficult thing because some of the code can be in platform independent areas (see isp_target.?) but a lot has to be in platform dependent areas because of not only the tight coupling of received commands/events and the specific OS subsystem but because the platform independent code has (deliberately) no event/wait mechanisms.
2000-01-03 23:55:30 +00:00
More rototilling with target mode in an attemp to get multiple CCB at a time outstanding reliable. It's not there yet, but this is the direction to go in so might as well commit. So far, multiple at a time CCBs work (see ISP_INTERNAL_TARGET test mode), but it fails if there are more downstream than the SIM wants to handle and SRR is sort of confused when this happens, plus it is not entirely quite clear what one does if a CCB/CTIO fails and you have more in flight (that don't fail, say) and more queued up at the SIM level that haven't been started yet. Some of this is driven because there apparently is no flow control to requeue XPT_CONTINUE_IO requests like there are for XPT_SCSI_IO requests. It is also more driven in that the few target mode periph drivers there are are not really set up for handling pushback- heck most of them don't even check for errors (and what would they really do with them anyway? It's the initiator's problem, really....). The data transfer arithmetic has been worked over again to handle multiple outstanding commands, so you have a notion of what's been moved already as well as what's currently in flight. It turns that this led to uncovering a REPORT_LUNS bug in the ISP_INTERNAL_TARGET code which was sending back 24 bytes of rpl data instead of the specified 16. What happened furthermore here is that sending back 16 bytes and reporting an overrun of 8 bytes made the initiator (running FC-Tape aware f/w) mad enough to request, and keep requesting, another FCP response (I guess it didn't like the answer so kept asking for it again). Sponsored by: Spectralogic MFC after: 1 month
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
/*
More rototilling with target mode in an attemp to get multiple CCB at a time outstanding reliable. It's not there yet, but this is the direction to go in so might as well commit. So far, multiple at a time CCBs work (see ISP_INTERNAL_TARGET test mode), but it fails if there are more downstream than the SIM wants to handle and SRR is sort of confused when this happens, plus it is not entirely quite clear what one does if a CCB/CTIO fails and you have more in flight (that don't fail, say) and more queued up at the SIM level that haven't been started yet. Some of this is driven because there apparently is no flow control to requeue XPT_CONTINUE_IO requests like there are for XPT_SCSI_IO requests. It is also more driven in that the few target mode periph drivers there are are not really set up for handling pushback- heck most of them don't even check for errors (and what would they really do with them anyway? It's the initiator's problem, really....). The data transfer arithmetic has been worked over again to handle multiple outstanding commands, so you have a notion of what's been moved already as well as what's currently in flight. It turns that this led to uncovering a REPORT_LUNS bug in the ISP_INTERNAL_TARGET code which was sending back 24 bytes of rpl data instead of the specified 16. What happened furthermore here is that sending back 16 bytes and reporting an overrun of 8 bytes made the initiator (running FC-Tape aware f/w) mad enough to request, and keep requesting, another FCP response (I guess it didn't like the answer so kept asking for it again). Sponsored by: Spectralogic MFC after: 1 month
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
*/
Fix residual length reporting in target mode. This allows to properly handle cases when target wants to receive or send more data then initiator wants to send or receive. Previously in such cases isp(4) returned CAM_DATA_RUN_ERR, while now it returns resid > 0. MFC after: 2 weeks
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);
More rototilling with target mode in an attemp to get multiple CCB at a time outstanding reliable. It's not there yet, but this is the direction to go in so might as well commit. So far, multiple at a time CCBs work (see ISP_INTERNAL_TARGET test mode), but it fails if there are more downstream than the SIM wants to handle and SRR is sort of confused when this happens, plus it is not entirely quite clear what one does if a CCB/CTIO fails and you have more in flight (that don't fail, say) and more queued up at the SIM level that haven't been started yet. Some of this is driven because there apparently is no flow control to requeue XPT_CONTINUE_IO requests like there are for XPT_SCSI_IO requests. It is also more driven in that the few target mode periph drivers there are are not really set up for handling pushback- heck most of them don't even check for errors (and what would they really do with them anyway? It's the initiator's problem, really....). The data transfer arithmetic has been worked over again to handle multiple outstanding commands, so you have a notion of what's been moved already as well as what's currently in flight. It turns that this led to uncovering a REPORT_LUNS bug in the ISP_INTERNAL_TARGET code which was sending back 24 bytes of rpl data instead of the specified 16. What happened furthermore here is that sending back 16 bytes and reporting an overrun of 8 bytes made the initiator (running FC-Tape aware f/w) mad enough to request, and keep requesting, another FCP response (I guess it didn't like the answer so kept asking for it again). Sponsored by: Spectralogic MFC after: 1 month
2012-08-08 18:24:33 +00:00
ccb->ccb_h.status = CAM_DATA_RUN_ERR;
xpt_done(ccb);
continue;
}
Fix residual length reporting in target mode. This allows to properly handle cases when target wants to receive or send more data then initiator wants to send or receive. Previously in such cases isp(4) returned CAM_DATA_RUN_ERR, while now it returns resid > 0. MFC after: 2 weeks
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;
}
}
More rototilling with target mode in an attemp to get multiple CCB at a time outstanding reliable. It's not there yet, but this is the direction to go in so might as well commit. So far, multiple at a time CCBs work (see ISP_INTERNAL_TARGET test mode), but it fails if there are more downstream than the SIM wants to handle and SRR is sort of confused when this happens, plus it is not entirely quite clear what one does if a CCB/CTIO fails and you have more in flight (that don't fail, say) and more queued up at the SIM level that haven't been started yet. Some of this is driven because there apparently is no flow control to requeue XPT_CONTINUE_IO requests like there are for XPT_SCSI_IO requests. It is also more driven in that the few target mode periph drivers there are are not really set up for handling pushback- heck most of them don't even check for errors (and what would they really do with them anyway? It's the initiator's problem, really....). The data transfer arithmetic has been worked over again to handle multiple outstanding commands, so you have a notion of what's been moved already as well as what's currently in flight. It turns that this led to uncovering a REPORT_LUNS bug in the ISP_INTERNAL_TARGET code which was sending back 24 bytes of rpl data instead of the specified 16. What happened furthermore here is that sending back 16 bytes and reporting an overrun of 8 bytes made the initiator (running FC-Tape aware f/w) mad enough to request, and keep requesting, another FCP response (I guess it didn't like the answer so kept asking for it again). Sponsored by: Spectralogic MFC after: 1 month
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;
Send TERMINATE to firmware when aborting active ATIO. MFC after: 2 weeks
2017-02-27 08:20:28 +00:00
cto->ct_iid_lo = atp->sid;
cto->ct_iid_hi = atp->sid >> 16;
More rototilling with target mode in an attemp to get multiple CCB at a time outstanding reliable. It's not there yet, but this is the direction to go in so might as well commit. So far, multiple at a time CCBs work (see ISP_INTERNAL_TARGET test mode), but it fails if there are more downstream than the SIM wants to handle and SRR is sort of confused when this happens, plus it is not entirely quite clear what one does if a CCB/CTIO fails and you have more in flight (that don't fail, say) and more queued up at the SIM level that haven't been started yet. Some of this is driven because there apparently is no flow control to requeue XPT_CONTINUE_IO requests like there are for XPT_SCSI_IO requests. It is also more driven in that the few target mode periph drivers there are are not really set up for handling pushback- heck most of them don't even check for errors (and what would they really do with them anyway? It's the initiator's problem, really....). The data transfer arithmetic has been worked over again to handle multiple outstanding commands, so you have a notion of what's been moved already as well as what's currently in flight. It turns that this led to uncovering a REPORT_LUNS bug in the ISP_INTERNAL_TARGET code which was sending back 24 bytes of rpl data instead of the specified 16. What happened furthermore here is that sending back 16 bytes and reporting an overrun of 8 bytes made the initiator (running FC-Tape aware f/w) mad enough to request, and keep requesting, another FCP response (I guess it didn't like the answer so kept asking for it again). Sponsored by: Spectralogic MFC after: 1 month
2012-08-08 18:24:33 +00:00
cto->ct_oxid = atp->oxid;
cto->ct_vpidx = ISP_GET_VPIDX(isp, XS_CHANNEL(ccb));
Improve command timeout handling. Let firmware do its best first, and if it can't, try software recovery. I would remove software timeout handler completely, but found bunch of complains on command timeout on sparc64 mailing list few years ago, so better be safe in case of interrupt loss. MFC after: 2 weeks
2017-03-21 13:10:37 +00:00
cto->ct_timeout = XS_TIME(ccb);
More rototilling with target mode in an attemp to get multiple CCB at a time outstanding reliable. It's not there yet, but this is the direction to go in so might as well commit. So far, multiple at a time CCBs work (see ISP_INTERNAL_TARGET test mode), but it fails if there are more downstream than the SIM wants to handle and SRR is sort of confused when this happens, plus it is not entirely quite clear what one does if a CCB/CTIO fails and you have more in flight (that don't fail, say) and more queued up at the SIM level that haven't been started yet. Some of this is driven because there apparently is no flow control to requeue XPT_CONTINUE_IO requests like there are for XPT_SCSI_IO requests. It is also more driven in that the few target mode periph drivers there are are not really set up for handling pushback- heck most of them don't even check for errors (and what would they really do with them anyway? It's the initiator's problem, really....). The data transfer arithmetic has been worked over again to handle multiple outstanding commands, so you have a notion of what's been moved already as well as what's currently in flight. It turns that this led to uncovering a REPORT_LUNS bug in the ISP_INTERNAL_TARGET code which was sending back 24 bytes of rpl data instead of the specified 16. What happened furthermore here is that sending back 16 bytes and reporting an overrun of 8 bytes made the initiator (running FC-Tape aware f/w) mad enough to request, and keep requesting, another FCP response (I guess it didn't like the answer so kept asking for it again). Sponsored by: Spectralogic MFC after: 1 month
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
Minor correction. MFC after: 1 day
2012-09-17 02:50:16 +00:00
* no data to transfer, and any sense data can fit into a ct7_entry_t.
More rototilling with target mode in an attemp to get multiple CCB at a time outstanding reliable. It's not there yet, but this is the direction to go in so might as well commit. So far, multiple at a time CCBs work (see ISP_INTERNAL_TARGET test mode), but it fails if there are more downstream than the SIM wants to handle and SRR is sort of confused when this happens, plus it is not entirely quite clear what one does if a CCB/CTIO fails and you have more in flight (that don't fail, say) and more queued up at the SIM level that haven't been started yet. Some of this is driven because there apparently is no flow control to requeue XPT_CONTINUE_IO requests like there are for XPT_SCSI_IO requests. It is also more driven in that the few target mode periph drivers there are are not really set up for handling pushback- heck most of them don't even check for errors (and what would they really do with them anyway? It's the initiator's problem, really....). The data transfer arithmetic has been worked over again to handle multiple outstanding commands, so you have a notion of what's been moved already as well as what's currently in flight. It turns that this led to uncovering a REPORT_LUNS bug in the ISP_INTERNAL_TARGET code which was sending back 24 bytes of rpl data instead of the specified 16. What happened furthermore here is that sending back 16 bytes and reporting an overrun of 8 bytes made the initiator (running FC-Tape aware f/w) mad enough to request, and keep requesting, another FCP response (I guess it didn't like the answer so kept asking for it again). Sponsored by: Spectralogic MFC after: 1 month
2012-08-08 18:24:33 +00:00
*
Add some edits to the changed comments so that they make more sense. MFC after: 1 day
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.
More rototilling with target mode in an attemp to get multiple CCB at a time outstanding reliable. It's not there yet, but this is the direction to go in so might as well commit. So far, multiple at a time CCBs work (see ISP_INTERNAL_TARGET test mode), but it fails if there are more downstream than the SIM wants to handle and SRR is sort of confused when this happens, plus it is not entirely quite clear what one does if a CCB/CTIO fails and you have more in flight (that don't fail, say) and more queued up at the SIM level that haven't been started yet. Some of this is driven because there apparently is no flow control to requeue XPT_CONTINUE_IO requests like there are for XPT_SCSI_IO requests. It is also more driven in that the few target mode periph drivers there are are not really set up for handling pushback- heck most of them don't even check for errors (and what would they really do with them anyway? It's the initiator's problem, really....). The data transfer arithmetic has been worked over again to handle multiple outstanding commands, so you have a notion of what's been moved already as well as what's currently in flight. It turns that this led to uncovering a REPORT_LUNS bug in the ISP_INTERNAL_TARGET code which was sending back 24 bytes of rpl data instead of the specified 16. What happened furthermore here is that sending back 16 bytes and reporting an overrun of 8 bytes made the initiator (running FC-Tape aware f/w) mad enough to request, and keep requesting, another FCP response (I guess it didn't like the answer so kept asking for it again). Sponsored by: Spectralogic MFC after: 1 month
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) {
Fix residual length reporting in target mode. This allows to properly handle cases when target wants to receive or send more data then initiator wants to send or receive. Previously in such cases isp(4) returned CAM_DATA_RUN_ERR, while now it returns resid > 0. MFC after: 2 weeks
2017-02-26 12:52:44 +00:00
cto->ct_resid = -resid;
More rototilling with target mode in an attemp to get multiple CCB at a time outstanding reliable. It's not there yet, but this is the direction to go in so might as well commit. So far, multiple at a time CCBs work (see ISP_INTERNAL_TARGET test mode), but it fails if there are more downstream than the SIM wants to handle and SRR is sort of confused when this happens, plus it is not entirely quite clear what one does if a CCB/CTIO fails and you have more in flight (that don't fail, say) and more queued up at the SIM level that haven't been started yet. Some of this is driven because there apparently is no flow control to requeue XPT_CONTINUE_IO requests like there are for XPT_SCSI_IO requests. It is also more driven in that the few target mode periph drivers there are are not really set up for handling pushback- heck most of them don't even check for errors (and what would they really do with them anyway? It's the initiator's problem, really....). The data transfer arithmetic has been worked over again to handle multiple outstanding commands, so you have a notion of what's been moved already as well as what's currently in flight. It turns that this led to uncovering a REPORT_LUNS bug in the ISP_INTERNAL_TARGET code which was sending back 24 bytes of rpl data instead of the specified 16. What happened furthermore here is that sending back 16 bytes and reporting an overrun of 8 bytes made the initiator (running FC-Tape aware f/w) mad enough to request, and keep requesting, another FCP response (I guess it didn't like the answer so kept asking for it again). Sponsored by: Spectralogic MFC after: 1 month
2012-08-08 18:24:33 +00:00
cto->ct_scsi_status |= (FCP_RESID_OVERFLOW << 8);
} else if (resid > 0) {
Fix residual length reporting in target mode. This allows to properly handle cases when target wants to receive or send more data then initiator wants to send or receive. Previously in such cases isp(4) returned CAM_DATA_RUN_ERR, while now it returns resid > 0. MFC after: 2 weeks
2017-02-26 12:52:44 +00:00
cto->ct_resid = resid;
More rototilling with target mode in an attemp to get multiple CCB at a time outstanding reliable. It's not there yet, but this is the direction to go in so might as well commit. So far, multiple at a time CCBs work (see ISP_INTERNAL_TARGET test mode), but it fails if there are more downstream than the SIM wants to handle and SRR is sort of confused when this happens, plus it is not entirely quite clear what one does if a CCB/CTIO fails and you have more in flight (that don't fail, say) and more queued up at the SIM level that haven't been started yet. Some of this is driven because there apparently is no flow control to requeue XPT_CONTINUE_IO requests like there are for XPT_SCSI_IO requests. It is also more driven in that the few target mode periph drivers there are are not really set up for handling pushback- heck most of them don't even check for errors (and what would they really do with them anyway? It's the initiator's problem, really....). The data transfer arithmetic has been worked over again to handle multiple outstanding commands, so you have a notion of what's been moved already as well as what's currently in flight. It turns that this led to uncovering a REPORT_LUNS bug in the ISP_INTERNAL_TARGET code which was sending back 24 bytes of rpl data instead of the specified 16. What happened furthermore here is that sending back 16 bytes and reporting an overrun of 8 bytes made the initiator (running FC-Tape aware f/w) mad enough to request, and keep requesting, another FCP response (I guess it didn't like the answer so kept asking for it again). Sponsored by: Spectralogic MFC after: 1 month
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;
Don't allocate full XCMD_SIZE (512 bytes) on stack. We need only 24 bytes (fcp_rsp_iu_t) there for isp_put_fcp_rsp_iu(). MFC after: 1 month
2020-11-18 02:12:51 +00:00
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) {
More rototilling with target mode in an attemp to get multiple CCB at a time outstanding reliable. It's not there yet, but this is the direction to go in so might as well commit. So far, multiple at a time CCBs work (see ISP_INTERNAL_TARGET test mode), but it fails if there are more downstream than the SIM wants to handle and SRR is sort of confused when this happens, plus it is not entirely quite clear what one does if a CCB/CTIO fails and you have more in flight (that don't fail, say) and more queued up at the SIM level that haven't been started yet. Some of this is driven because there apparently is no flow control to requeue XPT_CONTINUE_IO requests like there are for XPT_SCSI_IO requests. It is also more driven in that the few target mode periph drivers there are are not really set up for handling pushback- heck most of them don't even check for errors (and what would they really do with them anyway? It's the initiator's problem, really....). The data transfer arithmetic has been worked over again to handle multiple outstanding commands, so you have a notion of what's been moved already as well as what's currently in flight. It turns that this led to uncovering a REPORT_LUNS bug in the ISP_INTERNAL_TARGET code which was sending back 24 bytes of rpl data instead of the specified 16. What happened furthermore here is that sending back 16 bytes and reporting an overrun of 8 bytes made the initiator (running FC-Tape aware f/w) mad enough to request, and keep requesting, another FCP response (I guess it didn't like the answer so kept asking for it again). Sponsored by: Spectralogic MFC after: 1 month
2012-08-08 18:24:33 +00:00
atp->ests = isp_get_ecmd(isp);
if (atp->ests == NULL) {
Switch from using periph_links to sim_links. periph_links field belongs to periph drivers and must not be used here. MFC after: 2 weeks
2017-03-22 11:06:33 +00:00
TAILQ_INSERT_HEAD(waitq, &ccb->ccb_h, sim_links.tqe);
More rototilling with target mode in an attemp to get multiple CCB at a time outstanding reliable. It's not there yet, but this is the direction to go in so might as well commit. So far, multiple at a time CCBs work (see ISP_INTERNAL_TARGET test mode), but it fails if there are more downstream than the SIM wants to handle and SRR is sort of confused when this happens, plus it is not entirely quite clear what one does if a CCB/CTIO fails and you have more in flight (that don't fail, say) and more queued up at the SIM level that haven't been started yet. Some of this is driven because there apparently is no flow control to requeue XPT_CONTINUE_IO requests like there are for XPT_SCSI_IO requests. It is also more driven in that the few target mode periph drivers there are are not really set up for handling pushback- heck most of them don't even check for errors (and what would they really do with them anyway? It's the initiator's problem, really....). The data transfer arithmetic has been worked over again to handle multiple outstanding commands, so you have a notion of what's been moved already as well as what's currently in flight. It turns that this led to uncovering a REPORT_LUNS bug in the ISP_INTERNAL_TARGET code which was sending back 24 bytes of rpl data instead of the specified 16. What happened furthermore here is that sending back 16 bytes and reporting an overrun of 8 bytes made the initiator (running FC-Tape aware f/w) mad enough to request, and keep requesting, another FCP response (I guess it didn't like the answer so kept asking for it again). Sponsored by: Spectralogic MFC after: 1 month
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
}
Don't allocate full XCMD_SIZE (512 bytes) on stack. We need only 24 bytes (fcp_rsp_iu_t) there for isp_put_fcp_rsp_iu(). MFC after: 1 month
2020-11-18 02:12:51 +00:00
memset(&rp, 0, sizeof(rp));
More rototilling with target mode in an attemp to get multiple CCB at a time outstanding reliable. It's not there yet, but this is the direction to go in so might as well commit. So far, multiple at a time CCBs work (see ISP_INTERNAL_TARGET test mode), but it fails if there are more downstream than the SIM wants to handle and SRR is sort of confused when this happens, plus it is not entirely quite clear what one does if a CCB/CTIO fails and you have more in flight (that don't fail, say) and more queued up at the SIM level that haven't been started yet. Some of this is driven because there apparently is no flow control to requeue XPT_CONTINUE_IO requests like there are for XPT_SCSI_IO requests. It is also more driven in that the few target mode periph drivers there are are not really set up for handling pushback- heck most of them don't even check for errors (and what would they really do with them anyway? It's the initiator's problem, really....). The data transfer arithmetic has been worked over again to handle multiple outstanding commands, so you have a notion of what's been moved already as well as what's currently in flight. It turns that this led to uncovering a REPORT_LUNS bug in the ISP_INTERNAL_TARGET code which was sending back 24 bytes of rpl data instead of the specified 16. What happened furthermore here is that sending back 16 bytes and reporting an overrun of 8 bytes made the initiator (running FC-Tape aware f/w) mad enough to request, and keep requesting, another FCP response (I guess it didn't like the answer so kept asking for it again). Sponsored by: Spectralogic MFC after: 1 month
2012-08-08 18:24:33 +00:00
if (fctape) {
cto->ct_flags |= CT7_CONFIRM|CT7_EXPLCT_CONF;
Don't allocate full XCMD_SIZE (512 bytes) on stack. We need only 24 bytes (fcp_rsp_iu_t) there for isp_put_fcp_rsp_iu(). MFC after: 1 month
2020-11-18 02:12:51 +00:00
rp.fcp_rsp_bits |= FCP_CONF_REQ;
More rototilling with target mode in an attemp to get multiple CCB at a time outstanding reliable. It's not there yet, but this is the direction to go in so might as well commit. So far, multiple at a time CCBs work (see ISP_INTERNAL_TARGET test mode), but it fails if there are more downstream than the SIM wants to handle and SRR is sort of confused when this happens, plus it is not entirely quite clear what one does if a CCB/CTIO fails and you have more in flight (that don't fail, say) and more queued up at the SIM level that haven't been started yet. Some of this is driven because there apparently is no flow control to requeue XPT_CONTINUE_IO requests like there are for XPT_SCSI_IO requests. It is also more driven in that the few target mode periph drivers there are are not really set up for handling pushback- heck most of them don't even check for errors (and what would they really do with them anyway? It's the initiator's problem, really....). The data transfer arithmetic has been worked over again to handle multiple outstanding commands, so you have a notion of what's been moved already as well as what's currently in flight. It turns that this led to uncovering a REPORT_LUNS bug in the ISP_INTERNAL_TARGET code which was sending back 24 bytes of rpl data instead of the specified 16. What happened furthermore here is that sending back 16 bytes and reporting an overrun of 8 bytes made the initiator (running FC-Tape aware f/w) mad enough to request, and keep requesting, another FCP response (I guess it didn't like the answer so kept asking for it again). Sponsored by: Spectralogic MFC after: 1 month
2012-08-08 18:24:33 +00:00
}
cto->ct_flags |= CT7_FLAG_MODE2;
Don't allocate full XCMD_SIZE (512 bytes) on stack. We need only 24 bytes (fcp_rsp_iu_t) there for isp_put_fcp_rsp_iu(). MFC after: 1 month
2020-11-18 02:12:51 +00:00
rp.fcp_rsp_scsi_status = cso->scsi_status;
More rototilling with target mode in an attemp to get multiple CCB at a time outstanding reliable. It's not there yet, but this is the direction to go in so might as well commit. So far, multiple at a time CCBs work (see ISP_INTERNAL_TARGET test mode), but it fails if there are more downstream than the SIM wants to handle and SRR is sort of confused when this happens, plus it is not entirely quite clear what one does if a CCB/CTIO fails and you have more in flight (that don't fail, say) and more queued up at the SIM level that haven't been started yet. Some of this is driven because there apparently is no flow control to requeue XPT_CONTINUE_IO requests like there are for XPT_SCSI_IO requests. It is also more driven in that the few target mode periph drivers there are are not really set up for handling pushback- heck most of them don't even check for errors (and what would they really do with them anyway? It's the initiator's problem, really....). The data transfer arithmetic has been worked over again to handle multiple outstanding commands, so you have a notion of what's been moved already as well as what's currently in flight. It turns that this led to uncovering a REPORT_LUNS bug in the ISP_INTERNAL_TARGET code which was sending back 24 bytes of rpl data instead of the specified 16. What happened furthermore here is that sending back 16 bytes and reporting an overrun of 8 bytes made the initiator (running FC-Tape aware f/w) mad enough to request, and keep requesting, another FCP response (I guess it didn't like the answer so kept asking for it again). Sponsored by: Spectralogic MFC after: 1 month
2012-08-08 18:24:33 +00:00
if (resid < 0) {
Don't allocate full XCMD_SIZE (512 bytes) on stack. We need only 24 bytes (fcp_rsp_iu_t) there for isp_put_fcp_rsp_iu(). MFC after: 1 month
2020-11-18 02:12:51 +00:00
rp.fcp_rsp_resid = -resid;
rp.fcp_rsp_bits |= FCP_RESID_OVERFLOW;
More rototilling with target mode in an attemp to get multiple CCB at a time outstanding reliable. It's not there yet, but this is the direction to go in so might as well commit. So far, multiple at a time CCBs work (see ISP_INTERNAL_TARGET test mode), but it fails if there are more downstream than the SIM wants to handle and SRR is sort of confused when this happens, plus it is not entirely quite clear what one does if a CCB/CTIO fails and you have more in flight (that don't fail, say) and more queued up at the SIM level that haven't been started yet. Some of this is driven because there apparently is no flow control to requeue XPT_CONTINUE_IO requests like there are for XPT_SCSI_IO requests. It is also more driven in that the few target mode periph drivers there are are not really set up for handling pushback- heck most of them don't even check for errors (and what would they really do with them anyway? It's the initiator's problem, really....). The data transfer arithmetic has been worked over again to handle multiple outstanding commands, so you have a notion of what's been moved already as well as what's currently in flight. It turns that this led to uncovering a REPORT_LUNS bug in the ISP_INTERNAL_TARGET code which was sending back 24 bytes of rpl data instead of the specified 16. What happened furthermore here is that sending back 16 bytes and reporting an overrun of 8 bytes made the initiator (running FC-Tape aware f/w) mad enough to request, and keep requesting, another FCP response (I guess it didn't like the answer so kept asking for it again). Sponsored by: Spectralogic MFC after: 1 month
2012-08-08 18:24:33 +00:00
} else if (resid > 0) {
Don't allocate full XCMD_SIZE (512 bytes) on stack. We need only 24 bytes (fcp_rsp_iu_t) there for isp_put_fcp_rsp_iu(). MFC after: 1 month
2020-11-18 02:12:51 +00:00
rp.fcp_rsp_resid = resid;
rp.fcp_rsp_bits |= FCP_RESID_UNDERFLOW;
More rototilling with target mode in an attemp to get multiple CCB at a time outstanding reliable. It's not there yet, but this is the direction to go in so might as well commit. So far, multiple at a time CCBs work (see ISP_INTERNAL_TARGET test mode), but it fails if there are more downstream than the SIM wants to handle and SRR is sort of confused when this happens, plus it is not entirely quite clear what one does if a CCB/CTIO fails and you have more in flight (that don't fail, say) and more queued up at the SIM level that haven't been started yet. Some of this is driven because there apparently is no flow control to requeue XPT_CONTINUE_IO requests like there are for XPT_SCSI_IO requests. It is also more driven in that the few target mode periph drivers there are are not really set up for handling pushback- heck most of them don't even check for errors (and what would they really do with them anyway? It's the initiator's problem, really....). The data transfer arithmetic has been worked over again to handle multiple outstanding commands, so you have a notion of what's been moved already as well as what's currently in flight. It turns that this led to uncovering a REPORT_LUNS bug in the ISP_INTERNAL_TARGET code which was sending back 24 bytes of rpl data instead of the specified 16. What happened furthermore here is that sending back 16 bytes and reporting an overrun of 8 bytes made the initiator (running FC-Tape aware f/w) mad enough to request, and keep requesting, another FCP response (I guess it didn't like the answer so kept asking for it again). Sponsored by: Spectralogic MFC after: 1 month
2012-08-08 18:24:33 +00:00
}
if (sense_length) {
Don't allocate full XCMD_SIZE (512 bytes) on stack. We need only 24 bytes (fcp_rsp_iu_t) there for isp_put_fcp_rsp_iu(). MFC after: 1 month
2020-11-18 02:12:51 +00:00
rp.fcp_rsp_snslen = sense_length;
More rototilling with target mode in an attemp to get multiple CCB at a time outstanding reliable. It's not there yet, but this is the direction to go in so might as well commit. So far, multiple at a time CCBs work (see ISP_INTERNAL_TARGET test mode), but it fails if there are more downstream than the SIM wants to handle and SRR is sort of confused when this happens, plus it is not entirely quite clear what one does if a CCB/CTIO fails and you have more in flight (that don't fail, say) and more queued up at the SIM level that haven't been started yet. Some of this is driven because there apparently is no flow control to requeue XPT_CONTINUE_IO requests like there are for XPT_SCSI_IO requests. It is also more driven in that the few target mode periph drivers there are are not really set up for handling pushback- heck most of them don't even check for errors (and what would they really do with them anyway? It's the initiator's problem, really....). The data transfer arithmetic has been worked over again to handle multiple outstanding commands, so you have a notion of what's been moved already as well as what's currently in flight. It turns that this led to uncovering a REPORT_LUNS bug in the ISP_INTERNAL_TARGET code which was sending back 24 bytes of rpl data instead of the specified 16. What happened furthermore here is that sending back 16 bytes and reporting an overrun of 8 bytes made the initiator (running FC-Tape aware f/w) mad enough to request, and keep requesting, another FCP response (I guess it didn't like the answer so kept asking for it again). Sponsored by: Spectralogic MFC after: 1 month
2012-08-08 18:24:33 +00:00
cto->ct_senselen = sense_length;
Don't allocate full XCMD_SIZE (512 bytes) on stack. We need only 24 bytes (fcp_rsp_iu_t) there for isp_put_fcp_rsp_iu(). MFC after: 1 month
2020-11-18 02:12:51 +00:00
rp.fcp_rsp_bits |= FCP_SNSLEN_VALID;
isp_put_fcp_rsp_iu(isp, &rp, atp->ests);
More rototilling with target mode in an attemp to get multiple CCB at a time outstanding reliable. It's not there yet, but this is the direction to go in so might as well commit. So far, multiple at a time CCBs work (see ISP_INTERNAL_TARGET test mode), but it fails if there are more downstream than the SIM wants to handle and SRR is sort of confused when this happens, plus it is not entirely quite clear what one does if a CCB/CTIO fails and you have more in flight (that don't fail, say) and more queued up at the SIM level that haven't been started yet. Some of this is driven because there apparently is no flow control to requeue XPT_CONTINUE_IO requests like there are for XPT_SCSI_IO requests. It is also more driven in that the few target mode periph drivers there are are not really set up for handling pushback- heck most of them don't even check for errors (and what would they really do with them anyway? It's the initiator's problem, really....). The data transfer arithmetic has been worked over again to handle multiple outstanding commands, so you have a notion of what's been moved already as well as what's currently in flight. It turns that this led to uncovering a REPORT_LUNS bug in the ISP_INTERNAL_TARGET code which was sending back 24 bytes of rpl data instead of the specified 16. What happened furthermore here is that sending back 16 bytes and reporting an overrun of 8 bytes made the initiator (running FC-Tape aware f/w) mad enough to request, and keep requesting, another FCP response (I guess it didn't like the answer so kept asking for it again). Sponsored by: Spectralogic MFC after: 1 month
2012-08-08 18:24:33 +00:00
memcpy(((fcp_rsp_iu_t *)atp->ests)->fcp_rsp_extra, &cso->sense_data, sense_length);
} else {
Don't allocate full XCMD_SIZE (512 bytes) on stack. We need only 24 bytes (fcp_rsp_iu_t) there for isp_put_fcp_rsp_iu(). MFC after: 1 month
2020-11-18 02:12:51 +00:00
isp_put_fcp_rsp_iu(isp, &rp, atp->ests);
More rototilling with target mode in an attemp to get multiple CCB at a time outstanding reliable. It's not there yet, but this is the direction to go in so might as well commit. So far, multiple at a time CCBs work (see ISP_INTERNAL_TARGET test mode), but it fails if there are more downstream than the SIM wants to handle and SRR is sort of confused when this happens, plus it is not entirely quite clear what one does if a CCB/CTIO fails and you have more in flight (that don't fail, say) and more queued up at the SIM level that haven't been started yet. Some of this is driven because there apparently is no flow control to requeue XPT_CONTINUE_IO requests like there are for XPT_SCSI_IO requests. It is also more driven in that the few target mode periph drivers there are are not really set up for handling pushback- heck most of them don't even check for errors (and what would they really do with them anyway? It's the initiator's problem, really....). The data transfer arithmetic has been worked over again to handle multiple outstanding commands, so you have a notion of what's been moved already as well as what's currently in flight. It turns that this led to uncovering a REPORT_LUNS bug in the ISP_INTERNAL_TARGET code which was sending back 24 bytes of rpl data instead of the specified 16. What happened furthermore here is that sending back 16 bytes and reporting an overrun of 8 bytes made the initiator (running FC-Tape aware f/w) mad enough to request, and keep requesting, another FCP response (I guess it didn't like the answer so kept asking for it again). Sponsored by: Spectralogic MFC after: 1 month
2012-08-08 18:24:33 +00:00
}
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) {
More rototilling with target mode in an attemp to get multiple CCB at a time outstanding reliable. It's not there yet, but this is the direction to go in so might as well commit. So far, multiple at a time CCBs work (see ISP_INTERNAL_TARGET test mode), but it fails if there are more downstream than the SIM wants to handle and SRR is sort of confused when this happens, plus it is not entirely quite clear what one does if a CCB/CTIO fails and you have more in flight (that don't fail, say) and more queued up at the SIM level that haven't been started yet. Some of this is driven because there apparently is no flow control to requeue XPT_CONTINUE_IO requests like there are for XPT_SCSI_IO requests. It is also more driven in that the few target mode periph drivers there are are not really set up for handling pushback- heck most of them don't even check for errors (and what would they really do with them anyway? It's the initiator's problem, really....). The data transfer arithmetic has been worked over again to handle multiple outstanding commands, so you have a notion of what's been moved already as well as what's currently in flight. It turns that this led to uncovering a REPORT_LUNS bug in the ISP_INTERNAL_TARGET code which was sending back 24 bytes of rpl data instead of the specified 16. What happened furthermore here is that sending back 16 bytes and reporting an overrun of 8 bytes made the initiator (running FC-Tape aware f/w) mad enough to request, and keep requesting, another FCP response (I guess it didn't like the answer so kept asking for it again). Sponsored by: Spectralogic MFC after: 1 month
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 {
More rototilling with target mode in an attemp to get multiple CCB at a time outstanding reliable. It's not there yet, but this is the direction to go in so might as well commit. So far, multiple at a time CCBs work (see ISP_INTERNAL_TARGET test mode), but it fails if there are more downstream than the SIM wants to handle and SRR is sort of confused when this happens, plus it is not entirely quite clear what one does if a CCB/CTIO fails and you have more in flight (that don't fail, say) and more queued up at the SIM level that haven't been started yet. Some of this is driven because there apparently is no flow control to requeue XPT_CONTINUE_IO requests like there are for XPT_SCSI_IO requests. It is also more driven in that the few target mode periph drivers there are are not really set up for handling pushback- heck most of them don't even check for errors (and what would they really do with them anyway? It's the initiator's problem, really....). The data transfer arithmetic has been worked over again to handle multiple outstanding commands, so you have a notion of what's been moved already as well as what's currently in flight. It turns that this led to uncovering a REPORT_LUNS bug in the ISP_INTERNAL_TARGET code which was sending back 24 bytes of rpl data instead of the specified 16. What happened furthermore here is that sending back 16 bytes and reporting an overrun of 8 bytes made the initiator (running FC-Tape aware f/w) mad enough to request, and keep requesting, another FCP response (I guess it didn't like the answer so kept asking for it again). Sponsored by: Spectralogic MFC after: 1 month
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
}
More rototilling with target mode in an attemp to get multiple CCB at a time outstanding reliable. It's not there yet, but this is the direction to go in so might as well commit. So far, multiple at a time CCBs work (see ISP_INTERNAL_TARGET test mode), but it fails if there are more downstream than the SIM wants to handle and SRR is sort of confused when this happens, plus it is not entirely quite clear what one does if a CCB/CTIO fails and you have more in flight (that don't fail, say) and more queued up at the SIM level that haven't been started yet. Some of this is driven because there apparently is no flow control to requeue XPT_CONTINUE_IO requests like there are for XPT_SCSI_IO requests. It is also more driven in that the few target mode periph drivers there are are not really set up for handling pushback- heck most of them don't even check for errors (and what would they really do with them anyway? It's the initiator's problem, really....). The data transfer arithmetic has been worked over again to handle multiple outstanding commands, so you have a notion of what's been moved already as well as what's currently in flight. It turns that this led to uncovering a REPORT_LUNS bug in the ISP_INTERNAL_TARGET code which was sending back 24 bytes of rpl data instead of the specified 16. What happened furthermore here is that sending back 16 bytes and reporting an overrun of 8 bytes made the initiator (running FC-Tape aware f/w) mad enough to request, and keep requesting, another FCP response (I guess it didn't like the answer so kept asking for it again). Sponsored by: Spectralogic MFC after: 1 month
2012-08-08 18:24:33 +00:00
atp->state = ATPD_STATE_LAST_CTIO;
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
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
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
/*
More rototilling with target mode in an attemp to get multiple CCB at a time outstanding reliable. It's not there yet, but this is the direction to go in so might as well commit. So far, multiple at a time CCBs work (see ISP_INTERNAL_TARGET test mode), but it fails if there are more downstream than the SIM wants to handle and SRR is sort of confused when this happens, plus it is not entirely quite clear what one does if a CCB/CTIO fails and you have more in flight (that don't fail, say) and more queued up at the SIM level that haven't been started yet. Some of this is driven because there apparently is no flow control to requeue XPT_CONTINUE_IO requests like there are for XPT_SCSI_IO requests. It is also more driven in that the few target mode periph drivers there are are not really set up for handling pushback- heck most of them don't even check for errors (and what would they really do with them anyway? It's the initiator's problem, really....). The data transfer arithmetic has been worked over again to handle multiple outstanding commands, so you have a notion of what's been moved already as well as what's currently in flight. It turns that this led to uncovering a REPORT_LUNS bug in the ISP_INTERNAL_TARGET code which was sending back 24 bytes of rpl data instead of the specified 16. What happened furthermore here is that sending back 16 bytes and reporting an overrun of 8 bytes made the initiator (running FC-Tape aware f/w) mad enough to request, and keep requesting, another FCP response (I guess it didn't like the answer so kept asking for it again). Sponsored by: Spectralogic MFC after: 1 month
2012-08-08 18:24:33 +00:00
* Mode 0 data transfers, *possibly* with status.
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
*/
More rototilling with target mode in an attemp to get multiple CCB at a time outstanding reliable. It's not there yet, but this is the direction to go in so might as well commit. So far, multiple at a time CCBs work (see ISP_INTERNAL_TARGET test mode), but it fails if there are more downstream than the SIM wants to handle and SRR is sort of confused when this happens, plus it is not entirely quite clear what one does if a CCB/CTIO fails and you have more in flight (that don't fail, say) and more queued up at the SIM level that haven't been started yet. Some of this is driven because there apparently is no flow control to requeue XPT_CONTINUE_IO requests like there are for XPT_SCSI_IO requests. It is also more driven in that the few target mode periph drivers there are are not really set up for handling pushback- heck most of them don't even check for errors (and what would they really do with them anyway? It's the initiator's problem, really....). The data transfer arithmetic has been worked over again to handle multiple outstanding commands, so you have a notion of what's been moved already as well as what's currently in flight. It turns that this led to uncovering a REPORT_LUNS bug in the ISP_INTERNAL_TARGET code which was sending back 24 bytes of rpl data instead of the specified 16. What happened furthermore here is that sending back 16 bytes and reporting an overrun of 8 bytes made the initiator (running FC-Tape aware f/w) mad enough to request, and keep requesting, another FCP response (I guess it didn't like the answer so kept asking for it again). Sponsored by: Spectralogic MFC after: 1 month
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
More rototilling with target mode in an attemp to get multiple CCB at a time outstanding reliable. It's not there yet, but this is the direction to go in so might as well commit. So far, multiple at a time CCBs work (see ISP_INTERNAL_TARGET test mode), but it fails if there are more downstream than the SIM wants to handle and SRR is sort of confused when this happens, plus it is not entirely quite clear what one does if a CCB/CTIO fails and you have more in flight (that don't fail, say) and more queued up at the SIM level that haven't been started yet. Some of this is driven because there apparently is no flow control to requeue XPT_CONTINUE_IO requests like there are for XPT_SCSI_IO requests. It is also more driven in that the few target mode periph drivers there are are not really set up for handling pushback- heck most of them don't even check for errors (and what would they really do with them anyway? It's the initiator's problem, really....). The data transfer arithmetic has been worked over again to handle multiple outstanding commands, so you have a notion of what's been moved already as well as what's currently in flight. It turns that this led to uncovering a REPORT_LUNS bug in the ISP_INTERNAL_TARGET code which was sending back 24 bytes of rpl data instead of the specified 16. What happened furthermore here is that sending back 16 bytes and reporting an overrun of 8 bytes made the initiator (running FC-Tape aware f/w) mad enough to request, and keep requesting, another FCP response (I guess it didn't like the answer so kept asking for it again). Sponsored by: Spectralogic MFC after: 1 month
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
More rototilling with target mode in an attemp to get multiple CCB at a time outstanding reliable. It's not there yet, but this is the direction to go in so might as well commit. So far, multiple at a time CCBs work (see ISP_INTERNAL_TARGET test mode), but it fails if there are more downstream than the SIM wants to handle and SRR is sort of confused when this happens, plus it is not entirely quite clear what one does if a CCB/CTIO fails and you have more in flight (that don't fail, say) and more queued up at the SIM level that haven't been started yet. Some of this is driven because there apparently is no flow control to requeue XPT_CONTINUE_IO requests like there are for XPT_SCSI_IO requests. It is also more driven in that the few target mode periph drivers there are are not really set up for handling pushback- heck most of them don't even check for errors (and what would they really do with them anyway? It's the initiator's problem, really....). The data transfer arithmetic has been worked over again to handle multiple outstanding commands, so you have a notion of what's been moved already as well as what's currently in flight. It turns that this led to uncovering a REPORT_LUNS bug in the ISP_INTERNAL_TARGET code which was sending back 24 bytes of rpl data instead of the specified 16. What happened furthermore here is that sending back 16 bytes and reporting an overrun of 8 bytes made the initiator (running FC-Tape aware f/w) mad enough to request, and keep requesting, another FCP response (I guess it didn't like the answer so kept asking for it again). Sponsored by: Spectralogic MFC after: 1 month
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;
}
More rototilling with target mode in an attemp to get multiple CCB at a time outstanding reliable. It's not there yet, but this is the direction to go in so might as well commit. So far, multiple at a time CCBs work (see ISP_INTERNAL_TARGET test mode), but it fails if there are more downstream than the SIM wants to handle and SRR is sort of confused when this happens, plus it is not entirely quite clear what one does if a CCB/CTIO fails and you have more in flight (that don't fail, say) and more queued up at the SIM level that haven't been started yet. Some of this is driven because there apparently is no flow control to requeue XPT_CONTINUE_IO requests like there are for XPT_SCSI_IO requests. It is also more driven in that the few target mode periph drivers there are are not really set up for handling pushback- heck most of them don't even check for errors (and what would they really do with them anyway? It's the initiator's problem, really....). The data transfer arithmetic has been worked over again to handle multiple outstanding commands, so you have a notion of what's been moved already as well as what's currently in flight. It turns that this led to uncovering a REPORT_LUNS bug in the ISP_INTERNAL_TARGET code which was sending back 24 bytes of rpl data instead of the specified 16. What happened furthermore here is that sending back 16 bytes and reporting an overrun of 8 bytes made the initiator (running FC-Tape aware f/w) mad enough to request, and keep requesting, another FCP response (I guess it didn't like the answer so kept asking for it again). Sponsored by: Spectralogic MFC after: 1 month
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
}
Rip off target mode support for parallel SCSI QLogic adapters. Hacks to enable target mode there complicated code, while didn't really work. And for outdated hardware fixing it is not really interesting. Initiator mode tested with Qlogic 1080 adapter is still working fine.
2015-11-23 10:06:19 +00:00
} else {
More rototilling with target mode in an attemp to get multiple CCB at a time outstanding reliable. It's not there yet, but this is the direction to go in so might as well commit. So far, multiple at a time CCBs work (see ISP_INTERNAL_TARGET test mode), but it fails if there are more downstream than the SIM wants to handle and SRR is sort of confused when this happens, plus it is not entirely quite clear what one does if a CCB/CTIO fails and you have more in flight (that don't fail, say) and more queued up at the SIM level that haven't been started yet. Some of this is driven because there apparently is no flow control to requeue XPT_CONTINUE_IO requests like there are for XPT_SCSI_IO requests. It is also more driven in that the few target mode periph drivers there are are not really set up for handling pushback- heck most of them don't even check for errors (and what would they really do with them anyway? It's the initiator's problem, really....). The data transfer arithmetic has been worked over again to handle multiple outstanding commands, so you have a notion of what's been moved already as well as what's currently in flight. It turns that this led to uncovering a REPORT_LUNS bug in the ISP_INTERNAL_TARGET code which was sending back 24 bytes of rpl data instead of the specified 16. What happened furthermore here is that sending back 16 bytes and reporting an overrun of 8 bytes made the initiator (running FC-Tape aware f/w) mad enough to request, and keep requesting, another FCP response (I guess it didn't like the answer so kept asking for it again). Sponsored by: Spectralogic MFC after: 1 month
2012-08-08 18:24:33 +00:00
ct2_entry_t *cto = (ct2_entry_t *) local;
a whale of a lot of target mode cleanup
2000-01-15 01:50:48 +00:00
Unify initiator and target DMA setup and command sending. The code is so alike that it is pointless to keep it separate. MFC after: 2 weeks
2017-03-24 14:44:03 +00:00
cto->ct_header.rqs_entry_type = RQSTYPE_CTIO2;
More rototilling with target mode in an attemp to get multiple CCB at a time outstanding reliable. It's not there yet, but this is the direction to go in so might as well commit. So far, multiple at a time CCBs work (see ISP_INTERNAL_TARGET test mode), but it fails if there are more downstream than the SIM wants to handle and SRR is sort of confused when this happens, plus it is not entirely quite clear what one does if a CCB/CTIO fails and you have more in flight (that don't fail, say) and more queued up at the SIM level that haven't been started yet. Some of this is driven because there apparently is no flow control to requeue XPT_CONTINUE_IO requests like there are for XPT_SCSI_IO requests. It is also more driven in that the few target mode periph drivers there are are not really set up for handling pushback- heck most of them don't even check for errors (and what would they really do with them anyway? It's the initiator's problem, really....). The data transfer arithmetic has been worked over again to handle multiple outstanding commands, so you have a notion of what's been moved already as well as what's currently in flight. It turns that this led to uncovering a REPORT_LUNS bug in the ISP_INTERNAL_TARGET code which was sending back 24 bytes of rpl data instead of the specified 16. What happened furthermore here is that sending back 16 bytes and reporting an overrun of 8 bytes made the initiator (running FC-Tape aware f/w) mad enough to request, and keep requesting, another FCP response (I guess it didn't like the answer so kept asking for it again). Sponsored by: Spectralogic MFC after: 1 month
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);
Switch initiator IDs in target mode to the same address space as target IDs in initiator mode -- index in port database instead of handlers. This makes initiator IDs persist across role changes and firmware resets, when handlers previously assigned by firmware are lost and reused. Sponsored by: iXsystems, Inc.
2015-07-13 21:01:24 +00:00
if (ISP_CAP_2KLOGIN(isp)) {
((ct2e_entry_t *)cto)->ct_iid = atp->nphdl;
More rototilling with target mode in an attemp to get multiple CCB at a time outstanding reliable. It's not there yet, but this is the direction to go in so might as well commit. So far, multiple at a time CCBs work (see ISP_INTERNAL_TARGET test mode), but it fails if there are more downstream than the SIM wants to handle and SRR is sort of confused when this happens, plus it is not entirely quite clear what one does if a CCB/CTIO fails and you have more in flight (that don't fail, say) and more queued up at the SIM level that haven't been started yet. Some of this is driven because there apparently is no flow control to requeue XPT_CONTINUE_IO requests like there are for XPT_SCSI_IO requests. It is also more driven in that the few target mode periph drivers there are are not really set up for handling pushback- heck most of them don't even check for errors (and what would they really do with them anyway? It's the initiator's problem, really....). The data transfer arithmetic has been worked over again to handle multiple outstanding commands, so you have a notion of what's been moved already as well as what's currently in flight. It turns that this led to uncovering a REPORT_LUNS bug in the ISP_INTERNAL_TARGET code which was sending back 24 bytes of rpl data instead of the specified 16. What happened furthermore here is that sending back 16 bytes and reporting an overrun of 8 bytes made the initiator (running FC-Tape aware f/w) mad enough to request, and keep requesting, another FCP response (I guess it didn't like the answer so kept asking for it again). Sponsored by: Spectralogic MFC after: 1 month
2012-08-08 18:24:33 +00:00
} else {
Switch initiator IDs in target mode to the same address space as target IDs in initiator mode -- index in port database instead of handlers. This makes initiator IDs persist across role changes and firmware resets, when handlers previously assigned by firmware are lost and reused. Sponsored by: iXsystems, Inc.
2015-07-13 21:01:24 +00:00
cto->ct_iid = atp->nphdl;
More rototilling with target mode in an attemp to get multiple CCB at a time outstanding reliable. It's not there yet, but this is the direction to go in so might as well commit. So far, multiple at a time CCBs work (see ISP_INTERNAL_TARGET test mode), but it fails if there are more downstream than the SIM wants to handle and SRR is sort of confused when this happens, plus it is not entirely quite clear what one does if a CCB/CTIO fails and you have more in flight (that don't fail, say) and more queued up at the SIM level that haven't been started yet. Some of this is driven because there apparently is no flow control to requeue XPT_CONTINUE_IO requests like there are for XPT_SCSI_IO requests. It is also more driven in that the few target mode periph drivers there are are not really set up for handling pushback- heck most of them don't even check for errors (and what would they really do with them anyway? It's the initiator's problem, really....). The data transfer arithmetic has been worked over again to handle multiple outstanding commands, so you have a notion of what's been moved already as well as what's currently in flight. It turns that this led to uncovering a REPORT_LUNS bug in the ISP_INTERNAL_TARGET code which was sending back 24 bytes of rpl data instead of the specified 16. What happened furthermore here is that sending back 16 bytes and reporting an overrun of 8 bytes made the initiator (running FC-Tape aware f/w) mad enough to request, and keep requesting, another FCP response (I guess it didn't like the answer so kept asking for it again). Sponsored by: Spectralogic MFC after: 1 month
2012-08-08 18:24:33 +00:00
if (ISP_CAP_SCCFW(isp) == 0) {
cto->ct_lun = ccb->ccb_h.target_lun;
}
Remove bzero/bcopy vestiges. Be cognizant as to whether we're running 2KLogin f/w in target mode and do the appropriate loopid load based upon that.
2006-05-22 06:49:49 +00:00
}
Improve command timeout handling. Let firmware do its best first, and if it can't, try software recovery. I would remove software timeout handler completely, but found bunch of complains on command timeout on sparc64 mailing list few years ago, so better be safe in case of interrupt loss. MFC after: 2 weeks
2017-03-21 13:10:37 +00:00
cto->ct_timeout = XS_TIME(ccb);
More rototilling with target mode in an attemp to get multiple CCB at a time outstanding reliable. It's not there yet, but this is the direction to go in so might as well commit. So far, multiple at a time CCBs work (see ISP_INTERNAL_TARGET test mode), but it fails if there are more downstream than the SIM wants to handle and SRR is sort of confused when this happens, plus it is not entirely quite clear what one does if a CCB/CTIO fails and you have more in flight (that don't fail, say) and more queued up at the SIM level that haven't been started yet. Some of this is driven because there apparently is no flow control to requeue XPT_CONTINUE_IO requests like there are for XPT_SCSI_IO requests. It is also more driven in that the few target mode periph drivers there are are not really set up for handling pushback- heck most of them don't even check for errors (and what would they really do with them anyway? It's the initiator's problem, really....). The data transfer arithmetic has been worked over again to handle multiple outstanding commands, so you have a notion of what's been moved already as well as what's currently in flight. It turns that this led to uncovering a REPORT_LUNS bug in the ISP_INTERNAL_TARGET code which was sending back 24 bytes of rpl data instead of the specified 16. What happened furthermore here is that sending back 16 bytes and reporting an overrun of 8 bytes made the initiator (running FC-Tape aware f/w) mad enough to request, and keep requesting, another FCP response (I guess it didn't like the answer so kept asking for it again). Sponsored by: Spectralogic MFC after: 1 month
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
More rototilling with target mode in an attemp to get multiple CCB at a time outstanding reliable. It's not there yet, but this is the direction to go in so might as well commit. So far, multiple at a time CCBs work (see ISP_INTERNAL_TARGET test mode), but it fails if there are more downstream than the SIM wants to handle and SRR is sort of confused when this happens, plus it is not entirely quite clear what one does if a CCB/CTIO fails and you have more in flight (that don't fail, say) and more queued up at the SIM level that haven't been started yet. Some of this is driven because there apparently is no flow control to requeue XPT_CONTINUE_IO requests like there are for XPT_SCSI_IO requests. It is also more driven in that the few target mode periph drivers there are are not really set up for handling pushback- heck most of them don't even check for errors (and what would they really do with them anyway? It's the initiator's problem, really....). The data transfer arithmetic has been worked over again to handle multiple outstanding commands, so you have a notion of what's been moved already as well as what's currently in flight. It turns that this led to uncovering a REPORT_LUNS bug in the ISP_INTERNAL_TARGET code which was sending back 24 bytes of rpl data instead of the specified 16. What happened furthermore here is that sending back 16 bytes and reporting an overrun of 8 bytes made the initiator (running FC-Tape aware f/w) mad enough to request, and keep requesting, another FCP response (I guess it didn't like the answer so kept asking for it again). Sponsored by: Spectralogic MFC after: 1 month
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.
*
Correct double "the the" Approved by: cperciva MFC after: 3 days
2012-09-14 21:28:56 +00:00
* Mode 2, status, no data. We have to use this in the case the response
More rototilling with target mode in an attemp to get multiple CCB at a time outstanding reliable. It's not there yet, but this is the direction to go in so might as well commit. So far, multiple at a time CCBs work (see ISP_INTERNAL_TARGET test mode), but it fails if there are more downstream than the SIM wants to handle and SRR is sort of confused when this happens, plus it is not entirely quite clear what one does if a CCB/CTIO fails and you have more in flight (that don't fail, say) and more queued up at the SIM level that haven't been started yet. Some of this is driven because there apparently is no flow control to requeue XPT_CONTINUE_IO requests like there are for XPT_SCSI_IO requests. It is also more driven in that the few target mode periph drivers there are are not really set up for handling pushback- heck most of them don't even check for errors (and what would they really do with them anyway? It's the initiator's problem, really....). The data transfer arithmetic has been worked over again to handle multiple outstanding commands, so you have a notion of what's been moved already as well as what's currently in flight. It turns that this led to uncovering a REPORT_LUNS bug in the ISP_INTERNAL_TARGET code which was sending back 24 bytes of rpl data instead of the specified 16. What happened furthermore here is that sending back 16 bytes and reporting an overrun of 8 bytes made the initiator (running FC-Tape aware f/w) mad enough to request, and keep requesting, another FCP response (I guess it didn't like the answer so kept asking for it again). Sponsored by: Spectralogic MFC after: 1 month
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;
Don't allocate full XCMD_SIZE (512 bytes) on stack. We need only 24 bytes (fcp_rsp_iu_t) there for isp_put_fcp_rsp_iu(). MFC after: 1 month
2020-11-18 02:12:51 +00:00
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) {
More rototilling with target mode in an attemp to get multiple CCB at a time outstanding reliable. It's not there yet, but this is the direction to go in so might as well commit. So far, multiple at a time CCBs work (see ISP_INTERNAL_TARGET test mode), but it fails if there are more downstream than the SIM wants to handle and SRR is sort of confused when this happens, plus it is not entirely quite clear what one does if a CCB/CTIO fails and you have more in flight (that don't fail, say) and more queued up at the SIM level that haven't been started yet. Some of this is driven because there apparently is no flow control to requeue XPT_CONTINUE_IO requests like there are for XPT_SCSI_IO requests. It is also more driven in that the few target mode periph drivers there are are not really set up for handling pushback- heck most of them don't even check for errors (and what would they really do with them anyway? It's the initiator's problem, really....). The data transfer arithmetic has been worked over again to handle multiple outstanding commands, so you have a notion of what's been moved already as well as what's currently in flight. It turns that this led to uncovering a REPORT_LUNS bug in the ISP_INTERNAL_TARGET code which was sending back 24 bytes of rpl data instead of the specified 16. What happened furthermore here is that sending back 16 bytes and reporting an overrun of 8 bytes made the initiator (running FC-Tape aware f/w) mad enough to request, and keep requesting, another FCP response (I guess it didn't like the answer so kept asking for it again). Sponsored by: Spectralogic MFC after: 1 month
2012-08-08 18:24:33 +00:00
atp->ests = isp_get_ecmd(isp);
if (atp->ests == NULL) {
Switch from using periph_links to sim_links. periph_links field belongs to periph drivers and must not be used here. MFC after: 2 weeks
2017-03-22 11:06:33 +00:00
TAILQ_INSERT_HEAD(waitq, &ccb->ccb_h, sim_links.tqe);
More rototilling with target mode in an attemp to get multiple CCB at a time outstanding reliable. It's not there yet, but this is the direction to go in so might as well commit. So far, multiple at a time CCBs work (see ISP_INTERNAL_TARGET test mode), but it fails if there are more downstream than the SIM wants to handle and SRR is sort of confused when this happens, plus it is not entirely quite clear what one does if a CCB/CTIO fails and you have more in flight (that don't fail, say) and more queued up at the SIM level that haven't been started yet. Some of this is driven because there apparently is no flow control to requeue XPT_CONTINUE_IO requests like there are for XPT_SCSI_IO requests. It is also more driven in that the few target mode periph drivers there are are not really set up for handling pushback- heck most of them don't even check for errors (and what would they really do with them anyway? It's the initiator's problem, really....). The data transfer arithmetic has been worked over again to handle multiple outstanding commands, so you have a notion of what's been moved already as well as what's currently in flight. It turns that this led to uncovering a REPORT_LUNS bug in the ISP_INTERNAL_TARGET code which was sending back 24 bytes of rpl data instead of the specified 16. What happened furthermore here is that sending back 16 bytes and reporting an overrun of 8 bytes made the initiator (running FC-Tape aware f/w) mad enough to request, and keep requesting, another FCP response (I guess it didn't like the answer so kept asking for it again). Sponsored by: Spectralogic MFC after: 1 month
2012-08-08 18:24:33 +00:00
break;
}
}
Don't allocate full XCMD_SIZE (512 bytes) on stack. We need only 24 bytes (fcp_rsp_iu_t) there for isp_put_fcp_rsp_iu(). MFC after: 1 month
2020-11-18 02:12:51 +00:00
memset(&rp, 0, sizeof(rp));
More rototilling with target mode in an attemp to get multiple CCB at a time outstanding reliable. It's not there yet, but this is the direction to go in so might as well commit. So far, multiple at a time CCBs work (see ISP_INTERNAL_TARGET test mode), but it fails if there are more downstream than the SIM wants to handle and SRR is sort of confused when this happens, plus it is not entirely quite clear what one does if a CCB/CTIO fails and you have more in flight (that don't fail, say) and more queued up at the SIM level that haven't been started yet. Some of this is driven because there apparently is no flow control to requeue XPT_CONTINUE_IO requests like there are for XPT_SCSI_IO requests. It is also more driven in that the few target mode periph drivers there are are not really set up for handling pushback- heck most of them don't even check for errors (and what would they really do with them anyway? It's the initiator's problem, really....). The data transfer arithmetic has been worked over again to handle multiple outstanding commands, so you have a notion of what's been moved already as well as what's currently in flight. It turns that this led to uncovering a REPORT_LUNS bug in the ISP_INTERNAL_TARGET code which was sending back 24 bytes of rpl data instead of the specified 16. What happened furthermore here is that sending back 16 bytes and reporting an overrun of 8 bytes made the initiator (running FC-Tape aware f/w) mad enough to request, and keep requesting, another FCP response (I guess it didn't like the answer so kept asking for it again). Sponsored by: Spectralogic MFC after: 1 month
2012-08-08 18:24:33 +00:00
if (fctape) {
cto->ct_flags |= CT2_CONFIRM;
Don't allocate full XCMD_SIZE (512 bytes) on stack. We need only 24 bytes (fcp_rsp_iu_t) there for isp_put_fcp_rsp_iu(). MFC after: 1 month
2020-11-18 02:12:51 +00:00
rp.fcp_rsp_bits |= FCP_CONF_REQ;
More rototilling with target mode in an attemp to get multiple CCB at a time outstanding reliable. It's not there yet, but this is the direction to go in so might as well commit. So far, multiple at a time CCBs work (see ISP_INTERNAL_TARGET test mode), but it fails if there are more downstream than the SIM wants to handle and SRR is sort of confused when this happens, plus it is not entirely quite clear what one does if a CCB/CTIO fails and you have more in flight (that don't fail, say) and more queued up at the SIM level that haven't been started yet. Some of this is driven because there apparently is no flow control to requeue XPT_CONTINUE_IO requests like there are for XPT_SCSI_IO requests. It is also more driven in that the few target mode periph drivers there are are not really set up for handling pushback- heck most of them don't even check for errors (and what would they really do with them anyway? It's the initiator's problem, really....). The data transfer arithmetic has been worked over again to handle multiple outstanding commands, so you have a notion of what's been moved already as well as what's currently in flight. It turns that this led to uncovering a REPORT_LUNS bug in the ISP_INTERNAL_TARGET code which was sending back 24 bytes of rpl data instead of the specified 16. What happened furthermore here is that sending back 16 bytes and reporting an overrun of 8 bytes made the initiator (running FC-Tape aware f/w) mad enough to request, and keep requesting, another FCP response (I guess it didn't like the answer so kept asking for it again). Sponsored by: Spectralogic MFC after: 1 month
2012-08-08 18:24:33 +00:00
}
cto->ct_flags |= CT2_FLAG_MODE2;
Don't allocate full XCMD_SIZE (512 bytes) on stack. We need only 24 bytes (fcp_rsp_iu_t) there for isp_put_fcp_rsp_iu(). MFC after: 1 month
2020-11-18 02:12:51 +00:00
rp.fcp_rsp_scsi_status = cso->scsi_status;
More rototilling with target mode in an attemp to get multiple CCB at a time outstanding reliable. It's not there yet, but this is the direction to go in so might as well commit. So far, multiple at a time CCBs work (see ISP_INTERNAL_TARGET test mode), but it fails if there are more downstream than the SIM wants to handle and SRR is sort of confused when this happens, plus it is not entirely quite clear what one does if a CCB/CTIO fails and you have more in flight (that don't fail, say) and more queued up at the SIM level that haven't been started yet. Some of this is driven because there apparently is no flow control to requeue XPT_CONTINUE_IO requests like there are for XPT_SCSI_IO requests. It is also more driven in that the few target mode periph drivers there are are not really set up for handling pushback- heck most of them don't even check for errors (and what would they really do with them anyway? It's the initiator's problem, really....). The data transfer arithmetic has been worked over again to handle multiple outstanding commands, so you have a notion of what's been moved already as well as what's currently in flight. It turns that this led to uncovering a REPORT_LUNS bug in the ISP_INTERNAL_TARGET code which was sending back 24 bytes of rpl data instead of the specified 16. What happened furthermore here is that sending back 16 bytes and reporting an overrun of 8 bytes made the initiator (running FC-Tape aware f/w) mad enough to request, and keep requesting, another FCP response (I guess it didn't like the answer so kept asking for it again). Sponsored by: Spectralogic MFC after: 1 month
2012-08-08 18:24:33 +00:00
if (resid < 0) {
Don't allocate full XCMD_SIZE (512 bytes) on stack. We need only 24 bytes (fcp_rsp_iu_t) there for isp_put_fcp_rsp_iu(). MFC after: 1 month
2020-11-18 02:12:51 +00:00
rp.fcp_rsp_resid = -resid;
rp.fcp_rsp_bits |= FCP_RESID_OVERFLOW;
More rototilling with target mode in an attemp to get multiple CCB at a time outstanding reliable. It's not there yet, but this is the direction to go in so might as well commit. So far, multiple at a time CCBs work (see ISP_INTERNAL_TARGET test mode), but it fails if there are more downstream than the SIM wants to handle and SRR is sort of confused when this happens, plus it is not entirely quite clear what one does if a CCB/CTIO fails and you have more in flight (that don't fail, say) and more queued up at the SIM level that haven't been started yet. Some of this is driven because there apparently is no flow control to requeue XPT_CONTINUE_IO requests like there are for XPT_SCSI_IO requests. It is also more driven in that the few target mode periph drivers there are are not really set up for handling pushback- heck most of them don't even check for errors (and what would they really do with them anyway? It's the initiator's problem, really....). The data transfer arithmetic has been worked over again to handle multiple outstanding commands, so you have a notion of what's been moved already as well as what's currently in flight. It turns that this led to uncovering a REPORT_LUNS bug in the ISP_INTERNAL_TARGET code which was sending back 24 bytes of rpl data instead of the specified 16. What happened furthermore here is that sending back 16 bytes and reporting an overrun of 8 bytes made the initiator (running FC-Tape aware f/w) mad enough to request, and keep requesting, another FCP response (I guess it didn't like the answer so kept asking for it again). Sponsored by: Spectralogic MFC after: 1 month
2012-08-08 18:24:33 +00:00
} else if (resid > 0) {
Don't allocate full XCMD_SIZE (512 bytes) on stack. We need only 24 bytes (fcp_rsp_iu_t) there for isp_put_fcp_rsp_iu(). MFC after: 1 month
2020-11-18 02:12:51 +00:00
rp.fcp_rsp_resid = resid;
rp.fcp_rsp_bits |= FCP_RESID_UNDERFLOW;
More rototilling with target mode in an attemp to get multiple CCB at a time outstanding reliable. It's not there yet, but this is the direction to go in so might as well commit. So far, multiple at a time CCBs work (see ISP_INTERNAL_TARGET test mode), but it fails if there are more downstream than the SIM wants to handle and SRR is sort of confused when this happens, plus it is not entirely quite clear what one does if a CCB/CTIO fails and you have more in flight (that don't fail, say) and more queued up at the SIM level that haven't been started yet. Some of this is driven because there apparently is no flow control to requeue XPT_CONTINUE_IO requests like there are for XPT_SCSI_IO requests. It is also more driven in that the few target mode periph drivers there are are not really set up for handling pushback- heck most of them don't even check for errors (and what would they really do with them anyway? It's the initiator's problem, really....). The data transfer arithmetic has been worked over again to handle multiple outstanding commands, so you have a notion of what's been moved already as well as what's currently in flight. It turns that this led to uncovering a REPORT_LUNS bug in the ISP_INTERNAL_TARGET code which was sending back 24 bytes of rpl data instead of the specified 16. What happened furthermore here is that sending back 16 bytes and reporting an overrun of 8 bytes made the initiator (running FC-Tape aware f/w) mad enough to request, and keep requesting, another FCP response (I guess it didn't like the answer so kept asking for it again). Sponsored by: Spectralogic MFC after: 1 month
2012-08-08 18:24:33 +00:00
}
if (sense_length) {
Don't allocate full XCMD_SIZE (512 bytes) on stack. We need only 24 bytes (fcp_rsp_iu_t) there for isp_put_fcp_rsp_iu(). MFC after: 1 month
2020-11-18 02:12:51 +00:00
rp.fcp_rsp_snslen = sense_length;
rp.fcp_rsp_bits |= FCP_SNSLEN_VALID;
isp_put_fcp_rsp_iu(isp, &rp, atp->ests);
More rototilling with target mode in an attemp to get multiple CCB at a time outstanding reliable. It's not there yet, but this is the direction to go in so might as well commit. So far, multiple at a time CCBs work (see ISP_INTERNAL_TARGET test mode), but it fails if there are more downstream than the SIM wants to handle and SRR is sort of confused when this happens, plus it is not entirely quite clear what one does if a CCB/CTIO fails and you have more in flight (that don't fail, say) and more queued up at the SIM level that haven't been started yet. Some of this is driven because there apparently is no flow control to requeue XPT_CONTINUE_IO requests like there are for XPT_SCSI_IO requests. It is also more driven in that the few target mode periph drivers there are are not really set up for handling pushback- heck most of them don't even check for errors (and what would they really do with them anyway? It's the initiator's problem, really....). The data transfer arithmetic has been worked over again to handle multiple outstanding commands, so you have a notion of what's been moved already as well as what's currently in flight. It turns that this led to uncovering a REPORT_LUNS bug in the ISP_INTERNAL_TARGET code which was sending back 24 bytes of rpl data instead of the specified 16. What happened furthermore here is that sending back 16 bytes and reporting an overrun of 8 bytes made the initiator (running FC-Tape aware f/w) mad enough to request, and keep requesting, another FCP response (I guess it didn't like the answer so kept asking for it again). Sponsored by: Spectralogic MFC after: 1 month
2012-08-08 18:24:33 +00:00
memcpy(((fcp_rsp_iu_t *)atp->ests)->fcp_rsp_extra, &cso->sense_data, sense_length);
} else {
Don't allocate full XCMD_SIZE (512 bytes) on stack. We need only 24 bytes (fcp_rsp_iu_t) there for isp_put_fcp_rsp_iu(). MFC after: 1 month
2020-11-18 02:12:51 +00:00
isp_put_fcp_rsp_iu(isp, &rp, atp->ests);
More rototilling with target mode in an attemp to get multiple CCB at a time outstanding reliable. It's not there yet, but this is the direction to go in so might as well commit. So far, multiple at a time CCBs work (see ISP_INTERNAL_TARGET test mode), but it fails if there are more downstream than the SIM wants to handle and SRR is sort of confused when this happens, plus it is not entirely quite clear what one does if a CCB/CTIO fails and you have more in flight (that don't fail, say) and more queued up at the SIM level that haven't been started yet. Some of this is driven because there apparently is no flow control to requeue XPT_CONTINUE_IO requests like there are for XPT_SCSI_IO requests. It is also more driven in that the few target mode periph drivers there are are not really set up for handling pushback- heck most of them don't even check for errors (and what would they really do with them anyway? It's the initiator's problem, really....). The data transfer arithmetic has been worked over again to handle multiple outstanding commands, so you have a notion of what's been moved already as well as what's currently in flight. It turns that this led to uncovering a REPORT_LUNS bug in the ISP_INTERNAL_TARGET code which was sending back 24 bytes of rpl data instead of the specified 16. What happened furthermore here is that sending back 16 bytes and reporting an overrun of 8 bytes made the initiator (running FC-Tape aware f/w) mad enough to request, and keep requesting, another FCP response (I guess it didn't like the answer so kept asking for it again). Sponsored by: Spectralogic MFC after: 1 month
2012-08-08 18:24:33 +00:00
}
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;
Unify initiator and target DMA setup and command sending. The code is so alike that it is pointless to keep it separate. MFC after: 2 weeks
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) {
More rototilling with target mode in an attemp to get multiple CCB at a time outstanding reliable. It's not there yet, but this is the direction to go in so might as well commit. So far, multiple at a time CCBs work (see ISP_INTERNAL_TARGET test mode), but it fails if there are more downstream than the SIM wants to handle and SRR is sort of confused when this happens, plus it is not entirely quite clear what one does if a CCB/CTIO fails and you have more in flight (that don't fail, say) and more queued up at the SIM level that haven't been started yet. Some of this is driven because there apparently is no flow control to requeue XPT_CONTINUE_IO requests like there are for XPT_SCSI_IO requests. It is also more driven in that the few target mode periph drivers there are are not really set up for handling pushback- heck most of them don't even check for errors (and what would they really do with them anyway? It's the initiator's problem, really....). The data transfer arithmetic has been worked over again to handle multiple outstanding commands, so you have a notion of what's been moved already as well as what's currently in flight. It turns that this led to uncovering a REPORT_LUNS bug in the ISP_INTERNAL_TARGET code which was sending back 24 bytes of rpl data instead of the specified 16. What happened furthermore here is that sending back 16 bytes and reporting an overrun of 8 bytes made the initiator (running FC-Tape aware f/w) mad enough to request, and keep requesting, another FCP response (I guess it didn't like the answer so kept asking for it again). Sponsored by: Spectralogic MFC after: 1 month
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 {
More rototilling with target mode in an attemp to get multiple CCB at a time outstanding reliable. It's not there yet, but this is the direction to go in so might as well commit. So far, multiple at a time CCBs work (see ISP_INTERNAL_TARGET test mode), but it fails if there are more downstream than the SIM wants to handle and SRR is sort of confused when this happens, plus it is not entirely quite clear what one does if a CCB/CTIO fails and you have more in flight (that don't fail, say) and more queued up at the SIM level that haven't been started yet. Some of this is driven because there apparently is no flow control to requeue XPT_CONTINUE_IO requests like there are for XPT_SCSI_IO requests. It is also more driven in that the few target mode periph drivers there are are not really set up for handling pushback- heck most of them don't even check for errors (and what would they really do with them anyway? It's the initiator's problem, really....). The data transfer arithmetic has been worked over again to handle multiple outstanding commands, so you have a notion of what's been moved already as well as what's currently in flight. It turns that this led to uncovering a REPORT_LUNS bug in the ISP_INTERNAL_TARGET code which was sending back 24 bytes of rpl data instead of the specified 16. What happened furthermore here is that sending back 16 bytes and reporting an overrun of 8 bytes made the initiator (running FC-Tape aware f/w) mad enough to request, and keep requesting, another FCP response (I guess it didn't like the answer so kept asking for it again). Sponsored by: Spectralogic MFC after: 1 month
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
}
More rototilling with target mode in an attemp to get multiple CCB at a time outstanding reliable. It's not there yet, but this is the direction to go in so might as well commit. So far, multiple at a time CCBs work (see ISP_INTERNAL_TARGET test mode), but it fails if there are more downstream than the SIM wants to handle and SRR is sort of confused when this happens, plus it is not entirely quite clear what one does if a CCB/CTIO fails and you have more in flight (that don't fail, say) and more queued up at the SIM level that haven't been started yet. Some of this is driven because there apparently is no flow control to requeue XPT_CONTINUE_IO requests like there are for XPT_SCSI_IO requests. It is also more driven in that the few target mode periph drivers there are are not really set up for handling pushback- heck most of them don't even check for errors (and what would they really do with them anyway? It's the initiator's problem, really....). The data transfer arithmetic has been worked over again to handle multiple outstanding commands, so you have a notion of what's been moved already as well as what's currently in flight. It turns that this led to uncovering a REPORT_LUNS bug in the ISP_INTERNAL_TARGET code which was sending back 24 bytes of rpl data instead of the specified 16. What happened furthermore here is that sending back 16 bytes and reporting an overrun of 8 bytes made the initiator (running FC-Tape aware f/w) mad enough to request, and keep requesting, another FCP response (I guess it didn't like the answer so kept asking for it again). Sponsored by: Spectralogic MFC after: 1 month
2012-08-08 18:24:33 +00:00
atp->state = ATPD_STATE_LAST_CTIO;
Add a isp_target_putback_atio- we aren't using CCINCR at this time, so we need a function that tells the Qlogic f/w that a target mode command is done, so increase the resource count for that lun. Add in a timeout function to kick the putback again if we fail to do it the first time (we may not have the request queue space for ATIO push). Split the function isp_handle_platform_ctio into two parts so that the timeout function for the ATIO push or isp_handle_platform_ctio can inform CAM that the requested CTIO(s) are now done. Clean up (cough) residual handling. What we need for Fibre Channel is to preserve the at_datalen field from the original incoming ATIO so we can calculate a 'true' residual. Unfortunately, we're not guaranteed to get that back from CAM. We'll *try* to find it hiding in the periph_priv field (layering violation)- but if an ATIO was passed in from user land- forget it. This means that we'll probably get residuals wrong for Fibre Channel commands we're completing with an error. It's too late to 4.1 release to fix this- too bad. Luckily the only device we'd really care about this occurring on is a tape device and they're still so rare as FC attached devices that this can be considered an untested combination anyway. Remove all CCINCR usage (resource autoreplenish). When we've proved to ourself that things are working properly, we can add it back in. Make sure we propage 'suggested' sense data from the incoming ATIO into the created system ATIO- and set sense_len appropriately. Correctly propagate tag values. Fall back to the model of generating (well, the functions in isp_pci.c do the work) multiple CTIOs based upon what we get from XPT. Instead of being able to pair Qlogic generated ATIOs with CAM ATIOs, and then to pair CAM CTIOs with Qlogic CTIOs, we have to take the CTIO passed to us from XPT, and if it implies that we have to generate extra Qlogic CTIOs, so be it. This means that we have to wait until the last CTIO in a sequence we generated completes before calling xpt_done. Executive summary- target mode actually now pretty much works well enough to tell folks about.
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
More rototilling with target mode in an attemp to get multiple CCB at a time outstanding reliable. It's not there yet, but this is the direction to go in so might as well commit. So far, multiple at a time CCBs work (see ISP_INTERNAL_TARGET test mode), but it fails if there are more downstream than the SIM wants to handle and SRR is sort of confused when this happens, plus it is not entirely quite clear what one does if a CCB/CTIO fails and you have more in flight (that don't fail, say) and more queued up at the SIM level that haven't been started yet. Some of this is driven because there apparently is no flow control to requeue XPT_CONTINUE_IO requests like there are for XPT_SCSI_IO requests. It is also more driven in that the few target mode periph drivers there are are not really set up for handling pushback- heck most of them don't even check for errors (and what would they really do with them anyway? It's the initiator's problem, really....). The data transfer arithmetic has been worked over again to handle multiple outstanding commands, so you have a notion of what's been moved already as well as what's currently in flight. It turns that this led to uncovering a REPORT_LUNS bug in the ISP_INTERNAL_TARGET code which was sending back 24 bytes of rpl data instead of the specified 16. What happened furthermore here is that sending back 16 bytes and reporting an overrun of 8 bytes made the initiator (running FC-Tape aware f/w) mad enough to request, and keep requesting, another FCP response (I guess it didn't like the answer so kept asking for it again). Sponsored by: Spectralogic MFC after: 1 month
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
More rototilling with target mode in an attemp to get multiple CCB at a time outstanding reliable. It's not there yet, but this is the direction to go in so might as well commit. So far, multiple at a time CCBs work (see ISP_INTERNAL_TARGET test mode), but it fails if there are more downstream than the SIM wants to handle and SRR is sort of confused when this happens, plus it is not entirely quite clear what one does if a CCB/CTIO fails and you have more in flight (that don't fail, say) and more queued up at the SIM level that haven't been started yet. Some of this is driven because there apparently is no flow control to requeue XPT_CONTINUE_IO requests like there are for XPT_SCSI_IO requests. It is also more driven in that the few target mode periph drivers there are are not really set up for handling pushback- heck most of them don't even check for errors (and what would they really do with them anyway? It's the initiator's problem, really....). The data transfer arithmetic has been worked over again to handle multiple outstanding commands, so you have a notion of what's been moved already as well as what's currently in flight. It turns that this led to uncovering a REPORT_LUNS bug in the ISP_INTERNAL_TARGET code which was sending back 24 bytes of rpl data instead of the specified 16. What happened furthermore here is that sending back 16 bytes and reporting an overrun of 8 bytes made the initiator (running FC-Tape aware f/w) mad enough to request, and keep requesting, another FCP response (I guess it didn't like the answer so kept asking for it again). Sponsored by: Spectralogic MFC after: 1 month
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
More rototilling with target mode in an attemp to get multiple CCB at a time outstanding reliable. It's not there yet, but this is the direction to go in so might as well commit. So far, multiple at a time CCBs work (see ISP_INTERNAL_TARGET test mode), but it fails if there are more downstream than the SIM wants to handle and SRR is sort of confused when this happens, plus it is not entirely quite clear what one does if a CCB/CTIO fails and you have more in flight (that don't fail, say) and more queued up at the SIM level that haven't been started yet. Some of this is driven because there apparently is no flow control to requeue XPT_CONTINUE_IO requests like there are for XPT_SCSI_IO requests. It is also more driven in that the few target mode periph drivers there are are not really set up for handling pushback- heck most of them don't even check for errors (and what would they really do with them anyway? It's the initiator's problem, really....). The data transfer arithmetic has been worked over again to handle multiple outstanding commands, so you have a notion of what's been moved already as well as what's currently in flight. It turns that this led to uncovering a REPORT_LUNS bug in the ISP_INTERNAL_TARGET code which was sending back 24 bytes of rpl data instead of the specified 16. What happened furthermore here is that sending back 16 bytes and reporting an overrun of 8 bytes made the initiator (running FC-Tape aware f/w) mad enough to request, and keep requesting, another FCP response (I guess it didn't like the answer so kept asking for it again). Sponsored by: Spectralogic MFC after: 1 month
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;
Add support for ISP_FC_GETHINFO, which returns current connection topology, speed, loopid, WWPN/WWNN, etc. Beef up target mode. Add isp_handle_platform_notify_scsi and isp_handle_platform_notify_fc platform handlers to handle immediate notifies (isp_handle_platform_notify_scsi is still stubbed out). In implementation of isp_handle_platform_notify_fc, for IN_ABORT_TASK, peel off a pending XPT_IMMED_NOTIFY and call xpt_done on it and hope that somebody upstream is listening. Make sure on final CTIO2s that we set residual correctly. These are absolutely crucial. Make sure we set relative offset for each CTIO2 based upon bytes we've already xferred. This is what the private adjunct datat to the original ATIO is. Note state of command so we can figure out where to find it if we get an ABORT from the firmware. Make sure we *always* set CAM_TAG_ACTION_VALID for ATIO2s. Make sure we keep track of the original lun. If se sent status (or we're otherwise done with the command), don't forget to free the adjunct structure.
2002-06-16 05:08:02 +00:00
}
More rototilling with target mode in an attemp to get multiple CCB at a time outstanding reliable. It's not there yet, but this is the direction to go in so might as well commit. So far, multiple at a time CCBs work (see ISP_INTERNAL_TARGET test mode), but it fails if there are more downstream than the SIM wants to handle and SRR is sort of confused when this happens, plus it is not entirely quite clear what one does if a CCB/CTIO fails and you have more in flight (that don't fail, say) and more queued up at the SIM level that haven't been started yet. Some of this is driven because there apparently is no flow control to requeue XPT_CONTINUE_IO requests like there are for XPT_SCSI_IO requests. It is also more driven in that the few target mode periph drivers there are are not really set up for handling pushback- heck most of them don't even check for errors (and what would they really do with them anyway? It's the initiator's problem, really....). The data transfer arithmetic has been worked over again to handle multiple outstanding commands, so you have a notion of what's been moved already as well as what's currently in flight. It turns that this led to uncovering a REPORT_LUNS bug in the ISP_INTERNAL_TARGET code which was sending back 24 bytes of rpl data instead of the specified 16. What happened furthermore here is that sending back 16 bytes and reporting an overrun of 8 bytes made the initiator (running FC-Tape aware f/w) mad enough to request, and keep requesting, another FCP response (I guess it didn't like the answer so kept asking for it again). Sponsored by: Spectralogic MFC after: 1 month
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);
Some more gratuitous format and name changes. Pull in some target mode changes from a private branch. Pull in some more RELENG_4 compilation changes. A lot of lines changed, but not much content change yet.
2006-04-21 18:30:01 +00:00
}
a whale of a lot of target mode cleanup
2000-01-15 01:50:48 +00:00
More rototilling with target mode in an attemp to get multiple CCB at a time outstanding reliable. It's not there yet, but this is the direction to go in so might as well commit. So far, multiple at a time CCBs work (see ISP_INTERNAL_TARGET test mode), but it fails if there are more downstream than the SIM wants to handle and SRR is sort of confused when this happens, plus it is not entirely quite clear what one does if a CCB/CTIO fails and you have more in flight (that don't fail, say) and more queued up at the SIM level that haven't been started yet. Some of this is driven because there apparently is no flow control to requeue XPT_CONTINUE_IO requests like there are for XPT_SCSI_IO requests. It is also more driven in that the few target mode periph drivers there are are not really set up for handling pushback- heck most of them don't even check for errors (and what would they really do with them anyway? It's the initiator's problem, really....). The data transfer arithmetic has been worked over again to handle multiple outstanding commands, so you have a notion of what's been moved already as well as what's currently in flight. It turns that this led to uncovering a REPORT_LUNS bug in the ISP_INTERNAL_TARGET code which was sending back 24 bytes of rpl data instead of the specified 16. What happened furthermore here is that sending back 16 bytes and reporting an overrun of 8 bytes made the initiator (running FC-Tape aware f/w) mad enough to request, and keep requesting, another FCP response (I guess it didn't like the answer so kept asking for it again). Sponsored by: Spectralogic MFC after: 1 month
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");
Switch from using periph_links to sim_links. periph_links field belongs to periph drivers and must not be used here. MFC after: 2 weeks
2017-03-22 11:06:33 +00:00
TAILQ_INSERT_HEAD(waitq, &ccb->ccb_h, sim_links.tqe);
More rototilling with target mode in an attemp to get multiple CCB at a time outstanding reliable. It's not there yet, but this is the direction to go in so might as well commit. So far, multiple at a time CCBs work (see ISP_INTERNAL_TARGET test mode), but it fails if there are more downstream than the SIM wants to handle and SRR is sort of confused when this happens, plus it is not entirely quite clear what one does if a CCB/CTIO fails and you have more in flight (that don't fail, say) and more queued up at the SIM level that haven't been started yet. Some of this is driven because there apparently is no flow control to requeue XPT_CONTINUE_IO requests like there are for XPT_SCSI_IO requests. It is also more driven in that the few target mode periph drivers there are are not really set up for handling pushback- heck most of them don't even check for errors (and what would they really do with them anyway? It's the initiator's problem, really....). The data transfer arithmetic has been worked over again to handle multiple outstanding commands, so you have a notion of what's been moved already as well as what's currently in flight. It turns that this led to uncovering a REPORT_LUNS bug in the ISP_INTERNAL_TARGET code which was sending back 24 bytes of rpl data instead of the specified 16. What happened furthermore here is that sending back 16 bytes and reporting an overrun of 8 bytes made the initiator (running FC-Tape aware f/w) mad enough to request, and keep requesting, another FCP response (I guess it didn't like the answer so kept asking for it again). Sponsored by: Spectralogic MFC after: 1 month
2012-08-08 18:24:33 +00:00
break;
Make a static chain of isp softcs- gdb usage becomes a lot easier. Add in a very large amount of target mode support code- this is just a first pass at this. It's a difficult thing because some of the code can be in platform independent areas (see isp_target.?) but a lot has to be in platform dependent areas because of not only the tight coupling of received commands/events and the specific OS subsystem but because the platform independent code has (deliberately) no event/wait mechanisms.
2000-01-03 23:55:30 +00:00
}
Unify handles allocation for initiator and target IOCBs. I am not sure why this was split long ago, but I see no reason for it. At this point this unification just slightly reduces memory usage, but as next step I plan to reuse shared handle space for other IOCB types.
2015-12-25 13:03:18 +00:00
handle = isp_allocate_handle(isp, ccb, ISP_HANDLE_TARGET);
if (handle == 0) {
More rototilling with target mode in an attemp to get multiple CCB at a time outstanding reliable. It's not there yet, but this is the direction to go in so might as well commit. So far, multiple at a time CCBs work (see ISP_INTERNAL_TARGET test mode), but it fails if there are more downstream than the SIM wants to handle and SRR is sort of confused when this happens, plus it is not entirely quite clear what one does if a CCB/CTIO fails and you have more in flight (that don't fail, say) and more queued up at the SIM level that haven't been started yet. Some of this is driven because there apparently is no flow control to requeue XPT_CONTINUE_IO requests like there are for XPT_SCSI_IO requests. It is also more driven in that the few target mode periph drivers there are are not really set up for handling pushback- heck most of them don't even check for errors (and what would they really do with them anyway? It's the initiator's problem, really....). The data transfer arithmetic has been worked over again to handle multiple outstanding commands, so you have a notion of what's been moved already as well as what's currently in flight. It turns that this led to uncovering a REPORT_LUNS bug in the ISP_INTERNAL_TARGET code which was sending back 24 bytes of rpl data instead of the specified 16. What happened furthermore here is that sending back 16 bytes and reporting an overrun of 8 bytes made the initiator (running FC-Tape aware f/w) mad enough to request, and keep requesting, another FCP response (I guess it didn't like the answer so kept asking for it again). Sponsored by: Spectralogic MFC after: 1 month
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__);
Switch from using periph_links to sim_links. periph_links field belongs to periph drivers and must not be used here. MFC after: 2 weeks
2017-03-22 11:06:33 +00:00
TAILQ_INSERT_HEAD(waitq, &ccb->ccb_h, sim_links.tqe);
More rototilling with target mode in an attemp to get multiple CCB at a time outstanding reliable. It's not there yet, but this is the direction to go in so might as well commit. So far, multiple at a time CCBs work (see ISP_INTERNAL_TARGET test mode), but it fails if there are more downstream than the SIM wants to handle and SRR is sort of confused when this happens, plus it is not entirely quite clear what one does if a CCB/CTIO fails and you have more in flight (that don't fail, say) and more queued up at the SIM level that haven't been started yet. Some of this is driven because there apparently is no flow control to requeue XPT_CONTINUE_IO requests like there are for XPT_SCSI_IO requests. It is also more driven in that the few target mode periph drivers there are are not really set up for handling pushback- heck most of them don't even check for errors (and what would they really do with them anyway? It's the initiator's problem, really....). The data transfer arithmetic has been worked over again to handle multiple outstanding commands, so you have a notion of what's been moved already as well as what's currently in flight. It turns that this led to uncovering a REPORT_LUNS bug in the ISP_INTERNAL_TARGET code which was sending back 24 bytes of rpl data instead of the specified 16. What happened furthermore here is that sending back 16 bytes and reporting an overrun of 8 bytes made the initiator (running FC-Tape aware f/w) mad enough to request, and keep requesting, another FCP response (I guess it didn't like the answer so kept asking for it again). Sponsored by: Spectralogic MFC after: 1 month
2012-08-08 18:24:33 +00:00
isp_free_pcmd(isp, ccb);
break;
Clean up some debug printing. Find the correct lun when SCCLUN is defined. If we complete with a check condition but no sense data, say we had an AUTOSENSE failure.
2000-01-04 03:45:49 +00:00
}
More rototilling with target mode in an attemp to get multiple CCB at a time outstanding reliable. It's not there yet, but this is the direction to go in so might as well commit. So far, multiple at a time CCBs work (see ISP_INTERNAL_TARGET test mode), but it fails if there are more downstream than the SIM wants to handle and SRR is sort of confused when this happens, plus it is not entirely quite clear what one does if a CCB/CTIO fails and you have more in flight (that don't fail, say) and more queued up at the SIM level that haven't been started yet. Some of this is driven because there apparently is no flow control to requeue XPT_CONTINUE_IO requests like there are for XPT_SCSI_IO requests. It is also more driven in that the few target mode periph drivers there are are not really set up for handling pushback- heck most of them don't even check for errors (and what would they really do with them anyway? It's the initiator's problem, really....). The data transfer arithmetic has been worked over again to handle multiple outstanding commands, so you have a notion of what's been moved already as well as what's currently in flight. It turns that this led to uncovering a REPORT_LUNS bug in the ISP_INTERNAL_TARGET code which was sending back 24 bytes of rpl data instead of the specified 16. What happened furthermore here is that sending back 16 bytes and reporting an overrun of 8 bytes made the initiator (running FC-Tape aware f/w) mad enough to request, and keep requesting, another FCP response (I guess it didn't like the answer so kept asking for it again). Sponsored by: Spectralogic MFC after: 1 month
2012-08-08 18:24:33 +00:00
atp->bytes_in_transit += xfrlen;
PISP_PCMD(ccb)->datalen = xfrlen;
Make a static chain of isp softcs- gdb usage becomes a lot easier. Add in a very large amount of target mode support code- this is just a first pass at this. It's a difficult thing because some of the code can be in platform independent areas (see isp_target.?) but a lot has to be in platform dependent areas because of not only the tight coupling of received commands/events and the specific OS subsystem but because the platform independent code has (deliberately) no event/wait mechanisms.
2000-01-03 23:55:30 +00:00
More rototilling with target mode in an attemp to get multiple CCB at a time outstanding reliable. It's not there yet, but this is the direction to go in so might as well commit. So far, multiple at a time CCBs work (see ISP_INTERNAL_TARGET test mode), but it fails if there are more downstream than the SIM wants to handle and SRR is sort of confused when this happens, plus it is not entirely quite clear what one does if a CCB/CTIO fails and you have more in flight (that don't fail, say) and more queued up at the SIM level that haven't been started yet. Some of this is driven because there apparently is no flow control to requeue XPT_CONTINUE_IO requests like there are for XPT_SCSI_IO requests. It is also more driven in that the few target mode periph drivers there are are not really set up for handling pushback- heck most of them don't even check for errors (and what would they really do with them anyway? It's the initiator's problem, really....). The data transfer arithmetic has been worked over again to handle multiple outstanding commands, so you have a notion of what's been moved already as well as what's currently in flight. It turns that this led to uncovering a REPORT_LUNS bug in the ISP_INTERNAL_TARGET code which was sending back 24 bytes of rpl data instead of the specified 16. What happened furthermore here is that sending back 16 bytes and reporting an overrun of 8 bytes made the initiator (running FC-Tape aware f/w) mad enough to request, and keep requesting, another FCP response (I guess it didn't like the answer so kept asking for it again). Sponsored by: Spectralogic MFC after: 1 month
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.
*/
Make a static chain of isp softcs- gdb usage becomes a lot easier. Add in a very large amount of target mode support code- this is just a first pass at this. It's a difficult thing because some of the code can be in platform independent areas (see isp_target.?) but a lot has to be in platform dependent areas because of not only the tight coupling of received commands/events and the specific OS subsystem but because the platform independent code has (deliberately) no event/wait mechanisms.
2000-01-03 23:55:30 +00:00
More rototilling with target mode in an attemp to get multiple CCB at a time outstanding reliable. It's not there yet, but this is the direction to go in so might as well commit. So far, multiple at a time CCBs work (see ISP_INTERNAL_TARGET test mode), but it fails if there are more downstream than the SIM wants to handle and SRR is sort of confused when this happens, plus it is not entirely quite clear what one does if a CCB/CTIO fails and you have more in flight (that don't fail, say) and more queued up at the SIM level that haven't been started yet. Some of this is driven because there apparently is no flow control to requeue XPT_CONTINUE_IO requests like there are for XPT_SCSI_IO requests. It is also more driven in that the few target mode periph drivers there are are not really set up for handling pushback- heck most of them don't even check for errors (and what would they really do with them anyway? It's the initiator's problem, really....). The data transfer arithmetic has been worked over again to handle multiple outstanding commands, so you have a notion of what's been moved already as well as what's currently in flight. It turns that this led to uncovering a REPORT_LUNS bug in the ISP_INTERNAL_TARGET code which was sending back 24 bytes of rpl data instead of the specified 16. What happened furthermore here is that sending back 16 bytes and reporting an overrun of 8 bytes made the initiator (running FC-Tape aware f/w) mad enough to request, and keep requesting, another FCP response (I guess it didn't like the answer so kept asking for it again). Sponsored by: Spectralogic MFC after: 1 month
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 {
Rip off target mode support for parallel SCSI QLogic adapters. Hacks to enable target mode there complicated code, while didn't really work. And for outdated hardware fixing it is not really interesting. Initiator mode tested with Qlogic 1080 adapter is still working fine.
2015-11-23 10:06:19 +00:00
ct2_entry_t *cto = (ct2_entry_t *) local;
More rototilling with target mode in an attemp to get multiple CCB at a time outstanding reliable. It's not there yet, but this is the direction to go in so might as well commit. So far, multiple at a time CCBs work (see ISP_INTERNAL_TARGET test mode), but it fails if there are more downstream than the SIM wants to handle and SRR is sort of confused when this happens, plus it is not entirely quite clear what one does if a CCB/CTIO fails and you have more in flight (that don't fail, say) and more queued up at the SIM level that haven't been started yet. Some of this is driven because there apparently is no flow control to requeue XPT_CONTINUE_IO requests like there are for XPT_SCSI_IO requests. It is also more driven in that the few target mode periph drivers there are are not really set up for handling pushback- heck most of them don't even check for errors (and what would they really do with them anyway? It's the initiator's problem, really....). The data transfer arithmetic has been worked over again to handle multiple outstanding commands, so you have a notion of what's been moved already as well as what's currently in flight. It turns that this led to uncovering a REPORT_LUNS bug in the ISP_INTERNAL_TARGET code which was sending back 24 bytes of rpl data instead of the specified 16. What happened furthermore here is that sending back 16 bytes and reporting an overrun of 8 bytes made the initiator (running FC-Tape aware f/w) mad enough to request, and keep requesting, another FCP response (I guess it didn't like the answer so kept asking for it again). Sponsored by: Spectralogic MFC after: 1 month
2012-08-08 18:24:33 +00:00
cto->ct_syshandle = handle;
}
Redo a lot of the target mode infrastructure to be cognizant of Dual Bus cards like the 1280 && the 12160. Cleanup isp_target_putback_atio. Make sure bus and correct tag ids and firmware handles get propagated as needed.
2001-04-04 21:58:29 +00:00
More rototilling with target mode in an attemp to get multiple CCB at a time outstanding reliable. It's not there yet, but this is the direction to go in so might as well commit. So far, multiple at a time CCBs work (see ISP_INTERNAL_TARGET test mode), but it fails if there are more downstream than the SIM wants to handle and SRR is sort of confused when this happens, plus it is not entirely quite clear what one does if a CCB/CTIO fails and you have more in flight (that don't fail, say) and more queued up at the SIM level that haven't been started yet. Some of this is driven because there apparently is no flow control to requeue XPT_CONTINUE_IO requests like there are for XPT_SCSI_IO requests. It is also more driven in that the few target mode periph drivers there are are not really set up for handling pushback- heck most of them don't even check for errors (and what would they really do with them anyway? It's the initiator's problem, really....). The data transfer arithmetic has been worked over again to handle multiple outstanding commands, so you have a notion of what's been moved already as well as what's currently in flight. It turns that this led to uncovering a REPORT_LUNS bug in the ISP_INTERNAL_TARGET code which was sending back 24 bytes of rpl data instead of the specified 16. What happened furthermore here is that sending back 16 bytes and reporting an overrun of 8 bytes made the initiator (running FC-Tape aware f/w) mad enough to request, and keep requesting, another FCP response (I guess it didn't like the answer so kept asking for it again). Sponsored by: Spectralogic MFC after: 1 month
2012-08-08 18:24:33 +00:00
dmaresult = ISP_DMASETUP(isp, cso, (ispreq_t *) local);
if (dmaresult != CMD_QUEUED) {
Unify handles allocation for initiator and target IOCBs. I am not sure why this was split long ago, but I see no reason for it. At this point this unification just slightly reduces memory usage, but as next step I plan to reuse shared handle space for other IOCB types.
2015-12-25 13:03:18 +00:00
isp_destroy_handle(isp, handle);
More rototilling with target mode in an attemp to get multiple CCB at a time outstanding reliable. It's not there yet, but this is the direction to go in so might as well commit. So far, multiple at a time CCBs work (see ISP_INTERNAL_TARGET test mode), but it fails if there are more downstream than the SIM wants to handle and SRR is sort of confused when this happens, plus it is not entirely quite clear what one does if a CCB/CTIO fails and you have more in flight (that don't fail, say) and more queued up at the SIM level that haven't been started yet. Some of this is driven because there apparently is no flow control to requeue XPT_CONTINUE_IO requests like there are for XPT_SCSI_IO requests. It is also more driven in that the few target mode periph drivers there are are not really set up for handling pushback- heck most of them don't even check for errors (and what would they really do with them anyway? It's the initiator's problem, really....). The data transfer arithmetic has been worked over again to handle multiple outstanding commands, so you have a notion of what's been moved already as well as what's currently in flight. It turns that this led to uncovering a REPORT_LUNS bug in the ISP_INTERNAL_TARGET code which was sending back 24 bytes of rpl data instead of the specified 16. What happened furthermore here is that sending back 16 bytes and reporting an overrun of 8 bytes made the initiator (running FC-Tape aware f/w) mad enough to request, and keep requesting, another FCP response (I guess it didn't like the answer so kept asking for it again). Sponsored by: Spectralogic MFC after: 1 month
2012-08-08 18:24:33 +00:00
isp_free_pcmd(isp, ccb);
if (dmaresult == CMD_EAGAIN) {
Switch from using periph_links to sim_links. periph_links field belongs to periph drivers and must not be used here. MFC after: 2 weeks
2017-03-22 11:06:33 +00:00
TAILQ_INSERT_HEAD(waitq, &ccb->ccb_h, sim_links.tqe);
More rototilling with target mode in an attemp to get multiple CCB at a time outstanding reliable. It's not there yet, but this is the direction to go in so might as well commit. So far, multiple at a time CCBs work (see ISP_INTERNAL_TARGET test mode), but it fails if there are more downstream than the SIM wants to handle and SRR is sort of confused when this happens, plus it is not entirely quite clear what one does if a CCB/CTIO fails and you have more in flight (that don't fail, say) and more queued up at the SIM level that haven't been started yet. Some of this is driven because there apparently is no flow control to requeue XPT_CONTINUE_IO requests like there are for XPT_SCSI_IO requests. It is also more driven in that the few target mode periph drivers there are are not really set up for handling pushback- heck most of them don't even check for errors (and what would they really do with them anyway? It's the initiator's problem, really....). The data transfer arithmetic has been worked over again to handle multiple outstanding commands, so you have a notion of what's been moved already as well as what's currently in flight. It turns that this led to uncovering a REPORT_LUNS bug in the ISP_INTERNAL_TARGET code which was sending back 24 bytes of rpl data instead of the specified 16. What happened furthermore here is that sending back 16 bytes and reporting an overrun of 8 bytes made the initiator (running FC-Tape aware f/w) mad enough to request, and keep requesting, another FCP response (I guess it didn't like the answer so kept asking for it again). Sponsored by: Spectralogic MFC after: 1 month
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++;
More rototilling with target mode in an attemp to get multiple CCB at a time outstanding reliable. It's not there yet, but this is the direction to go in so might as well commit. So far, multiple at a time CCBs work (see ISP_INTERNAL_TARGET test mode), but it fails if there are more downstream than the SIM wants to handle and SRR is sort of confused when this happens, plus it is not entirely quite clear what one does if a CCB/CTIO fails and you have more in flight (that don't fail, say) and more queued up at the SIM level that haven't been started yet. Some of this is driven because there apparently is no flow control to requeue XPT_CONTINUE_IO requests like there are for XPT_SCSI_IO requests. It is also more driven in that the few target mode periph drivers there are are not really set up for handling pushback- heck most of them don't even check for errors (and what would they really do with them anyway? It's the initiator's problem, really....). The data transfer arithmetic has been worked over again to handle multiple outstanding commands, so you have a notion of what's been moved already as well as what's currently in flight. It turns that this led to uncovering a REPORT_LUNS bug in the ISP_INTERNAL_TARGET code which was sending back 24 bytes of rpl data instead of the specified 16. What happened furthermore here is that sending back 16 bytes and reporting an overrun of 8 bytes made the initiator (running FC-Tape aware f/w) mad enough to request, and keep requesting, another FCP response (I guess it didn't like the answer so kept asking for it again). Sponsored by: Spectralogic MFC after: 1 month
2012-08-08 18:24:33 +00:00
atp->seqno++;
Make a static chain of isp softcs- gdb usage becomes a lot easier. Add in a very large amount of target mode support code- this is just a first pass at this. It's a difficult thing because some of the code can be in platform independent areas (see isp_target.?) but a lot has to be in platform dependent areas because of not only the tight coupling of received commands/events and the specific OS subsystem but because the platform independent code has (deliberately) no event/wait mechanisms.
2000-01-03 23:55:30 +00:00
}
}
Redo a lot of the target mode infrastructure to be cognizant of Dual Bus cards like the 1280 && the 12160. Cleanup isp_target_putback_atio. Make sure bus and correct tag ids and firmware handles get propagated as needed.
2001-04-04 21:58:29 +00:00
static void
isp_refire_putback_atio(void *arg)
Add a isp_target_putback_atio- we aren't using CCINCR at this time, so we need a function that tells the Qlogic f/w that a target mode command is done, so increase the resource count for that lun. Add in a timeout function to kick the putback again if we fail to do it the first time (we may not have the request queue space for ATIO push). Split the function isp_handle_platform_ctio into two parts so that the timeout function for the ATIO push or isp_handle_platform_ctio can inform CAM that the requested CTIO(s) are now done. Clean up (cough) residual handling. What we need for Fibre Channel is to preserve the at_datalen field from the original incoming ATIO so we can calculate a 'true' residual. Unfortunately, we're not guaranteed to get that back from CAM. We'll *try* to find it hiding in the periph_priv field (layering violation)- but if an ATIO was passed in from user land- forget it. This means that we'll probably get residuals wrong for Fibre Channel commands we're completing with an error. It's too late to 4.1 release to fix this- too bad. Luckily the only device we'd really care about this occurring on is a tape device and they're still so rare as FC attached devices that this can be considered an untested combination anyway. Remove all CCINCR usage (resource autoreplenish). When we've proved to ourself that things are working properly, we can add it back in. Make sure we propage 'suggested' sense data from the incoming ATIO into the created system ATIO- and set sense_len appropriately. Correctly propagate tag values. Fall back to the model of generating (well, the functions in isp_pci.c do the work) multiple CTIOs based upon what we get from XPT. Instead of being able to pair Qlogic generated ATIOs with CAM ATIOs, and then to pair CAM CTIOs with Qlogic CTIOs, we have to take the CTIO passed to us from XPT, and if it implies that we have to generate extra Qlogic CTIOs, so be it. This means that we have to wait until the last CTIO in a sequence we generated completes before calling xpt_done. Executive summary- target mode actually now pretty much works well enough to tell folks about.
2000-07-18 06:58:28 +00:00
{
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
union ccb *ccb = arg;
Convert the refire_notify_ack timer from timeout(9) to callout(9). Tested by: no one
2014-11-18 21:03:46 +00:00
Fix build without INVARIANTS, broken by r274675.
2014-11-19 13:04:25 +00:00
ISP_ASSERT_LOCKED((ispsoftc_t *)XS_ISP(ccb));
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
isp_target_putback_atio(ccb);
Redo a lot of the target mode infrastructure to be cognizant of Dual Bus cards like the 1280 && the 12160. Cleanup isp_target_putback_atio. Make sure bus and correct tag ids and firmware handles get propagated as needed.
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;
Convert the refire_notify_ack timer from timeout(9) to callout(9). Tested by: no one
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)) {
Convert the refire_notify_ack timer from timeout(9) to callout(9). Tested by: no one
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);
}
}
Redo a lot of the target mode infrastructure to be cognizant of Dual Bus cards like the 1280 && the 12160. Cleanup isp_target_putback_atio. Make sure bus and correct tag ids and firmware handles get propagated as needed.
2001-04-04 21:58:29 +00:00
static void
isp_target_putback_atio(union ccb *ccb)
{
Use isp_target_put_entry() in places where it can be. This unifies the code and removes some duplication. MFC after: 2 weeks
2017-03-18 13:42:08 +00:00
ispsoftc_t *isp = XS_ISP(ccb);
struct ccb_scsiio *cso = &ccb->csio;
Rip off target mode support for parallel SCSI QLogic adapters. Hacks to enable target mode there complicated code, while didn't really work. And for outdated hardware fixing it is not really interesting. Initiator mode tested with Qlogic 1080 adapter is still working fine.
2015-11-23 10:06:19 +00:00
at2_entry_t local, *at = &local;
Redo a lot of the target mode infrastructure to be cognizant of Dual Bus cards like the 1280 && the 12160. Cleanup isp_target_putback_atio. Make sure bus and correct tag ids and firmware handles get propagated as needed.
2001-04-04 21:58:29 +00:00
Rip off target mode support for parallel SCSI QLogic adapters. Hacks to enable target mode there complicated code, while didn't really work. And for outdated hardware fixing it is not really interesting. Initiator mode tested with Qlogic 1080 adapter is still working fine.
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;
Add a isp_target_putback_atio- we aren't using CCINCR at this time, so we need a function that tells the Qlogic f/w that a target mode command is done, so increase the resource count for that lun. Add in a timeout function to kick the putback again if we fail to do it the first time (we may not have the request queue space for ATIO push). Split the function isp_handle_platform_ctio into two parts so that the timeout function for the ATIO push or isp_handle_platform_ctio can inform CAM that the requested CTIO(s) are now done. Clean up (cough) residual handling. What we need for Fibre Channel is to preserve the at_datalen field from the original incoming ATIO so we can calculate a 'true' residual. Unfortunately, we're not guaranteed to get that back from CAM. We'll *try* to find it hiding in the periph_priv field (layering violation)- but if an ATIO was passed in from user land- forget it. This means that we'll probably get residuals wrong for Fibre Channel commands we're completing with an error. It's too late to 4.1 release to fix this- too bad. Luckily the only device we'd really care about this occurring on is a tape device and they're still so rare as FC attached devices that this can be considered an untested combination anyway. Remove all CCINCR usage (resource autoreplenish). When we've proved to ourself that things are working properly, we can add it back in. Make sure we propage 'suggested' sense data from the incoming ATIO into the created system ATIO- and set sense_len appropriately. Correctly propagate tag values. Fall back to the model of generating (well, the functions in isp_pci.c do the work) multiple CTIOs based upon what we get from XPT. Instead of being able to pair Qlogic generated ATIOs with CAM ATIOs, and then to pair CAM CTIOs with Qlogic CTIOs, we have to take the CTIO passed to us from XPT, and if it implies that we have to generate extra Qlogic CTIOs, so be it. This means that we have to wait until the last CTIO in a sequence we generated completes before calling xpt_done. Executive summary- target mode actually now pretty much works well enough to tell folks about.
2000-07-18 06:58:28 +00:00
} else {
Rip off target mode support for parallel SCSI QLogic adapters. Hacks to enable target mode there complicated code, while didn't really work. And for outdated hardware fixing it is not really interesting. Initiator mode tested with Qlogic 1080 adapter is still working fine.
2015-11-23 10:06:19 +00:00
at->at_lun = (uint8_t) ccb->ccb_h.target_lun;
Add a isp_target_putback_atio- we aren't using CCINCR at this time, so we need a function that tells the Qlogic f/w that a target mode command is done, so increase the resource count for that lun. Add in a timeout function to kick the putback again if we fail to do it the first time (we may not have the request queue space for ATIO push). Split the function isp_handle_platform_ctio into two parts so that the timeout function for the ATIO push or isp_handle_platform_ctio can inform CAM that the requested CTIO(s) are now done. Clean up (cough) residual handling. What we need for Fibre Channel is to preserve the at_datalen field from the original incoming ATIO so we can calculate a 'true' residual. Unfortunately, we're not guaranteed to get that back from CAM. We'll *try* to find it hiding in the periph_priv field (layering violation)- but if an ATIO was passed in from user land- forget it. This means that we'll probably get residuals wrong for Fibre Channel commands we're completing with an error. It's too late to 4.1 release to fix this- too bad. Luckily the only device we'd really care about this occurring on is a tape device and they're still so rare as FC attached devices that this can be considered an untested combination anyway. Remove all CCINCR usage (resource autoreplenish). When we've proved to ourself that things are working properly, we can add it back in. Make sure we propage 'suggested' sense data from the incoming ATIO into the created system ATIO- and set sense_len appropriately. Correctly propagate tag values. Fall back to the model of generating (well, the functions in isp_pci.c do the work) multiple CTIOs based upon what we get from XPT. Instead of being able to pair Qlogic generated ATIOs with CAM ATIOs, and then to pair CAM CTIOs with Qlogic CTIOs, we have to take the CTIO passed to us from XPT, and if it implies that we have to generate extra Qlogic CTIOs, so be it. This means that we have to wait until the last CTIO in a sequence we generated completes before calling xpt_done. Executive summary- target mode actually now pretty much works well enough to tell folks about.
2000-07-18 06:58:28 +00:00
}
Rip off target mode support for parallel SCSI QLogic adapters. Hacks to enable target mode there complicated code, while didn't really work. And for outdated hardware fixing it is not really interesting. Initiator mode tested with Qlogic 1080 adapter is still working fine.
2015-11-23 10:06:19 +00:00
at->at_status = CT_OK;
at->at_rxid = cso->tag_id;
Polish target_id/target_lun setting for ATIOs/INOTs. For ATIOs it is pointless to report isp_loopid to CAM, since in other places it operates with port database record IDs, not with loop IDs. For INOTs target_id/target_lun seems were never set, so wildcard INOTs probably were not working correctly when LUN IDs were important.
2017-06-30 06:10:18 +00:00
at->at_iid = cso->init_id;
Use isp_target_put_entry() in places where it can be. This unifies the code and removes some duplication. MFC after: 2 weeks
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);
Add a isp_target_putback_atio- we aren't using CCINCR at this time, so we need a function that tells the Qlogic f/w that a target mode command is done, so increase the resource count for that lun. Add in a timeout function to kick the putback again if we fail to do it the first time (we may not have the request queue space for ATIO push). Split the function isp_handle_platform_ctio into two parts so that the timeout function for the ATIO push or isp_handle_platform_ctio can inform CAM that the requested CTIO(s) are now done. Clean up (cough) residual handling. What we need for Fibre Channel is to preserve the at_datalen field from the original incoming ATIO so we can calculate a 'true' residual. Unfortunately, we're not guaranteed to get that back from CAM. We'll *try* to find it hiding in the periph_priv field (layering violation)- but if an ATIO was passed in from user land- forget it. This means that we'll probably get residuals wrong for Fibre Channel commands we're completing with an error. It's too late to 4.1 release to fix this- too bad. Luckily the only device we'd really care about this occurring on is a tape device and they're still so rare as FC attached devices that this can be considered an untested combination anyway. Remove all CCINCR usage (resource autoreplenish). When we've proved to ourself that things are working properly, we can add it back in. Make sure we propage 'suggested' sense data from the incoming ATIO into the created system ATIO- and set sense_len appropriately. Correctly propagate tag values. Fall back to the model of generating (well, the functions in isp_pci.c do the work) multiple CTIOs based upon what we get from XPT. Instead of being able to pair Qlogic generated ATIOs with CAM ATIOs, and then to pair CAM CTIOs with Qlogic CTIOs, we have to take the CTIO passed to us from XPT, and if it implies that we have to generate extra Qlogic CTIOs, so be it. This means that we have to wait until the last CTIO in a sequence we generated completes before calling xpt_done. Executive summary- target mode actually now pretty much works well enough to tell folks about.
2000-07-18 06:58:28 +00:00
}
static void
Redo a lot of the target mode infrastructure to be cognizant of Dual Bus cards like the 1280 && the 12160. Cleanup isp_target_putback_atio. Make sure bus and correct tag ids and firmware handles get propagated as needed.
2001-04-04 21:58:29 +00:00
isp_complete_ctio(union ccb *ccb)
Add a isp_target_putback_atio- we aren't using CCINCR at this time, so we need a function that tells the Qlogic f/w that a target mode command is done, so increase the resource count for that lun. Add in a timeout function to kick the putback again if we fail to do it the first time (we may not have the request queue space for ATIO push). Split the function isp_handle_platform_ctio into two parts so that the timeout function for the ATIO push or isp_handle_platform_ctio can inform CAM that the requested CTIO(s) are now done. Clean up (cough) residual handling. What we need for Fibre Channel is to preserve the at_datalen field from the original incoming ATIO so we can calculate a 'true' residual. Unfortunately, we're not guaranteed to get that back from CAM. We'll *try* to find it hiding in the periph_priv field (layering violation)- but if an ATIO was passed in from user land- forget it. This means that we'll probably get residuals wrong for Fibre Channel commands we're completing with an error. It's too late to 4.1 release to fix this- too bad. Luckily the only device we'd really care about this occurring on is a tape device and they're still so rare as FC attached devices that this can be considered an untested combination anyway. Remove all CCINCR usage (resource autoreplenish). When we've proved to ourself that things are working properly, we can add it back in. Make sure we propage 'suggested' sense data from the incoming ATIO into the created system ATIO- and set sense_len appropriately. Correctly propagate tag values. Fall back to the model of generating (well, the functions in isp_pci.c do the work) multiple CTIOs based upon what we get from XPT. Instead of being able to pair Qlogic generated ATIOs with CAM ATIOs, and then to pair CAM CTIOs with Qlogic CTIOs, we have to take the CTIO passed to us from XPT, and if it implies that we have to generate extra Qlogic CTIOs, so be it. This means that we have to wait until the last CTIO in a sequence we generated completes before calling xpt_done. Executive summary- target mode actually now pretty much works well enough to tell folks about.
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);
Add a isp_target_putback_atio- we aren't using CCINCR at this time, so we need a function that tells the Qlogic f/w that a target mode command is done, so increase the resource count for that lun. Add in a timeout function to kick the putback again if we fail to do it the first time (we may not have the request queue space for ATIO push). Split the function isp_handle_platform_ctio into two parts so that the timeout function for the ATIO push or isp_handle_platform_ctio can inform CAM that the requested CTIO(s) are now done. Clean up (cough) residual handling. What we need for Fibre Channel is to preserve the at_datalen field from the original incoming ATIO so we can calculate a 'true' residual. Unfortunately, we're not guaranteed to get that back from CAM. We'll *try* to find it hiding in the periph_priv field (layering violation)- but if an ATIO was passed in from user land- forget it. This means that we'll probably get residuals wrong for Fibre Channel commands we're completing with an error. It's too late to 4.1 release to fix this- too bad. Luckily the only device we'd really care about this occurring on is a tape device and they're still so rare as FC attached devices that this can be considered an untested combination anyway. Remove all CCINCR usage (resource autoreplenish). When we've proved to ourself that things are working properly, we can add it back in. Make sure we propage 'suggested' sense data from the incoming ATIO into the created system ATIO- and set sense_len appropriately. Correctly propagate tag values. Fall back to the model of generating (well, the functions in isp_pci.c do the work) multiple CTIOs based upon what we get from XPT. Instead of being able to pair Qlogic generated ATIOs with CAM ATIOs, and then to pair CAM CTIOs with Qlogic CTIOs, we have to take the CTIO passed to us from XPT, and if it implies that we have to generate extra Qlogic CTIOs, so be it. This means that we have to wait until the last CTIO in a sequence we generated completes before calling xpt_done. Executive summary- target mode actually now pretty much works well enough to tell folks about.
2000-07-18 06:58:28 +00:00
}
}
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
static void
Some more gratuitous format and name changes. Pull in some target mode changes from a private branch. Pull in some more RELENG_4 compilation changes. A lot of lines changed, but not much content change yet.
2006-04-21 18:30:01 +00:00
isp_handle_platform_atio2(ispsoftc_t *isp, at2_entry_t *aep)
Make a static chain of isp softcs- gdb usage becomes a lot easier. Add in a very large amount of target mode support code- this is just a first pass at this. It's a difficult thing because some of the code can be in platform independent areas (see isp_target.?) but a lot has to be in platform dependent areas because of not only the tight coupling of received commands/events and the specific OS subsystem but because the platform independent code has (deliberately) no event/wait mechanisms.
2000-01-03 23:55:30 +00:00
{
Generate fake ISPASYNC_CHANGE_PDB on fake login on pre-24xx. This makes port scanner fix absent port ID for added initiator.
2015-11-22 16:55:43 +00:00
fcparam *fcp;
Clean up some debug printing. Find the correct lun when SCCLUN is defined. If we complete with a check condition but no sense data, say we had an AUTOSENSE failure.
2000-01-04 03:45:49 +00:00
lun_id_t lun;
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
fcportdb_t *lp;
Make a static chain of isp softcs- gdb usage becomes a lot easier. Add in a very large amount of target mode support code- this is just a first pass at this. It's a difficult thing because some of the code can be in platform independent areas (see isp_target.?) but a lot has to be in platform dependent areas because of not only the tight coupling of received commands/events and the specific OS subsystem but because the platform independent code has (deliberately) no event/wait mechanisms.
2000-01-03 23:55:30 +00:00
tstate_t *tptr;
struct ccb_accept_tio *atiop;
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
uint16_t nphdl;
Various minor and not so minor fixes suggested by Coverity. In at least one case, it's amazing that target mode worked at all. Found by: Coverity. MFC after: 2 weeks
2010-06-02 23:31:27 +00:00
atio_private_data_t *atp;
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
inot_private_data_t *ntp;
Make a static chain of isp softcs- gdb usage becomes a lot easier. Add in a very large amount of target mode support code- this is just a first pass at this. It's a difficult thing because some of the code can be in platform independent areas (see isp_target.?) but a lot has to be in platform dependent areas because of not only the tight coupling of received commands/events and the specific OS subsystem but because the platform independent code has (deliberately) no event/wait mechanisms.
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.
*
Fix typos. PR: bin/148894 Submitted by: olgeni
2010-11-09 10:59:09 +00:00
* If QLTM_SVALID is set, the firmware has recommended Sense Data.
Make a static chain of isp softcs- gdb usage becomes a lot easier. Add in a very large amount of target mode support code- this is just a first pass at this. It's a difficult thing because some of the code can be in platform independent areas (see isp_target.?) but a lot has to be in platform dependent areas because of not only the tight coupling of received commands/events and the specific OS subsystem but because the platform independent code has (deliberately) no event/wait mechanisms.
2000-01-03 23:55:30 +00:00
*/
if ((aep->at_status & ~QLTM_SVALID) != AT_CDB) {
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
isp_prt(isp, ISP_LOGWARN, "bogus atio (0x%x) leaked to platform", aep->at_status);
Fix multiple problems around LUN disable under load. - Move private data about ATIOs/INOTs from per-LUN to per-channel data. This allows active commands to continue operation after LUN destruction. This also simplifies lookup of the data by tag in some situations. - Unify three restart_queue processing implementations. - Complete all ATIOs from restart_queue on LUN disable. - Delete ATIO private data when command completed or aborted, not depending on the ATIO being requeued, that was ugly hack and could never happen. CAM should always call ether XPT_CONT_TARGET_IO with status or XPT_ABORT. - Implement XPT_ABORT for queued ATIOs/INOTs to allow CAM do graceful shutdown, not depending on LUN disable, as it is done in ahd(4)/targ(4). - Unify isp_endcmd() arguments to make it more usable in generic code. - Remove never really used LUN state reference counter. MFC after: 2 weeks
2017-02-22 06:43:49 +00:00
isp_endcmd(isp, aep, NIL_HANDLE, 0, SCSI_STATUS_BUSY, 0);
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
return;
Make a static chain of isp softcs- gdb usage becomes a lot easier. Add in a very large amount of target mode support code- this is just a first pass at this. It's a difficult thing because some of the code can be in platform independent areas (see isp_target.?) but a lot has to be in platform dependent areas because of not only the tight coupling of received commands/events and the specific OS subsystem but because the platform independent code has (deliberately) no event/wait mechanisms.
2000-01-03 23:55:30 +00:00
}
Generate fake ISPASYNC_CHANGE_PDB on fake login on pre-24xx. This makes port scanner fix absent port ID for added initiator.
2015-11-22 16:55:43 +00:00
fcp = FCPARAM(isp, 0);
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
if (ISP_CAP_SCCFW(isp)) {
Remove all ISP2100_SCCLUN define protected code and replace it with runtime checks.
2000-06-18 04:50:26 +00:00
lun = aep->at_scclun;
} else {
lun = aep->at_lun;
}
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
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;
}
Redo a lot of the target mode infrastructure to be cognizant of Dual Bus cards like the 1280 && the 12160. Cleanup isp_target_putback_atio. Make sure bus and correct tag ids and firmware handles get propagated as needed.
2001-04-04 21:58:29 +00:00
tptr = get_lun_statep(isp, 0, lun);
Make a static chain of isp softcs- gdb usage becomes a lot easier. Add in a very large amount of target mode support code- this is just a first pass at this. It's a difficult thing because some of the code can be in platform independent areas (see isp_target.?) but a lot has to be in platform dependent areas because of not only the tight coupling of received commands/events and the specific OS subsystem but because the platform independent code has (deliberately) no event/wait mechanisms.
2000-01-03 23:55:30 +00:00
if (tptr == NULL) {
Redo a lot of the target mode infrastructure to be cognizant of Dual Bus cards like the 1280 && the 12160. Cleanup isp_target_putback_atio. Make sure bus and correct tag ids and firmware handles get propagated as needed.
2001-04-04 21:58:29 +00:00
tptr = get_lun_statep(isp, 0, CAM_LUN_WILDCARD);
Checkpoint of work in progress in cleaning up target mode. It actually seems to work well in RELENG_4. However, 5.X locking foo means that I'll have to do some quick redesign. Add ioctl handlers for ISP_GETROLE and ISP_SETROLE ioctls.
2004-02-07 03:47:33 +00:00
if (tptr == NULL) {
Adjust various SCSI drivers to handle either a 32-bit or 64-bit lun_id_t, mostly by adjustments to debugging printf() format specifiers. For high numbered LUNs, also switch to printing them in hex as per SAM-5. MFC after: 2 weeks
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) {
Fix multiple problems around LUN disable under load. - Move private data about ATIOs/INOTs from per-LUN to per-channel data. This allows active commands to continue operation after LUN destruction. This also simplifies lookup of the data by tag in some situations. - Unify three restart_queue processing implementations. - Complete all ATIOs from restart_queue on LUN disable. - Delete ATIO private data when command completed or aborted, not depending on the ATIO being requeued, that was ugly hack and could never happen. CAM should always call ether XPT_CONT_TARGET_IO with status or XPT_ABORT. - Implement XPT_ABORT for queued ATIOs/INOTs to allow CAM do graceful shutdown, not depending on LUN disable, as it is done in ahd(4)/targ(4). - Unify isp_endcmd() arguments to make it more usable in generic code. - Remove never really used LUN state reference counter. MFC after: 2 weeks
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 {
Fix multiple problems around LUN disable under load. - Move private data about ATIOs/INOTs from per-LUN to per-channel data. This allows active commands to continue operation after LUN destruction. This also simplifies lookup of the data by tag in some situations. - Unify three restart_queue processing implementations. - Complete all ATIOs from restart_queue on LUN disable. - Delete ATIO private data when command completed or aborted, not depending on the ATIO being requeued, that was ugly hack and could never happen. CAM should always call ether XPT_CONT_TARGET_IO with status or XPT_ABORT. - Implement XPT_ABORT for queued ATIOs/INOTs to allow CAM do graceful shutdown, not depending on LUN disable, as it is done in ahd(4)/targ(4). - Unify isp_endcmd() arguments to make it more usable in generic code. - Remove never really used LUN state reference counter. MFC after: 2 weeks
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
}
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
return;
}
}
/*
* Start any commands pending resources first.
*/
Fix multiple problems around LUN disable under load. - Move private data about ATIOs/INOTs from per-LUN to per-channel data. This allows active commands to continue operation after LUN destruction. This also simplifies lookup of the data by tag in some situations. - Unify three restart_queue processing implementations. - Complete all ATIOs from restart_queue on LUN disable. - Delete ATIO private data when command completed or aborted, not depending on the ATIO being requeued, that was ugly hack and could never happen. CAM should always call ether XPT_CONT_TARGET_IO with status or XPT_ABORT. - Implement XPT_ABORT for queued ATIOs/INOTs to allow CAM do graceful shutdown, not depending on LUN disable, as it is done in ahd(4)/targ(4). - Unify isp_endcmd() arguments to make it more usable in generic code. - Remove never really used LUN state reference counter. MFC after: 2 weeks
2017-02-22 06:43:49 +00:00
if (isp_atio_restart(isp, 0, tptr))
goto noresrc;
Make a static chain of isp softcs- gdb usage becomes a lot easier. Add in a very large amount of target mode support code- this is just a first pass at this. It's a difficult thing because some of the code can be in platform independent areas (see isp_target.?) but a lot has to be in platform dependent areas because of not only the tight coupling of received commands/events and the specific OS subsystem but because the platform independent code has (deliberately) no event/wait mechanisms.
2000-01-03 23:55:30 +00:00
atiop = (struct ccb_accept_tio *) SLIST_FIRST(&tptr->atios);
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
if (atiop == NULL) {
goto noresrc;
}
Checkpoint of work in progress in cleaning up target mode. It actually seems to work well in RELENG_4. However, 5.X locking foo means that I'll have to do some quick redesign. Add ioctl handlers for ISP_GETROLE and ISP_SETROLE ioctls.
2004-02-07 03:47:33 +00:00
Fix multiple problems around LUN disable under load. - Move private data about ATIOs/INOTs from per-LUN to per-channel data. This allows active commands to continue operation after LUN destruction. This also simplifies lookup of the data by tag in some situations. - Unify three restart_queue processing implementations. - Complete all ATIOs from restart_queue on LUN disable. - Delete ATIO private data when command completed or aborted, not depending on the ATIO being requeued, that was ugly hack and could never happen. CAM should always call ether XPT_CONT_TARGET_IO with status or XPT_ABORT. - Implement XPT_ABORT for queued ATIOs/INOTs to allow CAM do graceful shutdown, not depending on LUN disable, as it is done in ahd(4)/targ(4). - Unify isp_endcmd() arguments to make it more usable in generic code. - Remove never really used LUN state reference counter. MFC after: 2 weeks
2017-02-22 06:43:49 +00:00
atp = isp_get_atpd(isp, 0, aep->at_rxid);
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
if (atp == NULL) {
goto noresrc;
Make a static chain of isp softcs- gdb usage becomes a lot easier. Add in a very large amount of target mode support code- this is just a first pass at this. It's a difficult thing because some of the code can be in platform independent areas (see isp_target.?) but a lot has to be in platform dependent areas because of not only the tight coupling of received commands/events and the specific OS subsystem but because the platform independent code has (deliberately) no event/wait mechanisms.
2000-01-03 23:55:30 +00:00
}
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
Add support for ISP_FC_GETHINFO, which returns current connection topology, speed, loopid, WWPN/WWNN, etc. Beef up target mode. Add isp_handle_platform_notify_scsi and isp_handle_platform_notify_fc platform handlers to handle immediate notifies (isp_handle_platform_notify_scsi is still stubbed out). In implementation of isp_handle_platform_notify_fc, for IN_ABORT_TASK, peel off a pending XPT_IMMED_NOTIFY and call xpt_done on it and hope that somebody upstream is listening. Make sure on final CTIO2s that we set residual correctly. These are absolutely crucial. Make sure we set relative offset for each CTIO2 based upon bytes we've already xferred. This is what the private adjunct datat to the original ATIO is. Note state of command so we can figure out where to find it if we get an ABORT from the firmware. Make sure we *always* set CAM_TAG_ACTION_VALID for ATIO2s. Make sure we keep track of the original lun. If se sent status (or we're otherwise done with the command), don't forget to free the adjunct structure.
2002-06-16 05:08:02 +00:00
atp->state = ATPD_STATE_ATIO;
Make a static chain of isp softcs- gdb usage becomes a lot easier. Add in a very large amount of target mode support code- this is just a first pass at this. It's a difficult thing because some of the code can be in platform independent areas (see isp_target.?) but a lot has to be in platform dependent areas because of not only the tight coupling of received commands/events and the specific OS subsystem but because the platform independent code has (deliberately) no event/wait mechanisms.
2000-01-03 23:55:30 +00:00
SLIST_REMOVE_HEAD(&tptr->atios, sim_links.sle);
Remove not very useful ATIO/INOT stats. While there polish respective debug logging. MFC after: 2 weeks
2017-03-15 19:49:45 +00:00
ISP_PATH_PRT(isp, ISP_LOGTDEBUG2, atiop->ccb_h.path, "Take FREE ATIO\n");
Polish target_id/target_lun setting for ATIOs/INOTs. For ATIOs it is pointless to report isp_loopid to CAM, since in other places it operates with port database record IDs, not with loop IDs. For INOTs target_id/target_lun seems were never set, so wildcard INOTs probably were not working correctly when LUN IDs were important.
2017-06-30 06:10:18 +00:00
atiop->ccb_h.target_id = ISP_MAX_TARGETS(isp);
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
atiop->ccb_h.target_lun = lun;
Add a isp_target_putback_atio- we aren't using CCINCR at this time, so we need a function that tells the Qlogic f/w that a target mode command is done, so increase the resource count for that lun. Add in a timeout function to kick the putback again if we fail to do it the first time (we may not have the request queue space for ATIO push). Split the function isp_handle_platform_ctio into two parts so that the timeout function for the ATIO push or isp_handle_platform_ctio can inform CAM that the requested CTIO(s) are now done. Clean up (cough) residual handling. What we need for Fibre Channel is to preserve the at_datalen field from the original incoming ATIO so we can calculate a 'true' residual. Unfortunately, we're not guaranteed to get that back from CAM. We'll *try* to find it hiding in the periph_priv field (layering violation)- but if an ATIO was passed in from user land- forget it. This means that we'll probably get residuals wrong for Fibre Channel commands we're completing with an error. It's too late to 4.1 release to fix this- too bad. Luckily the only device we'd really care about this occurring on is a tape device and they're still so rare as FC attached devices that this can be considered an untested combination anyway. Remove all CCINCR usage (resource autoreplenish). When we've proved to ourself that things are working properly, we can add it back in. Make sure we propage 'suggested' sense data from the incoming ATIO into the created system ATIO- and set sense_len appropriately. Correctly propagate tag values. Fall back to the model of generating (well, the functions in isp_pci.c do the work) multiple CTIOs based upon what we get from XPT. Instead of being able to pair Qlogic generated ATIOs with CAM ATIOs, and then to pair CAM CTIOs with Qlogic CTIOs, we have to take the CTIO passed to us from XPT, and if it implies that we have to generate extra Qlogic CTIOs, so be it. This means that we have to wait until the last CTIO in a sequence we generated completes before calling xpt_done. Executive summary- target mode actually now pretty much works well enough to tell folks about.
2000-07-18 06:58:28 +00:00
Fix at2_entry_t to reflect what the firmware actually writes (instead of just deriving from SCSI at_entry_t). In this case, there is no 'suggested sense' for FC cards.
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;
Add a isp_target_putback_atio- we aren't using CCINCR at this time, so we need a function that tells the Qlogic f/w that a target mode command is done, so increase the resource count for that lun. Add in a timeout function to kick the putback again if we fail to do it the first time (we may not have the request queue space for ATIO push). Split the function isp_handle_platform_ctio into two parts so that the timeout function for the ATIO push or isp_handle_platform_ctio can inform CAM that the requested CTIO(s) are now done. Clean up (cough) residual handling. What we need for Fibre Channel is to preserve the at_datalen field from the original incoming ATIO so we can calculate a 'true' residual. Unfortunately, we're not guaranteed to get that back from CAM. We'll *try* to find it hiding in the periph_priv field (layering violation)- but if an ATIO was passed in from user land- forget it. This means that we'll probably get residuals wrong for Fibre Channel commands we're completing with an error. It's too late to 4.1 release to fix this- too bad. Luckily the only device we'd really care about this occurring on is a tape device and they're still so rare as FC attached devices that this can be considered an untested combination anyway. Remove all CCINCR usage (resource autoreplenish). When we've proved to ourself that things are working properly, we can add it back in. Make sure we propage 'suggested' sense data from the incoming ATIO into the created system ATIO- and set sense_len appropriately. Correctly propagate tag values. Fall back to the model of generating (well, the functions in isp_pci.c do the work) multiple CTIOs based upon what we get from XPT. Instead of being able to pair Qlogic generated ATIOs with CAM ATIOs, and then to pair CAM CTIOs with Qlogic CTIOs, we have to take the CTIO passed to us from XPT, and if it implies that we have to generate extra Qlogic CTIOs, so be it. This means that we have to wait until the last CTIO in a sequence we generated completes before calling xpt_done. Executive summary- target mode actually now pretty much works well enough to tell folks about.
2000-07-18 06:58:28 +00:00
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
/*
* If we're not in the port database, add ourselves.
*/
Switch initiator IDs in target mode to the same address space as target IDs in initiator mode -- index in port database instead of handlers. This makes initiator IDs persist across role changes and firmware resets, when handlers previously assigned by firmware are lost and reused. Sponsored by: iXsystems, Inc.
2015-07-13 21:01:24 +00:00
if (IS_2100(isp))
atiop->init_id = nphdl;
else {
Move <= 23xx PDB workaround to generic code. It is chip-specific and has nothing to do with platform. MFC after: 2 weeks
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;
Switch initiator IDs in target mode to the same address space as target IDs in initiator mode -- index in port database instead of handlers. This makes initiator IDs persist across role changes and firmware resets, when handlers previously assigned by firmware are lost and reused. Sponsored by: iXsystems, Inc.
2015-07-13 21:01:24 +00:00
}
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
}
Make a static chain of isp softcs- gdb usage becomes a lot easier. Add in a very large amount of target mode support code- this is just a first pass at this. It's a difficult thing because some of the code can be in platform independent areas (see isp_target.?) but a lot has to be in platform dependent areas because of not only the tight coupling of received commands/events and the specific OS subsystem but because the platform independent code has (deliberately) no event/wait mechanisms.
2000-01-03 23:55:30 +00:00
atiop->cdb_len = ATIO2_CDBLEN;
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
ISP_MEMCPY(atiop->cdb_io.cdb_bytes, aep->at_cdb, ATIO2_CDBLEN);
Make a static chain of isp softcs- gdb usage becomes a lot easier. Add in a very large amount of target mode support code- this is just a first pass at this. It's a difficult thing because some of the code can be in platform independent areas (see isp_target.?) but a lot has to be in platform dependent areas because of not only the tight coupling of received commands/events and the specific OS subsystem but because the platform independent code has (deliberately) no event/wait mechanisms.
2000-01-03 23:55:30 +00:00
atiop->ccb_h.status = CAM_CDB_RECVD;
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
atiop->tag_id = atp->tag;
Make a static chain of isp softcs- gdb usage becomes a lot easier. Add in a very large amount of target mode support code- this is just a first pass at this. It's a difficult thing because some of the code can be in platform independent areas (see isp_target.?) but a lot has to be in platform dependent areas because of not only the tight coupling of received commands/events and the specific OS subsystem but because the platform independent code has (deliberately) no event/wait mechanisms.
2000-01-03 23:55:30 +00:00
switch (aep->at_taskflags & ATIO2_TC_ATTR_MASK) {
case ATIO2_TC_ATTR_SIMPLEQ:
Partial MFproject/camlock r256671: Fix several target mode SIMs to not blindly clear ccb_h.flags field of ATIO CCBs. Not all CCB flags there belong to them.
2013-10-21 06:04:39 +00:00
atiop->ccb_h.flags |= CAM_TAG_ACTION_VALID;
Make a static chain of isp softcs- gdb usage becomes a lot easier. Add in a very large amount of target mode support code- this is just a first pass at this. It's a difficult thing because some of the code can be in platform independent areas (see isp_target.?) but a lot has to be in platform dependent areas because of not only the tight coupling of received commands/events and the specific OS subsystem but because the platform independent code has (deliberately) no event/wait mechanisms.
2000-01-03 23:55:30 +00:00
atiop->tag_action = MSG_SIMPLE_Q_TAG;
break;
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
case ATIO2_TC_ATTR_HEADOFQ:
Partial MFproject/camlock r256671: Fix several target mode SIMs to not blindly clear ccb_h.flags field of ATIO CCBs. Not all CCB flags there belong to them.
2013-10-21 06:04:39 +00:00
atiop->ccb_h.flags |= CAM_TAG_ACTION_VALID;
Make a static chain of isp softcs- gdb usage becomes a lot easier. Add in a very large amount of target mode support code- this is just a first pass at this. It's a difficult thing because some of the code can be in platform independent areas (see isp_target.?) but a lot has to be in platform dependent areas because of not only the tight coupling of received commands/events and the specific OS subsystem but because the platform independent code has (deliberately) no event/wait mechanisms.
2000-01-03 23:55:30 +00:00
atiop->tag_action = MSG_HEAD_OF_Q_TAG;
break;
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
case ATIO2_TC_ATTR_ORDERED:
Partial MFproject/camlock r256671: Fix several target mode SIMs to not blindly clear ccb_h.flags field of ATIO CCBs. Not all CCB flags there belong to them.
2013-10-21 06:04:39 +00:00
atiop->ccb_h.flags |= CAM_TAG_ACTION_VALID;
Make a static chain of isp softcs- gdb usage becomes a lot easier. Add in a very large amount of target mode support code- this is just a first pass at this. It's a difficult thing because some of the code can be in platform independent areas (see isp_target.?) but a lot has to be in platform dependent areas because of not only the tight coupling of received commands/events and the specific OS subsystem but because the platform independent code has (deliberately) no event/wait mechanisms.
2000-01-03 23:55:30 +00:00
atiop->tag_action = MSG_ORDERED_Q_TAG;
break;
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
case ATIO2_TC_ATTR_ACAQ: /* ?? */
Make a static chain of isp softcs- gdb usage becomes a lot easier. Add in a very large amount of target mode support code- this is just a first pass at this. It's a difficult thing because some of the code can be in platform independent areas (see isp_target.?) but a lot has to be in platform dependent areas because of not only the tight coupling of received commands/events and the specific OS subsystem but because the platform independent code has (deliberately) no event/wait mechanisms.
2000-01-03 23:55:30 +00:00
case ATIO2_TC_ATTR_UNTAGGED:
default:
atiop->tag_action = 0;
break;
}
Add a isp_target_putback_atio- we aren't using CCINCR at this time, so we need a function that tells the Qlogic f/w that a target mode command is done, so increase the resource count for that lun. Add in a timeout function to kick the putback again if we fail to do it the first time (we may not have the request queue space for ATIO push). Split the function isp_handle_platform_ctio into two parts so that the timeout function for the ATIO push or isp_handle_platform_ctio can inform CAM that the requested CTIO(s) are now done. Clean up (cough) residual handling. What we need for Fibre Channel is to preserve the at_datalen field from the original incoming ATIO so we can calculate a 'true' residual. Unfortunately, we're not guaranteed to get that back from CAM. We'll *try* to find it hiding in the periph_priv field (layering violation)- but if an ATIO was passed in from user land- forget it. This means that we'll probably get residuals wrong for Fibre Channel commands we're completing with an error. It's too late to 4.1 release to fix this- too bad. Luckily the only device we'd really care about this occurring on is a tape device and they're still so rare as FC attached devices that this can be considered an untested combination anyway. Remove all CCINCR usage (resource autoreplenish). When we've proved to ourself that things are working properly, we can add it back in. Make sure we propage 'suggested' sense data from the incoming ATIO into the created system ATIO- and set sense_len appropriately. Correctly propagate tag values. Fall back to the model of generating (well, the functions in isp_pci.c do the work) multiple CTIOs based upon what we get from XPT. Instead of being able to pair Qlogic generated ATIOs with CAM ATIOs, and then to pair CAM CTIOs with Qlogic CTIOs, we have to take the CTIO passed to us from XPT, and if it implies that we have to generate extra Qlogic CTIOs, so be it. This means that we have to wait until the last CTIO in a sequence we generated completes before calling xpt_done. Executive summary- target mode actually now pretty much works well enough to tell folks about.
2000-07-18 06:58:28 +00:00
Begin to implement target mode that for Fibre Channel has a private per-command component that we *don't* try and pass thru CAM. CAM just is too risky and too much of a pain- structures get copied, but not all info of interest can be considered safely transported thru all consumers (including user space) from the incoming ATIO to the outgoing CTIO- it's just much safer to have a buddy structure, identified by the command's tag which *does* make it thru safely. Pay attention to link speed and report 200MB/s xfer speed for a 23XX card in 2GPs mode. MFC after: 1 week
2001-10-01 03:48:42 +00:00
atp->orig_datalen = aep->at_datalen;
atp->bytes_xfered = 0;
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
atp->lun = lun;
Switch initiator IDs in target mode to the same address space as target IDs in initiator mode -- index in port database instead of handlers. This makes initiator IDs persist across role changes and firmware resets, when handlers previously assigned by firmware are lost and reused. Sponsored by: iXsystems, Inc.
2015-07-13 21:01:24 +00:00
atp->nphdl = nphdl;
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
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;
Add support for ISP_FC_GETHINFO, which returns current connection topology, speed, loopid, WWPN/WWNN, etc. Beef up target mode. Add isp_handle_platform_notify_scsi and isp_handle_platform_notify_fc platform handlers to handle immediate notifies (isp_handle_platform_notify_scsi is still stubbed out). In implementation of isp_handle_platform_notify_fc, for IN_ABORT_TASK, peel off a pending XPT_IMMED_NOTIFY and call xpt_done on it and hope that somebody upstream is listening. Make sure on final CTIO2s that we set residual correctly. These are absolutely crucial. Make sure we set relative offset for each CTIO2 based upon bytes we've already xferred. This is what the private adjunct datat to the original ATIO is. Note state of command so we can figure out where to find it if we get an ABORT from the firmware. Make sure we *always* set CAM_TAG_ACTION_VALID for ATIO2s. Make sure we keep track of the original lun. If se sent status (or we're otherwise done with the command), don't forget to free the adjunct structure.
2002-06-16 05:08:02 +00:00
atp->state = ATPD_STATE_CAM;
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
xpt_done((union ccb *)atiop);
Adjust various SCSI drivers to handle either a 32-bit or 64-bit lun_id_t, mostly by adjustments to debugging printf() format specifiers. For high numbered LUNs, also switch to printing them in hex as per SAM-5. MFC after: 2 weeks
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);
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
return;
noresrc:
Fix multiple problems around LUN disable under load. - Move private data about ATIOs/INOTs from per-LUN to per-channel data. This allows active commands to continue operation after LUN destruction. This also simplifies lookup of the data by tag in some situations. - Unify three restart_queue processing implementations. - Complete all ATIOs from restart_queue on LUN disable. - Delete ATIO private data when command completed or aborted, not depending on the ATIO being requeued, that was ugly hack and could never happen. CAM should always call ether XPT_CONT_TARGET_IO with status or XPT_ABORT. - Implement XPT_ABORT for queued ATIOs/INOTs to allow CAM do graceful shutdown, not depending on LUN disable, as it is done in ahd(4)/targ(4). - Unify isp_endcmd() arguments to make it more usable in generic code. - Remove never really used LUN state reference counter. MFC after: 2 weeks
2017-02-22 06:43:49 +00:00
ntp = isp_get_ntpd(isp, 0);
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
if (ntp == NULL) {
Fix multiple problems around LUN disable under load. - Move private data about ATIOs/INOTs from per-LUN to per-channel data. This allows active commands to continue operation after LUN destruction. This also simplifies lookup of the data by tag in some situations. - Unify three restart_queue processing implementations. - Complete all ATIOs from restart_queue on LUN disable. - Delete ATIO private data when command completed or aborted, not depending on the ATIO being requeued, that was ugly hack and could never happen. CAM should always call ether XPT_CONT_TARGET_IO with status or XPT_ABORT. - Implement XPT_ABORT for queued ATIOs/INOTs to allow CAM do graceful shutdown, not depending on LUN disable, as it is done in ahd(4)/targ(4). - Unify isp_endcmd() arguments to make it more usable in generic code. - Remove never really used LUN state reference counter. MFC after: 2 weeks
2017-02-22 06:43:49 +00:00
isp_endcmd(isp, aep, nphdl, 0, SCSI_STATUS_BUSY, 0);
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
return;
}
Fix multiple problems around LUN disable under load. - Move private data about ATIOs/INOTs from per-LUN to per-channel data. This allows active commands to continue operation after LUN destruction. This also simplifies lookup of the data by tag in some situations. - Unify three restart_queue processing implementations. - Complete all ATIOs from restart_queue on LUN disable. - Delete ATIO private data when command completed or aborted, not depending on the ATIO being requeued, that was ugly hack and could never happen. CAM should always call ether XPT_CONT_TARGET_IO with status or XPT_ABORT. - Implement XPT_ABORT for queued ATIOs/INOTs to allow CAM do graceful shutdown, not depending on LUN disable, as it is done in ahd(4)/targ(4). - Unify isp_endcmd() arguments to make it more usable in generic code. - Remove never really used LUN state reference counter. MFC after: 2 weeks
2017-02-22 06:43:49 +00:00
memcpy(ntp->data, aep, QENTRY_LEN);
STAILQ_INSERT_TAIL(&tptr->restart_queue, ntp, next);
Make a static chain of isp softcs- gdb usage becomes a lot easier. Add in a very large amount of target mode support code- this is just a first pass at this. It's a difficult thing because some of the code can be in platform independent areas (see isp_target.?) but a lot has to be in platform dependent areas because of not only the tight coupling of received commands/events and the specific OS subsystem but because the platform independent code has (deliberately) no event/wait mechanisms.
2000-01-03 23:55:30 +00:00
}
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
static void
isp_handle_platform_atio7(ispsoftc_t *isp, at7_entry_t *aep)
Make a static chain of isp softcs- gdb usage becomes a lot easier. Add in a very large amount of target mode support code- this is just a first pass at this. It's a difficult thing because some of the code can be in platform independent areas (see isp_target.?) but a lot has to be in platform dependent areas because of not only the tight coupling of received commands/events and the specific OS subsystem but because the platform independent code has (deliberately) no event/wait mechanisms.
2000-01-03 23:55:30 +00:00
{
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
int cdbxlen;
Add PIM_EXTLUNS support to isp(4) driver. Now 24xx and above chips support full 8-byte LUN address space. Older FC chips may support up to 16K LUNs when firmware allows. Tested in both initiator and target modes for 23xx, 24xx and 25xx.
2015-10-24 17:34:40 +00:00
lun_id_t lun;
uint16_t chan, nphdl = NIL_HANDLE;
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
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;
Clean up multi-id mode so it's driven by the f/w loaded, not by some hint setting. Do more preparations for FC-Tape. Clean up resource counting for 24XX or later chipsets so we find out after EXEC_FIRMWARE what is actually supported. Set target mode exchange count based upon whether or not we are supporting simultaneous target/initiator mode. Clean up some old (pre-24XX) xfwoption and zfwoption issues. Sponsored by: Spectralogic MFC after: 3 days
2012-06-24 17:30:54 +00:00
atio_private_data_t *oatp;
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
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];
Add PIM_EXTLUNS support to isp(4) driver. Now 24xx and above chips support full 8-byte LUN address space. Older FC chips may support up to 16K LUNs when firmware allows. Tested in both initiator and target modes for 23xx, 24xx and 25xx.
2015-10-24 17:34:40 +00:00
lun = CAM_EXTLUN_BYTE_SWIZZLE(be64dec(aep->at_cmnd.fcp_cmnd_lun));
Make a static chain of isp softcs- gdb usage becomes a lot easier. Add in a very large amount of target mode support code- this is just a first pass at this. It's a difficult thing because some of the code can be in platform independent areas (see isp_target.?) but a lot has to be in platform dependent areas because of not only the tight coupling of received commands/events and the specific OS subsystem but because the platform independent code has (deliberately) no event/wait mechanisms.
2000-01-03 23:55:30 +00:00
MULTI_ID supported does not mean it is used.
2015-07-15 12:04:12 +00:00
if (ISP_CAP_MULTI_ID(isp) && isp->isp_nchan > 1) {
Remove hackish code delaying ATIOs to unknown virtual port. Since we support RQSTYPE_RPT_ID_ACQ, that functionality is only useful in loop mode, which probably doesn't worth having this hack in 2017. MFC after: 2 weeks
2017-03-19 13:46:11 +00:00
/* Channel has to be derived from D_ID */
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
isp_find_chan_by_did(isp, did, &chan);
if (chan == ISP_NOCHAN) {
Remove hackish code delaying ATIOs to unknown virtual port. Since we support RQSTYPE_RPT_ID_ACQ, that functionality is only useful in loop mode, which probably doesn't worth having this hack in 2017. MFC after: 2 weeks
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;
Add support for ISP_FC_GETHINFO, which returns current connection topology, speed, loopid, WWPN/WWNN, etc. Beef up target mode. Add isp_handle_platform_notify_scsi and isp_handle_platform_notify_fc platform handlers to handle immediate notifies (isp_handle_platform_notify_scsi is still stubbed out). In implementation of isp_handle_platform_notify_fc, for IN_ABORT_TASK, peel off a pending XPT_IMMED_NOTIFY and call xpt_done on it and hope that somebody upstream is listening. Make sure on final CTIO2s that we set residual correctly. These are absolutely crucial. Make sure we set relative offset for each CTIO2 based upon bytes we've already xferred. This is what the private adjunct datat to the original ATIO is. Note state of command so we can figure out where to find it if we get an ABORT from the firmware. Make sure we *always* set CAM_TAG_ACTION_VALID for ATIO2s. Make sure we keep track of the original lun. If se sent status (or we're otherwise done with the command), don't forget to free the adjunct structure.
2002-06-16 05:08:02 +00:00
}
Make a static chain of isp softcs- gdb usage becomes a lot easier. Add in a very large amount of target mode support code- this is just a first pass at this. It's a difficult thing because some of the code can be in platform independent areas (see isp_target.?) but a lot has to be in platform dependent areas because of not only the tight coupling of received commands/events and the specific OS subsystem but because the platform independent code has (deliberately) no event/wait mechanisms.
2000-01-03 23:55:30 +00:00
} else {
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
chan = 0;
}
/*
* Find the PDB entry for this initiator
*/
Another round of port scanner rewrite. This change simplifies and unifies port adding/updating for loop and fabric scanners. It also fixes problems with scanning restarts due to concurrent port databases changes. It also fixes many cosmetic issues.
2015-11-19 17:43:47 +00:00
if (isp_find_pdb_by_portid(isp, chan, sid, &lp) == 0) {
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
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);
Unify port database use for target and initiator roles. Aside from cleaner and more consistent code, this allows ports to be both target and initiator same time, and easily switch from any role to any. Sponsored by: iXsystems, Inc.
2015-07-13 15:11:05 +00:00
isp_dump_portdb(isp, chan);
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
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) {
Add PIM_EXTLUNS support to isp(4) driver. Now 24xx and above chips support full 8-byte LUN address space. Older FC chips may support up to 16K LUNs when firmware allows. Tested in both initiator and target modes for 23xx, 24xx and 25xx.
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) {
Add proper reporting for early task management errors. This covers unknown requests and requests to unknown virtual ports. Previously it "worked" only because of timeout handling on initiator.
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);
}
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
return;
}
}
/*
* Start any commands pending resources first.
*/
Fix multiple problems around LUN disable under load. - Move private data about ATIOs/INOTs from per-LUN to per-channel data. This allows active commands to continue operation after LUN destruction. This also simplifies lookup of the data by tag in some situations. - Unify three restart_queue processing implementations. - Complete all ATIOs from restart_queue on LUN disable. - Delete ATIO private data when command completed or aborted, not depending on the ATIO being requeued, that was ugly hack and could never happen. CAM should always call ether XPT_CONT_TARGET_IO with status or XPT_ABORT. - Implement XPT_ABORT for queued ATIOs/INOTs to allow CAM do graceful shutdown, not depending on LUN disable, as it is done in ahd(4)/targ(4). - Unify isp_endcmd() arguments to make it more usable in generic code. - Remove never really used LUN state reference counter. MFC after: 2 weeks
2017-02-22 06:43:49 +00:00
if (isp_atio_restart(isp, chan, tptr))
goto noresrc;
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
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;
}
Fix multiple problems around LUN disable under load. - Move private data about ATIOs/INOTs from per-LUN to per-channel data. This allows active commands to continue operation after LUN destruction. This also simplifies lookup of the data by tag in some situations. - Unify three restart_queue processing implementations. - Complete all ATIOs from restart_queue on LUN disable. - Delete ATIO private data when command completed or aborted, not depending on the ATIO being requeued, that was ugly hack and could never happen. CAM should always call ether XPT_CONT_TARGET_IO with status or XPT_ABORT. - Implement XPT_ABORT for queued ATIOs/INOTs to allow CAM do graceful shutdown, not depending on LUN disable, as it is done in ahd(4)/targ(4). - Unify isp_endcmd() arguments to make it more usable in generic code. - Remove never really used LUN state reference counter. MFC after: 2 weeks
2017-02-22 06:43:49 +00:00
oatp = isp_find_atpd(isp, chan, aep->at_rxid);
Clean up multi-id mode so it's driven by the f/w loaded, not by some hint setting. Do more preparations for FC-Tape. Clean up resource counting for 24XX or later chipsets so we find out after EXEC_FIRMWARE what is actually supported. Set target mode exchange count based upon whether or not we are supporting simultaneous target/initiator mode. Clean up some old (pre-24XX) xfwoption and zfwoption issues. Sponsored by: Spectralogic MFC after: 3 days
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",
Clean up multi-id mode so it's driven by the f/w loaded, not by some hint setting. Do more preparations for FC-Tape. Clean up resource counting for 24XX or later chipsets so we find out after EXEC_FIRMWARE what is actually supported. Set target mode exchange count based upon whether or not we are supporting simultaneous target/initiator mode. Clean up some old (pre-24XX) xfwoption and zfwoption issues. Sponsored by: Spectralogic MFC after: 3 days
2012-06-24 17:30:54 +00:00
aep->at_rxid, nphdl, sid, aep->at_hdr.ox_id, oatp->state);
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
/*
* It's not a "no resource" condition- but we can treat it like one
*/
goto noresrc;
}
Fix multiple problems around LUN disable under load. - Move private data about ATIOs/INOTs from per-LUN to per-channel data. This allows active commands to continue operation after LUN destruction. This also simplifies lookup of the data by tag in some situations. - Unify three restart_queue processing implementations. - Complete all ATIOs from restart_queue on LUN disable. - Delete ATIO private data when command completed or aborted, not depending on the ATIO being requeued, that was ugly hack and could never happen. CAM should always call ether XPT_CONT_TARGET_IO with status or XPT_ABORT. - Implement XPT_ABORT for queued ATIOs/INOTs to allow CAM do graceful shutdown, not depending on LUN disable, as it is done in ahd(4)/targ(4). - Unify isp_endcmd() arguments to make it more usable in generic code. - Remove never really used LUN state reference counter. MFC after: 2 weeks
2017-02-22 06:43:49 +00:00
atp = isp_get_atpd(isp, chan, aep->at_rxid);
Optimize isp(4) to reduce CPU usage, especially in target mode: - Remove two excessive and slow register reads from isp_intr(). Instead of rereading value every time, assume that registers contain what we have written there. - Avoid sequential search through 4096 array elements when looking for command tag. Use hash of lists to store active tags separately from free ones and so greatly speedup the searches. Reviewed by: mjacob
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;
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
atp->state = ATPD_STATE_ATIO;
SLIST_REMOVE_HEAD(&tptr->atios, sim_links.sle);
Remove not very useful ATIO/INOT stats. While there polish respective debug logging. MFC after: 2 weeks
2017-03-15 19:49:45 +00:00
ISP_PATH_PRT(isp, ISP_LOGTDEBUG2, atiop->ccb_h.path, "Take FREE ATIO\n");
Switch initiator IDs in target mode to the same address space as target IDs in initiator mode -- index in port database instead of handlers. This makes initiator IDs persist across role changes and firmware resets, when handlers previously assigned by firmware are lost and reused. Sponsored by: iXsystems, Inc.
2015-07-13 21:01:24 +00:00
atiop->init_id = FC_PORTDB_TGT(isp, chan, lp);
Polish target_id/target_lun setting for ATIOs/INOTs. For ATIOs it is pointless to report isp_loopid to CAM, since in other places it operates with port database record IDs, not with loop IDs. For INOTs target_id/target_lun seems were never set, so wildcard INOTs probably were not working correctly when LUN IDs were important.
2017-06-30 06:10:18 +00:00
atiop->ccb_h.target_id = ISP_MAX_TARGETS(isp);
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
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:
Partial MFproject/camlock r256671: Fix several target mode SIMs to not blindly clear ccb_h.flags field of ATIO CCBs. Not all CCB flags there belong to them.
2013-10-21 06:04:39 +00:00
atiop->ccb_h.flags |= CAM_TAG_ACTION_VALID;
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
atiop->tag_action = MSG_SIMPLE_Q_TAG;
break;
case FCP_CMND_TASK_ATTR_HEAD:
Partial MFproject/camlock r256671: Fix several target mode SIMs to not blindly clear ccb_h.flags field of ATIO CCBs. Not all CCB flags there belong to them.
2013-10-21 06:04:39 +00:00
atiop->ccb_h.flags |= CAM_TAG_ACTION_VALID;
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
atiop->tag_action = MSG_HEAD_OF_Q_TAG;
break;
case FCP_CMND_TASK_ATTR_ORDERED:
Partial MFproject/camlock r256671: Fix several target mode SIMs to not blindly clear ccb_h.flags field of ATIO CCBs. Not all CCB flags there belong to them.
2013-10-21 06:04:39 +00:00
atiop->ccb_h.flags |= CAM_TAG_ACTION_VALID;
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
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;
}
Introduce support of SCSI Command Priority. SAM-3 specification introduced concept of Task Priority, that was renamed to Command Priority in SAM-4, and supported by all modern SCSI transports. It provides 15 levels of relative priorities: 1 - highest, 15 - lowest and 0 - default. SAT specification for SATA devices translates priorities 1-3 into NCQ high priority. This change adds new "priority" field into empty spots of struct ccb_scsiio and struct ccb_accept_tio of CAM and struct ctl_scsiio of CTL. Respective support is added into iscsi(4), isp(4), mpr(4), mps(4) and ocs_fc(4) drivers for both initiator and where applicable target roles. Minimal support was added to CTL to receive the priority value from different frontends, pass it between HA controllers and report in few places. This patch does not add consumers of this functionality, so nothing should really change yet, since the field is still set to 0 (default) on initiator and not actively used on target. Those are to be implemented separately. I've confirmed priority working on WD Red SATA disks connected via mpr(4) and properly transferred to CTL target via iscsi(4), isp(4) and ocs_fc(4). While there, added missing tag_action support to ocs_fc(4) initiator role. MFC after: 1 month Relnotes: yes Sponsored by: iXsystems, Inc.
2020-10-25 19:34:02 +00:00
atiop->priority = (aep->at_cmnd.fcp_cmnd_task_attribute &
FCP_CMND_PRIO_MASK) >> FCP_CMND_PRIO_SHIFT;
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
atp->orig_datalen = aep->at_cmnd.cdb_dl.sf.fcp_cmnd_dl;
atp->bytes_xfered = 0;
atp->lun = lun;
atp->nphdl = nphdl;
Send TERMINATE to firmware when aborting active ATIO. MFC after: 2 weeks
2017-02-27 08:20:28 +00:00
atp->sid = sid;
atp->did = did;
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
atp->oxid = aep->at_hdr.ox_id;
Clean up multi-id mode so it's driven by the f/w loaded, not by some hint setting. Do more preparations for FC-Tape. Clean up resource counting for 24XX or later chipsets so we find out after EXEC_FIRMWARE what is actually supported. Set target mode exchange count based upon whether or not we are supporting simultaneous target/initiator mode. Clean up some old (pre-24XX) xfwoption and zfwoption issues. Sponsored by: Spectralogic MFC after: 3 days
2012-06-24 17:30:54 +00:00
atp->rxid = aep->at_hdr.rx_id;
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
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;
Add PIM_EXTLUNS support to isp(4) driver. Now 24xx and above chips support full 8-byte LUN address space. Older FC chips may support up to 16K LUNs when firmware allows. Tested in both initiator and target modes for 23xx, 24xx and 25xx.
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);
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
xpt_done((union ccb *)atiop);
return;
noresrc:
Fix multiple problems around LUN disable under load. - Move private data about ATIOs/INOTs from per-LUN to per-channel data. This allows active commands to continue operation after LUN destruction. This also simplifies lookup of the data by tag in some situations. - Unify three restart_queue processing implementations. - Complete all ATIOs from restart_queue on LUN disable. - Delete ATIO private data when command completed or aborted, not depending on the ATIO being requeued, that was ugly hack and could never happen. CAM should always call ether XPT_CONT_TARGET_IO with status or XPT_ABORT. - Implement XPT_ABORT for queued ATIOs/INOTs to allow CAM do graceful shutdown, not depending on LUN disable, as it is done in ahd(4)/targ(4). - Unify isp_endcmd() arguments to make it more usable in generic code. - Remove never really used LUN state reference counter. MFC after: 2 weeks
2017-02-22 06:43:49 +00:00
if (atp)
isp_put_atpd(isp, chan, atp);
ntp = isp_get_ntpd(isp, chan);
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
if (ntp == NULL) {
isp_endcmd(isp, aep, nphdl, chan, SCSI_STATUS_BUSY, 0);
return;
}
Fix multiple problems around LUN disable under load. - Move private data about ATIOs/INOTs from per-LUN to per-channel data. This allows active commands to continue operation after LUN destruction. This also simplifies lookup of the data by tag in some situations. - Unify three restart_queue processing implementations. - Complete all ATIOs from restart_queue on LUN disable. - Delete ATIO private data when command completed or aborted, not depending on the ATIO being requeued, that was ugly hack and could never happen. CAM should always call ether XPT_CONT_TARGET_IO with status or XPT_ABORT. - Implement XPT_ABORT for queued ATIOs/INOTs to allow CAM do graceful shutdown, not depending on LUN disable, as it is done in ahd(4)/targ(4). - Unify isp_endcmd() arguments to make it more usable in generic code. - Remove never really used LUN state reference counter. MFC after: 2 weeks
2017-02-22 06:43:49 +00:00
memcpy(ntp->data, aep, QENTRY_LEN);
STAILQ_INSERT_TAIL(&tptr->restart_queue, ntp, next);
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
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
Fix multiple problems around LUN disable under load. - Move private data about ATIOs/INOTs from per-LUN to per-channel data. This allows active commands to continue operation after LUN destruction. This also simplifies lookup of the data by tag in some situations. - Unify three restart_queue processing implementations. - Complete all ATIOs from restart_queue on LUN disable. - Delete ATIO private data when command completed or aborted, not depending on the ATIO being requeued, that was ugly hack and could never happen. CAM should always call ether XPT_CONT_TARGET_IO with status or XPT_ABORT. - Implement XPT_ABORT for queued ATIOs/INOTs to allow CAM do graceful shutdown, not depending on LUN disable, as it is done in ahd(4)/targ(4). - Unify isp_endcmd() arguments to make it more usable in generic code. - Remove never really used LUN state reference counter. MFC after: 2 weeks
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) {
More rototilling with target mode in an attemp to get multiple CCB at a time outstanding reliable. It's not there yet, but this is the direction to go in so might as well commit. So far, multiple at a time CCBs work (see ISP_INTERNAL_TARGET test mode), but it fails if there are more downstream than the SIM wants to handle and SRR is sort of confused when this happens, plus it is not entirely quite clear what one does if a CCB/CTIO fails and you have more in flight (that don't fail, say) and more queued up at the SIM level that haven't been started yet. Some of this is driven because there apparently is no flow control to requeue XPT_CONTINUE_IO requests like there are for XPT_SCSI_IO requests. It is also more driven in that the few target mode periph drivers there are are not really set up for handling pushback- heck most of them don't even check for errors (and what would they really do with them anyway? It's the initiator's problem, really....). The data transfer arithmetic has been worked over again to handle multiple outstanding commands, so you have a notion of what's been moved already as well as what's currently in flight. It turns that this led to uncovering a REPORT_LUNS bug in the ISP_INTERNAL_TARGET code which was sending back 24 bytes of rpl data instead of the specified 16. What happened furthermore here is that sending back 16 bytes and reporting an overrun of 8 bytes made the initiator (running FC-Tape aware f/w) mad enough to request, and keep requesting, another FCP response (I guess it didn't like the answer so kept asking for it again). Sponsored by: Spectralogic MFC after: 1 month
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) {
More rototilling with target mode in an attemp to get multiple CCB at a time outstanding reliable. It's not there yet, but this is the direction to go in so might as well commit. So far, multiple at a time CCBs work (see ISP_INTERNAL_TARGET test mode), but it fails if there are more downstream than the SIM wants to handle and SRR is sort of confused when this happens, plus it is not entirely quite clear what one does if a CCB/CTIO fails and you have more in flight (that don't fail, say) and more queued up at the SIM level that haven't been started yet. Some of this is driven because there apparently is no flow control to requeue XPT_CONTINUE_IO requests like there are for XPT_SCSI_IO requests. It is also more driven in that the few target mode periph drivers there are are not really set up for handling pushback- heck most of them don't even check for errors (and what would they really do with them anyway? It's the initiator's problem, really....). The data transfer arithmetic has been worked over again to handle multiple outstanding commands, so you have a notion of what's been moved already as well as what's currently in flight. It turns that this led to uncovering a REPORT_LUNS bug in the ISP_INTERNAL_TARGET code which was sending back 24 bytes of rpl data instead of the specified 16. What happened furthermore here is that sending back 16 bytes and reporting an overrun of 8 bytes made the initiator (running FC-Tape aware f/w) mad enough to request, and keep requesting, another FCP response (I guess it didn't like the answer so kept asking for it again). Sponsored by: Spectralogic MFC after: 1 month
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) {
More rototilling with target mode in an attemp to get multiple CCB at a time outstanding reliable. It's not there yet, but this is the direction to go in so might as well commit. So far, multiple at a time CCBs work (see ISP_INTERNAL_TARGET test mode), but it fails if there are more downstream than the SIM wants to handle and SRR is sort of confused when this happens, plus it is not entirely quite clear what one does if a CCB/CTIO fails and you have more in flight (that don't fail, say) and more queued up at the SIM level that haven't been started yet. Some of this is driven because there apparently is no flow control to requeue XPT_CONTINUE_IO requests like there are for XPT_SCSI_IO requests. It is also more driven in that the few target mode periph drivers there are are not really set up for handling pushback- heck most of them don't even check for errors (and what would they really do with them anyway? It's the initiator's problem, really....). The data transfer arithmetic has been worked over again to handle multiple outstanding commands, so you have a notion of what's been moved already as well as what's currently in flight. It turns that this led to uncovering a REPORT_LUNS bug in the ISP_INTERNAL_TARGET code which was sending back 24 bytes of rpl data instead of the specified 16. What happened furthermore here is that sending back 16 bytes and reporting an overrun of 8 bytes made the initiator (running FC-Tape aware f/w) mad enough to request, and keep requesting, another FCP response (I guess it didn't like the answer so kept asking for it again). Sponsored by: Spectralogic MFC after: 1 month
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;
}
More rototilling with target mode in an attemp to get multiple CCB at a time outstanding reliable. It's not there yet, but this is the direction to go in so might as well commit. So far, multiple at a time CCBs work (see ISP_INTERNAL_TARGET test mode), but it fails if there are more downstream than the SIM wants to handle and SRR is sort of confused when this happens, plus it is not entirely quite clear what one does if a CCB/CTIO fails and you have more in flight (that don't fail, say) and more queued up at the SIM level that haven't been started yet. Some of this is driven because there apparently is no flow control to requeue XPT_CONTINUE_IO requests like there are for XPT_SCSI_IO requests. It is also more driven in that the few target mode periph drivers there are are not really set up for handling pushback- heck most of them don't even check for errors (and what would they really do with them anyway? It's the initiator's problem, really....). The data transfer arithmetic has been worked over again to handle multiple outstanding commands, so you have a notion of what's been moved already as well as what's currently in flight. It turns that this led to uncovering a REPORT_LUNS bug in the ISP_INTERNAL_TARGET code which was sending back 24 bytes of rpl data instead of the specified 16. What happened furthermore here is that sending back 16 bytes and reporting an overrun of 8 bytes made the initiator (running FC-Tape aware f/w) mad enough to request, and keep requesting, another FCP response (I guess it didn't like the answer so kept asking for it again). Sponsored by: Spectralogic MFC after: 1 month
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:
More rototilling with target mode in an attemp to get multiple CCB at a time outstanding reliable. It's not there yet, but this is the direction to go in so might as well commit. So far, multiple at a time CCBs work (see ISP_INTERNAL_TARGET test mode), but it fails if there are more downstream than the SIM wants to handle and SRR is sort of confused when this happens, plus it is not entirely quite clear what one does if a CCB/CTIO fails and you have more in flight (that don't fail, say) and more queued up at the SIM level that haven't been started yet. Some of this is driven because there apparently is no flow control to requeue XPT_CONTINUE_IO requests like there are for XPT_SCSI_IO requests. It is also more driven in that the few target mode periph drivers there are are not really set up for handling pushback- heck most of them don't even check for errors (and what would they really do with them anyway? It's the initiator's problem, really....). The data transfer arithmetic has been worked over again to handle multiple outstanding commands, so you have a notion of what's been moved already as well as what's currently in flight. It turns that this led to uncovering a REPORT_LUNS bug in the ISP_INTERNAL_TARGET code which was sending back 24 bytes of rpl data instead of the specified 16. What happened furthermore here is that sending back 16 bytes and reporting an overrun of 8 bytes made the initiator (running FC-Tape aware f/w) mad enough to request, and keep requesting, another FCP response (I guess it didn't like the answer so kept asking for it again). Sponsored by: Spectralogic MFC after: 1 month
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
Move 24xx RQSTYPE_NOTIFY handling to generic code. This code has nothing to do with specific platform. MFC after: 2 weeks
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
{
Move 24xx RQSTYPE_NOTIFY handling to generic code. This code has nothing to do with specific platform. MFC after: 2 weeks
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;
Move 24xx RQSTYPE_NOTIFY handling to generic code. This code has nothing to do with specific platform. MFC after: 2 weeks
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
Move 24xx RQSTYPE_NOTIFY handling to generic code. This code has nothing to do with specific platform. MFC after: 2 weeks
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) {
Move 24xx RQSTYPE_NOTIFY handling to generic code. This code has nothing to do with specific platform. MFC after: 2 weeks
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));
Move 24xx RQSTYPE_NOTIFY handling to generic code. This code has nothing to do with specific platform. MFC after: 2 weeks
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)
Fix multiple problems around LUN disable under load. - Move private data about ATIOs/INOTs from per-LUN to per-channel data. This allows active commands to continue operation after LUN destruction. This also simplifies lookup of the data by tag in some situations. - Unify three restart_queue processing implementations. - Complete all ATIOs from restart_queue on LUN disable. - Delete ATIO private data when command completed or aborted, not depending on the ATIO being requeued, that was ugly hack and could never happen. CAM should always call ether XPT_CONT_TARGET_IO with status or XPT_ABORT. - Implement XPT_ABORT for queued ATIOs/INOTs to allow CAM do graceful shutdown, not depending on LUN disable, as it is done in ahd(4)/targ(4). - Unify isp_endcmd() arguments to make it more usable in generic code. - Remove never really used LUN state reference counter. MFC after: 2 weeks
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
}
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
static void
isp_handle_platform_ctio(ispsoftc_t *isp, void *arg)
{
union ccb *ccb;
Fix residual length reporting in target mode. This allows to properly handle cases when target wants to receive or send more data then initiator wants to send or receive. Previously in such cases isp(4) returned CAM_DATA_RUN_ERR, while now it returns resid > 0. MFC after: 2 weeks
2017-02-26 12:52:44 +00:00
int sentstatus = 0, ok = 0, notify_cam = 0, failure = 0;
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
atio_private_data_t *atp = NULL;
int bus;
Fix residual length reporting in target mode. This allows to properly handle cases when target wants to receive or send more data then initiator wants to send or receive. Previously in such cases isp(4) returned CAM_DATA_RUN_ERR, while now it returns resid > 0. MFC after: 2 weeks
2017-02-26 12:52:44 +00:00
uint32_t handle, data_requested, resid;
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
Rip off target mode support for parallel SCSI QLogic adapters. Hacks to enable target mode there complicated code, while didn't really work. And for outdated hardware fixing it is not really interesting. Initiator mode tested with Qlogic 1080 adapter is still working fine.
2015-11-23 10:06:19 +00:00
handle = ((ct2_entry_t *)arg)->ct_syshandle;
Unify handles allocation for initiator and target IOCBs. I am not sure why this was split long ago, but I see no reason for it. At this point this unification just slightly reduces memory usage, but as next step I plan to reuse shared handle space for other IOCB types.
2015-12-25 13:03:18 +00:00
ccb = isp_find_xs(isp, handle);
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
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;
}
Unify handles allocation for initiator and target IOCBs. I am not sure why this was split long ago, but I see no reason for it. At this point this unification just slightly reduces memory usage, but as next step I plan to reuse shared handle space for other IOCB types.
2015-12-25 13:03:18 +00:00
isp_destroy_handle(isp, handle);
Fix residual length reporting in target mode. This allows to properly handle cases when target wants to receive or send more data then initiator wants to send or receive. Previously in such cases isp(4) returned CAM_DATA_RUN_ERR, while now it returns resid > 0. MFC after: 2 weeks
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);
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
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)) {
Fix multiple problems around LUN disable under load. - Move private data about ATIOs/INOTs from per-LUN to per-channel data. This allows active commands to continue operation after LUN destruction. This also simplifies lookup of the data by tag in some situations. - Unify three restart_queue processing implementations. - Complete all ATIOs from restart_queue on LUN disable. - Delete ATIO private data when command completed or aborted, not depending on the ATIO being requeued, that was ugly hack and could never happen. CAM should always call ether XPT_CONT_TARGET_IO with status or XPT_ABORT. - Implement XPT_ABORT for queued ATIOs/INOTs to allow CAM do graceful shutdown, not depending on LUN disable, as it is done in ahd(4)/targ(4). - Unify isp_endcmd() arguments to make it more usable in generic code. - Remove never really used LUN state reference counter. MFC after: 2 weeks
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 {
Fix multiple problems around LUN disable under load. - Move private data about ATIOs/INOTs from per-LUN to per-channel data. This allows active commands to continue operation after LUN destruction. This also simplifies lookup of the data by tag in some situations. - Unify three restart_queue processing implementations. - Complete all ATIOs from restart_queue on LUN disable. - Delete ATIO private data when command completed or aborted, not depending on the ATIO being requeued, that was ugly hack and could never happen. CAM should always call ether XPT_CONT_TARGET_IO with status or XPT_ABORT. - Implement XPT_ABORT for queued ATIOs/INOTs to allow CAM do graceful shutdown, not depending on LUN disable, as it is done in ahd(4)/targ(4). - Unify isp_endcmd() arguments to make it more usable in generic code. - Remove never really used LUN state reference counter. MFC after: 2 weeks
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
}
In case of target mode disable at least ISP2532 return invalid zero ct_rxid value on CTIO completion. Try to workaround that using tag_id from the CCB, pointed by still valid ct_syshandle. I don't know whether this is valid fix or dirty hack, but considering that alternative is indefinitely stuck command -- it worth trying. MFC after: 1 week
2015-06-18 07:50:27 +00:00
if (atp == NULL) {
/*
Change comment added in r284540. This appeared to be not card's issue, but driver's, though solution is the same so far.
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.
In case of target mode disable at least ISP2532 return invalid zero ct_rxid value on CTIO completion. Try to workaround that using tag_id from the CCB, pointed by still valid ct_syshandle. I don't know whether this is valid fix or dirty hack, but considering that alternative is indefinitely stuck command -- it worth trying. MFC after: 1 week
2015-06-18 07:50:27 +00:00
*/
Fix multiple problems around LUN disable under load. - Move private data about ATIOs/INOTs from per-LUN to per-channel data. This allows active commands to continue operation after LUN destruction. This also simplifies lookup of the data by tag in some situations. - Unify three restart_queue processing implementations. - Complete all ATIOs from restart_queue on LUN disable. - Delete ATIO private data when command completed or aborted, not depending on the ATIO being requeued, that was ugly hack and could never happen. CAM should always call ether XPT_CONT_TARGET_IO with status or XPT_ABORT. - Implement XPT_ABORT for queued ATIOs/INOTs to allow CAM do graceful shutdown, not depending on LUN disable, as it is done in ahd(4)/targ(4). - Unify isp_endcmd() arguments to make it more usable in generic code. - Remove never really used LUN state reference counter. MFC after: 2 weeks
2017-02-22 06:43:49 +00:00
atp = isp_find_atpd(isp, bus, ccb->csio.tag_id);
In case of target mode disable at least ISP2532 return invalid zero ct_rxid value on CTIO completion. Try to workaround that using tag_id from the CCB, pointed by still valid ct_syshandle. I don't know whether this is valid fix or dirty hack, but considering that alternative is indefinitely stuck command -- it worth trying. MFC after: 1 week
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"));
More rototilling with target mode in an attemp to get multiple CCB at a time outstanding reliable. It's not there yet, but this is the direction to go in so might as well commit. So far, multiple at a time CCBs work (see ISP_INTERNAL_TARGET test mode), but it fails if there are more downstream than the SIM wants to handle and SRR is sort of confused when this happens, plus it is not entirely quite clear what one does if a CCB/CTIO fails and you have more in flight (that don't fail, say) and more queued up at the SIM level that haven't been started yet. Some of this is driven because there apparently is no flow control to requeue XPT_CONTINUE_IO requests like there are for XPT_SCSI_IO requests. It is also more driven in that the few target mode periph drivers there are are not really set up for handling pushback- heck most of them don't even check for errors (and what would they really do with them anyway? It's the initiator's problem, really....). The data transfer arithmetic has been worked over again to handle multiple outstanding commands, so you have a notion of what's been moved already as well as what's currently in flight. It turns that this led to uncovering a REPORT_LUNS bug in the ISP_INTERNAL_TARGET code which was sending back 24 bytes of rpl data instead of the specified 16. What happened furthermore here is that sending back 16 bytes and reporting an overrun of 8 bytes made the initiator (running FC-Tape aware f/w) mad enough to request, and keep requesting, another FCP response (I guess it didn't like the answer so kept asking for it again). Sponsored by: Spectralogic MFC after: 1 month
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;
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
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)
Fix multiple problems around LUN disable under load. - Move private data about ATIOs/INOTs from per-LUN to per-channel data. This allows active commands to continue operation after LUN destruction. This also simplifies lookup of the data by tag in some situations. - Unify three restart_queue processing implementations. - Complete all ATIOs from restart_queue on LUN disable. - Delete ATIO private data when command completed or aborted, not depending on the ATIO being requeued, that was ugly hack and could never happen. CAM should always call ether XPT_CONT_TARGET_IO with status or XPT_ABORT. - Implement XPT_ABORT for queued ATIOs/INOTs to allow CAM do graceful shutdown, not depending on LUN disable, as it is done in ahd(4)/targ(4). - Unify isp_endcmd() arguments to make it more usable in generic code. - Remove never really used LUN state reference counter. MFC after: 2 weeks
2017-02-22 06:43:49 +00:00
isp_handle_srr_start(isp, atp);
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
return;
}
if (ct->ct_nphdl == CT_HBA_RESET) {
Respecting r314204 tighten ATIO cleanup requirements. Every ATIO must complete with either successfully sent status or XPT_ABORT. MFC after: 2 weeks
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);
More rototilling with target mode in an attemp to get multiple CCB at a time outstanding reliable. It's not there yet, but this is the direction to go in so might as well commit. So far, multiple at a time CCBs work (see ISP_INTERNAL_TARGET test mode), but it fails if there are more downstream than the SIM wants to handle and SRR is sort of confused when this happens, plus it is not entirely quite clear what one does if a CCB/CTIO fails and you have more in flight (that don't fail, say) and more queued up at the SIM level that haven't been started yet. Some of this is driven because there apparently is no flow control to requeue XPT_CONTINUE_IO requests like there are for XPT_SCSI_IO requests. It is also more driven in that the few target mode periph drivers there are are not really set up for handling pushback- heck most of them don't even check for errors (and what would they really do with them anyway? It's the initiator's problem, really....). The data transfer arithmetic has been worked over again to handle multiple outstanding commands, so you have a notion of what's been moved already as well as what's currently in flight. It turns that this led to uncovering a REPORT_LUNS bug in the ISP_INTERNAL_TARGET code which was sending back 24 bytes of rpl data instead of the specified 16. What happened furthermore here is that sending back 16 bytes and reporting an overrun of 8 bytes made the initiator (running FC-Tape aware f/w) mad enough to request, and keep requesting, another FCP response (I guess it didn't like the answer so kept asking for it again). Sponsored by: Spectralogic MFC after: 1 month
2012-08-08 18:24:33 +00:00
notify_cam = (ct->ct_header.rqs_seqno & ATPD_SEQ_NOTIFY_CAM) != 0;
Fix residual length reporting in target mode. This allows to properly handle cases when target wants to receive or send more data then initiator wants to send or receive. Previously in such cases isp(4) returned CAM_DATA_RUN_ERR, while now it returns resid > 0. MFC after: 2 weeks
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;
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
}
More rototilling with target mode in an attemp to get multiple CCB at a time outstanding reliable. It's not there yet, but this is the direction to go in so might as well commit. So far, multiple at a time CCBs work (see ISP_INTERNAL_TARGET test mode), but it fails if there are more downstream than the SIM wants to handle and SRR is sort of confused when this happens, plus it is not entirely quite clear what one does if a CCB/CTIO fails and you have more in flight (that don't fail, say) and more queued up at the SIM level that haven't been started yet. Some of this is driven because there apparently is no flow control to requeue XPT_CONTINUE_IO requests like there are for XPT_SCSI_IO requests. It is also more driven in that the few target mode periph drivers there are are not really set up for handling pushback- heck most of them don't even check for errors (and what would they really do with them anyway? It's the initiator's problem, really....). The data transfer arithmetic has been worked over again to handle multiple outstanding commands, so you have a notion of what's been moved already as well as what's currently in flight. It turns that this led to uncovering a REPORT_LUNS bug in the ISP_INTERNAL_TARGET code which was sending back 24 bytes of rpl data instead of the specified 16. What happened furthermore here is that sending back 16 bytes and reporting an overrun of 8 bytes made the initiator (running FC-Tape aware f/w) mad enough to request, and keep requesting, another FCP response (I guess it didn't like the answer so kept asking for it again). Sponsored by: Spectralogic MFC after: 1 month
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");
Rip off target mode support for parallel SCSI QLogic adapters. Hacks to enable target mode there complicated code, while didn't really work. And for outdated hardware fixing it is not really interesting. Initiator mode tested with Qlogic 1080 adapter is still working fine.
2015-11-23 10:06:19 +00:00
} else {
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
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)
Fix multiple problems around LUN disable under load. - Move private data about ATIOs/INOTs from per-LUN to per-channel data. This allows active commands to continue operation after LUN destruction. This also simplifies lookup of the data by tag in some situations. - Unify three restart_queue processing implementations. - Complete all ATIOs from restart_queue on LUN disable. - Delete ATIO private data when command completed or aborted, not depending on the ATIO being requeued, that was ugly hack and could never happen. CAM should always call ether XPT_CONT_TARGET_IO with status or XPT_ABORT. - Implement XPT_ABORT for queued ATIOs/INOTs to allow CAM do graceful shutdown, not depending on LUN disable, as it is done in ahd(4)/targ(4). - Unify isp_endcmd() arguments to make it more usable in generic code. - Remove never really used LUN state reference counter. MFC after: 2 weeks
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);
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
return;
}
if (ct->ct_status == CT_HBA_RESET) {
Respecting r314204 tighten ATIO cleanup requirements. Every ATIO must complete with either successfully sent status or XPT_ABORT. MFC after: 2 weeks
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;
More rototilling with target mode in an attemp to get multiple CCB at a time outstanding reliable. It's not there yet, but this is the direction to go in so might as well commit. So far, multiple at a time CCBs work (see ISP_INTERNAL_TARGET test mode), but it fails if there are more downstream than the SIM wants to handle and SRR is sort of confused when this happens, plus it is not entirely quite clear what one does if a CCB/CTIO fails and you have more in flight (that don't fail, say) and more queued up at the SIM level that haven't been started yet. Some of this is driven because there apparently is no flow control to requeue XPT_CONTINUE_IO requests like there are for XPT_SCSI_IO requests. It is also more driven in that the few target mode periph drivers there are are not really set up for handling pushback- heck most of them don't even check for errors (and what would they really do with them anyway? It's the initiator's problem, really....). The data transfer arithmetic has been worked over again to handle multiple outstanding commands, so you have a notion of what's been moved already as well as what's currently in flight. It turns that this led to uncovering a REPORT_LUNS bug in the ISP_INTERNAL_TARGET code which was sending back 24 bytes of rpl data instead of the specified 16. What happened furthermore here is that sending back 16 bytes and reporting an overrun of 8 bytes made the initiator (running FC-Tape aware f/w) mad enough to request, and keep requesting, another FCP response (I guess it didn't like the answer so kept asking for it again). Sponsored by: Spectralogic MFC after: 1 month
2012-08-08 18:24:33 +00:00
notify_cam = (ct->ct_header.rqs_seqno & ATPD_SEQ_NOTIFY_CAM) != 0;
Fix residual length reporting in target mode. This allows to properly handle cases when target wants to receive or send more data then initiator wants to send or receive. Previously in such cases isp(4) returned CAM_DATA_RUN_ERR, while now it returns resid > 0. MFC after: 2 weeks
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;
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
}
More rototilling with target mode in an attemp to get multiple CCB at a time outstanding reliable. It's not there yet, but this is the direction to go in so might as well commit. So far, multiple at a time CCBs work (see ISP_INTERNAL_TARGET test mode), but it fails if there are more downstream than the SIM wants to handle and SRR is sort of confused when this happens, plus it is not entirely quite clear what one does if a CCB/CTIO fails and you have more in flight (that don't fail, say) and more queued up at the SIM level that haven't been started yet. Some of this is driven because there apparently is no flow control to requeue XPT_CONTINUE_IO requests like there are for XPT_SCSI_IO requests. It is also more driven in that the few target mode periph drivers there are are not really set up for handling pushback- heck most of them don't even check for errors (and what would they really do with them anyway? It's the initiator's problem, really....). The data transfer arithmetic has been worked over again to handle multiple outstanding commands, so you have a notion of what's been moved already as well as what's currently in flight. It turns that this led to uncovering a REPORT_LUNS bug in the ISP_INTERNAL_TARGET code which was sending back 24 bytes of rpl data instead of the specified 16. What happened furthermore here is that sending back 16 bytes and reporting an overrun of 8 bytes made the initiator (running FC-Tape aware f/w) mad enough to request, and keep requesting, another FCP response (I guess it didn't like the answer so kept asking for it again). Sponsored by: Spectralogic MFC after: 1 month
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");
Make a static chain of isp softcs- gdb usage becomes a lot easier. Add in a very large amount of target mode support code- this is just a first pass at this. It's a difficult thing because some of the code can be in platform independent areas (see isp_target.?) but a lot has to be in platform dependent areas because of not only the tight coupling of received commands/events and the specific OS subsystem but because the platform independent code has (deliberately) no event/wait mechanisms.
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) {
Fix residual length reporting in target mode. This allows to properly handle cases when target wants to receive or send more data then initiator wants to send or receive. Previously in such cases isp(4) returned CAM_DATA_RUN_ERR, while now it returns resid > 0. MFC after: 2 weeks
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
}
Fix residual length reporting in target mode. This allows to properly handle cases when target wants to receive or send more data then initiator wants to send or receive. Previously in such cases isp(4) returned CAM_DATA_RUN_ERR, while now it returns resid > 0. MFC after: 2 weeks
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;
Make a static chain of isp softcs- gdb usage becomes a lot easier. Add in a very large amount of target mode support code- this is just a first pass at this. It's a difficult thing because some of the code can be in platform independent areas (see isp_target.?) but a lot has to be in platform dependent areas because of not only the tight coupling of received commands/events and the specific OS subsystem but because the platform independent code has (deliberately) no event/wait mechanisms.
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.
Make a static chain of isp softcs- gdb usage becomes a lot easier. Add in a very large amount of target mode support code- this is just a first pass at this. It's a difficult thing because some of the code can be in platform independent areas (see isp_target.?) but a lot has to be in platform dependent areas because of not only the tight coupling of received commands/events and the specific OS subsystem but because the platform independent code has (deliberately) no event/wait mechanisms.
2000-01-03 23:55:30 +00:00
*/
More rototilling with target mode in an attemp to get multiple CCB at a time outstanding reliable. It's not there yet, but this is the direction to go in so might as well commit. So far, multiple at a time CCBs work (see ISP_INTERNAL_TARGET test mode), but it fails if there are more downstream than the SIM wants to handle and SRR is sort of confused when this happens, plus it is not entirely quite clear what one does if a CCB/CTIO fails and you have more in flight (that don't fail, say) and more queued up at the SIM level that haven't been started yet. Some of this is driven because there apparently is no flow control to requeue XPT_CONTINUE_IO requests like there are for XPT_SCSI_IO requests. It is also more driven in that the few target mode periph drivers there are are not really set up for handling pushback- heck most of them don't even check for errors (and what would they really do with them anyway? It's the initiator's problem, really....). The data transfer arithmetic has been worked over again to handle multiple outstanding commands, so you have a notion of what's been moved already as well as what's currently in flight. It turns that this led to uncovering a REPORT_LUNS bug in the ISP_INTERNAL_TARGET code which was sending back 24 bytes of rpl data instead of the specified 16. What happened furthermore here is that sending back 16 bytes and reporting an overrun of 8 bytes made the initiator (running FC-Tape aware f/w) mad enough to request, and keep requesting, another FCP response (I guess it didn't like the answer so kept asking for it again). Sponsored by: Spectralogic MFC after: 1 month
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);
Add a isp_target_putback_atio- we aren't using CCINCR at this time, so we need a function that tells the Qlogic f/w that a target mode command is done, so increase the resource count for that lun. Add in a timeout function to kick the putback again if we fail to do it the first time (we may not have the request queue space for ATIO push). Split the function isp_handle_platform_ctio into two parts so that the timeout function for the ATIO push or isp_handle_platform_ctio can inform CAM that the requested CTIO(s) are now done. Clean up (cough) residual handling. What we need for Fibre Channel is to preserve the at_datalen field from the original incoming ATIO so we can calculate a 'true' residual. Unfortunately, we're not guaranteed to get that back from CAM. We'll *try* to find it hiding in the periph_priv field (layering violation)- but if an ATIO was passed in from user land- forget it. This means that we'll probably get residuals wrong for Fibre Channel commands we're completing with an error. It's too late to 4.1 release to fix this- too bad. Luckily the only device we'd really care about this occurring on is a tape device and they're still so rare as FC attached devices that this can be considered an untested combination anyway. Remove all CCINCR usage (resource autoreplenish). When we've proved to ourself that things are working properly, we can add it back in. Make sure we propage 'suggested' sense data from the incoming ATIO into the created system ATIO- and set sense_len appropriately. Correctly propagate tag values. Fall back to the model of generating (well, the functions in isp_pci.c do the work) multiple CTIOs based upon what we get from XPT. Instead of being able to pair Qlogic generated ATIOs with CAM ATIOs, and then to pair CAM CTIOs with Qlogic CTIOs, we have to take the CTIO passed to us from XPT, and if it implies that we have to generate extra Qlogic CTIOs, so be it. This means that we have to wait until the last CTIO in a sequence we generated completes before calling xpt_done. Executive summary- target mode actually now pretty much works well enough to tell folks about.
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);
}
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
return;
Add a isp_target_putback_atio- we aren't using CCINCR at this time, so we need a function that tells the Qlogic f/w that a target mode command is done, so increase the resource count for that lun. Add in a timeout function to kick the putback again if we fail to do it the first time (we may not have the request queue space for ATIO push). Split the function isp_handle_platform_ctio into two parts so that the timeout function for the ATIO push or isp_handle_platform_ctio can inform CAM that the requested CTIO(s) are now done. Clean up (cough) residual handling. What we need for Fibre Channel is to preserve the at_datalen field from the original incoming ATIO so we can calculate a 'true' residual. Unfortunately, we're not guaranteed to get that back from CAM. We'll *try* to find it hiding in the periph_priv field (layering violation)- but if an ATIO was passed in from user land- forget it. This means that we'll probably get residuals wrong for Fibre Channel commands we're completing with an error. It's too late to 4.1 release to fix this- too bad. Luckily the only device we'd really care about this occurring on is a tape device and they're still so rare as FC attached devices that this can be considered an untested combination anyway. Remove all CCINCR usage (resource autoreplenish). When we've proved to ourself that things are working properly, we can add it back in. Make sure we propage 'suggested' sense data from the incoming ATIO into the created system ATIO- and set sense_len appropriately. Correctly propagate tag values. Fall back to the model of generating (well, the functions in isp_pci.c do the work) multiple CTIOs based upon what we get from XPT. Instead of being able to pair Qlogic generated ATIOs with CAM ATIOs, and then to pair CAM CTIOs with Qlogic CTIOs, we have to take the CTIO passed to us from XPT, and if it implies that we have to generate extra Qlogic CTIOs, so be it. This means that we have to wait until the last CTIO in a sequence we generated completes before calling xpt_done. Executive summary- target mode actually now pretty much works well enough to tell folks about.
2000-07-18 06:58:28 +00:00
}
Redo a lot of the target mode infrastructure to be cognizant of Dual Bus cards like the 1280 && the 12160. Cleanup isp_target_putback_atio. Make sure bus and correct tag ids and firmware handles get propagated as needed.
2001-04-04 21:58:29 +00:00
Fix multiple problems around LUN disable under load. - Move private data about ATIOs/INOTs from per-LUN to per-channel data. This allows active commands to continue operation after LUN destruction. This also simplifies lookup of the data by tag in some situations. - Unify three restart_queue processing implementations. - Complete all ATIOs from restart_queue on LUN disable. - Delete ATIO private data when command completed or aborted, not depending on the ATIO being requeued, that was ugly hack and could never happen. CAM should always call ether XPT_CONT_TARGET_IO with status or XPT_ABORT. - Implement XPT_ABORT for queued ATIOs/INOTs to allow CAM do graceful shutdown, not depending on LUN disable, as it is done in ahd(4)/targ(4). - Unify isp_endcmd() arguments to make it more usable in generic code. - Remove never really used LUN state reference counter. MFC after: 2 weeks
2017-02-22 06:43:49 +00:00
/*
Respecting r314204 tighten ATIO cleanup requirements. Every ATIO must complete with either successfully sent status or XPT_ABORT. MFC after: 2 weeks
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.
Fix multiple problems around LUN disable under load. - Move private data about ATIOs/INOTs from per-LUN to per-channel data. This allows active commands to continue operation after LUN destruction. This also simplifies lookup of the data by tag in some situations. - Unify three restart_queue processing implementations. - Complete all ATIOs from restart_queue on LUN disable. - Delete ATIO private data when command completed or aborted, not depending on the ATIO being requeued, that was ugly hack and could never happen. CAM should always call ether XPT_CONT_TARGET_IO with status or XPT_ABORT. - Implement XPT_ABORT for queued ATIOs/INOTs to allow CAM do graceful shutdown, not depending on LUN disable, as it is done in ahd(4)/targ(4). - Unify isp_endcmd() arguments to make it more usable in generic code. - Remove never really used LUN state reference counter. MFC after: 2 weeks
2017-02-22 06:43:49 +00:00
*/
Respecting r314204 tighten ATIO cleanup requirements. Every ATIO must complete with either successfully sent status or XPT_ABORT. MFC after: 2 weeks
2017-02-24 14:48:17 +00:00
if (ok && sentstatus)
Fix multiple problems around LUN disable under load. - Move private data about ATIOs/INOTs from per-LUN to per-channel data. This allows active commands to continue operation after LUN destruction. This also simplifies lookup of the data by tag in some situations. - Unify three restart_queue processing implementations. - Complete all ATIOs from restart_queue on LUN disable. - Delete ATIO private data when command completed or aborted, not depending on the ATIO being requeued, that was ugly hack and could never happen. CAM should always call ether XPT_CONT_TARGET_IO with status or XPT_ABORT. - Implement XPT_ABORT for queued ATIOs/INOTs to allow CAM do graceful shutdown, not depending on LUN disable, as it is done in ahd(4)/targ(4). - Unify isp_endcmd() arguments to make it more usable in generic code. - Remove never really used LUN state reference counter. MFC after: 2 weeks
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.
*
* 24XX 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)) {
Redo a lot of the target mode infrastructure to be cognizant of Dual Bus cards like the 1280 && the 12160. Cleanup isp_target_putback_atio. Make sure bus and correct tag ids and firmware handles get propagated as needed.
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);
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
}
}
static int
Pass task management response information from CTL through CAM to isp(4), utilizing previously unused arg field of struct ccb_notify_acknowledge. This makes new QUERY TASK, QUERY TASK SET and QUERY ASYNC EVENT requests really functional for CAM target mode drivers.
2016-05-20 10:26:12 +00:00
isp_handle_platform_target_notify_ack(ispsoftc_t *isp, isp_notify_t *mp, uint32_t rsp)
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
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];
Another round of port scanner rewrite. This change simplifies and unifies port adding/updating for loop and fabric scanners. It also fixes problems with scanning restarts due to concurrent port databases changes. It also fixes many cosmetic issues.
2015-11-19 17:43:47 +00:00
if (isp_find_pdb_by_portid(isp, mp->nt_channel, sid, &lp)) {
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
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;
Pass task management response information from CTL through CAM to isp(4), utilizing previously unused arg field of struct ccb_notify_acknowledge. This makes new QUERY TASK, QUERY TASK SET and QUERY ASYNC EVENT requests really functional for CAM target mode drivers.
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;
}
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
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
*/
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
return (isp_notify_ack(isp, mp->nt_lreserved));
}
return (0);
}
/*
Fix typos. PR: bin/148894 Submitted by: olgeni
2010-11-09 10:59:09 +00:00
* Handle task management functions.
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
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;
Move RQSTYPE_ABTS_RCVD parsing into generic code. MFC after: 2 weeks
2017-03-18 17:01:11 +00:00
atio_private_data_t *atp;
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
lun_id_t lun;
Extend nt_lun to full 8 byte. MFC after: 2 weeks
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,
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
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) {
Move RQSTYPE_ABTS_RCVD parsing into generic code. MFC after: 2 weeks
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;
}
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
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) {
Adjust various SCSI drivers to handle either a 32-bit or 64-bit lun_id_t, mostly by adjustments to debugging printf() format specifiers. For high numbered LUNs, also switch to printing them in hex as per SAM-5. MFC after: 2 weeks
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);
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
goto bad;
}
}
inot = (struct ccb_immediate_notify *) SLIST_FIRST(&tptr->inots);
if (inot == NULL) {
Adjust various SCSI drivers to handle either a 32-bit or 64-bit lun_id_t, mostly by adjustments to debugging printf() format specifiers. For high numbered LUNs, also switch to printing them in hex as per SAM-5. MFC after: 2 weeks
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);
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
goto bad;
}
Polish target_id/target_lun setting for ATIOs/INOTs. For ATIOs it is pointless to report isp_loopid to CAM, since in other places it operates with port database record IDs, not with loop IDs. For INOTs target_id/target_lun seems were never set, so wildcard INOTs probably were not working correctly when LUN IDs were important.
2017-06-30 06:10:18 +00:00
inot->ccb_h.target_id = ISP_MAX_TARGETS(isp);
inot->ccb_h.target_lun = lun;
Another round of port scanner rewrite. This change simplifies and unifies port adding/updating for loop and fabric scanners. It also fixes problems with scanning restarts due to concurrent port databases changes. It also fixes many cosmetic issues.
2015-11-19 17:43:47 +00:00
if (isp_find_pdb_by_portid(isp, notify->nt_channel, notify->nt_sid, &lp) == 0 &&
Switch initiator IDs in target mode to the same address space as target IDs in initiator mode -- index in port database instead of handlers. This makes initiator IDs persist across role changes and firmware resets, when handlers previously assigned by firmware are lost and reused. Sponsored by: iXsystems, Inc.
2015-07-13 21:01:24 +00:00
isp_find_pdb_by_handle(isp, notify->nt_channel, notify->nt_nphdl, &lp) == 0) {
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
inot->initiator_id = CAM_TARGET_WILDCARD;
} else {
Switch initiator IDs in target mode to the same address space as target IDs in initiator mode -- index in port database instead of handlers. This makes initiator IDs persist across role changes and firmware resets, when handlers previously assigned by firmware are lost and reused. Sponsored by: iXsystems, Inc.
2015-07-13 21:01:24 +00:00
inot->initiator_id = FC_PORTDB_TGT(isp, notify->nt_channel, lp);
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
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:
Fix multiple problems around LUN disable under load. - Move private data about ATIOs/INOTs from per-LUN to per-channel data. This allows active commands to continue operation after LUN destruction. This also simplifies lookup of the data by tag in some situations. - Unify three restart_queue processing implementations. - Complete all ATIOs from restart_queue on LUN disable. - Delete ATIO private data when command completed or aborted, not depending on the ATIO being requeued, that was ugly hack and could never happen. CAM should always call ether XPT_CONT_TARGET_IO with status or XPT_ABORT. - Implement XPT_ABORT for queued ATIOs/INOTs to allow CAM do graceful shutdown, not depending on LUN disable, as it is done in ahd(4)/targ(4). - Unify isp_endcmd() arguments to make it more usable in generic code. - Remove never really used LUN state reference counter. MFC after: 2 weeks
2017-02-22 06:43:49 +00:00
isp_target_mark_aborted_early(isp, notify->nt_channel, tptr, inot->tag_id);
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
inot->arg = MSG_ABORT_TASK;
break;
case NT_ABORT_TASK_SET:
Fix multiple problems around LUN disable under load. - Move private data about ATIOs/INOTs from per-LUN to per-channel data. This allows active commands to continue operation after LUN destruction. This also simplifies lookup of the data by tag in some situations. - Unify three restart_queue processing implementations. - Complete all ATIOs from restart_queue on LUN disable. - Delete ATIO private data when command completed or aborted, not depending on the ATIO being requeued, that was ugly hack and could never happen. CAM should always call ether XPT_CONT_TARGET_IO with status or XPT_ABORT. - Implement XPT_ABORT for queued ATIOs/INOTs to allow CAM do graceful shutdown, not depending on LUN disable, as it is done in ahd(4)/targ(4). - Unify isp_endcmd() arguments to make it more usable in generic code. - Remove never really used LUN state reference counter. MFC after: 2 weeks
2017-02-22 06:43:49 +00:00
isp_target_mark_aborted_early(isp, notify->nt_channel, tptr, TAG_ANY);
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
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;
Add partial support for QUERY TMF to CAM and isp(4). This change allows to decode respective functions in isp(4) in target mode and pass them through CAM to CTL. Unfortunately neither CAM nor isp(4) support returning response info for those task management functions now. On the other side I just have no initiator to test this functionality.
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;
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
default:
Adjust various SCSI drivers to handle either a 32-bit or 64-bit lun_id_t, mostly by adjustments to debugging printf() format specifiers. For high numbered LUNs, also switch to printing them in hex as per SAM-5. MFC after: 2 weeks
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);
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
goto bad;
}
Fix multiple problems around LUN disable under load. - Move private data about ATIOs/INOTs from per-LUN to per-channel data. This allows active commands to continue operation after LUN destruction. This also simplifies lookup of the data by tag in some situations. - Unify three restart_queue processing implementations. - Complete all ATIOs from restart_queue on LUN disable. - Delete ATIO private data when command completed or aborted, not depending on the ATIO being requeued, that was ugly hack and could never happen. CAM should always call ether XPT_CONT_TARGET_IO with status or XPT_ABORT. - Implement XPT_ABORT for queued ATIOs/INOTs to allow CAM do graceful shutdown, not depending on LUN disable, as it is done in ahd(4)/targ(4). - Unify isp_endcmd() arguments to make it more usable in generic code. - Remove never really used LUN state reference counter. MFC after: 2 weeks
2017-02-22 06:43:49 +00:00
ntp = isp_get_ntpd(isp, notify->nt_channel);
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
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;
}
Fix multiple problems around LUN disable under load. - Move private data about ATIOs/INOTs from per-LUN to per-channel data. This allows active commands to continue operation after LUN destruction. This also simplifies lookup of the data by tag in some situations. - Unify three restart_queue processing implementations. - Complete all ATIOs from restart_queue on LUN disable. - Delete ATIO private data when command completed or aborted, not depending on the ATIO being requeued, that was ugly hack and could never happen. CAM should always call ether XPT_CONT_TARGET_IO with status or XPT_ABORT. - Implement XPT_ABORT for queued ATIOs/INOTs to allow CAM do graceful shutdown, not depending on LUN disable, as it is done in ahd(4)/targ(4). - Unify isp_endcmd() arguments to make it more usable in generic code. - Remove never really used LUN state reference counter. MFC after: 2 weeks
2017-02-22 06:43:49 +00:00
ISP_MEMCPY(&ntp->nt, notify, sizeof (isp_notify_t));
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
if (notify->nt_lreserved) {
Fix multiple problems around LUN disable under load. - Move private data about ATIOs/INOTs from per-LUN to per-channel data. This allows active commands to continue operation after LUN destruction. This also simplifies lookup of the data by tag in some situations. - Unify three restart_queue processing implementations. - Complete all ATIOs from restart_queue on LUN disable. - Delete ATIO private data when command completed or aborted, not depending on the ATIO being requeued, that was ugly hack and could never happen. CAM should always call ether XPT_CONT_TARGET_IO with status or XPT_ABORT. - Implement XPT_ABORT for queued ATIOs/INOTs to allow CAM do graceful shutdown, not depending on LUN disable, as it is done in ahd(4)/targ(4). - Unify isp_endcmd() arguments to make it more usable in generic code. - Remove never really used LUN state reference counter. MFC after: 2 weeks
2017-02-22 06:43:49 +00:00
ISP_MEMCPY(&ntp->data, notify->nt_lreserved, QENTRY_LEN);
ntp->nt.nt_lreserved = &ntp->data;
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
}
Fix multiple problems around LUN disable under load. - Move private data about ATIOs/INOTs from per-LUN to per-channel data. This allows active commands to continue operation after LUN destruction. This also simplifies lookup of the data by tag in some situations. - Unify three restart_queue processing implementations. - Complete all ATIOs from restart_queue on LUN disable. - Delete ATIO private data when command completed or aborted, not depending on the ATIO being requeued, that was ugly hack and could never happen. CAM should always call ether XPT_CONT_TARGET_IO with status or XPT_ABORT. - Implement XPT_ABORT for queued ATIOs/INOTs to allow CAM do graceful shutdown, not depending on LUN disable, as it is done in ahd(4)/targ(4). - Unify isp_endcmd() arguments to make it more usable in generic code. - Remove never really used LUN state reference counter. MFC after: 2 weeks
2017-02-22 06:43:49 +00:00
ntp->seq_id = notify->nt_tagval;
ntp->tag_id = notify->nt_tagval >> 32;
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
SLIST_REMOVE_HEAD(&tptr->inots, sim_links.sle);
Remove not very useful ATIO/INOT stats. While there polish respective debug logging. MFC after: 2 weeks
2017-03-15 19:49:45 +00:00
ISP_PATH_PRT(isp, ISP_LOGTDEBUG2, inot->ccb_h.path, "Take FREE INOT\n");
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
inot->ccb_h.status = CAM_MESSAGE_RECV;
xpt_done((union ccb *)inot);
return;
bad:
Do some notify acks cleanup. ISPASYNC_TARGET_NOTIFY_ACK makes no sense without argument. MFC after: 2 weeks
2017-03-18 10:34:29 +00:00
if (notify->nt_need_ack) {
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
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");
}
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
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);
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
}
}
}
static void
Fix multiple problems around LUN disable under load. - Move private data about ATIOs/INOTs from per-LUN to per-channel data. This allows active commands to continue operation after LUN destruction. This also simplifies lookup of the data by tag in some situations. - Unify three restart_queue processing implementations. - Complete all ATIOs from restart_queue on LUN disable. - Delete ATIO private data when command completed or aborted, not depending on the ATIO being requeued, that was ugly hack and could never happen. CAM should always call ether XPT_CONT_TARGET_IO with status or XPT_ABORT. - Implement XPT_ABORT for queued ATIOs/INOTs to allow CAM do graceful shutdown, not depending on LUN disable, as it is done in ahd(4)/targ(4). - Unify isp_endcmd() arguments to make it more usable in generic code. - Remove never really used LUN state reference counter. MFC after: 2 weeks
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)
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
{
Fix multiple problems around LUN disable under load. - Move private data about ATIOs/INOTs from per-LUN to per-channel data. This allows active commands to continue operation after LUN destruction. This also simplifies lookup of the data by tag in some situations. - Unify three restart_queue processing implementations. - Complete all ATIOs from restart_queue on LUN disable. - Delete ATIO private data when command completed or aborted, not depending on the ATIO being requeued, that was ugly hack and could never happen. CAM should always call ether XPT_CONT_TARGET_IO with status or XPT_ABORT. - Implement XPT_ABORT for queued ATIOs/INOTs to allow CAM do graceful shutdown, not depending on LUN disable, as it is done in ahd(4)/targ(4). - Unify isp_endcmd() arguments to make it more usable in generic code. - Remove never really used LUN state reference counter. MFC after: 2 weeks
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;
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
/*
* First, clean any commands pending restart
*/
Fix multiple problems around LUN disable under load. - Move private data about ATIOs/INOTs from per-LUN to per-channel data. This allows active commands to continue operation after LUN destruction. This also simplifies lookup of the data by tag in some situations. - Unify three restart_queue processing implementations. - Complete all ATIOs from restart_queue on LUN disable. - Delete ATIO private data when command completed or aborted, not depending on the ATIO being requeued, that was ugly hack and could never happen. CAM should always call ether XPT_CONT_TARGET_IO with status or XPT_ABORT. - Implement XPT_ABORT for queued ATIOs/INOTs to allow CAM do graceful shutdown, not depending on LUN disable, as it is done in ahd(4)/targ(4). - Unify isp_endcmd() arguments to make it more usable in generic code. - Remove never really used LUN state reference counter. MFC after: 2 weeks
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;
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
if ((uint64_t)tag_id == TAG_ANY || tag_id == this_tag_id) {
Fix multiple problems around LUN disable under load. - Move private data about ATIOs/INOTs from per-LUN to per-channel data. This allows active commands to continue operation after LUN destruction. This also simplifies lookup of the data by tag in some situations. - Unify three restart_queue processing implementations. - Complete all ATIOs from restart_queue on LUN disable. - Delete ATIO private data when command completed or aborted, not depending on the ATIO being requeued, that was ugly hack and could never happen. CAM should always call ether XPT_CONT_TARGET_IO with status or XPT_ABORT. - Implement XPT_ABORT for queued ATIOs/INOTs to allow CAM do graceful shutdown, not depending on LUN disable, as it is done in ahd(4)/targ(4). - Unify isp_endcmd() arguments to make it more usable in generic code. - Remove never really used LUN state reference counter. MFC after: 2 weeks
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);
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
}
}
/*
* Now mark other ones dead as well.
*/
Fix multiple problems around LUN disable under load. - Move private data about ATIOs/INOTs from per-LUN to per-channel data. This allows active commands to continue operation after LUN destruction. This also simplifies lookup of the data by tag in some situations. - Unify three restart_queue processing implementations. - Complete all ATIOs from restart_queue on LUN disable. - Delete ATIO private data when command completed or aborted, not depending on the ATIO being requeued, that was ugly hack and could never happen. CAM should always call ether XPT_CONT_TARGET_IO with status or XPT_ABORT. - Implement XPT_ABORT for queued ATIOs/INOTs to allow CAM do graceful shutdown, not depending on LUN disable, as it is done in ahd(4)/targ(4). - Unify isp_endcmd() arguments to make it more usable in generic code. - Remove never really used LUN state reference counter. MFC after: 2 weeks
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)
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
atp->dead = 1;
}
}
Make a static chain of isp softcs- gdb usage becomes a lot easier. Add in a very large amount of target mode support code- this is just a first pass at this. It's a difficult thing because some of the code can be in platform independent areas (see isp_target.?) but a lot has to be in platform dependent areas because of not only the tight coupling of received commands/events and the specific OS subsystem but because the platform independent code has (deliberately) no event/wait mechanisms.
2000-01-03 23:55:30 +00:00
#endif
Update QLogic ISP support for CAM. Add preliminary target mode support. Submitted by: Matthew Jacob <mjacob@feral.com>
1998-09-15 08:42:56 +00:00
static void
a) clean up some declaration stuff (i.e., make more modern with respect to getting rid u_int for uint and so on). b) Turn back on 64 bit DAC support. Cheeze it a bit in that we have two DMA callback functions- one when we have bus_addr_t > 4 bits in width and the other which should be normal. Even Cheezier in that we turn off setting up DMA maps to be BUS_SPACE_MAXADDR if we're in ISP_TARGET_MODE. More work on this in a week or so. c) Tested under amd64 and 1MB DFLTPHYS, sparc64, i386 (PAE, but insufficient memory to really test > 4GB). LINT check under amd64. MFC after: 1 month
2006-02-15 00:31:48 +00:00
isp_cam_async(void *cbarg, uint32_t code, struct cam_path *path, void *arg)
Update QLogic ISP support for CAM. Add preliminary target mode support. Submitted by: Matthew Jacob <mjacob@feral.com>
1998-09-15 08:42:56 +00:00
{
struct cam_sim *sim;
Most of these changes to isp are to allow for isp.ko unloading. We also revive loop down freezes. We also externaliz within isp isp_prt_endcmd so something outside the core module can print something about a command completing. Also some work in progress to assist in handling timed out commands better. Partially Sponsored by: Panasas Approved by: re (kib) MFC after: 1 month
2011-08-13 23:34:17 +00:00
int bus, tgt;
Some more gratuitous format and name changes. Pull in some target mode changes from a private branch. Pull in some more RELENG_4 compilation changes. A lot of lines changed, but not much content change yet.
2006-04-21 18:30:01 +00:00
ispsoftc_t *isp;
Update QLogic ISP support for CAM. Add preliminary target mode support. Submitted by: Matthew Jacob <mjacob@feral.com>
1998-09-15 08:42:56 +00:00
sim = (struct cam_sim *)cbarg;
Some more gratuitous format and name changes. Pull in some target mode changes from a private branch. Pull in some more RELENG_4 compilation changes. A lot of lines changed, but not much content change yet.
2006-04-21 18:30:01 +00:00
isp = (ispsoftc_t *) cam_sim_softc(sim);
Most of these changes to isp are to allow for isp.ko unloading. We also revive loop down freezes. We also externaliz within isp isp_prt_endcmd so something outside the core module can print something about a command completing. Also some work in progress to assist in handling timed out commands better. Partially Sponsored by: Panasas Approved by: re (kib) MFC after: 1 month
2011-08-13 23:34:17 +00:00
bus = cam_sim_bus(sim);
tgt = xpt_path_target_id(path);
Update QLogic ISP support for CAM. Add preliminary target mode support. Submitted by: Matthew Jacob <mjacob@feral.com>
1998-09-15 08:42:56 +00:00
switch (code) {
case AC_LOST_DEVICE:
Add in isp_debug variable. It defaults to zero unless CAMDEBUG is defined where it defaults to one. Change simq width allocation to the max number of commands supported by the HBA after f/w fires up- not the constant MAXISPREQUEST value. Do some stylistic changes.
1999-10-17 18:50:47 +00:00
if (IS_SCSI(isp)) {
a) clean up some declaration stuff (i.e., make more modern with respect to getting rid u_int for uint and so on). b) Turn back on 64 bit DAC support. Cheeze it a bit in that we have two DMA callback functions- one when we have bus_addr_t > 4 bits in width and the other which should be normal. Even Cheezier in that we turn off setting up DMA maps to be BUS_SPACE_MAXADDR if we're in ISP_TARGET_MODE. More work on this in a week or so. c) Tested under amd64 and 1MB DFLTPHYS, sparc64, i386 (PAE, but insufficient memory to really test > 4GB). LINT check under amd64. MFC after: 1 month
2006-02-15 00:31:48 +00:00
uint16_t oflags, nflags;
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
sdparam *sdp = SDPARAM(isp, bus);
Update QLogic ISP support for CAM. Add preliminary target mode support. Submitted by: Matthew Jacob <mjacob@feral.com>
1998-09-15 08:42:56 +00:00
From PHK's flex tool- we can get -1 returned from xpt_path_target_id, so don't index off of it. MFC after: 1 day
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;
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
sdp->update = 1;
(void) isp_control(isp, ISPCTL_UPDATE_PARAMS, bus);
From PHK's flex tool- we can get -1 returned from xpt_path_target_id, so don't index off of it. MFC after: 1 day
2002-10-10 17:29:05 +00:00
sdp->isp_devparam[tgt].goal_flags = oflags;
}
Update QLogic ISP support for CAM. Add preliminary target mode support. Submitted by: Matthew Jacob <mjacob@feral.com>
1998-09-15 08:42:56 +00:00
}
break;
default:
Finally eliminate as many of the printf calls as possible (still leaving ones where we have a CAM path) and replacing them with calls to isp_prt., Eliminate isp_unit references- we no longer have an isp_unit- we now have an isp_dev that device_get_unit can work with.
2001-03-01 02:14:54 +00:00
isp_prt(isp, ISP_LOGWARN, "isp_cam_async: Code 0x%x", code);
Update QLogic ISP support for CAM. Add preliminary target mode support. Submitted by: Matthew Jacob <mjacob@feral.com>
1998-09-15 08:42:56 +00:00
break;
}
}
static void
clarify headers;move uninit to outer layer;remove watchdog
1998-12-28 19:22:27 +00:00
isp_poll(struct cam_sim *sim)
Update QLogic ISP support for CAM. Add preliminary target mode support. Submitted by: Matthew Jacob <mjacob@feral.com>
1998-09-15 08:42:56 +00:00
{
Some more gratuitous format and name changes. Pull in some target mode changes from a private branch. Pull in some more RELENG_4 compilation changes. A lot of lines changed, but not much content change yet.
2006-04-21 18:30:01 +00:00
ispsoftc_t *isp = cam_sim_softc(sim);
Add 2 Gigabit Fibre Channel support (2300 && 2312 cards). This required some reworking (and consequent cleanup) of the interrupt service code. Also begin to start a cleanup of target mode support that will (eventually) not require more inforamtion routed with the ATIO to come back with the CTIO other than tag. MFC after: 4 weeks
2001-08-31 21:39:04 +00:00
Refactor interrupt handling. Instead of single isp_intr() function doing all possible magic, introduce four different functions to handle mailbox operation completions, async events, response and ATIO queues. The goal is to isolate different code paths to make code more readable, and to make easier support for multiple interrupt vectors. Even oldest hardware in many cases can identify what code path it should run on interrupt. Contemporary hardware can assign them to different interrupt vectors. MFC after: 2 weeks
2017-03-15 14:58:29 +00:00
ISP_RUN_ISR(isp);
Update QLogic ISP support for CAM. Add preliminary target mode support. Submitted by: Matthew Jacob <mjacob@feral.com>
1998-09-15 08:42:56 +00:00
}
Add in isp_debug variable. It defaults to zero unless CAMDEBUG is defined where it defaults to one. Change simq width allocation to the max number of commands supported by the HBA after f/w fires up- not the constant MAXISPREQUEST value. Do some stylistic changes.
1999-10-17 18:50:47 +00:00
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
static void
isp_watchdog(void *arg)
Add in a watchdog routine to catch cases where we've dropped the command. Apparently the f/w has finished the command, but somehow an interrupt is being lost. So, we just plain wedge when booting alphas. This is a general routine we've needed for a while.
2000-05-09 01:08:21 +00:00
{
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
struct ccb_scsiio *xs = arg;
ispsoftc_t *isp;
Most of these changes to isp are to allow for isp.ko unloading. We also revive loop down freezes. We also externaliz within isp isp_prt_endcmd so something outside the core module can print something about a command completing. Also some work in progress to assist in handling timed out commands better. Partially Sponsored by: Panasas Approved by: re (kib) MFC after: 1 month
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
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
isp = XS_ISP(xs);
Add in a watchdog routine to catch cases where we've dropped the command. Apparently the f/w has finished the command, but somehow an interrupt is being lost. So, we just plain wedge when booting alphas. This is a general routine we've needed for a while.
2000-05-09 01:08:21 +00:00
handle = isp_find_handle(isp, xs);
Most of these changes to isp are to allow for isp.ko unloading. We also revive loop down freezes. We also externaliz within isp isp_prt_endcmd so something outside the core module can print something about a command completing. Also some work in progress to assist in handling timed out commands better. Partially Sponsored by: Panasas Approved by: re (kib) MFC after: 1 month
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) {
Refactor interrupt handling. Instead of single isp_intr() function doing all possible magic, introduce four different functions to handle mailbox operation completions, async events, response and ATIO queues. The goal is to isolate different code paths to make code more readable, and to make easier support for multiple interrupt vectors. Even oldest hardware in many cases can identify what code path it should run on interrupt. Contemporary hardware can assign them to different interrupt vectors. MFC after: 2 weeks
2017-03-15 14:58:29 +00:00
ISP_RUN_ISR(isp);
Most of these changes to isp are to allow for isp.ko unloading. We also revive loop down freezes. We also externaliz within isp isp_prt_endcmd so something outside the core module can print something about a command completing. Also some work in progress to assist in handling timed out commands better. Partially Sponsored by: Panasas Approved by: re (kib) MFC after: 1 month
2011-08-13 23:34:17 +00:00
ohandle = handle;
handle = isp_find_handle(isp, xs);
}
Redo how commands handles are created and managed and implement sequence numbers and handle types in rational way. This will better protect from (unwittingly) dealing with stale handles/commands. Fix the watchdog timeout code to better protect itself from mistakes. If we run an abort on a putatively timed out command, the command may in fact get completed, so check to make sure the command we're timing it out is still around. If the abort succeeds, btw, the command should get returned via a different path.
2010-02-03 21:09:32 +00:00
if (handle != ISP_HANDLE_FREE) {
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
/*
Redo how commands handles are created and managed and implement sequence numbers and handle types in rational way. This will better protect from (unwittingly) dealing with stale handles/commands. Fix the watchdog timeout code to better protect itself from mistakes. If we run an abort on a putatively timed out command, the command may in fact get completed, so check to make sure the command we're timing it out is still around. If the abort succeeds, btw, the command should get returned via a different path.
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.
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
*/
Redo how commands handles are created and managed and implement sequence numbers and handle types in rational way. This will better protect from (unwittingly) dealing with stale handles/commands. Fix the watchdog timeout code to better protect itself from mistakes. If we run an abort on a putatively timed out command, the command may in fact get completed, so check to make sure the command we're timing it out is still around. If the abort succeeds, btw, the command should get returned via a different path.
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;
}
Oops! If we're deciding a command is now really dead, make *darned* sure that it really is by issuing a ISPCTL_ABORT_CMD just on the off chance the f/w will start it up again and, ha ha, start using the DMA resources we gave it but are now taking away.
2000-07-05 06:44:17 +00:00
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
/*
Redo how commands handles are created and managed and implement sequence numbers and handle types in rational way. This will better protect from (unwittingly) dealing with stale handles/commands. Fix the watchdog timeout code to better protect itself from mistakes. If we run an abort on a putatively timed out command, the command may in fact get completed, so check to make sure the command we're timing it out is still around. If the abort succeeds, btw, the command should get returned via a different path.
2010-02-03 21:09:32 +00:00
* After this point, the command is really dead.
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
*/
if (XS_XFRLEN(xs)) {
ISP_DMAFREE(isp, xs, handle);
}
isp_destroy_handle(isp, handle);
Redo how commands handles are created and managed and implement sequence numbers and handle types in rational way. This will better protect from (unwittingly) dealing with stale handles/commands. Fix the watchdog timeout code to better protect itself from mistakes. If we run an abort on a putatively timed out command, the command may in fact get completed, so check to make sure the command we're timing it out is still around. If the abort succeeds, btw, the command should get returned via a different path.
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);
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
isp_done(xs);
Most of these changes to isp are to allow for isp.ko unloading. We also revive loop down freezes. We also externaliz within isp isp_prt_endcmd so something outside the core module can print something about a command completing. Also some work in progress to assist in handling timed out commands better. Partially Sponsored by: Panasas Approved by: re (kib) MFC after: 1 month
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__);
}
Push things closer to path failover by implementing loop down and gone device timers and zombie state entries. There are tunables that can be used to select a number of parameters. loop_down_limit - how long to wait for loop to come back up before declaring all devices dead (default 300 seconds) gone_device_time- how long to wait for a device that has appeared to leave the loop or fabric to reappear (default 30 seconds) Internal tunables include (which should be externalized): quick_boot_time- how long to wait when booting for loop to come up change_is_bad- whether or not to accept devices with the same WWNN/WWPN that reappear at a different PortID as being the 'same' device. Keen students of some of the subtle issues here will ask how one can keep devices from being re-accepted at all (the answer is to set a gone_device_time to zero- that effectively would be the same thing).
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)
Push things closer to path failover by implementing loop down and gone device timers and zombie state entries. There are tunables that can be used to select a number of parameters. loop_down_limit - how long to wait for loop to come back up before declaring all devices dead (default 300 seconds) gone_device_time- how long to wait for a device that has appeared to leave the loop or fabric to reappear (default 30 seconds) Internal tunables include (which should be externalized): quick_boot_time- how long to wait when booting for loop to come up change_is_bad- whether or not to accept devices with the same WWNN/WWPN that reappear at a different PortID as being the 'same' device. Keen students of some of the subtle issues here will ask how one can keep devices from being re-accepted at all (the answer is to set a gone_device_time to zero- that effectively would be the same thing).
2006-11-14 08:45:48 +00:00
{
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
union ccb *ccb;
struct isp_fc *fc = ISP_FC_PC(isp, chan);
Make this an MP safe driver but also still be multi-release. Seems to work on RELENG_4 through -current and also on sparc64 now. There may still be some issues with the auto attach/detach code to sort out. MFC after: 3 days
2007-05-05 20:17:23 +00:00
Use the new xpt_rescan function to truly now have dynamic attachment of new devices that arrive (and we notice them via async Fibre Channel events). We've always had the right thing (of sorts) happen when devices go away- this is the corollary function that makes multipath failover actually work. MFC after: 2 weeks
2007-02-23 05:51:57 +00:00
/*
Add a new primitive, XPT_SCAN_TGT, to cover the range between scanning a whole bus (XPT_SCAN_BUS) and a single lun on that bus (XPT_SCAN_LUN). It's less resource comsumptive than scanning a whole bus when the caller knows only one target has changes. Reviewed by: scsi@ Sponsored by: Panasas MFC after: 1 month
2010-05-26 22:49:42 +00:00
* Allocate a CCB, create a wildcard path for this target and schedule a rescan.
Use the new xpt_rescan function to truly now have dynamic attachment of new devices that arrive (and we notice them via async Fibre Channel events). We've always had the right thing (of sorts) happen when devices go away- this is the corollary function that makes multipath failover actually work. MFC after: 2 weeks
2007-02-23 05:51:57 +00:00
*/
Revert a driver API change to xpt_alloc_ccb that isn't necessary. Fix a couple of associated error checks.
2007-04-18 04:58:53 +00:00
ccb = xpt_alloc_ccb_nowait();
Use the new xpt_rescan function to truly now have dynamic attachment of new devices that arrive (and we notice them via async Fibre Channel events). We've always had the right thing (of sorts) happen when devices go away- this is the corollary function that makes multipath failover actually work. MFC after: 2 weeks
2007-02-23 05:51:57 +00:00
if (ccb == NULL) {
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
isp_prt(isp, ISP_LOGWARN, "Chan %d unable to alloc CCB for rescan", chan);
Use the new xpt_rescan function to truly now have dynamic attachment of new devices that arrive (and we notice them via async Fibre Channel events). We've always had the right thing (of sorts) happen when devices go away- this is the corollary function that makes multipath failover actually work. MFC after: 2 weeks
2007-02-23 05:51:57 +00:00
return;
}
MFprojects/camlock r248982: Stop abusing xpt_periph in random plases that really have no periph related to CCB, for example, bus scanning. NULL value is fine in such cases and it is correctly logged in debug messages as "noperiph". If at some point we need some real XPT periphs (alike to pmpX now), quite likely they will be per-bus, and not a single global instance as xpt_periph now.
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) {
Use the new xpt_rescan function to truly now have dynamic attachment of new devices that arrive (and we notice them via async Fibre Channel events). We've always had the right thing (of sorts) happen when devices go away- this is the corollary function that makes multipath failover actually work. MFC after: 2 weeks
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)
Use the new xpt_rescan function to truly now have dynamic attachment of new devices that arrive (and we notice them via async Fibre Channel events). We've always had the right thing (of sorts) happen when devices go away- this is the corollary function that makes multipath failover actually work. MFC after: 2 weeks
2007-02-23 05:51:57 +00:00
{
struct cam_path *tp;
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
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) {
Use the new xpt_rescan function to truly now have dynamic attachment of new devices that arrive (and we notice them via async Fibre Channel events). We've always had the right thing (of sorts) happen when devices go away- this is the corollary function that makes multipath failover actually work. MFC after: 2 weeks
2007-02-23 05:51:57 +00:00
xpt_async(AC_LOST_DEVICE, tp, NULL);
xpt_free_path(tp);
Push things closer to path failover by implementing loop down and gone device timers and zombie state entries. There are tunables that can be used to select a number of parameters. loop_down_limit - how long to wait for loop to come back up before declaring all devices dead (default 300 seconds) gone_device_time- how long to wait for a device that has appeared to leave the loop or fabric to reappear (default 30 seconds) Internal tunables include (which should be externalized): quick_boot_time- how long to wait when booting for loop to come up change_is_bad- whether or not to accept devices with the same WWNN/WWPN that reappear at a different PortID as being the 'same' device. Keen students of some of the subtle issues here will ask how one can keep devices from being re-accepted at all (the answer is to set a gone_device_time to zero- that effectively would be the same thing).
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)
Fixes zombie device and loop down timers so that they work more than once. Use taskqueues to do the actual work. Fix an offset line. Fix isp_prt so that prints from just one buffer, which makes it appear cleanly cleanly in logs on SMP systems. Approved by: re (kib) MFC after: 1 month
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)
Push things closer to path failover by implementing loop down and gone device timers and zombie state entries. There are tunables that can be used to select a number of parameters. loop_down_limit - how long to wait for loop to come back up before declaring all devices dead (default 300 seconds) gone_device_time- how long to wait for a device that has appeared to leave the loop or fabric to reappear (default 30 seconds) Internal tunables include (which should be externalized): quick_boot_time- how long to wait when booting for loop to come up change_is_bad- whether or not to accept devices with the same WWNN/WWPN that reappear at a different PortID as being the 'same' device. Keen students of some of the subtle issues here will ask how one can keep devices from being re-accepted at all (the answer is to set a gone_device_time to zero- that effectively would be the same thing).
2006-11-14 08:45:48 +00:00
{
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
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;
Push things closer to path failover by implementing loop down and gone device timers and zombie state entries. There are tunables that can be used to select a number of parameters. loop_down_limit - how long to wait for loop to come back up before declaring all devices dead (default 300 seconds) gone_device_time- how long to wait for a device that has appeared to leave the loop or fabric to reappear (default 30 seconds) Internal tunables include (which should be externalized): quick_boot_time- how long to wait when booting for loop to come up change_is_bad- whether or not to accept devices with the same WWNN/WWPN that reappear at a different PortID as being the 'same' device. Keen students of some of the subtle issues here will ask how one can keep devices from being re-accepted at all (the answer is to set a gone_device_time to zero- that effectively would be the same thing).
2006-11-14 08:45:48 +00:00
fcportdb_t *lp;
Unify port database use for target and initiator roles. Aside from cleaner and more consistent code, this allows ports to be both target and initiator same time, and easily switch from any role to any. Sponsored by: iXsystems, Inc.
2015-07-13 15:11:05 +00:00
struct ac_contract ac;
struct ac_device_changed *adc;
Remove extra level of target ID indirection (isp_dev_map). FreeBSD never had limitation on number of target IDs, and there is no any other requirement to allocate them densely. Since slots of port database already populated just sequentially, there is no much need for another indirection to allocate sequentially too.
2015-07-05 02:09:46 +00:00
int dbidx, more_to_do = 0;
Push things closer to path failover by implementing loop down and gone device timers and zombie state entries. There are tunables that can be used to select a number of parameters. loop_down_limit - how long to wait for loop to come back up before declaring all devices dead (default 300 seconds) gone_device_time- how long to wait for a device that has appeared to leave the loop or fabric to reappear (default 30 seconds) Internal tunables include (which should be externalized): quick_boot_time- how long to wait when booting for loop to come up change_is_bad- whether or not to accept devices with the same WWNN/WWPN that reappear at a different PortID as being the 'same' device. Keen students of some of the subtle issues here will ask how one can keep devices from being re-accepted at all (the answer is to set a gone_device_time to zero- that effectively would be the same thing).
2006-11-14 08:45:48 +00:00
Fixes zombie device and loop down timers so that they work more than once. Use taskqueues to do the actual work. Fix an offset line. Fix isp_prt so that prints from just one buffer, which makes it appear cleanly cleanly in logs on SMP systems. Approved by: re (kib) MFC after: 1 month
2011-08-12 19:51:28 +00:00
ISP_LOCK(isp);
isp_prt(isp, ISP_LOGDEBUG0, "Chan %d GDT timer expired", chan);
Push things closer to path failover by implementing loop down and gone device timers and zombie state entries. There are tunables that can be used to select a number of parameters. loop_down_limit - how long to wait for loop to come back up before declaring all devices dead (default 300 seconds) gone_device_time- how long to wait for a device that has appeared to leave the loop or fabric to reappear (default 30 seconds) Internal tunables include (which should be externalized): quick_boot_time- how long to wait when booting for loop to come up change_is_bad- whether or not to accept devices with the same WWNN/WWPN that reappear at a different PortID as being the 'same' device. Keen students of some of the subtle issues here will ask how one can keep devices from being re-accepted at all (the answer is to set a gone_device_time to zero- that effectively would be the same thing).
2006-11-14 08:45:48 +00:00
for (dbidx = 0; dbidx < MAX_FC_TARG; dbidx++) {
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
lp = &FCPARAM(isp, chan)->portdb[dbidx];
Push things closer to path failover by implementing loop down and gone device timers and zombie state entries. There are tunables that can be used to select a number of parameters. loop_down_limit - how long to wait for loop to come back up before declaring all devices dead (default 300 seconds) gone_device_time- how long to wait for a device that has appeared to leave the loop or fabric to reappear (default 30 seconds) Internal tunables include (which should be externalized): quick_boot_time- how long to wait when booting for loop to come up change_is_bad- whether or not to accept devices with the same WWNN/WWPN that reappear at a different PortID as being the 'same' device. Keen students of some of the subtle issues here will ask how one can keep devices from being re-accepted at all (the answer is to set a gone_device_time to zero- that effectively would be the same thing).
2006-11-14 08:45:48 +00:00
if (lp->state != FC_PORTDB_STATE_ZOMBIE) {
continue;
}
Whap. Hook up some wires that were forgotten a few months ago and restore the zombie device timeout code and the loop down time code and the fabric hysteresis code. MFC after: 1 week Sponsored By: Panasas
2010-05-15 20:26:10 +00:00
if (lp->gone_timer != 0) {
lp->gone_timer -= 1;
Push things closer to path failover by implementing loop down and gone device timers and zombie state entries. There are tunables that can be used to select a number of parameters. loop_down_limit - how long to wait for loop to come back up before declaring all devices dead (default 300 seconds) gone_device_time- how long to wait for a device that has appeared to leave the loop or fabric to reappear (default 30 seconds) Internal tunables include (which should be externalized): quick_boot_time- how long to wait when booting for loop to come up change_is_bad- whether or not to accept devices with the same WWNN/WWPN that reappear at a different PortID as being the 'same' device. Keen students of some of the subtle issues here will ask how one can keep devices from being re-accepted at all (the answer is to set a gone_device_time to zero- that effectively would be the same thing).
2006-11-14 08:45:48 +00:00
more_to_do++;
continue;
}
Unify port database use for target and initiator roles. Aside from cleaner and more consistent code, this allows ports to be both target and initiator same time, and easily switch from any role to any. Sponsored by: iXsystems, Inc.
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;
Switch initiator IDs in target mode to the same address space as target IDs in initiator mode -- index in port database instead of handlers. This makes initiator IDs persist across role changes and firmware resets, when handlers previously assigned by firmware are lost and reused. Sponsored by: iXsystems, Inc.
2015-07-13 21:01:24 +00:00
adc->target = dbidx;
Unify port database use for target and initiator roles. Aside from cleaner and more consistent code, this allows ports to be both target and initiator same time, and easily switch from any role to any. Sponsored by: iXsystems, Inc.
2015-07-13 15:11:05 +00:00
adc->arrived = 0;
xpt_async(AC_CONTRACT, fc->path, &ac);
}
Push things closer to path failover by implementing loop down and gone device timers and zombie state entries. There are tunables that can be used to select a number of parameters. loop_down_limit - how long to wait for loop to come back up before declaring all devices dead (default 300 seconds) gone_device_time- how long to wait for a device that has appeared to leave the loop or fabric to reappear (default 30 seconds) Internal tunables include (which should be externalized): quick_boot_time- how long to wait when booting for loop to come up change_is_bad- whether or not to accept devices with the same WWNN/WWPN that reappear at a different PortID as being the 'same' device. Keen students of some of the subtle issues here will ask how one can keep devices from being re-accepted at all (the answer is to set a gone_device_time to zero- that effectively would be the same thing).
2006-11-14 08:45:48 +00:00
lp->state = FC_PORTDB_STATE_NIL;
}
Fix cases where we've managed to get a Loop UP event prior to initializing the loop down counter, as well as other things. This was brought to my attention with a different fix, more for RELENG_7- this one covers the multiple channel case. PR: 140438 MFC after: 1 month
2009-12-04 03:34:12 +00:00
if (fc->ready) {
if (more_to_do) {
callout_reset(&fc->gdt, hz, isp_gdt, fc);
} else {
Fixes zombie device and loop down timers so that they work more than once. Use taskqueues to do the actual work. Fix an offset line. Fix isp_prt so that prints from just one buffer, which makes it appear cleanly cleanly in logs on SMP systems. Approved by: re (kib) MFC after: 1 month
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);
Fix cases where we've managed to get a Loop UP event prior to initializing the loop down counter, as well as other things. This was brought to my attention with a different fix, more for RELENG_7- this one covers the multiple channel case. PR: 140438 MFC after: 1 month
2009-12-04 03:34:12 +00:00
}
Add in a watchdog routine to catch cases where we've dropped the command. Apparently the f/w has finished the command, but somehow an interrupt is being lost. So, we just plain wedge when booting alphas. This is a general routine we've needed for a while.
2000-05-09 01:08:21 +00:00
}
Fixes zombie device and loop down timers so that they work more than once. Use taskqueues to do the actual work. Fix an offset line. Fix isp_prt so that prints from just one buffer, which makes it appear cleanly cleanly in logs on SMP systems. Approved by: re (kib) MFC after: 1 month
2011-08-12 19:51:28 +00:00
ISP_UNLOCK(isp);
Add in a watchdog routine to catch cases where we've dropped the command. Apparently the f/w has finished the command, but somehow an interrupt is being lost. So, we just plain wedge when booting alphas. This is a general routine we've needed for a while.
2000-05-09 01:08:21 +00:00
}
Push things closer to path failover by implementing loop down and gone device timers and zombie state entries. There are tunables that can be used to select a number of parameters. loop_down_limit - how long to wait for loop to come back up before declaring all devices dead (default 300 seconds) gone_device_time- how long to wait for a device that has appeared to leave the loop or fabric to reappear (default 30 seconds) Internal tunables include (which should be externalized): quick_boot_time- how long to wait when booting for loop to come up change_is_bad- whether or not to accept devices with the same WWNN/WWPN that reappear at a different PortID as being the 'same' device. Keen students of some of the subtle issues here will ask how one can keep devices from being re-accepted at all (the answer is to set a gone_device_time to zero- that effectively would be the same thing).
2006-11-14 08:45:48 +00:00
/*
One more round of port scanner rewrite. - Make scan aborted by event restart immediately and infinitely. - Improve handling of some loop events from firmware. - Remove loop down timer, adding its functionality to scanner thread. - Some more unification and simplification.
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.
*
Push things closer to path failover by implementing loop down and gone device timers and zombie state entries. There are tunables that can be used to select a number of parameters. loop_down_limit - how long to wait for loop to come back up before declaring all devices dead (default 300 seconds) gone_device_time- how long to wait for a device that has appeared to leave the loop or fabric to reappear (default 30 seconds) Internal tunables include (which should be externalized): quick_boot_time- how long to wait when booting for loop to come up change_is_bad- whether or not to accept devices with the same WWNN/WWPN that reappear at a different PortID as being the 'same' device. Keen students of some of the subtle issues here will ask how one can keep devices from being re-accepted at all (the answer is to set a gone_device_time to zero- that effectively would be the same thing).
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
One more round of port scanner rewrite. - Make scan aborted by event restart immediately and infinitely. - Improve handling of some loop events from firmware. - Remove loop down timer, adding its functionality to scanner thread. - Some more unification and simplification.
2015-11-26 13:04:58 +00:00
isp_loop_changed(ispsoftc_t *isp, int chan)
Fixes zombie device and loop down timers so that they work more than once. Use taskqueues to do the actual work. Fix an offset line. Fix isp_prt so that prints from just one buffer, which makes it appear cleanly cleanly in logs on SMP systems. Approved by: re (kib) MFC after: 1 month
2011-08-12 19:51:28 +00:00
{
One more round of port scanner rewrite. - Make scan aborted by event restart immediately and infinitely. - Improve handling of some loop events from firmware. - Remove loop down timer, adding its functionality to scanner thread. - Some more unification and simplification.
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);
Fixes zombie device and loop down timers so that they work more than once. Use taskqueues to do the actual work. Fix an offset line. Fix isp_prt so that prints from just one buffer, which makes it appear cleanly cleanly in logs on SMP systems. Approved by: re (kib) MFC after: 1 month
2011-08-12 19:51:28 +00:00
}
static void
One more round of port scanner rewrite. - Make scan aborted by event restart immediately and infinitely. - Improve handling of some loop events from firmware. - Remove loop down timer, adding its functionality to scanner thread. - Some more unification and simplification.
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
{
One more round of port scanner rewrite. - Make scan aborted by event restart immediately and infinitely. - Improve handling of some loop events from firmware. - Remove loop down timer, adding its functionality to scanner thread. - Some more unification and simplification.
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);
Push things closer to path failover by implementing loop down and gone device timers and zombie state entries. There are tunables that can be used to select a number of parameters. loop_down_limit - how long to wait for loop to come back up before declaring all devices dead (default 300 seconds) gone_device_time- how long to wait for a device that has appeared to leave the loop or fabric to reappear (default 30 seconds) Internal tunables include (which should be externalized): quick_boot_time- how long to wait when booting for loop to come up change_is_bad- whether or not to accept devices with the same WWNN/WWPN that reappear at a different PortID as being the 'same' device. Keen students of some of the subtle issues here will ask how one can keep devices from being re-accepted at all (the answer is to set a gone_device_time to zero- that effectively would be the same thing).
2006-11-14 08:45:48 +00:00
fcportdb_t *lp;
Unify port database use for target and initiator roles. Aside from cleaner and more consistent code, this allows ports to be both target and initiator same time, and easily switch from any role to any. Sponsored by: iXsystems, Inc.
2015-07-13 15:11:05 +00:00
struct ac_contract ac;
struct ac_device_changed *adc;
Remove extra level of target ID indirection (isp_dev_map). FreeBSD never had limitation on number of target IDs, and there is no any other requirement to allocate them densely. Since slots of port database already populated just sequentially, there is no much need for another indirection to allocate sequentially too.
2015-07-05 02:09:46 +00:00
int dbidx, i;
Push things closer to path failover by implementing loop down and gone device timers and zombie state entries. There are tunables that can be used to select a number of parameters. loop_down_limit - how long to wait for loop to come back up before declaring all devices dead (default 300 seconds) gone_device_time- how long to wait for a device that has appeared to leave the loop or fabric to reappear (default 30 seconds) Internal tunables include (which should be externalized): quick_boot_time- how long to wait when booting for loop to come up change_is_bad- whether or not to accept devices with the same WWNN/WWPN that reappear at a different PortID as being the 'same' device. Keen students of some of the subtle issues here will ask how one can keep devices from being re-accepted at all (the answer is to set a gone_device_time to zero- that effectively would be the same thing).
2006-11-14 08:45:48 +00:00
One more round of port scanner rewrite. - Make scan aborted by event restart immediately and infinitely. - Improve handling of some loop events from firmware. - Remove loop down timer, adding its functionality to scanner thread. - Some more unification and simplification.
2015-11-26 13:04:58 +00:00
isp_prt(isp, ISP_LOG_SANCFG|ISP_LOGDEBUG0, "Chan %d Loop is dead", chan);
Make this an MP safe driver but also still be multi-release. Seems to work on RELENG_4 through -current and also on sparc64 now. There may still be some issues with the auto attach/detach code to sort out. MFC after: 3 days
2007-05-05 20:17:23 +00:00
Push things closer to path failover by implementing loop down and gone device timers and zombie state entries. There are tunables that can be used to select a number of parameters. loop_down_limit - how long to wait for loop to come back up before declaring all devices dead (default 300 seconds) gone_device_time- how long to wait for a device that has appeared to leave the loop or fabric to reappear (default 30 seconds) Internal tunables include (which should be externalized): quick_boot_time- how long to wait when booting for loop to come up change_is_bad- whether or not to accept devices with the same WWNN/WWPN that reappear at a different PortID as being the 'same' device. Keen students of some of the subtle issues here will ask how one can keep devices from being re-accepted at all (the answer is to set a gone_device_time to zero- that effectively would be the same thing).
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++) {
One more round of port scanner rewrite. - Make scan aborted by event restart immediately and infinitely. - Improve handling of some loop events from firmware. - Remove loop down timer, adding its functionality to scanner thread. - Some more unification and simplification.
2015-11-26 13:04:58 +00:00
lp = &fcp->portdb[dbidx];
Push things closer to path failover by implementing loop down and gone device timers and zombie state entries. There are tunables that can be used to select a number of parameters. loop_down_limit - how long to wait for loop to come back up before declaring all devices dead (default 300 seconds) gone_device_time- how long to wait for a device that has appeared to leave the loop or fabric to reappear (default 30 seconds) Internal tunables include (which should be externalized): quick_boot_time- how long to wait when booting for loop to come up change_is_bad- whether or not to accept devices with the same WWNN/WWPN that reappear at a different PortID as being the 'same' device. Keen students of some of the subtle issues here will ask how one can keep devices from being re-accepted at all (the answer is to set a gone_device_time to zero- that effectively would be the same thing).
2006-11-14 08:45:48 +00:00
Unify port database use for target and initiator roles. Aside from cleaner and more consistent code, this allows ports to be both target and initiator same time, and easily switch from any role to any. Sponsored by: iXsystems, Inc.
2015-07-13 15:11:05 +00:00
if (lp->state == FC_PORTDB_STATE_NIL)
Push things closer to path failover by implementing loop down and gone device timers and zombie state entries. There are tunables that can be used to select a number of parameters. loop_down_limit - how long to wait for loop to come back up before declaring all devices dead (default 300 seconds) gone_device_time- how long to wait for a device that has appeared to leave the loop or fabric to reappear (default 30 seconds) Internal tunables include (which should be externalized): quick_boot_time- how long to wait when booting for loop to come up change_is_bad- whether or not to accept devices with the same WWNN/WWPN that reappear at a different PortID as being the 'same' device. Keen students of some of the subtle issues here will ask how one can keep devices from being re-accepted at all (the answer is to set a gone_device_time to zero- that effectively would be the same thing).
2006-11-14 08:45:48 +00:00
continue;
Most of these changes to isp are to allow for isp.ko unloading. We also revive loop down freezes. We also externaliz within isp isp_prt_endcmd so something outside the core module can print something about a command completing. Also some work in progress to assist in handling timed out commands better. Partially Sponsored by: Panasas Approved by: re (kib) MFC after: 1 month
2011-08-13 23:34:17 +00:00
for (i = 0; i < isp->isp_maxcmds; i++) {
struct ccb_scsiio *xs;
Unify handles allocation for initiator and target IOCBs. I am not sure why this was split long ago, but I see no reason for it. At this point this unification just slightly reduces memory usage, but as next step I plan to reuse shared handle space for other IOCB types.
2015-12-25 13:03:18 +00:00
if (ISP_H2HT(isp->isp_xflist[i].handle) != ISP_HANDLE_INITIATOR) {
Most of these changes to isp are to allow for isp.ko unloading. We also revive loop down freezes. We also externaliz within isp isp_prt_endcmd so something outside the core module can print something about a command completing. Also some work in progress to assist in handling timed out commands better. Partially Sponsored by: Panasas Approved by: re (kib) MFC after: 1 month
2011-08-13 23:34:17 +00:00
continue;
}
if ((xs = isp->isp_xflist[i].cmd) == NULL) {
continue;
}
Remove extra level of target ID indirection (isp_dev_map). FreeBSD never had limitation on number of target IDs, and there is no any other requirement to allocate them densely. Since slots of port database already populated just sequentially, there is no much need for another indirection to allocate sequentially too.
2015-07-05 02:09:46 +00:00
if (dbidx != XS_TGT(xs)) {
Most of these changes to isp are to allow for isp.ko unloading. We also revive loop down freezes. We also externaliz within isp isp_prt_endcmd so something outside the core module can print something about a command completing. Also some work in progress to assist in handling timed out commands better. Partially Sponsored by: Panasas Approved by: re (kib) MFC after: 1 month
2011-08-13 23:34:17 +00:00
continue;
}
Add PIM_EXTLUNS support to isp(4) driver. Now 24xx and above chips support full 8-byte LUN address space. Older FC chips may support up to 16K LUNs when firmware allows. Tested in both initiator and target modes for 23xx, 24xx and 25xx.
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);
Most of these changes to isp are to allow for isp.ko unloading. We also revive loop down freezes. We also externaliz within isp isp_prt_endcmd so something outside the core module can print something about a command completing. Also some work in progress to assist in handling timed out commands better. Partially Sponsored by: Panasas Approved by: re (kib) MFC after: 1 month
2011-08-13 23:34:17 +00:00
}
Push things closer to path failover by implementing loop down and gone device timers and zombie state entries. There are tunables that can be used to select a number of parameters. loop_down_limit - how long to wait for loop to come back up before declaring all devices dead (default 300 seconds) gone_device_time- how long to wait for a device that has appeared to leave the loop or fabric to reappear (default 30 seconds) Internal tunables include (which should be externalized): quick_boot_time- how long to wait when booting for loop to come up change_is_bad- whether or not to accept devices with the same WWNN/WWPN that reappear at a different PortID as being the 'same' device. Keen students of some of the subtle issues here will ask how one can keep devices from being re-accepted at all (the answer is to set a gone_device_time to zero- that effectively would be the same thing).
2006-11-14 08:45:48 +00:00
Unify port database use for target and initiator roles. Aside from cleaner and more consistent code, this allows ports to be both target and initiator same time, and easily switch from any role to any. Sponsored by: iXsystems, Inc.
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;
Switch initiator IDs in target mode to the same address space as target IDs in initiator mode -- index in port database instead of handlers. This makes initiator IDs persist across role changes and firmware resets, when handlers previously assigned by firmware are lost and reused. Sponsored by: iXsystems, Inc.
2015-07-13 21:01:24 +00:00
adc->target = dbidx;
Unify port database use for target and initiator roles. Aside from cleaner and more consistent code, this allows ports to be both target and initiator same time, and easily switch from any role to any. Sponsored by: iXsystems, Inc.
2015-07-13 15:11:05 +00:00
adc->arrived = 0;
xpt_async(AC_CONTRACT, fc->path, &ac);
}
Push things closer to path failover by implementing loop down and gone device timers and zombie state entries. There are tunables that can be used to select a number of parameters. loop_down_limit - how long to wait for loop to come back up before declaring all devices dead (default 300 seconds) gone_device_time- how long to wait for a device that has appeared to leave the loop or fabric to reappear (default 30 seconds) Internal tunables include (which should be externalized): quick_boot_time- how long to wait when booting for loop to come up change_is_bad- whether or not to accept devices with the same WWNN/WWPN that reappear at a different PortID as being the 'same' device. Keen students of some of the subtle issues here will ask how one can keep devices from being re-accepted at all (the answer is to set a gone_device_time to zero- that effectively would be the same thing).
2006-11-14 08:45:48 +00:00
}
Some more gratuitous format and name changes. Pull in some target mode changes from a private branch. Pull in some more RELENG_4 compilation changes. A lot of lines changed, but not much content change yet.
2006-04-21 18:30:01 +00:00
Unify port database use for target and initiator roles. Aside from cleaner and more consistent code, this allows ports to be both target and initiator same time, and easily switch from any role to any. Sponsored by: iXsystems, Inc.
2015-07-13 15:11:05 +00:00
isp_unfreeze_loopdown(isp, chan);
One more round of port scanner rewrite. - Make scan aborted by event restart immediately and infinitely. - Improve handling of some loop events from firmware. - Remove loop down timer, adding its functionality to scanner thread. - Some more unification and simplification.
2015-11-26 13:04:58 +00:00
fc->loop_down_time = 0;
Push things closer to path failover by implementing loop down and gone device timers and zombie state entries. There are tunables that can be used to select a number of parameters. loop_down_limit - how long to wait for loop to come back up before declaring all devices dead (default 300 seconds) gone_device_time- how long to wait for a device that has appeared to leave the loop or fabric to reappear (default 30 seconds) Internal tunables include (which should be externalized): quick_boot_time- how long to wait when booting for loop to come up change_is_bad- whether or not to accept devices with the same WWNN/WWPN that reappear at a different PortID as being the 'same' device. Keen students of some of the subtle issues here will ask how one can keep devices from being re-accepted at all (the answer is to set a gone_device_time to zero- that effectively would be the same thing).
2006-11-14 08:45:48 +00:00
}
static void
isp_kthread(void *arg)
{
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
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;
One more round of port scanner rewrite. - Make scan aborted by event restart immediately and infinitely. - Improve handling of some loop events from firmware. - Remove loop down timer, adding its functionality to scanner thread. - Some more unification and simplification.
2015-11-26 13:04:58 +00:00
int slp = 0, d;
int lb, lim;
Fix cases where we've managed to get a Loop UP event prior to initializing the loop down counter, as well as other things. This was brought to my attention with a different fix, more for RELENG_7- this one covers the multiple channel case. PR: 140438 MFC after: 1 month
2009-12-04 03:34:12 +00:00
Clean/unify some macro usage. MFC after: 2 weeks
2017-03-21 10:34:34 +00:00
ISP_LOCK(isp);
Fix a kernel panic when unloading isp(4). In the current implementation, the isp_kthread() threads never exit. The target threads do have an exit mode from isp_attach(), but it is not invoked from isp_detach(). Ensure isp_detach() notifies threads started for each channel, such that they exit before their parent device softc detaches, and thus before the module does. Otherwise, a page fault panic occurs later in: sysctl_kern_proc sysctl_out_proc kern_proc_out fill_kinfo_proc fill_kinfo_thread strlcpy(kp->ki_wmesg, td->td_wmesg, sizeof(kp->ki_wmesg)); For isp_kthread() (and isp(4) target threads), td->td_wmesg references now-unmapped memory after the module has been unloaded. These threads are typically msleep()ing at the time of unload, but they could also attempt to execute now-unmapped code segments. MFC after: 1 month Sponsored by: Spectra Logic MFSpectraBSD: r1070921 on 2014/06/22 13:01:17
2014-09-18 02:01:36 +00:00
while (isp->isp_osinfo.is_exiting == 0) {
One more round of port scanner rewrite. - Make scan aborted by event restart immediately and infinitely. - Improve handling of some loop events from firmware. - Remove loop down timer, adding its functionality to scanner thread. - Some more unification and simplification.
2015-11-26 13:04:58 +00:00
isp_prt(isp, ISP_LOG_SANCFG|ISP_LOGDEBUG0,
"Chan %d Checking FC state", chan);
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
lb = isp_fc_runstate(isp, chan, 250000);
One more round of port scanner rewrite. - Make scan aborted by event restart immediately and infinitely. - Improve handling of some loop events from firmware. - Remove loop down timer, adding its functionality to scanner thread. - Some more unification and simplification.
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));
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
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.
*/
One more round of port scanner rewrite. - Make scan aborted by event restart immediately and infinitely. - Improve handling of some loop events from firmware. - Remove loop down timer, adding its functionality to scanner thread. - Some more unification and simplification.
2015-11-26 13:04:58 +00:00
if (lb == LOOP_READY || lb < 0) {
slp = 0;
} else {
Add 4Gb (24XX) support and lay the foundation for a lot of new stuff.
2006-11-02 03:21:32 +00:00
/*
* If we've never seen loop up and we've waited longer
Push things closer to path failover by implementing loop down and gone device timers and zombie state entries. There are tunables that can be used to select a number of parameters. loop_down_limit - how long to wait for loop to come back up before declaring all devices dead (default 300 seconds) gone_device_time- how long to wait for a device that has appeared to leave the loop or fabric to reappear (default 30 seconds) Internal tunables include (which should be externalized): quick_boot_time- how long to wait when booting for loop to come up change_is_bad- whether or not to accept devices with the same WWNN/WWPN that reappear at a different PortID as being the 'same' device. Keen students of some of the subtle issues here will ask how one can keep devices from being re-accepted at all (the answer is to set a gone_device_time to zero- that effectively would be the same thing).
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.
Add 4Gb (24XX) support and lay the foundation for a lot of new stuff.
2006-11-02 03:21:32 +00:00
*/
One more round of port scanner rewrite. - Make scan aborted by event restart immediately and infinitely. - Improve handling of some loop events from firmware. - Remove loop down timer, adding its functionality to scanner thread. - Some more unification and simplification.
2015-11-26 13:04:58 +00:00
if (fc->loop_seen_once == 0)
Push things closer to path failover by implementing loop down and gone device timers and zombie state entries. There are tunables that can be used to select a number of parameters. loop_down_limit - how long to wait for loop to come back up before declaring all devices dead (default 300 seconds) gone_device_time- how long to wait for a device that has appeared to leave the loop or fabric to reappear (default 30 seconds) Internal tunables include (which should be externalized): quick_boot_time- how long to wait when booting for loop to come up change_is_bad- whether or not to accept devices with the same WWNN/WWPN that reappear at a different PortID as being the 'same' device. Keen students of some of the subtle issues here will ask how one can keep devices from being re-accepted at all (the answer is to set a gone_device_time to zero- that effectively would be the same thing).
2006-11-14 08:45:48 +00:00
lim = isp_quickboot_time;
One more round of port scanner rewrite. - Make scan aborted by event restart immediately and infinitely. - Improve handling of some loop events from firmware. - Remove loop down timer, adding its functionality to scanner thread. - Some more unification and simplification.
2015-11-26 13:04:58 +00:00
else
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
lim = fc->loop_down_limit;
One more round of port scanner rewrite. - Make scan aborted by event restart immediately and infinitely. - Improve handling of some loop events from firmware. - Remove loop down timer, adding its functionality to scanner thread. - Some more unification and simplification.
2015-11-26 13:04:58 +00:00
d = time_uptime - fc->loop_down_time;
if (d >= lim)
Push things closer to path failover by implementing loop down and gone device timers and zombie state entries. There are tunables that can be used to select a number of parameters. loop_down_limit - how long to wait for loop to come back up before declaring all devices dead (default 300 seconds) gone_device_time- how long to wait for a device that has appeared to leave the loop or fabric to reappear (default 30 seconds) Internal tunables include (which should be externalized): quick_boot_time- how long to wait when booting for loop to come up change_is_bad- whether or not to accept devices with the same WWNN/WWPN that reappear at a different PortID as being the 'same' device. Keen students of some of the subtle issues here will ask how one can keep devices from being re-accepted at all (the answer is to set a gone_device_time to zero- that effectively would be the same thing).
2006-11-14 08:45:48 +00:00
slp = 0;
One more round of port scanner rewrite. - Make scan aborted by event restart immediately and infinitely. - Improve handling of some loop events from firmware. - Remove loop down timer, adding its functionality to scanner thread. - Some more unification and simplification.
2015-11-26 13:04:58 +00:00
else if (d < 10)
Push things closer to path failover by implementing loop down and gone device timers and zombie state entries. There are tunables that can be used to select a number of parameters. loop_down_limit - how long to wait for loop to come back up before declaring all devices dead (default 300 seconds) gone_device_time- how long to wait for a device that has appeared to leave the loop or fabric to reappear (default 30 seconds) Internal tunables include (which should be externalized): quick_boot_time- how long to wait when booting for loop to come up change_is_bad- whether or not to accept devices with the same WWNN/WWPN that reappear at a different PortID as being the 'same' device. Keen students of some of the subtle issues here will ask how one can keep devices from being re-accepted at all (the answer is to set a gone_device_time to zero- that effectively would be the same thing).
2006-11-14 08:45:48 +00:00
slp = 1;
One more round of port scanner rewrite. - Make scan aborted by event restart immediately and infinitely. - Improve handling of some loop events from firmware. - Remove loop down timer, adding its functionality to scanner thread. - Some more unification and simplification.
2015-11-26 13:04:58 +00:00
else if (d < 30)
Push things closer to path failover by implementing loop down and gone device timers and zombie state entries. There are tunables that can be used to select a number of parameters. loop_down_limit - how long to wait for loop to come back up before declaring all devices dead (default 300 seconds) gone_device_time- how long to wait for a device that has appeared to leave the loop or fabric to reappear (default 30 seconds) Internal tunables include (which should be externalized): quick_boot_time- how long to wait when booting for loop to come up change_is_bad- whether or not to accept devices with the same WWNN/WWPN that reappear at a different PortID as being the 'same' device. Keen students of some of the subtle issues here will ask how one can keep devices from being re-accepted at all (the answer is to set a gone_device_time to zero- that effectively would be the same thing).
2006-11-14 08:45:48 +00:00
slp = 5;
One more round of port scanner rewrite. - Make scan aborted by event restart immediately and infinitely. - Improve handling of some loop events from firmware. - Remove loop down timer, adding its functionality to scanner thread. - Some more unification and simplification.
2015-11-26 13:04:58 +00:00
else if (d < 60)
Push things closer to path failover by implementing loop down and gone device timers and zombie state entries. There are tunables that can be used to select a number of parameters. loop_down_limit - how long to wait for loop to come back up before declaring all devices dead (default 300 seconds) gone_device_time- how long to wait for a device that has appeared to leave the loop or fabric to reappear (default 30 seconds) Internal tunables include (which should be externalized): quick_boot_time- how long to wait when booting for loop to come up change_is_bad- whether or not to accept devices with the same WWNN/WWPN that reappear at a different PortID as being the 'same' device. Keen students of some of the subtle issues here will ask how one can keep devices from being re-accepted at all (the answer is to set a gone_device_time to zero- that effectively would be the same thing).
2006-11-14 08:45:48 +00:00
slp = 10;
One more round of port scanner rewrite. - Make scan aborted by event restart immediately and infinitely. - Improve handling of some loop events from firmware. - Remove loop down timer, adding its functionality to scanner thread. - Some more unification and simplification.
2015-11-26 13:04:58 +00:00
else if (d < 120)
Push things closer to path failover by implementing loop down and gone device timers and zombie state entries. There are tunables that can be used to select a number of parameters. loop_down_limit - how long to wait for loop to come back up before declaring all devices dead (default 300 seconds) gone_device_time- how long to wait for a device that has appeared to leave the loop or fabric to reappear (default 30 seconds) Internal tunables include (which should be externalized): quick_boot_time- how long to wait when booting for loop to come up change_is_bad- whether or not to accept devices with the same WWNN/WWPN that reappear at a different PortID as being the 'same' device. Keen students of some of the subtle issues here will ask how one can keep devices from being re-accepted at all (the answer is to set a gone_device_time to zero- that effectively would be the same thing).
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
One more round of port scanner rewrite. - Make scan aborted by event restart immediately and infinitely. - Improve handling of some loop events from firmware. - Remove loop down timer, adding its functionality to scanner thread. - Some more unification and simplification.
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
}
Add get/set param ioctl support. Remove sim queue freezes for resource shortages. I've had too many strange race conditions where I freeze on a resource shortage but never get unfrozen. Consolidate the remaining sim queue freeze condition (for loopdown) into an inline with debug messages that allows us to track problems at ISP_LOGDEBUG0 level easier. Change a bunch of debug messages about loop down/up conditions to ISP_LOGDEBUG0 level. Remove dead isp_relsim code. Change some internal flag stuff for efficiency. Complain vociferously if we try and use our FC scratch area while it's busy being used already (I mean, if we don't have solaris' ability to sleep as an interrupt thread which would allow us to just use a p/v semaphore, at least *say* when you've just borked yourself). Add infrastructure to allow overrides of hard loopid && initiator id from boot variables. Fix the usual quota of silly bugs: + 'ktmature' needs to be per-instance. Argh. + When entering isp_watchdog, set intsok to zero, preserving old value to restore later. It's not nice to try and sleep from splsoftclock. + Fix tick overflow buglet in checking timeout value. MFC after: 1 week
2002-07-08 17:42:47 +00:00
One more round of port scanner rewrite. - Make scan aborted by event restart immediately and infinitely. - Improve handling of some loop events from firmware. - Remove loop down timer, adding its functionality to scanner thread. - Some more unification and simplification.
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);
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
}
One more round of port scanner rewrite. - Make scan aborted by event restart immediately and infinitely. - Improve handling of some loop events from firmware. - Remove loop down timer, adding its functionality to scanner thread. - Some more unification and simplification.
2015-11-26 13:04:58 +00:00
isp_prt(isp, ISP_LOG_SANCFG|ISP_LOGDEBUG0,
"Chan %d sleep for %d seconds", chan, slp);
Clean/unify some macro usage. MFC after: 2 weeks
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
}
Fix a kernel panic when unloading isp(4). In the current implementation, the isp_kthread() threads never exit. The target threads do have an exit mode from isp_attach(), but it is not invoked from isp_detach(). Ensure isp_detach() notifies threads started for each channel, such that they exit before their parent device softc detaches, and thus before the module does. Otherwise, a page fault panic occurs later in: sysctl_kern_proc sysctl_out_proc kern_proc_out fill_kinfo_proc fill_kinfo_thread strlcpy(kp->ki_wmesg, td->td_wmesg, sizeof(kp->ki_wmesg)); For isp_kthread() (and isp(4) target threads), td->td_wmesg references now-unmapped memory after the module has been unloaded. These threads are typically msleep()ing at the time of unload, but they could also attempt to execute now-unmapped code segments. MFC after: 1 month Sponsored by: Spectra Logic MFSpectraBSD: r1070921 on 2014/06/22 13:01:17
2014-09-18 02:01:36 +00:00
fc->num_threads -= 1;
Clean/unify some macro usage. MFC after: 2 weeks
2017-03-21 10:34:34 +00:00
ISP_UNLOCK(isp);
Fix a kernel panic when unloading isp(4). In the current implementation, the isp_kthread() threads never exit. The target threads do have an exit mode from isp_attach(), but it is not invoked from isp_detach(). Ensure isp_detach() notifies threads started for each channel, such that they exit before their parent device softc detaches, and thus before the module does. Otherwise, a page fault panic occurs later in: sysctl_kern_proc sysctl_out_proc kern_proc_out fill_kinfo_proc fill_kinfo_thread strlcpy(kp->ki_wmesg, td->td_wmesg, sizeof(kp->ki_wmesg)); For isp_kthread() (and isp(4) target threads), td->td_wmesg references now-unmapped memory after the module has been unloaded. These threads are typically msleep()ing at the time of unload, but they could also attempt to execute now-unmapped code segments. MFC after: 1 month Sponsored by: Spectra Logic MFSpectraBSD: r1070921 on 2014/06/22 13:01:17
2014-09-18 02:01:36 +00:00
kthread_exit();
Make this an MP safe driver but also still be multi-release. Seems to work on RELENG_4 through -current and also on sparc64 now. There may still be some issues with the auto attach/detach code to sort out. MFC after: 3 days
2007-05-05 20:17:23 +00:00
}
Fix multiple problems around LUN disable under load. - Move private data about ATIOs/INOTs from per-LUN to per-channel data. This allows active commands to continue operation after LUN destruction. This also simplifies lookup of the data by tag in some situations. - Unify three restart_queue processing implementations. - Complete all ATIOs from restart_queue on LUN disable. - Delete ATIO private data when command completed or aborted, not depending on the ATIO being requeued, that was ugly hack and could never happen. CAM should always call ether XPT_CONT_TARGET_IO with status or XPT_ABORT. - Implement XPT_ABORT for queued ATIOs/INOTs to allow CAM do graceful shutdown, not depending on LUN disable, as it is done in ahd(4)/targ(4). - Unify isp_endcmd() arguments to make it more usable in generic code. - Remove never really used LUN state reference counter. MFC after: 2 weeks
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);
Remove not very useful ATIO/INOT stats. While there polish respective debug logging. MFC after: 2 weeks
2017-03-15 19:49:45 +00:00
ISP_PATH_PRT(isp, ISP_LOGTDEBUG2, sccb->path,
"Abort FREE ATIO\n");
Fix multiple problems around LUN disable under load. - Move private data about ATIOs/INOTs from per-LUN to per-channel data. This allows active commands to continue operation after LUN destruction. This also simplifies lookup of the data by tag in some situations. - Unify three restart_queue processing implementations. - Complete all ATIOs from restart_queue on LUN disable. - Delete ATIO private data when command completed or aborted, not depending on the ATIO being requeued, that was ugly hack and could never happen. CAM should always call ether XPT_CONT_TARGET_IO with status or XPT_ABORT. - Implement XPT_ABORT for queued ATIOs/INOTs to allow CAM do graceful shutdown, not depending on LUN disable, as it is done in ahd(4)/targ(4). - Unify isp_endcmd() arguments to make it more usable in generic code. - Remove never really used LUN state reference counter. MFC after: 2 weeks
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) {
Send TERMINATE to firmware when aborting active ATIO. MFC after: 2 weeks
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);
}
Fix multiple problems around LUN disable under load. - Move private data about ATIOs/INOTs from per-LUN to per-channel data. This allows active commands to continue operation after LUN destruction. This also simplifies lookup of the data by tag in some situations. - Unify three restart_queue processing implementations. - Complete all ATIOs from restart_queue on LUN disable. - Delete ATIO private data when command completed or aborted, not depending on the ATIO being requeued, that was ugly hack and could never happen. CAM should always call ether XPT_CONT_TARGET_IO with status or XPT_ABORT. - Implement XPT_ABORT for queued ATIOs/INOTs to allow CAM do graceful shutdown, not depending on LUN disable, as it is done in ahd(4)/targ(4). - Unify isp_endcmd() arguments to make it more usable in generic code. - Remove never really used LUN state reference counter. MFC after: 2 weeks
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);
Remove not very useful ATIO/INOT stats. While there polish respective debug logging. MFC after: 2 weeks
2017-03-15 19:49:45 +00:00
ISP_PATH_PRT(isp, ISP_LOGTDEBUG2, sccb->path,
"Abort FREE INOT\n");
Fix multiple problems around LUN disable under load. - Move private data about ATIOs/INOTs from per-LUN to per-channel data. This allows active commands to continue operation after LUN destruction. This also simplifies lookup of the data by tag in some situations. - Unify three restart_queue processing implementations. - Complete all ATIOs from restart_queue on LUN disable. - Delete ATIO private data when command completed or aborted, not depending on the ATIO being requeued, that was ugly hack and could never happen. CAM should always call ether XPT_CONT_TARGET_IO with status or XPT_ABORT. - Implement XPT_ABORT for queued ATIOs/INOTs to allow CAM do graceful shutdown, not depending on LUN disable, as it is done in ahd(4)/targ(4). - Unify isp_endcmd() arguments to make it more usable in generic code. - Remove never really used LUN state reference counter. MFC after: 2 weeks
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) {
Do some notify acks cleanup. ISPASYNC_TARGET_NOTIFY_ACK makes no sense without argument. MFC after: 2 weeks
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);
}
Fix multiple problems around LUN disable under load. - Move private data about ATIOs/INOTs from per-LUN to per-channel data. This allows active commands to continue operation after LUN destruction. This also simplifies lookup of the data by tag in some situations. - Unify three restart_queue processing implementations. - Complete all ATIOs from restart_queue on LUN disable. - Delete ATIO private data when command completed or aborted, not depending on the ATIO being requeued, that was ugly hack and could never happen. CAM should always call ether XPT_CONT_TARGET_IO with status or XPT_ABORT. - Implement XPT_ABORT for queued ATIOs/INOTs to allow CAM do graceful shutdown, not depending on LUN disable, as it is done in ahd(4)/targ(4). - Unify isp_endcmd() arguments to make it more usable in generic code. - Remove never really used LUN state reference counter. MFC after: 2 weeks
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
Make this an MP safe driver but also still be multi-release. Seems to work on RELENG_4 through -current and also on sparc64 now. There may still be some issues with the auto attach/detach code to sort out. MFC after: 3 days
2007-05-05 20:17:23 +00:00
static void
isp_action(struct cam_sim *sim, union ccb *ccb)
{
Improve command timeout handling. Let firmware do its best first, and if it can't, try software recovery. I would remove software timeout handler completely, but found bunch of complains on command timeout on sparc64 mailing list few years ago, so better be safe in case of interrupt loss. MFC after: 2 weeks
2017-03-21 13:10:37 +00:00
int bus, tgt, error;
Some more gratuitous format and name changes. Pull in some target mode changes from a private branch. Pull in some more RELENG_4 compilation changes. A lot of lines changed, but not much content change yet.
2006-04-21 18:30:01 +00:00
ispsoftc_t *isp;
-Wunused cleanup. Submitted by: Poul-Henning Kamp <phk@freebsd.org>
1998-10-15 23:46:33 +00:00
struct ccb_trans_settings *cts;
Improve command timeout handling. Let firmware do its best first, and if it can't, try software recovery. I would remove software timeout handler completely, but found bunch of complains on command timeout on sparc64 mailing list few years ago, so better be safe in case of interrupt loss. MFC after: 2 weeks
2017-03-21 13:10:37 +00:00
sbintime_t ts;
Update QLogic ISP support for CAM. Add preliminary target mode support. Submitted by: Matthew Jacob <mjacob@feral.com>
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
Some more gratuitous format and name changes. Pull in some target mode changes from a private branch. Pull in some more RELENG_4 compilation changes. A lot of lines changed, but not much content change yet.
2006-04-21 18:30:01 +00:00
isp = (ispsoftc_t *)cam_sim_softc(sim);
Clean/unify some macro usage. MFC after: 2 weeks
2017-03-21 10:34:34 +00:00
ISP_ASSERT_LOCKED(isp);
bus = cam_sim_bus(sim);
Fix reported_gone setting, missed in some cases. This makes driver better track reported CAM_SEL_TIMEOUTs to properly report device reappearance later. This fixes target 0 not reappearing after initiator mode disabled and then reenabled. MFC after: 3 days
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;
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
Update QLogic ISP support for CAM. Add preliminary target mode support. Submitted by: Matthew Jacob <mjacob@feral.com>
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;
Fix reported_gone setting, missed in some cases. This makes driver better track reported CAM_SEL_TIMEOUTs to properly report device reappearance later. This fixes target 0 not reappearing after initiator mode disabled and then reenabled. MFC after: 3 days
2015-06-24 09:06:12 +00:00
isp_done((struct ccb_scsiio *) ccb);
Update QLogic ISP support for CAM. Add preliminary target mode support. Submitted by: Matthew Jacob <mjacob@feral.com>
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;
Clarify and cleanup some CAM queueing breakages.
1999-08-16 20:11:45 +00:00
#ifdef DIAGNOSTIC
Add PIM_EXTLUNS support to isp(4) driver. Now 24xx and above chips support full 8-byte LUN address space. Older FC chips may support up to 16K LUNs when firmware allows. Tested in both initiator and target modes for 23xx, 24xx and 25xx.
2015-10-24 17:34:40 +00:00
if (ccb->ccb_h.target_id >= ISP_MAX_TARGETS(isp)) {
Make ISPCTL_PLOGX find a handle to log into the management server with- not hope for the best. Change some things which were gated off of 24XX to be gated off of 2K login support. Convert some isp_prt calls to xpt_print calls.
2006-12-05 07:50:23 +00:00
xpt_print(ccb->ccb_h.path, "invalid target\n");
Clarify and cleanup some CAM queueing breakages.
1999-08-16 20:11:45 +00:00
ccb->ccb_h.status = CAM_PATH_INVALID;
Add PIM_EXTLUNS support to isp(4) driver. Now 24xx and above chips support full 8-byte LUN address space. Older FC chips may support up to 16K LUNs when firmware allows. Tested in both initiator and target modes for 23xx, 24xx and 25xx.
2015-10-24 17:34:40 +00:00
} else if (ISP_MAX_LUNS(isp) > 0 &&
ccb->ccb_h.target_lun >= ISP_MAX_LUNS(isp)) {
Make ISPCTL_PLOGX find a handle to log into the management server with- not hope for the best. Change some things which were gated off of 24XX to be gated off of 2K login support. Convert some isp_prt calls to xpt_print calls.
2006-12-05 07:50:23 +00:00
xpt_print(ccb->ccb_h.path, "invalid lun\n");
Clarify and cleanup some CAM queueing breakages.
1999-08-16 20:11:45 +00:00
ccb->ccb_h.status = CAM_PATH_INVALID;
Update QLogic ISP support for CAM. Add preliminary target mode support. Submitted by: Matthew Jacob <mjacob@feral.com>
1998-09-15 08:42:56 +00:00
}
if (ccb->ccb_h.status == CAM_PATH_INVALID) {
xpt_done(ccb);
break;
}
Clarify and cleanup some CAM queueing breakages.
1999-08-16 20:11:45 +00:00
#endif
Make this an MP safe driver but also still be multi-release. Seems to work on RELENG_4 through -current and also on sparc64 now. There may still be some issues with the auto attach/detach code to sort out. MFC after: 3 days
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);
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
cam_release_devq(ccb->ccb_h.path, RELSIM_RELEASE_AFTER_TIMEOUT, 0, 250, 0);
Fix reported_gone setting, missed in some cases. This makes driver better track reported CAM_SEL_TIMEOUTs to properly report device reappearance later. This fixes target 0 not reappearing after initiator mode disabled and then reenabled. MFC after: 3 days
2015-06-24 09:06:12 +00:00
ccb->ccb_h.status = CAM_REQUEUE_REQ;
Make this an MP safe driver but also still be multi-release. Seems to work on RELENG_4 through -current and also on sparc64 now. There may still be some issues with the auto attach/detach code to sort out. MFC after: 3 days
2007-05-05 20:17:23 +00:00
xpt_done(ccb);
break;
}
Core version 2.0 rewrite. In this file we replace isp_tdebug with isp_prt calls. We now use an argument to the ISPCTL_FCLINK_TEST call. We change all IDPRINTF macros to isp_prt calls. We add the isp_prt function here.
2000-08-01 06:31:44 +00:00
error = isp_start((XS_T *) ccb);
Clarify and cleanup some CAM queueing breakages.
1999-08-16 20:11:45 +00:00
switch (error) {
Update QLogic ISP support for CAM. Add preliminary target mode support. Submitted by: Matthew Jacob <mjacob@feral.com>
1998-09-15 08:42:56 +00:00
case CMD_QUEUED:
ccb->ccb_h.status |= CAM_SIM_QUEUED;
Improve command timeout handling. Let firmware do its best first, and if it can't, try software recovery. I would remove software timeout handler completely, but found bunch of complains on command timeout on sparc64 mailing list few years ago, so better be safe in case of interrupt loss. MFC after: 2 weeks
2017-03-21 13:10:37 +00:00
if (ccb->ccb_h.timeout == CAM_TIME_INFINITY)
Make this an MP safe driver but also still be multi-release. Seems to work on RELENG_4 through -current and also on sparc64 now. There may still be some issues with the auto attach/detach code to sort out. MFC after: 3 days
2007-05-05 20:17:23 +00:00
break;
Improve command timeout handling. Let firmware do its best first, and if it can't, try software recovery. I would remove software timeout handler completely, but found bunch of complains on command timeout on sparc64 mailing list few years ago, so better be safe in case of interrupt loss. MFC after: 2 weeks
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);
Update QLogic ISP support for CAM. Add preliminary target mode support. Submitted by: Matthew Jacob <mjacob@feral.com>
1998-09-15 08:42:56 +00:00
break;
Clarify and cleanup some CAM queueing breakages.
1999-08-16 20:11:45 +00:00
case CMD_RQLATER:
Add PIM_EXTLUNS support to isp(4) driver. Now 24xx and above chips support full 8-byte LUN address space. Older FC chips may support up to 16K LUNs when firmware allows. Tested in both initiator and target modes for 23xx, 24xx and 25xx.
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));
Push things closer to path failover by implementing loop down and gone device timers and zombie state entries. There are tunables that can be used to select a number of parameters. loop_down_limit - how long to wait for loop to come back up before declaring all devices dead (default 300 seconds) gone_device_time- how long to wait for a device that has appeared to leave the loop or fabric to reappear (default 30 seconds) Internal tunables include (which should be externalized): quick_boot_time- how long to wait when booting for loop to come up change_is_bad- whether or not to accept devices with the same WWNN/WWPN that reappear at a different PortID as being the 'same' device. Keen students of some of the subtle issues here will ask how one can keep devices from being re-accepted at all (the answer is to set a gone_device_time to zero- that effectively would be the same thing).
2006-11-14 08:45:48 +00:00
cam_freeze_devq(ccb->ccb_h.path);
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
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;
Make this an MP safe driver but also still be multi-release. Seems to work on RELENG_4 through -current and also on sparc64 now. There may still be some issues with the auto attach/detach code to sort out. MFC after: 3 days
2007-05-05 20:17:23 +00:00
isp_free_pcmd(isp, ccb);
Update QLogic ISP support for CAM. Add preliminary target mode support. Submitted by: Matthew Jacob <mjacob@feral.com>
1998-09-15 08:42:56 +00:00
xpt_done(ccb);
break;
Clarify and cleanup some CAM queueing breakages.
1999-08-16 20:11:45 +00:00
case CMD_EAGAIN:
Make this an MP safe driver but also still be multi-release. Seems to work on RELENG_4 through -current and also on sparc64 now. There may still be some issues with the auto attach/detach code to sort out. MFC after: 3 days
2007-05-05 20:17:23 +00:00
isp_free_pcmd(isp, ccb);
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
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;
Update QLogic ISP support for CAM. Add preliminary target mode support. Submitted by: Matthew Jacob <mjacob@feral.com>
1998-09-15 08:42:56 +00:00
xpt_done(ccb);
break;
Clarify and cleanup some CAM queueing breakages.
1999-08-16 20:11:45 +00:00
case CMD_COMPLETE:
isp_done((struct ccb_scsiio *) ccb);
break;
default:
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
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;
Make this an MP safe driver but also still be multi-release. Seems to work on RELENG_4 through -current and also on sparc64 now. There may still be some issues with the auto attach/detach code to sort out. MFC after: 3 days
2007-05-05 20:17:23 +00:00
isp_free_pcmd(isp, ccb);
Clarify and cleanup some CAM queueing breakages.
1999-08-16 20:11:45 +00:00
xpt_done(ccb);
Update QLogic ISP support for CAM. Add preliminary target mode support. Submitted by: Matthew Jacob <mjacob@feral.com>
1998-09-15 08:42:56 +00:00
}
break;
Make a static chain of isp softcs- gdb usage becomes a lot easier. Add in a very large amount of target mode support code- this is just a first pass at this. It's a difficult thing because some of the code can be in platform independent areas (see isp_target.?) but a lot has to be in platform dependent areas because of not only the tight coupling of received commands/events and the specific OS subsystem but because the platform independent code has (deliberately) no event/wait mechanisms.
2000-01-03 23:55:30 +00:00
#ifdef ISP_TARGET_MODE
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
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);
Remove condition variables and status associated with target mode enabling. Instead, go to an interrupt/polled model. Fix get_lun_statep so we don't panic if there are no wildcard luns enabled. MFC after: 6 days
2004-02-08 19:17:56 +00:00
}
Update QLogic ISP support for CAM. Add preliminary target mode support. Submitted by: Matthew Jacob <mjacob@feral.com>
1998-09-15 08:42:56 +00:00
break;
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
case XPT_IMMEDIATE_NOTIFY: /* Add Immediate Notify Resource */
Make a static chain of isp softcs- gdb usage becomes a lot easier. Add in a very large amount of target mode support code- this is just a first pass at this. It's a difficult thing because some of the code can be in platform independent areas (see isp_target.?) but a lot has to be in platform dependent areas because of not only the tight coupling of received commands/events and the specific OS subsystem but because the platform independent code has (deliberately) no event/wait mechanisms.
2000-01-03 23:55:30 +00:00
case XPT_ACCEPT_TARGET_IO: /* Add Accept Target IO Resource */
{
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
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;
Fix multiple problems around LUN disable under load. - Move private data about ATIOs/INOTs from per-LUN to per-channel data. This allows active commands to continue operation after LUN destruction. This also simplifies lookup of the data by tag in some situations. - Unify three restart_queue processing implementations. - Complete all ATIOs from restart_queue on LUN disable. - Delete ATIO private data when command completed or aborted, not depending on the ATIO being requeued, that was ugly hack and could never happen. CAM should always call ether XPT_CONT_TARGET_IO with status or XPT_ABORT. - Implement XPT_ABORT for queued ATIOs/INOTs to allow CAM do graceful shutdown, not depending on LUN disable, as it is done in ahd(4)/targ(4). - Unify isp_endcmd() arguments to make it more usable in generic code. - Remove never really used LUN state reference counter. MFC after: 2 weeks
2017-02-22 06:43:49 +00:00
if (ccb->ccb_h.func_code == XPT_IMMEDIATE_NOTIFY)
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
str = "XPT_IMMEDIATE_NOTIFY";
Fix multiple problems around LUN disable under load. - Move private data about ATIOs/INOTs from per-LUN to per-channel data. This allows active commands to continue operation after LUN destruction. This also simplifies lookup of the data by tag in some situations. - Unify three restart_queue processing implementations. - Complete all ATIOs from restart_queue on LUN disable. - Delete ATIO private data when command completed or aborted, not depending on the ATIO being requeued, that was ugly hack and could never happen. CAM should always call ether XPT_CONT_TARGET_IO with status or XPT_ABORT. - Implement XPT_ABORT for queued ATIOs/INOTs to allow CAM do graceful shutdown, not depending on LUN disable, as it is done in ahd(4)/targ(4). - Unify isp_endcmd() arguments to make it more usable in generic code. - Remove never really used LUN state reference counter. MFC after: 2 weeks
2017-02-22 06:43:49 +00:00
else
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
str = "XPT_ACCEPT_TARGET_IO";
Fix multiple problems around LUN disable under load. - Move private data about ATIOs/INOTs from per-LUN to per-channel data. This allows active commands to continue operation after LUN destruction. This also simplifies lookup of the data by tag in some situations. - Unify three restart_queue processing implementations. - Complete all ATIOs from restart_queue on LUN disable. - Delete ATIO private data when command completed or aborted, not depending on the ATIO being requeued, that was ugly hack and could never happen. CAM should always call ether XPT_CONT_TARGET_IO with status or XPT_ABORT. - Implement XPT_ABORT for queued ATIOs/INOTs to allow CAM do graceful shutdown, not depending on LUN disable, as it is done in ahd(4)/targ(4). - Unify isp_endcmd() arguments to make it more usable in generic code. - Remove never really used LUN state reference counter. MFC after: 2 weeks
2017-02-22 06:43:49 +00:00
ISP_PATH_PRT(isp, ISP_LOGWARN, ccb->ccb_h.path,
Fix missing xpt_done() for ATIO/INOT on missing LUN. MFC after: 2 weeks
2017-02-24 12:11:17 +00:00
"%s: no state pointer found for %s\n",
Fix multiple problems around LUN disable under load. - Move private data about ATIOs/INOTs from per-LUN to per-channel data. This allows active commands to continue operation after LUN destruction. This also simplifies lookup of the data by tag in some situations. - Unify three restart_queue processing implementations. - Complete all ATIOs from restart_queue on LUN disable. - Delete ATIO private data when command completed or aborted, not depending on the ATIO being requeued, that was ugly hack and could never happen. CAM should always call ether XPT_CONT_TARGET_IO with status or XPT_ABORT. - Implement XPT_ABORT for queued ATIOs/INOTs to allow CAM do graceful shutdown, not depending on LUN disable, as it is done in ahd(4)/targ(4). - Unify isp_endcmd() arguments to make it more usable in generic code. - Remove never really used LUN state reference counter. MFC after: 2 weeks
2017-02-22 06:43:49 +00:00
__func__, str);
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
ccb->ccb_h.status = CAM_DEV_NOT_THERE;
Fix missing xpt_done() for ATIO/INOT on missing LUN. MFC after: 2 weeks
2017-02-24 12:11:17 +00:00
xpt_done(ccb);
Make a static chain of isp softcs- gdb usage becomes a lot easier. Add in a very large amount of target mode support code- this is just a first pass at this. It's a difficult thing because some of the code can be in platform independent areas (see isp_target.?) but a lot has to be in platform dependent areas because of not only the tight coupling of received commands/events and the specific OS subsystem but because the platform independent code has (deliberately) no event/wait mechanisms.
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;
Add support for ISP_FC_GETHINFO, which returns current connection topology, speed, loopid, WWPN/WWNN, etc. Beef up target mode. Add isp_handle_platform_notify_scsi and isp_handle_platform_notify_fc platform handlers to handle immediate notifies (isp_handle_platform_notify_scsi is still stubbed out). In implementation of isp_handle_platform_notify_fc, for IN_ABORT_TASK, peel off a pending XPT_IMMED_NOTIFY and call xpt_done on it and hope that somebody upstream is listening. Make sure on final CTIO2s that we set residual correctly. These are absolutely crucial. Make sure we set relative offset for each CTIO2 based upon bytes we've already xferred. This is what the private adjunct datat to the original ATIO is. Note state of command so we can figure out where to find it if we get an ABORT from the firmware. Make sure we *always* set CAM_TAG_ACTION_VALID for ATIO2s. Make sure we keep track of the original lun. If se sent status (or we're otherwise done with the command), don't forget to free the adjunct structure.
2002-06-16 05:08:02 +00:00
Make a static chain of isp softcs- gdb usage becomes a lot easier. Add in a very large amount of target mode support code- this is just a first pass at this. It's a difficult thing because some of the code can be in platform independent areas (see isp_target.?) but a lot has to be in platform dependent areas because of not only the tight coupling of received commands/events and the specific OS subsystem but because the platform independent code has (deliberately) no event/wait mechanisms.
2000-01-03 23:55:30 +00:00
if (ccb->ccb_h.func_code == XPT_ACCEPT_TARGET_IO) {
Fix multiple problems around LUN disable under load. - Move private data about ATIOs/INOTs from per-LUN to per-channel data. This allows active commands to continue operation after LUN destruction. This also simplifies lookup of the data by tag in some situations. - Unify three restart_queue processing implementations. - Complete all ATIOs from restart_queue on LUN disable. - Delete ATIO private data when command completed or aborted, not depending on the ATIO being requeued, that was ugly hack and could never happen. CAM should always call ether XPT_CONT_TARGET_IO with status or XPT_ABORT. - Implement XPT_ABORT for queued ATIOs/INOTs to allow CAM do graceful shutdown, not depending on LUN disable, as it is done in ahd(4)/targ(4). - Unify isp_endcmd() arguments to make it more usable in generic code. - Remove never really used LUN state reference counter. MFC after: 2 weeks
2017-02-22 06:43:49 +00:00
ccb->atio.tag_id = 0;
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
SLIST_INSERT_HEAD(&tptr->atios, &ccb->ccb_h, sim_links.sle);
Fix multiple problems around LUN disable under load. - Move private data about ATIOs/INOTs from per-LUN to per-channel data. This allows active commands to continue operation after LUN destruction. This also simplifies lookup of the data by tag in some situations. - Unify three restart_queue processing implementations. - Complete all ATIOs from restart_queue on LUN disable. - Delete ATIO private data when command completed or aborted, not depending on the ATIO being requeued, that was ugly hack and could never happen. CAM should always call ether XPT_CONT_TARGET_IO with status or XPT_ABORT. - Implement XPT_ABORT for queued ATIOs/INOTs to allow CAM do graceful shutdown, not depending on LUN disable, as it is done in ahd(4)/targ(4). - Unify isp_endcmd() arguments to make it more usable in generic code. - Remove never really used LUN state reference counter. MFC after: 2 weeks
2017-02-22 06:43:49 +00:00
ISP_PATH_PRT(isp, ISP_LOGTDEBUG2, ccb->ccb_h.path,
Remove not very useful ATIO/INOT stats. While there polish respective debug logging. MFC after: 2 weeks
2017-03-15 19:49:45 +00:00
"Put FREE ATIO\n");
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
} else if (ccb->ccb_h.func_code == XPT_IMMEDIATE_NOTIFY) {
Fix multiple problems around LUN disable under load. - Move private data about ATIOs/INOTs from per-LUN to per-channel data. This allows active commands to continue operation after LUN destruction. This also simplifies lookup of the data by tag in some situations. - Unify three restart_queue processing implementations. - Complete all ATIOs from restart_queue on LUN disable. - Delete ATIO private data when command completed or aborted, not depending on the ATIO being requeued, that was ugly hack and could never happen. CAM should always call ether XPT_CONT_TARGET_IO with status or XPT_ABORT. - Implement XPT_ABORT for queued ATIOs/INOTs to allow CAM do graceful shutdown, not depending on LUN disable, as it is done in ahd(4)/targ(4). - Unify isp_endcmd() arguments to make it more usable in generic code. - Remove never really used LUN state reference counter. MFC after: 2 weeks
2017-02-22 06:43:49 +00:00
ccb->cin1.seq_id = ccb->cin1.tag_id = 0;
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
SLIST_INSERT_HEAD(&tptr->inots, &ccb->ccb_h, sim_links.sle);
Fix multiple problems around LUN disable under load. - Move private data about ATIOs/INOTs from per-LUN to per-channel data. This allows active commands to continue operation after LUN destruction. This also simplifies lookup of the data by tag in some situations. - Unify three restart_queue processing implementations. - Complete all ATIOs from restart_queue on LUN disable. - Delete ATIO private data when command completed or aborted, not depending on the ATIO being requeued, that was ugly hack and could never happen. CAM should always call ether XPT_CONT_TARGET_IO with status or XPT_ABORT. - Implement XPT_ABORT for queued ATIOs/INOTs to allow CAM do graceful shutdown, not depending on LUN disable, as it is done in ahd(4)/targ(4). - Unify isp_endcmd() arguments to make it more usable in generic code. - Remove never really used LUN state reference counter. MFC after: 2 weeks
2017-02-22 06:43:49 +00:00
ISP_PATH_PRT(isp, ISP_LOGTDEBUG2, ccb->ccb_h.path,
Remove not very useful ATIO/INOT stats. While there polish respective debug logging. MFC after: 2 weeks
2017-03-15 19:49:45 +00:00
"Put FREE INOT\n");
Make a static chain of isp softcs- gdb usage becomes a lot easier. Add in a very large amount of target mode support code- this is just a first pass at this. It's a difficult thing because some of the code can be in platform independent areas (see isp_target.?) but a lot has to be in platform dependent areas because of not only the tight coupling of received commands/events and the specific OS subsystem but because the platform independent code has (deliberately) no event/wait mechanisms.
2000-01-03 23:55:30 +00:00
}
ccb->ccb_h.status = CAM_REQ_INPROG;
break;
}
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
case XPT_NOTIFY_ACKNOWLEDGE: /* notify ack */
Make a static chain of isp softcs- gdb usage becomes a lot easier. Add in a very large amount of target mode support code- this is just a first pass at this. It's a difficult thing because some of the code can be in platform independent areas (see isp_target.?) but a lot has to be in platform dependent areas because of not only the tight coupling of received commands/events and the specific OS subsystem but because the platform independent code has (deliberately) no event/wait mechanisms.
2000-01-03 23:55:30 +00:00
{
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
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);
Fix multiple problems around LUN disable under load. - Move private data about ATIOs/INOTs from per-LUN to per-channel data. This allows active commands to continue operation after LUN destruction. This also simplifies lookup of the data by tag in some situations. - Unify three restart_queue processing implementations. - Complete all ATIOs from restart_queue on LUN disable. - Delete ATIO private data when command completed or aborted, not depending on the ATIO being requeued, that was ugly hack and could never happen. CAM should always call ether XPT_CONT_TARGET_IO with status or XPT_ABORT. - Implement XPT_ABORT for queued ATIOs/INOTs to allow CAM do graceful shutdown, not depending on LUN disable, as it is done in ahd(4)/targ(4). - Unify isp_endcmd() arguments to make it more usable in generic code. - Remove never really used LUN state reference counter. MFC after: 2 weeks
2017-02-22 06:43:49 +00:00
ntp = isp_find_ntpd(isp, XS_CHANNEL(ccb), ccb->cna2.tag_id, ccb->cna2.seq_id);
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
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;
}
Fix multiple problems around LUN disable under load. - Move private data about ATIOs/INOTs from per-LUN to per-channel data. This allows active commands to continue operation after LUN destruction. This also simplifies lookup of the data by tag in some situations. - Unify three restart_queue processing implementations. - Complete all ATIOs from restart_queue on LUN disable. - Delete ATIO private data when command completed or aborted, not depending on the ATIO being requeued, that was ugly hack and could never happen. CAM should always call ether XPT_CONT_TARGET_IO with status or XPT_ABORT. - Implement XPT_ABORT for queued ATIOs/INOTs to allow CAM do graceful shutdown, not depending on LUN disable, as it is done in ahd(4)/targ(4). - Unify isp_endcmd() arguments to make it more usable in generic code. - Remove never really used LUN state reference counter. MFC after: 2 weeks
2017-02-22 06:43:49 +00:00
if (isp_handle_platform_target_notify_ack(isp, &ntp->nt,
Pass task management response information from CTL through CAM to isp(4), utilizing previously unused arg field of struct ccb_notify_acknowledge. This makes new QUERY TASK, QUERY TASK SET and QUERY ASYNC EVENT requests really functional for CAM target mode drivers.
2016-05-20 10:26:12 +00:00
(ccb->ccb_h.flags & CAM_SEND_STATUS) ? ccb->cna2.arg : 0)) {
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
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;
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
break;
}
Fix multiple problems around LUN disable under load. - Move private data about ATIOs/INOTs from per-LUN to per-channel data. This allows active commands to continue operation after LUN destruction. This also simplifies lookup of the data by tag in some situations. - Unify three restart_queue processing implementations. - Complete all ATIOs from restart_queue on LUN disable. - Delete ATIO private data when command completed or aborted, not depending on the ATIO being requeued, that was ugly hack and could never happen. CAM should always call ether XPT_CONT_TARGET_IO with status or XPT_ABORT. - Implement XPT_ABORT for queued ATIOs/INOTs to allow CAM do graceful shutdown, not depending on LUN disable, as it is done in ahd(4)/targ(4). - Unify isp_endcmd() arguments to make it more usable in generic code. - Remove never really used LUN state reference counter. MFC after: 2 weeks
2017-02-22 06:43:49 +00:00
isp_put_ntpd(isp, XS_CHANNEL(ccb), ntp);
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
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);
Make a static chain of isp softcs- gdb usage becomes a lot easier. Add in a very large amount of target mode support code- this is just a first pass at this. It's a difficult thing because some of the code can be in platform independent areas (see isp_target.?) but a lot has to be in platform dependent areas because of not only the tight coupling of received commands/events and the specific OS subsystem but because the platform independent code has (deliberately) no event/wait mechanisms.
2000-01-03 23:55:30 +00:00
break;
}
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
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);
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
break;
Make a static chain of isp softcs- gdb usage becomes a lot easier. Add in a very large amount of target mode support code- this is just a first pass at this. It's a difficult thing because some of the code can be in platform independent areas (see isp_target.?) but a lot has to be in platform dependent areas because of not only the tight coupling of received commands/events and the specific OS subsystem but because the platform independent code has (deliberately) no event/wait mechanisms.
2000-01-03 23:55:30 +00:00
#endif
Update QLogic ISP support for CAM. Add preliminary target mode support. Submitted by: Matthew Jacob <mjacob@feral.com>
1998-09-15 08:42:56 +00:00
case XPT_RESET_DEV: /* BDR the specified SCSI device */
Make a static chain of isp softcs- gdb usage becomes a lot easier. Add in a very large amount of target mode support code- this is just a first pass at this. It's a difficult thing because some of the code can be in platform independent areas (see isp_target.?) but a lot has to be in platform dependent areas because of not only the tight coupling of received commands/events and the specific OS subsystem but because the platform independent code has (deliberately) no event/wait mechanisms.
2000-01-03 23:55:30 +00:00
tgt = ccb->ccb_h.target_id;
tgt |= (bus << 16);
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
error = isp_control(isp, ISPCTL_RESET_DEV, bus, tgt);
Update QLogic ISP support for CAM. Add preliminary target mode support. Submitted by: Matthew Jacob <mjacob@feral.com>
1998-09-15 08:42:56 +00:00
if (error) {
ccb->ccb_h.status = CAM_REQ_CMP_ERR;
} else {
Change 1112791 by kenm@ken.spectrabsd8 on 2015/01/15 16:45:13 Fix SCSI status byte reporting on 4Gb and 8Gb Qlogic boards. The newer boards don't have the response field that indicates whether the SCSI status byte is present. You have to just look to see whether it is non-zero. The code was looking to see whether the sense length was valid before propagating the SCSI status byte (and sense information) up the stack. With a status like Reservation Conflict, there is no sense information, only the SCSI status byte. So it wasn't getting correctly returned. isp.c: In isp_intr(), if we are on a 2400 or 2500 type board and get a response, look at the actual contents of the SCSI status value and set the RQSF_GOT_STATUS flag accordingly so that return any SCSI status value we get. The RQSF_GOT_SENSE flag will get set later on if there is actual sense information returned. Submitted by: ken MFC after: 1 week Sponsored by: Spectra Logic MFSpectraBSD: 1112791 on 2015/01/15
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.
*/
Fix/improve CRN tracking.
2015-11-14 19:47:17 +00:00
if (IS_FC(isp))
isp_fcp_reset_crn(isp, bus, tgt, /*tgt_set*/ 1);
Change 1112791 by kenm@ken.spectrabsd8 on 2015/01/15 16:45:13 Fix SCSI status byte reporting on 4Gb and 8Gb Qlogic boards. The newer boards don't have the response field that indicates whether the SCSI status byte is present. You have to just look to see whether it is non-zero. The code was looking to see whether the sense length was valid before propagating the SCSI status byte (and sense information) up the stack. With a status like Reservation Conflict, there is no sense information, only the SCSI status byte. So it wasn't getting correctly returned. isp.c: In isp_intr(), if we are on a 2400 or 2500 type board and get a response, look at the actual contents of the SCSI status value and set the RQSF_GOT_STATUS flag accordingly so that return any SCSI status value we get. The RQSF_GOT_SENSE flag will get set later on if there is actual sense information returned. Submitted by: ken MFC after: 1 week Sponsored by: Spectra Logic MFSpectraBSD: 1112791 on 2015/01/15
2015-01-21 20:22:53 +00:00
Update QLogic ISP support for CAM. Add preliminary target mode support. Submitted by: Matthew Jacob <mjacob@feral.com>
1998-09-15 08:42:56 +00:00
ccb->ccb_h.status = CAM_REQ_CMP;
}
xpt_done(ccb);
break;
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
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:
Fix multiple problems around LUN disable under load. - Move private data about ATIOs/INOTs from per-LUN to per-channel data. This allows active commands to continue operation after LUN destruction. This also simplifies lookup of the data by tag in some situations. - Unify three restart_queue processing implementations. - Complete all ATIOs from restart_queue on LUN disable. - Delete ATIO private data when command completed or aborted, not depending on the ATIO being requeued, that was ugly hack and could never happen. CAM should always call ether XPT_CONT_TARGET_IO with status or XPT_ABORT. - Implement XPT_ABORT for queued ATIOs/INOTs to allow CAM do graceful shutdown, not depending on LUN disable, as it is done in ahd(4)/targ(4). - Unify isp_endcmd() arguments to make it more usable in generic code. - Remove never really used LUN state reference counter. MFC after: 2 weeks
2017-02-22 06:43:49 +00:00
isp_abort_atio(isp, ccb);
break;
case XPT_IMMEDIATE_NOTIFY:
isp_abort_inot(isp, ccb);
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
break;
#endif
case XPT_SCSI_IO:
Pass correct command that should be aborted to ISPCTL_ABORT_CMD. This makes XPT_ABORT to work for me on initiator side of isp(4). Previous code was trying to abort the XPT_ABORT itself and failed. MFC after: 1 week
2014-07-08 13:01:36 +00:00
error = isp_control(isp, ISPCTL_ABORT_CMD, accb);
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
if (error) {
ccb->ccb_h.status = CAM_UA_ABORT;
Add back some CAM_NEW_TRAN code to make backporting to RELENG_6 easier.
2006-12-18 23:50:30 +00:00
} else {
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
ccb->ccb_h.status = CAM_REQ_CMP;
Add back some CAM_NEW_TRAN code to make backporting to RELENG_6 easier.
2006-12-18 23:50:30 +00:00
}
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
break;
default:
ccb->ccb_h.status = CAM_REQ_INVALID;
break;
}
Don't leak CCBs for every ABORT. Submitted by: Ken Merry MFC after: One week
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.
*/
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
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);
a) clean up some declaration stuff (i.e., make more modern with respect to getting rid u_int for uint and so on). b) Turn back on 64 bit DAC support. Cheeze it a bit in that we have two DMA callback functions- one when we have bus_addr_t > 4 bits in width and the other which should be normal. Even Cheezier in that we turn off setting up DMA maps to be BUS_SPACE_MAXADDR if we're in ISP_TARGET_MODE. More work on this in a week or so. c) Tested under amd64 and 1MB DFLTPHYS, sparc64, i386 (PAE, but insufficient memory to really test > 4GB). LINT check under amd64. MFC after: 1 month
2006-02-15 00:31:48 +00:00
uint16_t *dptr;
Add CAM_NEW_TRAN_CODE support. Use correct CAMLOCK_2_ISPLOCK macros. For fibre channel, start going for the gusto and using AC_FOUND_DEVICE and AC_LOST_DEVICE calls to xpt_async when devices appear and disappear as the loop or fabric changes. ISPASYNC_FW_CRASH is the async event code where the platform layer deals with a firmware crash.
2001-07-04 18:54:29 +00:00
Fix XPT_GET_TRANSPORT_SETTINGS to zero validity and flags- this was causing us to not negotiate sync at all, or at random.
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;
}
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
Add CAM_NEW_TRAN_CODE support. Use correct CAMLOCK_2_ISPLOCK macros. For fibre channel, start going for the gusto and using AC_FOUND_DEVICE and AC_LOST_DEVICE calls to xpt_async when devices appear and disappear as the loop or fabric changes. ISPASYNC_FW_CRASH is the async event code where the platform layer deals with a firmware crash.
2001-07-04 18:54:29 +00:00
/*
Redo how we manage SCSI device settings- have a 3rd flags (nvram) that records either what's in NVRAM or what the safe defaults would be if we lack NVRAM. Then we rename cur_XXXX to actv_XXXX (these are the currently active settings) and the dev_XXX settings to goal_XXXX (these are the settings which we want cur_XXXX to converge to). This probably isn't entirely final as yet- but it's a lot closer to now being what it should be, including allowing camcontrol to actually set specific settings.
2001-07-30 01:00:21 +00:00
* We always update (internally) from goal_flags
Add CAM_NEW_TRAN_CODE support. Use correct CAMLOCK_2_ISPLOCK macros. For fibre channel, start going for the gusto and using AC_FOUND_DEVICE and AC_LOST_DEVICE calls to xpt_async when devices appear and disappear as the loop or fabric changes. ISPASYNC_FW_CRASH is the async event code where the platform layer deals with a firmware crash.
2001-07-04 18:54:29 +00:00
* so any request to change settings just gets
* vectored to that location.
*/
Redo how we manage SCSI device settings- have a 3rd flags (nvram) that records either what's in NVRAM or what the safe defaults would be if we lack NVRAM. Then we rename cur_XXXX to actv_XXXX (these are the currently active settings) and the dev_XXX settings to goal_XXXX (these are the settings which we want cur_XXXX to converge to). This probably isn't entirely final as yet- but it's a lot closer to now being what it should be, including allowing camcontrol to actually set specific settings.
2001-07-30 01:00:21 +00:00
dptr = &sdp->isp_devparam[tgt].goal_flags;
Add CAM_NEW_TRAN_CODE support. Use correct CAMLOCK_2_ISPLOCK macros. For fibre channel, start going for the gusto and using AC_FOUND_DEVICE and AC_LOST_DEVICE calls to xpt_async when devices appear and disappear as the loop or fabric changes. ISPASYNC_FW_CRASH is the async event code where the platform layer deals with a firmware crash.
2001-07-04 18:54:29 +00:00
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
*/
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
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)) {
Add CAM_NEW_TRAN_CODE support. Use correct CAMLOCK_2_ISPLOCK macros. For fibre channel, start going for the gusto and using AC_FOUND_DEVICE and AC_LOST_DEVICE calls to xpt_async when devices appear and disappear as the loop or fabric changes. ISPASYNC_FW_CRASH is the async event code where the platform layer deals with a firmware crash.
2001-07-04 18:54:29 +00:00
*dptr |= DPARM_SYNC;
Redo how we manage SCSI device settings- have a 3rd flags (nvram) that records either what's in NVRAM or what the safe defaults would be if we lack NVRAM. Then we rename cur_XXXX to actv_XXXX (these are the currently active settings) and the dev_XXX settings to goal_XXXX (these are the settings which we want cur_XXXX to converge to). This probably isn't entirely final as yet- but it's a lot closer to now being what it should be, including allowing camcontrol to actually set specific settings.
2001-07-30 01:00:21 +00:00
/*
* XXX: CHECK FOR LEGALITY
*/
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
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;
Add CAM_NEW_TRAN_CODE support. Use correct CAMLOCK_2_ISPLOCK macros. For fibre channel, start going for the gusto and using AC_FOUND_DEVICE and AC_LOST_DEVICE calls to xpt_async when devices appear and disappear as the loop or fabric changes. ISPASYNC_FW_CRASH is the async event code where the platform layer deals with a firmware crash.
2001-07-04 18:54:29 +00:00
} else {
*dptr &= ~DPARM_SYNC;
}
Adjust various SCSI drivers to handle either a 32-bit or 64-bit lun_id_t, mostly by adjustments to debugging printf() format specifiers. For high numbered LUNs, also switch to printing them in hex as per SAM-5. MFC after: 2 weeks
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,
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
sdp->isp_devparam[tgt].goal_offset, sdp->isp_devparam[tgt].goal_period);
Update QLogic ISP support for CAM. Add preliminary target mode support. Submitted by: Matthew Jacob <mjacob@feral.com>
1998-09-15 08:42:56 +00:00
sdp->isp_devparam[tgt].dev_update = 1;
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
sdp->update = 1;
Update QLogic ISP support for CAM. Add preliminary target mode support. Submitted by: Matthew Jacob <mjacob@feral.com>
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;
Add in isp_debug variable. It defaults to zero unless CAMDEBUG is defined where it defaults to one. Change simq width allocation to the max number of commands supported by the HBA after f/w fires up- not the constant MAXISPREQUEST value. Do some stylistic changes.
1999-10-17 18:50:47 +00:00
if (IS_FC(isp)) {
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
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;
Add CAM_NEW_TRAN_CODE support. Use correct CAMLOCK_2_ISPLOCK macros. For fibre channel, start going for the gusto and using AC_FOUND_DEVICE and AC_LOST_DEVICE calls to xpt_async when devices appear and disappear as the loop or fabric changes. ISPASYNC_FW_CRASH is the async event code where the platform layer deals with a firmware crash.
2001-07-04 18:54:29 +00:00
cts->protocol = PROTO_SCSI;
cts->protocol_version = SCSI_REV_2;
cts->transport = XPORT_FC;
cts->transport_version = 0;
Find another spot where tagged command queueing got accidentally nuked.
2006-12-09 01:30:05 +00:00
scsi->valid = CTS_SCSI_VALID_TQ;
scsi->flags = CTS_SCSI_FLAGS_TAG_ENB;
Add CAM_NEW_TRAN_CODE support. Use correct CAMLOCK_2_ISPLOCK macros. For fibre channel, start going for the gusto and using AC_FOUND_DEVICE and AC_LOST_DEVICE calls to xpt_async when devices appear and disappear as the loop or fabric changes. ISPASYNC_FW_CRASH is the async event code where the platform layer deals with a firmware crash.
2001-07-04 18:54:29 +00:00
fc->valid = CTS_FC_VALID_SPEED;
Export 4Gbps Fibre Channel link speed correctly with inquiry commands. Approved by: re (kensmith) MFC after: 3 days
2007-08-23 15:57:13 +00:00
fc->bitrate = 100000;
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
fc->bitrate *= fcp->isp_gbspeed;
Remove extra level of target ID indirection (isp_dev_map). FreeBSD never had limitation on number of target IDs, and there is no any other requirement to allocate them densely. Since slots of port database already populated just sequentially, there is no much need for another indirection to allocate sequentially too.
2015-07-05 02:09:46 +00:00
if (tgt < MAX_FC_TARG) {
fcportdb_t *lp = &fcp->portdb[tgt];
Add CAM_NEW_TRAN_CODE support. Use correct CAMLOCK_2_ISPLOCK macros. For fibre channel, start going for the gusto and using AC_FOUND_DEVICE and AC_LOST_DEVICE calls to xpt_async when devices appear and disappear as the loop or fabric changes. ISPASYNC_FW_CRASH is the async event code where the platform layer deals with a firmware crash.
2001-07-04 18:54:29 +00:00
fc->wwnn = lp->node_wwn;
fc->wwpn = lp->port_wwn;
fc->port = lp->portid;
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
fc->valid |= CTS_FC_VALID_WWNN | CTS_FC_VALID_WWPN | CTS_FC_VALID_PORT;
Add CAM_NEW_TRAN_CODE support. Use correct CAMLOCK_2_ISPLOCK macros. For fibre channel, start going for the gusto and using AC_FOUND_DEVICE and AC_LOST_DEVICE calls to xpt_async when devices appear and disappear as the loop or fabric changes. ISPASYNC_FW_CRASH is the async event code where the platform layer deals with a firmware crash.
2001-07-04 18:54:29 +00:00
}
Update QLogic ISP support for CAM. Add preliminary target mode support. Submitted by: Matthew Jacob <mjacob@feral.com>
1998-09-15 08:42:56 +00:00
} else {
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
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);
a) clean up some declaration stuff (i.e., make more modern with respect to getting rid u_int for uint and so on). b) Turn back on 64 bit DAC support. Cheeze it a bit in that we have two DMA callback functions- one when we have bus_addr_t > 4 bits in width and the other which should be normal. Even Cheezier in that we turn off setting up DMA maps to be BUS_SPACE_MAXADDR if we're in ISP_TARGET_MODE. More work on this in a week or so. c) Tested under amd64 and 1MB DFLTPHYS, sparc64, i386 (PAE, but insufficient memory to really test > 4GB). LINT check under amd64. MFC after: 1 month
2006-02-15 00:31:48 +00:00
uint16_t dval, pval, oval;
Update QLogic ISP support for CAM. Add preliminary target mode support. Submitted by: Matthew Jacob <mjacob@feral.com>
1998-09-15 08:42:56 +00:00
Add CAM_NEW_TRAN_CODE support. Use correct CAMLOCK_2_ISPLOCK macros. For fibre channel, start going for the gusto and using AC_FOUND_DEVICE and AC_LOST_DEVICE calls to xpt_async when devices appear and disappear as the loop or fabric changes. ISPASYNC_FW_CRASH is the async event code where the platform layer deals with a firmware crash.
2001-07-04 18:54:29 +00:00
if (IS_CURRENT_SETTINGS(cts)) {
When asked to get the current transfer settings go do a dev_refresh isp_update call to get a better chance at seeing whether a recent settings change has latched up.
1999-05-12 19:00:16 +00:00
sdp->isp_devparam[tgt].dev_refresh = 1;
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
sdp->update = 1;
(void) isp_control(isp, ISPCTL_UPDATE_PARAMS, bus);
Redo how we manage SCSI device settings- have a 3rd flags (nvram) that records either what's in NVRAM or what the safe defaults would be if we lack NVRAM. Then we rename cur_XXXX to actv_XXXX (these are the currently active settings) and the dev_XXX settings to goal_XXXX (these are the settings which we want cur_XXXX to converge to). This probably isn't entirely final as yet- but it's a lot closer to now being what it should be, including allowing camcontrol to actually set specific settings.
2001-07-30 01:00:21 +00:00
dval = sdp->isp_devparam[tgt].actv_flags;
oval = sdp->isp_devparam[tgt].actv_offset;
pval = sdp->isp_devparam[tgt].actv_period;
Add in 1080 LVD support and some basis also for the 1240. The port database printout is now enabled.
1999-03-25 22:52:45 +00:00
} else {
Redo how we manage SCSI device settings- have a 3rd flags (nvram) that records either what's in NVRAM or what the safe defaults would be if we lack NVRAM. Then we rename cur_XXXX to actv_XXXX (these are the currently active settings) and the dev_XXX settings to goal_XXXX (these are the settings which we want cur_XXXX to converge to). This probably isn't entirely final as yet- but it's a lot closer to now being what it should be, including allowing camcontrol to actually set specific settings.
2001-07-30 01:00:21 +00:00
dval = sdp->isp_devparam[tgt].nvrm_flags;
oval = sdp->isp_devparam[tgt].nvrm_offset;
pval = sdp->isp_devparam[tgt].nvrm_period;
Add in 1080 LVD support and some basis also for the 1240. The port database printout is now enabled.
1999-03-25 22:52:45 +00:00
}
Update QLogic ISP support for CAM. Add preliminary target mode support. Submitted by: Matthew Jacob <mjacob@feral.com>
1998-09-15 08:42:56 +00:00
Add CAM_NEW_TRAN_CODE support. Use correct CAMLOCK_2_ISPLOCK macros. For fibre channel, start going for the gusto and using AC_FOUND_DEVICE and AC_LOST_DEVICE calls to xpt_async when devices appear and disappear as the loop or fabric changes. ISPASYNC_FW_CRASH is the async event code where the platform layer deals with a firmware crash.
2001-07-04 18:54:29 +00:00
cts->protocol = PROTO_SCSI;
cts->protocol_version = SCSI_REV_2;
cts->transport = XPORT_SPI;
cts->transport_version = 2;
Fix XPT_GET_TRANSPORT_SETTINGS to zero validity and flags- this was causing us to not negotiate sync at all, or at random.
2006-12-03 07:22:15 +00:00
spi->valid = 0;
scsi->valid = 0;
spi->flags = 0;
scsi->flags = 0;
Add CAM_NEW_TRAN_CODE support. Use correct CAMLOCK_2_ISPLOCK macros. For fibre channel, start going for the gusto and using AC_FOUND_DEVICE and AC_LOST_DEVICE calls to xpt_async when devices appear and disappear as the loop or fabric changes. ISPASYNC_FW_CRASH is the async event code where the platform layer deals with a firmware crash.
2001-07-04 18:54:29 +00:00
if (dval & DPARM_DISC) {
spi->flags |= CTS_SPI_FLAGS_DISC_ENB;
}
Redo how we manage SCSI device settings- have a 3rd flags (nvram) that records either what's in NVRAM or what the safe defaults would be if we lack NVRAM. Then we rename cur_XXXX to actv_XXXX (these are the currently active settings) and the dev_XXX settings to goal_XXXX (these are the settings which we want cur_XXXX to converge to). This probably isn't entirely final as yet- but it's a lot closer to now being what it should be, including allowing camcontrol to actually set specific settings.
2001-07-30 01:00:21 +00:00
if ((dval & DPARM_SYNC) && oval && pval) {
Add CAM_NEW_TRAN_CODE support. Use correct CAMLOCK_2_ISPLOCK macros. For fibre channel, start going for the gusto and using AC_FOUND_DEVICE and AC_LOST_DEVICE calls to xpt_async when devices appear and disappear as the loop or fabric changes. ISPASYNC_FW_CRASH is the async event code where the platform layer deals with a firmware crash.
2001-07-04 18:54:29 +00:00
spi->sync_offset = oval;
spi->sync_period = pval;
Fix XPT_GET_TRANSPORT_SETTINGS to zero validity and flags- this was causing us to not negotiate sync at all, or at random.
2006-12-03 07:22:15 +00:00
} else {
spi->sync_offset = 0;
spi->sync_period = 0;
Add CAM_NEW_TRAN_CODE support. Use correct CAMLOCK_2_ISPLOCK macros. For fibre channel, start going for the gusto and using AC_FOUND_DEVICE and AC_LOST_DEVICE calls to xpt_async when devices appear and disappear as the loop or fabric changes. ISPASYNC_FW_CRASH is the async event code where the platform layer deals with a firmware crash.
2001-07-04 18:54:29 +00:00
}
Fix XPT_GET_TRANSPORT_SETTINGS to zero validity and flags- this was causing us to not negotiate sync at all, or at random.
2006-12-03 07:22:15 +00:00
spi->valid |= CTS_SPI_VALID_SYNC_OFFSET;
spi->valid |= CTS_SPI_VALID_SYNC_RATE;
Add CAM_NEW_TRAN_CODE support. Use correct CAMLOCK_2_ISPLOCK macros. For fibre channel, start going for the gusto and using AC_FOUND_DEVICE and AC_LOST_DEVICE calls to xpt_async when devices appear and disappear as the loop or fabric changes. ISPASYNC_FW_CRASH is the async event code where the platform layer deals with a firmware crash.
2001-07-04 18:54:29 +00:00
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;
Fix XPT_GET_TRANSPORT_SETTINGS to zero validity and flags- this was causing us to not negotiate sync at all, or at random.
2006-12-03 07:22:15 +00:00
if (dval & DPARM_TQING) {
scsi->flags |= CTS_SCSI_FLAGS_TAG_ENB;
}
Add CAM_NEW_TRAN_CODE support. Use correct CAMLOCK_2_ISPLOCK macros. For fibre channel, start going for the gusto and using AC_FOUND_DEVICE and AC_LOST_DEVICE calls to xpt_async when devices appear and disappear as the loop or fabric changes. ISPASYNC_FW_CRASH is the async event code where the platform layer deals with a firmware crash.
2001-07-04 18:54:29 +00:00
spi->valid |= CTS_SPI_VALID_DISC;
}
Adjust various SCSI drivers to handle either a 32-bit or 64-bit lun_id_t, mostly by adjustments to debugging printf() format specifiers. For high numbered LUNs, also switch to printing them in hex as per SAM-5. MFC after: 2 weeks
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);
Update QLogic ISP support for CAM. Add preliminary target mode support. Submitted by: Matthew Jacob <mjacob@feral.com>
1998-09-15 08:42:56 +00:00
}
ccb->ccb_h.status = CAM_REQ_CMP;
xpt_done(ccb);
break;
case XPT_CALC_GEOMETRY:
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
cam_calc_geometry(&ccb->ccg, 1);
xpt_done(ccb);
break;
Update QLogic ISP support for CAM. Add preliminary target mode support. Submitted by: Matthew Jacob <mjacob@feral.com>
1998-09-15 08:42:56 +00:00
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
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;
Update QLogic ISP support for CAM. Add preliminary target mode support. Submitted by: Matthew Jacob <mjacob@feral.com>
1998-09-15 08:42:56 +00:00
xpt_done(ccb);
break;
}
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
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);
Some more gratuitous format and name changes. Pull in some target mode changes from a private branch. Pull in some more RELENG_4 compilation changes. A lot of lines changed, but not much content change yet.
2006-04-21 18:30:01 +00:00
} else {
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
xpt_async(AC_BUS_RESET, ISP_SPI_PC(isp, bus)->path, 0);
Some more gratuitous format and name changes. Pull in some target mode changes from a private branch. Pull in some more RELENG_4 compilation changes. A lot of lines changed, but not much content change yet.
2006-04-21 18:30:01 +00:00
}
ccb->ccb_h.status = CAM_REQ_CMP;
xpt_done(ccb);
break;
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
case XPT_TERM_IO: /* Terminate the I/O process */
ccb->ccb_h.status = CAM_REQ_INVALID;
Update QLogic ISP support for CAM. Add preliminary target mode support. Submitted by: Matthew Jacob <mjacob@feral.com>
1998-09-15 08:42:56 +00:00
xpt_done(ccb);
break;
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
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;
Fixes zombie device and loop down timers so that they work more than once. Use taskqueues to do the actual work. Fix an offset line. Fix isp_prt so that prints from just one buffer, which makes it appear cleanly cleanly in logs on SMP systems. Approved by: re (kib) MFC after: 1 month
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);
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
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) {
Clean up and complete the incomplete deferred enable code. Make the default role NONE if target mode is selected. This allows ctl(8) to switch to/from target mode via knob settings. If we default to role 'none', this causes a reset of the 24XX f/w which then causes initiators to wake up and notice when we come online. Reviewed by: kdm MFC after: 2 weeks Sponsored by: Spectralogic
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);
Drop discovered targets when initiator role is disabled.
2015-07-04 18:38:46 +00:00
if (isp_control(isp, ISPCTL_CHANGE_ROLE,
bus, newrole) != 0) {
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
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;
}
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
}
Allow fibre channel 'bus resets' to go through. Handle Loop Down/Loop Up events by freezing/unfreezing the simq- nice to have such control at this level! Do bus resets in attach layer (non-CAM defined code).
1999-02-09 01:08:38 +00:00
}
Update QLogic ISP support for CAM. Add preliminary target mode support. Submitted by: Matthew Jacob <mjacob@feral.com>
1998-09-15 08:42:56 +00:00
xpt_done(ccb);
break;
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
}
Move to new value for XPT_GET_SIM_KNOB to avoid clash with XPT_ATA_IO.
2016-03-10 06:25:05 +00:00
case XPT_GET_SIM_KNOB_OLD: /* Get SIM knobs -- compat value */
Clean up and complete the incomplete deferred enable code. Make the default role NONE if target mode is selected. This allows ctl(8) to switch to/from target mode via knob settings. If we default to role 'none', this causes a reset of the 24XX f/w which then causes initiators to wake up and notice when we come online. Reviewed by: kdm MFC after: 2 weeks Sponsored by: Spectralogic
2012-06-01 23:29:48 +00:00
case XPT_GET_SIM_KNOB: /* Get SIM knobs */
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
{
struct ccb_sim_knob *kp = &ccb->knob;
Update QLogic ISP support for CAM. Add preliminary target mode support. Submitted by: Matthew Jacob <mjacob@feral.com>
1998-09-15 08:42:56 +00:00
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
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;
}
Update QLogic ISP support for CAM. Add preliminary target mode support. Submitted by: Matthew Jacob <mjacob@feral.com>
1998-09-15 08:42:56 +00:00
xpt_done(ccb);
break;
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
}
Update QLogic ISP support for CAM. Add preliminary target mode support. Submitted by: Matthew Jacob <mjacob@feral.com>
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;
Make a static chain of isp softcs- gdb usage becomes a lot easier. Add in a very large amount of target mode support code- this is just a first pass at this. It's a difficult thing because some of the code can be in platform independent areas (see isp_target.?) but a lot has to be in platform dependent areas because of not only the tight coupling of received commands/events and the specific OS subsystem but because the platform independent code has (deliberately) no event/wait mechanisms.
2000-01-03 23:55:30 +00:00
#ifdef ISP_TARGET_MODE
Rip off target mode support for parallel SCSI QLogic adapters. Hacks to enable target mode there complicated code, while didn't really work. And for outdated hardware fixing it is not really interesting. Initiator mode tested with Qlogic 1080 adapter is still working fine.
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
Make a static chain of isp softcs- gdb usage becomes a lot easier. Add in a very large amount of target mode support code- this is just a first pass at this. It's a difficult thing because some of the code can be in platform independent areas (see isp_target.?) but a lot has to be in platform dependent areas because of not only the tight coupling of received commands/events and the specific OS subsystem but because the platform independent code has (deliberately) no event/wait mechanisms.
2000-01-03 23:55:30 +00:00
#endif
Rip off target mode support for parallel SCSI QLogic adapters. Hacks to enable target mode there complicated code, while didn't really work. And for outdated hardware fixing it is not really interesting. Initiator mode tested with Qlogic 1080 adapter is still working fine.
2015-11-23 10:06:19 +00:00
cpi->target_sprt = 0;
Update QLogic ISP support for CAM. Add preliminary target mode support. Submitted by: Matthew Jacob <mjacob@feral.com>
1998-09-15 08:42:56 +00:00
cpi->hba_eng_cnt = 0;
Clarify and cleanup some CAM queueing breakages.
1999-08-16 20:11:45 +00:00
cpi->max_target = ISP_MAX_TARGETS(isp) - 1;
Add PIM_EXTLUNS support to isp(4) driver. Now 24xx and above chips support full 8-byte LUN address space. Older FC chips may support up to 16K LUNs when firmware allows. Tested in both initiator and target modes for 23xx, 24xx and 25xx.
2015-10-24 17:34:40 +00:00
cpi->max_lun = ISP_MAX_LUNS(isp) == 0 ?
255 : ISP_MAX_LUNS(isp) - 1;
Clarify and cleanup some CAM queueing breakages.
1999-08-16 20:11:45 +00:00
cpi->bus_id = cam_sim_bus(sim);
Unify initiator and target DMA setup and command sending. The code is so alike that it is pointless to keep it separate. MFC after: 2 weeks
2017-03-24 14:44:03 +00:00
if (sizeof (bus_size_t) > 4)
Export the maxio field in the CAM XPT_PATH_INQ CCB in the isp(4) driver. This tells consumers up the stack the maximum I/O size that the controller can handle. The I/O size is bounded by the number of scatter/gather segments the controller can handle and the page size. For an amd64 system, it works out to around 5MB. Reviewed by: mjacob MFC after: 3 days Sponsored by: Spectra Logic
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;
Add in 1080 LVD support and some basis also for the 1240. The port database printout is now enabled.
1999-03-25 22:52:45 +00:00
if (IS_FC(isp)) {
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
fcparam *fcp = FCPARAM(isp, bus);
Flag isp(4) as supporting unmapped I/O; all necessary conversion actually already has been done as part of r246713. Reviewed by: mjacob
2013-06-04 11:05:57 +00:00
cpi->hba_misc = PIM_NOBUSRESET | PIM_UNMAPPED;
Remove code for unsupported FreeBSD versions. MFC after: 2 weeks
2017-03-12 14:17:57 +00:00
cpi->hba_misc |= PIM_EXTLUNS | PIM_NOSCAN;
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
Clarify and cleanup some CAM queueing breakages.
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
/*
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
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
*/
Most of these changes to isp are to allow for isp.ko unloading. We also revive loop down freezes. We also externaliz within isp isp_prt_endcmd so something outside the core module can print something about a command completing. Also some work in progress to assist in handling timed out commands better. Partially Sponsored by: Panasas Approved by: re (kib) MFC after: 1 month
2011-08-13 23:34:17 +00:00
if (IS_25XX(isp)) {
cpi->base_transfer_speed = 8000000;
} else if (IS_24XX(isp)) {
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
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;
}
Clarify and cleanup some CAM queueing breakages.
1999-08-16 20:11:45 +00:00
cpi->hba_inquiry = PI_TAG_ABLE;
Add CAM_NEW_TRAN_CODE support. Use correct CAMLOCK_2_ISPLOCK macros. For fibre channel, start going for the gusto and using AC_FOUND_DEVICE and AC_LOST_DEVICE calls to xpt_async when devices appear and disappear as the loop or fabric changes. ISPASYNC_FW_CRASH is the async event code where the platform layer deals with a firmware crash.
2001-07-04 18:54:29 +00:00
cpi->transport = XPORT_FC;
Add back some CAM_NEW_TRAN code to make backporting to RELENG_6 easier.
2006-12-18 23:50:30 +00:00
cpi->transport_version = 0;
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
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;
Update QLogic ISP support for CAM. Add preliminary target mode support. Submitted by: Matthew Jacob <mjacob@feral.com>
1998-09-15 08:42:56 +00:00
} else {
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
sdparam *sdp = SDPARAM(isp, bus);
Clarify and cleanup some CAM queueing breakages.
1999-08-16 20:11:45 +00:00
cpi->hba_inquiry = PI_SDTR_ABLE|PI_TAG_ABLE|PI_WIDE_16;
Flag isp(4) as supporting unmapped I/O; all necessary conversion actually already has been done as part of r246713. Reviewed by: mjacob
2013-06-04 11:05:57 +00:00
cpi->hba_misc = PIM_UNMAPPED;
A large set of changes to handle dual bus adapters.
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;
Add CAM_NEW_TRAN_CODE support. Use correct CAMLOCK_2_ISPLOCK macros. For fibre channel, start going for the gusto and using AC_FOUND_DEVICE and AC_LOST_DEVICE calls to xpt_async when devices appear and disappear as the loop or fabric changes. ISPASYNC_FW_CRASH is the async event code where the platform layer deals with a firmware crash.
2001-07-04 18:54:29 +00:00
cpi->transport = XPORT_SPI;
Add back some CAM_NEW_TRAN code to make backporting to RELENG_6 easier.
2006-12-18 23:50:30 +00:00
cpi->transport_version = 2;
Update QLogic ISP support for CAM. Add preliminary target mode support. Submitted by: Matthew Jacob <mjacob@feral.com>
1998-09-15 08:42:56 +00:00
}
Add CAM_NEW_TRAN_CODE support. Use correct CAMLOCK_2_ISPLOCK macros. For fibre channel, start going for the gusto and using AC_FOUND_DEVICE and AC_LOST_DEVICE calls to xpt_async when devices appear and disappear as the loop or fabric changes. ISPASYNC_FW_CRASH is the async event code where the platform layer deals with a firmware crash.
2001-07-04 18:54:29 +00:00
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);
Update QLogic ISP support for CAM. Add preliminary target mode support. Submitted by: Matthew Jacob <mjacob@feral.com>
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;
}
}
make a real "done" func; clarify some LUN widths
1998-12-05 01:31:21 +00:00
void
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
isp_done(XS_T *sccb)
make a real "done" func; clarify some LUN widths
1998-12-05 01:31:21 +00:00
{
Some more gratuitous format and name changes. Pull in some target mode changes from a private branch. Pull in some more RELENG_4 compilation changes. A lot of lines changed, but not much content change yet.
2006-04-21 18:30:01 +00:00
ispsoftc_t *isp = XS_ISP(sccb);
Most of these changes to isp are to allow for isp.ko unloading. We also revive loop down freezes. We also externaliz within isp isp_prt_endcmd so something outside the core module can print something about a command completing. Also some work in progress to assist in handling timed out commands better. Partially Sponsored by: Panasas Approved by: re (kib) MFC after: 1 month
2011-08-13 23:34:17 +00:00
uint32_t status;
make a real "done" func; clarify some LUN widths
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
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
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)) {
make a real "done" func; clarify some LUN widths
1998-12-05 01:31:21 +00:00
sccb->ccb_h.status &= ~CAM_STATUS_MASK;
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
if ((sccb->scsi_status == SCSI_STATUS_CHECK_COND) && (sccb->ccb_h.status & CAM_AUTOSNS_VALID) == 0) {
Clean up some debug printing. Find the correct lun when SCCLUN is defined. If we complete with a check condition but no sense data, say we had an AUTOSENSE failure.
2000-01-04 03:45:49 +00:00
sccb->ccb_h.status |= CAM_AUTOSENSE_FAIL;
} else {
sccb->ccb_h.status |= CAM_SCSI_STATUS_ERROR;
}
make a real "done" func; clarify some LUN widths
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
Clarify and cleanup some CAM queueing breakages.
1999-08-16 20:11:45 +00:00
sccb->ccb_h.status &= ~CAM_SIM_QUEUED;
Most of these changes to isp are to allow for isp.ko unloading. We also revive loop down freezes. We also externaliz within isp isp_prt_endcmd so something outside the core module can print something about a command completing. Also some work in progress to assist in handling timed out commands better. Partially Sponsored by: Panasas Approved by: re (kib) MFC after: 1 month
2011-08-13 23:34:17 +00:00
status = sccb->ccb_h.status & CAM_STATUS_MASK;
Try to slight untangle I/O and loop status handling. MFC after: 2 weeks
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);
make a real "done" func; clarify some LUN widths
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
Fix reported_gone setting, missed in some cases. This makes driver better track reported CAM_SEL_TIMEOUTs to properly report device reappearance later. This fixes target 0 not reappearing after initiator mode disabled and then reenabled. MFC after: 3 days
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);
}
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
xpt_done((union ccb *) sccb);
make a real "done" func; clarify some LUN widths
1998-12-05 01:31:21 +00:00
}
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
void
isp_async(ispsoftc_t *isp, ispasync_t cmd, ...)
{
Unify port database use for target and initiator roles. Aside from cleaner and more consistent code, this allows ports to be both target and initiator same time, and easily switch from any role to any. Sponsored by: iXsystems, Inc.
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];
Push things closer to path failover by implementing loop down and gone device timers and zombie state entries. There are tunables that can be used to select a number of parameters. loop_down_limit - how long to wait for loop to come back up before declaring all devices dead (default 300 seconds) gone_device_time- how long to wait for a device that has appeared to leave the loop or fabric to reappear (default 30 seconds) Internal tunables include (which should be externalized): quick_boot_time- how long to wait when booting for loop to come up change_is_bad- whether or not to accept devices with the same WWNN/WWPN that reappear at a different PortID as being the 'same' device. Keen students of some of the subtle issues here will ask how one can keep devices from being re-accepted at all (the answer is to set a gone_device_time to zero- that effectively would be the same thing).
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;
Add 4Gb (24XX) support and lay the foundation for a lot of new stuff.
2006-11-02 03:21:32 +00:00
fcportdb_t *lp;
Fix cases where we've managed to get a Loop UP event prior to initializing the loop down counter, as well as other things. This was brought to my attention with a different fix, more for RELENG_7- this one covers the multiple channel case. PR: 140438 MFC after: 1 month
2009-12-04 03:34:12 +00:00
struct isp_fc *fc;
Add 4Gb (24XX) support and lay the foundation for a lot of new stuff.
2006-11-02 03:21:32 +00:00
struct cam_path *tmppath;
Unify port database use for target and initiator roles. Aside from cleaner and more consistent code, this allows ports to be both target and initiator same time, and easily switch from any role to any. Sponsored by: iXsystems, Inc.
2015-07-13 15:11:05 +00:00
struct ac_contract ac;
struct ac_device_changed *adc;
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
va_list ap;
Add 4Gb (24XX) support and lay the foundation for a lot of new stuff.
2006-11-02 03:21:32 +00:00
Implement and use Fast Posting for both parallel && fibre. Redo a bit of the startup code. Implement a call to outer framework function so that asynchronous events can be handled (e.g., speed negotiation, target mode). Roll internal release tags.
1999-01-30 07:29:00 +00:00
switch (cmd) {
case ISPASYNC_NEW_TGT_PARAMS:
Clarify and cleanup some CAM queueing breakages.
1999-08-16 20:11:45 +00:00
{
Add CAM_NEW_TRAN_CODE support. Use correct CAMLOCK_2_ISPLOCK macros. For fibre channel, start going for the gusto and using AC_FOUND_DEVICE and AC_LOST_DEVICE calls to xpt_async when devices appear and disappear as the loop or fabric changes. ISPASYNC_FW_CRASH is the async event code where the platform layer deals with a firmware crash.
2001-07-04 18:54:29 +00:00
struct ccb_trans_settings_scsi *scsi;
struct ccb_trans_settings_spi *spi;
Clarify and cleanup some CAM queueing breakages.
1999-08-16 20:11:45 +00:00
int flags, tgt;
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
sdparam *sdp;
Add CAM_NEW_TRAN_CODE support. Use correct CAMLOCK_2_ISPLOCK macros. For fibre channel, start going for the gusto and using AC_FOUND_DEVICE and AC_LOST_DEVICE calls to xpt_async when devices appear and disappear as the loop or fabric changes. ISPASYNC_FW_CRASH is the async event code where the platform layer deals with a firmware crash.
2001-07-04 18:54:29 +00:00
struct ccb_trans_settings cts;
Clarify and cleanup some CAM queueing breakages.
1999-08-16 20:11:45 +00:00
Remove bzero/bcopy vestiges. Be cognizant as to whether we're running 2KLogin f/w in target mode and do the appropriate loopid load based upon that.
2006-05-22 06:49:49 +00:00
memset(&cts, 0, sizeof (struct ccb_trans_settings));
Add CAM_NEW_TRAN_CODE support. Use correct CAMLOCK_2_ISPLOCK macros. For fibre channel, start going for the gusto and using AC_FOUND_DEVICE and AC_LOST_DEVICE calls to xpt_async when devices appear and disappear as the loop or fabric changes. ISPASYNC_FW_CRASH is the async event code where the platform layer deals with a firmware crash.
2001-07-04 18:54:29 +00:00
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
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);
Clarify and cleanup some CAM queueing breakages.
1999-08-16 20:11:45 +00:00
break;
}
Redo how we manage SCSI device settings- have a 3rd flags (nvram) that records either what's in NVRAM or what the safe defaults would be if we lack NVRAM. Then we rename cur_XXXX to actv_XXXX (these are the currently active settings) and the dev_XXX settings to goal_XXXX (these are the settings which we want cur_XXXX to converge to). This probably isn't entirely final as yet- but it's a lot closer to now being what it should be, including allowing camcontrol to actually set specific settings.
2001-07-30 01:00:21 +00:00
flags = sdp->isp_devparam[tgt].actv_flags;
Add CAM_NEW_TRAN_CODE support. Use correct CAMLOCK_2_ISPLOCK macros. For fibre channel, start going for the gusto and using AC_FOUND_DEVICE and AC_LOST_DEVICE calls to xpt_async when devices appear and disappear as the loop or fabric changes. ISPASYNC_FW_CRASH is the async event code where the platform layer deals with a firmware crash.
2001-07-04 18:54:29 +00:00
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;
}
Clarify and cleanup some CAM queueing breakages.
1999-08-16 20:11:45 +00:00
if (flags & DPARM_DISC) {
Add CAM_NEW_TRAN_CODE support. Use correct CAMLOCK_2_ISPLOCK macros. For fibre channel, start going for the gusto and using AC_FOUND_DEVICE and AC_LOST_DEVICE calls to xpt_async when devices appear and disappear as the loop or fabric changes. ISPASYNC_FW_CRASH is the async event code where the platform layer deals with a firmware crash.
2001-07-04 18:54:29 +00:00
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;
Redo how we manage SCSI device settings- have a 3rd flags (nvram) that records either what's in NVRAM or what the safe defaults would be if we lack NVRAM. Then we rename cur_XXXX to actv_XXXX (these are the currently active settings) and the dev_XXX settings to goal_XXXX (these are the settings which we want cur_XXXX to converge to). This probably isn't entirely final as yet- but it's a lot closer to now being what it should be, including allowing camcontrol to actually set specific settings.
2001-07-30 01:00:21 +00:00
spi->sync_period = sdp->isp_devparam[tgt].actv_period;
spi->sync_offset = sdp->isp_devparam[tgt].actv_offset;
Add CAM_NEW_TRAN_CODE support. Use correct CAMLOCK_2_ISPLOCK macros. For fibre channel, start going for the gusto and using AC_FOUND_DEVICE and AC_LOST_DEVICE calls to xpt_async when devices appear and disappear as the loop or fabric changes. ISPASYNC_FW_CRASH is the async event code where the platform layer deals with a firmware crash.
2001-07-04 18:54:29 +00:00
}
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
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);
Add CAM_NEW_TRAN_CODE support. Use correct CAMLOCK_2_ISPLOCK macros. For fibre channel, start going for the gusto and using AC_FOUND_DEVICE and AC_LOST_DEVICE calls to xpt_async when devices appear and disappear as the loop or fabric changes. ISPASYNC_FW_CRASH is the async event code where the platform layer deals with a firmware crash.
2001-07-04 18:54:29 +00:00
xpt_setup_ccb(&cts.ccb_h, tmppath, 1);
xpt_async(AC_TRANSFER_NEG, tmppath, &cts);
Clarify and cleanup some CAM queueing breakages.
1999-08-16 20:11:45 +00:00
xpt_free_path(tmppath);
Implement and use Fast Posting for both parallel && fibre. Redo a bit of the startup code. Implement a call to outer framework function so that asynchronous events can be handled (e.g., speed negotiation, target mode). Roll internal release tags.
1999-01-30 07:29:00 +00:00
break;
Clarify and cleanup some CAM queueing breakages.
1999-08-16 20:11:45 +00:00
}
A wad of changes- prepping for 1080/1240 support (which caused a massive thwank in register layout goop). A different mboxcmd approach. Some PDB change infrastructure. Some better management of loopdown/loopup events (keep them distinct from resource starvation for simq freeze/unfreeze actions).
1999-03-17 05:04:39 +00:00
case ISPASYNC_BUS_RESET:
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
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);
A wad of changes- prepping for 1080/1240 support (which caused a massive thwank in register layout goop). A different mboxcmd approach. Some PDB change infrastructure. Some better management of loopdown/loopup events (keep them distinct from resource starvation for simq freeze/unfreeze actions).
1999-03-17 05:04:39 +00:00
}
break;
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
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, 24xx 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:
Improve INOTs handling for 24xx and above chips.
2015-10-23 16:54:24 +00:00
if (msg == NULL)
Push things closer to path failover by implementing loop down and gone device timers and zombie state entries. There are tunables that can be used to select a number of parameters. loop_down_limit - how long to wait for loop to come back up before declaring all devices dead (default 300 seconds) gone_device_time- how long to wait for a device that has appeared to leave the loop or fabric to reappear (default 30 seconds) Internal tunables include (which should be externalized): quick_boot_time- how long to wait when booting for loop to come up change_is_bad- whether or not to accept devices with the same WWNN/WWPN that reappear at a different PortID as being the 'same' device. Keen students of some of the subtle issues here will ask how one can keep devices from being re-accepted at all (the answer is to set a gone_device_time to zero- that effectively would be the same thing).
2006-11-14 08:45:48 +00:00
msg = "LIP Received";
/* FALLTHROUGH */
A wad of changes- prepping for 1080/1240 support (which caused a massive thwank in register layout goop). A different mboxcmd approach. Some PDB change infrastructure. Some better management of loopdown/loopup events (keep them distinct from resource starvation for simq freeze/unfreeze actions).
1999-03-17 05:04:39 +00:00
case ISPASYNC_LOOP_DOWN:
Improve INOTs handling for 24xx and above chips.
2015-10-23 16:54:24 +00:00
if (msg == NULL)
Push things closer to path failover by implementing loop down and gone device timers and zombie state entries. There are tunables that can be used to select a number of parameters. loop_down_limit - how long to wait for loop to come back up before declaring all devices dead (default 300 seconds) gone_device_time- how long to wait for a device that has appeared to leave the loop or fabric to reappear (default 30 seconds) Internal tunables include (which should be externalized): quick_boot_time- how long to wait when booting for loop to come up change_is_bad- whether or not to accept devices with the same WWNN/WWPN that reappear at a different PortID as being the 'same' device. Keen students of some of the subtle issues here will ask how one can keep devices from being re-accepted at all (the answer is to set a gone_device_time to zero- that effectively would be the same thing).
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 */
A wad of changes- prepping for 1080/1240 support (which caused a massive thwank in register layout goop). A different mboxcmd approach. Some PDB change infrastructure. Some better management of loopdown/loopup events (keep them distinct from resource starvation for simq freeze/unfreeze actions).
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";
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
va_start(ap, cmd);
bus = va_arg(ap, int);
va_end(ap);
One more round of port scanner rewrite. - Make scan aborted by event restart immediately and infinitely. - Improve handling of some loop events from firmware. - Remove loop down timer, adding its functionality to scanner thread. - Some more unification and simplification.
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);
A wad of changes- prepping for 1080/1240 support (which caused a massive thwank in register layout goop). A different mboxcmd approach. Some PDB change infrastructure. Some better management of loopdown/loopup events (keep them distinct from resource starvation for simq freeze/unfreeze actions).
1999-03-17 05:04:39 +00:00
break;
Add 4Gb (24XX) support and lay the foundation for a lot of new stuff.
2006-11-02 03:21:32 +00:00
case ISPASYNC_DEV_ARRIVED:
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
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);
Fix cases where we've managed to get a Loop UP event prior to initializing the loop down counter, as well as other things. This was brought to my attention with a different fix, more for RELENG_7- this one covers the multiple channel case. PR: 140438 MFC after: 1 month
2009-12-04 03:34:12 +00:00
fc = ISP_FC_PC(isp, bus);
Unify port database use for target and initiator roles. Aside from cleaner and more consistent code, this allows ports to be both target and initiator same time, and easily switch from any role to any. Sponsored by: iXsystems, Inc.
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);
Unify port database use for target and initiator roles. Aside from cleaner and more consistent code, this allows ports to be both target and initiator same time, and easily switch from any role to any. Sponsored by: iXsystems, Inc.
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;
Fix/improve CRN tracking.
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);
Unify port database use for target and initiator roles. Aside from cleaner and more consistent code, this allows ports to be both target and initiator same time, and easily switch from any role to any. Sponsored by: iXsystems, Inc.
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;
Switch initiator IDs in target mode to the same address space as target IDs in initiator mode -- index in port database instead of handlers. This makes initiator IDs persist across role changes and firmware resets, when handlers previously assigned by firmware are lost and reused. Sponsored by: iXsystems, Inc.
2015-07-13 21:01:24 +00:00
adc->target = tgt;
Unify port database use for target and initiator roles. Aside from cleaner and more consistent code, this allows ports to be both target and initiator same time, and easily switch from any role to any. Sponsored by: iXsystems, Inc.
2015-07-13 15:11:05 +00:00
adc->arrived = 1;
xpt_async(AC_CONTRACT, fc->path, &ac);
Add 4Gb (24XX) support and lay the foundation for a lot of new stuff.
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:
Fix CRN resets in the isp(4) driver in certain situations. The Command Reference Number (CRN) is part of the FC-Tape features that we enable when talking to tape drives. It starts at 1, and goes to 255 and wraps around to 1. There are a number of reset type conditions that result in the CRN getting reset to 1. These are detailed in section 4.10 (table 8) of the FCP-4r02b specification. One of the conditions is when a PRLI (Process Login) is sent by the initiator, and the Establish Image Pair bit is set in Word 0 of the PRLI. Previously, the isp(4) driver core sent a notification via isp_async() that the target had changed or stayed in place, but there was no indication of whether a PRLI was sent and whether the Establish Image Pair bit was set. The result of this was that in some situations, notably switching back and forth between a direct connection and a switch connection to a tape drive, the isp(4) driver would fail to reset the CRN in situations that require it according to the spec. When the CRN isn't reset in a situation that requires it, the tape drive then rejects every subsequent command that is sent to the drive. It is assuming that the commands are being sent out of order. So, modify the isp(4) driver to include Word 0 of the PRLI command when it sends isp_async() notifications of target changes. Look at the Establish Image Pair bit, and reset the CRN if that bit is set. With this change, I am able to switch a tape drive back and forth between a direct connection and a switch connection, and the isp(4) driver resets the CRN when it should. sys/dev/isp_stds.h: Add bit definitions for PRLI Word 0. sys/dev/ispmbox.h: Add PRLI Word 0 to the port database type, isp_pdb_t. sys/dev/ispvar.h Add PRLI Word 0 to fcportdb_t. sys/dev/isp.c: Populate the new prli_word0 parameter in the port database. In isp_pdb_add_update(), add a check to see if the Establish Image Pair bit is set in PRLI Word 0. If it is, then that is an additional reason to create a change notification. sys/dev/isp_freebsd.c: In isp_async(), if the device changed or stayed, look at PRLI Word 0 to see if the Establish Image Pair bit is set. If it is, reset the CRN if we haven't already. MFC after: 1 week Sponsored by: Spectra Logic Differential Revision: https://reviews.freebsd.org/D19472
2019-03-11 14:21:14 +00:00
{
int crn_reset_done;
crn_reset_done = 0;
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
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);
Fix cases where we've managed to get a Loop UP event prior to initializing the loop down counter, as well as other things. This was brought to my attention with a different fix, more for RELENG_7- this one covers the multiple channel case. PR: 140438 MFC after: 1 month
2009-12-04 03:34:12 +00:00
fc = ISP_FC_PC(isp, bus);
Unify port database use for target and initiator roles. Aside from cleaner and more consistent code, this allows ports to be both target and initiator same time, and easily switch from any role to any. Sponsored by: iXsystems, Inc.
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");
Unify port database use for target and initiator roles. Aside from cleaner and more consistent code, this allows ports to be both target and initiator same time, and easily switch from any role to any. Sponsored by: iXsystems, Inc.
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) {
Fix CRN resets in the isp(4) driver in certain situations. The Command Reference Number (CRN) is part of the FC-Tape features that we enable when talking to tape drives. It starts at 1, and goes to 255 and wraps around to 1. There are a number of reset type conditions that result in the CRN getting reset to 1. These are detailed in section 4.10 (table 8) of the FCP-4r02b specification. One of the conditions is when a PRLI (Process Login) is sent by the initiator, and the Establish Image Pair bit is set in Word 0 of the PRLI. Previously, the isp(4) driver core sent a notification via isp_async() that the target had changed or stayed in place, but there was no indication of whether a PRLI was sent and whether the Establish Image Pair bit was set. The result of this was that in some situations, notably switching back and forth between a direct connection and a switch connection to a tape drive, the isp(4) driver would fail to reset the CRN in situations that require it according to the spec. When the CRN isn't reset in a situation that requires it, the tape drive then rejects every subsequent command that is sent to the drive. It is assuming that the commands are being sent out of order. So, modify the isp(4) driver to include Word 0 of the PRLI command when it sends isp_async() notifications of target changes. Look at the Establish Image Pair bit, and reset the CRN if that bit is set. With this change, I am able to switch a tape drive back and forth between a direct connection and a switch connection, and the isp(4) driver resets the CRN when it should. sys/dev/isp_stds.h: Add bit definitions for PRLI Word 0. sys/dev/ispmbox.h: Add PRLI Word 0 to the port database type, isp_pdb_t. sys/dev/ispvar.h Add PRLI Word 0 to fcportdb_t. sys/dev/isp.c: Populate the new prli_word0 parameter in the port database. In isp_pdb_add_update(), add a check to see if the Establish Image Pair bit is set in PRLI Word 0. If it is, then that is an additional reason to create a change notification. sys/dev/isp_freebsd.c: In isp_async(), if the device changed or stayed, look at PRLI Word 0 to see if the Establish Image Pair bit is set. If it is, reset the CRN if we haven't already. MFC after: 1 week Sponsored by: Spectra Logic Differential Revision: https://reviews.freebsd.org/D19472
2019-03-11 14:21:14 +00:00
if (cmd == 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
isp_fcp_reset_crn(isp, bus, tgt, /*tgt_set*/ 1);
Fix CRN resets in the isp(4) driver in certain situations. The Command Reference Number (CRN) is part of the FC-Tape features that we enable when talking to tape drives. It starts at 1, and goes to 255 and wraps around to 1. There are a number of reset type conditions that result in the CRN getting reset to 1. These are detailed in section 4.10 (table 8) of the FCP-4r02b specification. One of the conditions is when a PRLI (Process Login) is sent by the initiator, and the Establish Image Pair bit is set in Word 0 of the PRLI. Previously, the isp(4) driver core sent a notification via isp_async() that the target had changed or stayed in place, but there was no indication of whether a PRLI was sent and whether the Establish Image Pair bit was set. The result of this was that in some situations, notably switching back and forth between a direct connection and a switch connection to a tape drive, the isp(4) driver would fail to reset the CRN in situations that require it according to the spec. When the CRN isn't reset in a situation that requires it, the tape drive then rejects every subsequent command that is sent to the drive. It is assuming that the commands are being sent out of order. So, modify the isp(4) driver to include Word 0 of the PRLI command when it sends isp_async() notifications of target changes. Look at the Establish Image Pair bit, and reset the CRN if that bit is set. With this change, I am able to switch a tape drive back and forth between a direct connection and a switch connection, and the isp(4) driver resets the CRN when it should. sys/dev/isp_stds.h: Add bit definitions for PRLI Word 0. sys/dev/ispmbox.h: Add PRLI Word 0 to the port database type, isp_pdb_t. sys/dev/ispvar.h Add PRLI Word 0 to fcportdb_t. sys/dev/isp.c: Populate the new prli_word0 parameter in the port database. In isp_pdb_add_update(), add a check to see if the Establish Image Pair bit is set in PRLI Word 0. If it is, then that is an additional reason to create a change notification. sys/dev/isp_freebsd.c: In isp_async(), if the device changed or stayed, look at PRLI Word 0 to see if the Establish Image Pair bit is set. If it is, reset the CRN if we haven't already. MFC after: 1 week Sponsored by: Spectra Logic Differential Revision: https://reviews.freebsd.org/D19472
2019-03-11 14:21:14 +00:00
crn_reset_done = 1;
}
Unify port database use for target and initiator roles. Aside from cleaner and more consistent code, this allows ports to be both target and initiator same time, and easily switch from any role to any. Sponsored by: iXsystems, Inc.
2015-07-13 15:11:05 +00:00
isp_make_here(isp, lp, bus, tgt);
Push things closer to path failover by implementing loop down and gone device timers and zombie state entries. There are tunables that can be used to select a number of parameters. loop_down_limit - how long to wait for loop to come back up before declaring all devices dead (default 300 seconds) gone_device_time- how long to wait for a device that has appeared to leave the loop or fabric to reappear (default 30 seconds) Internal tunables include (which should be externalized): quick_boot_time- how long to wait when booting for loop to come up change_is_bad- whether or not to accept devices with the same WWNN/WWPN that reappear at a different PortID as being the 'same' device. Keen students of some of the subtle issues here will ask how one can keep devices from being re-accepted at all (the answer is to set a gone_device_time to zero- that effectively would be the same thing).
2006-11-14 08:45:48 +00:00
} else {
Unify port database use for target and initiator roles. Aside from cleaner and more consistent code, this allows ports to be both target and initiator same time, and easily switch from any role to any. Sponsored by: iXsystems, Inc.
2015-07-13 15:11:05 +00:00
isp_make_gone(isp, lp, bus, tgt);
Fix CRN resets in the isp(4) driver in certain situations. The Command Reference Number (CRN) is part of the FC-Tape features that we enable when talking to tape drives. It starts at 1, and goes to 255 and wraps around to 1. There are a number of reset type conditions that result in the CRN getting reset to 1. These are detailed in section 4.10 (table 8) of the FCP-4r02b specification. One of the conditions is when a PRLI (Process Login) is sent by the initiator, and the Establish Image Pair bit is set in Word 0 of the PRLI. Previously, the isp(4) driver core sent a notification via isp_async() that the target had changed or stayed in place, but there was no indication of whether a PRLI was sent and whether the Establish Image Pair bit was set. The result of this was that in some situations, notably switching back and forth between a direct connection and a switch connection to a tape drive, the isp(4) driver would fail to reset the CRN in situations that require it according to the spec. When the CRN isn't reset in a situation that requires it, the tape drive then rejects every subsequent command that is sent to the drive. It is assuming that the commands are being sent out of order. So, modify the isp(4) driver to include Word 0 of the PRLI command when it sends isp_async() notifications of target changes. Look at the Establish Image Pair bit, and reset the CRN if that bit is set. With this change, I am able to switch a tape drive back and forth between a direct connection and a switch connection, and the isp(4) driver resets the CRN when it should. sys/dev/isp_stds.h: Add bit definitions for PRLI Word 0. sys/dev/ispmbox.h: Add PRLI Word 0 to the port database type, isp_pdb_t. sys/dev/ispvar.h Add PRLI Word 0 to fcportdb_t. sys/dev/isp.c: Populate the new prli_word0 parameter in the port database. In isp_pdb_add_update(), add a check to see if the Establish Image Pair bit is set in PRLI Word 0. If it is, then that is an additional reason to create a change notification. sys/dev/isp_freebsd.c: In isp_async(), if the device changed or stayed, look at PRLI Word 0 to see if the Establish Image Pair bit is set. If it is, reset the CRN if we haven't already. MFC after: 1 week Sponsored by: Spectra Logic Differential Revision: https://reviews.freebsd.org/D19472
2019-03-11 14:21:14 +00:00
if (cmd == 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
isp_fcp_reset_crn(isp, bus, tgt, /*tgt_set*/ 1);
Fix CRN resets in the isp(4) driver in certain situations. The Command Reference Number (CRN) is part of the FC-Tape features that we enable when talking to tape drives. It starts at 1, and goes to 255 and wraps around to 1. There are a number of reset type conditions that result in the CRN getting reset to 1. These are detailed in section 4.10 (table 8) of the FCP-4r02b specification. One of the conditions is when a PRLI (Process Login) is sent by the initiator, and the Establish Image Pair bit is set in Word 0 of the PRLI. Previously, the isp(4) driver core sent a notification via isp_async() that the target had changed or stayed in place, but there was no indication of whether a PRLI was sent and whether the Establish Image Pair bit was set. The result of this was that in some situations, notably switching back and forth between a direct connection and a switch connection to a tape drive, the isp(4) driver would fail to reset the CRN in situations that require it according to the spec. When the CRN isn't reset in a situation that requires it, the tape drive then rejects every subsequent command that is sent to the drive. It is assuming that the commands are being sent out of order. So, modify the isp(4) driver to include Word 0 of the PRLI command when it sends isp_async() notifications of target changes. Look at the Establish Image Pair bit, and reset the CRN if that bit is set. With this change, I am able to switch a tape drive back and forth between a direct connection and a switch connection, and the isp(4) driver resets the CRN when it should. sys/dev/isp_stds.h: Add bit definitions for PRLI Word 0. sys/dev/ispmbox.h: Add PRLI Word 0 to the port database type, isp_pdb_t. sys/dev/ispvar.h Add PRLI Word 0 to fcportdb_t. sys/dev/isp.c: Populate the new prli_word0 parameter in the port database. In isp_pdb_add_update(), add a check to see if the Establish Image Pair bit is set in PRLI Word 0. If it is, then that is an additional reason to create a change notification. sys/dev/isp_freebsd.c: In isp_async(), if the device changed or stayed, look at PRLI Word 0 to see if the Establish Image Pair bit is set. If it is, reset the CRN if we haven't already. MFC after: 1 week Sponsored by: Spectra Logic Differential Revision: https://reviews.freebsd.org/D19472
2019-03-11 14:21:14 +00:00
crn_reset_done = 1;
}
Push things closer to path failover by implementing loop down and gone device timers and zombie state entries. There are tunables that can be used to select a number of parameters. loop_down_limit - how long to wait for loop to come back up before declaring all devices dead (default 300 seconds) gone_device_time- how long to wait for a device that has appeared to leave the loop or fabric to reappear (default 30 seconds) Internal tunables include (which should be externalized): quick_boot_time- how long to wait when booting for loop to come up change_is_bad- whether or not to accept devices with the same WWNN/WWPN that reappear at a different PortID as being the 'same' device. Keen students of some of the subtle issues here will ask how one can keep devices from being re-accepted at all (the answer is to set a gone_device_time to zero- that effectively would be the same thing).
2006-11-14 08:45:48 +00:00
}
Add 4Gb (24XX) support and lay the foundation for a lot of new stuff.
2006-11-02 03:21:32 +00:00
}
Unify port database use for target and initiator roles. Aside from cleaner and more consistent code, this allows ports to be both target and initiator same time, and easily switch from any role to any. Sponsored by: iXsystems, Inc.
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;
Switch initiator IDs in target mode to the same address space as target IDs in initiator mode -- index in port database instead of handlers. This makes initiator IDs persist across role changes and firmware resets, when handlers previously assigned by firmware are lost and reused. Sponsored by: iXsystems, Inc.
2015-07-13 21:01:24 +00:00
adc->target = tgt;
Unify port database use for target and initiator roles. Aside from cleaner and more consistent code, this allows ports to be both target and initiator same time, and easily switch from any role to any. Sponsored by: iXsystems, Inc.
2015-07-13 15:11:05 +00:00
adc->arrived = lp->is_initiator;
xpt_async(AC_CONTRACT, fc->path, &ac);
}
Fix CRN resets in the isp(4) driver in certain situations. The Command Reference Number (CRN) is part of the FC-Tape features that we enable when talking to tape drives. It starts at 1, and goes to 255 and wraps around to 1. There are a number of reset type conditions that result in the CRN getting reset to 1. These are detailed in section 4.10 (table 8) of the FCP-4r02b specification. One of the conditions is when a PRLI (Process Login) is sent by the initiator, and the Establish Image Pair bit is set in Word 0 of the PRLI. Previously, the isp(4) driver core sent a notification via isp_async() that the target had changed or stayed in place, but there was no indication of whether a PRLI was sent and whether the Establish Image Pair bit was set. The result of this was that in some situations, notably switching back and forth between a direct connection and a switch connection to a tape drive, the isp(4) driver would fail to reset the CRN in situations that require it according to the spec. When the CRN isn't reset in a situation that requires it, the tape drive then rejects every subsequent command that is sent to the drive. It is assuming that the commands are being sent out of order. So, modify the isp(4) driver to include Word 0 of the PRLI command when it sends isp_async() notifications of target changes. Look at the Establish Image Pair bit, and reset the CRN if that bit is set. With this change, I am able to switch a tape drive back and forth between a direct connection and a switch connection, and the isp(4) driver resets the CRN when it should. sys/dev/isp_stds.h: Add bit definitions for PRLI Word 0. sys/dev/ispmbox.h: Add PRLI Word 0 to the port database type, isp_pdb_t. sys/dev/ispvar.h Add PRLI Word 0 to fcportdb_t. sys/dev/isp.c: Populate the new prli_word0 parameter in the port database. In isp_pdb_add_update(), add a check to see if the Establish Image Pair bit is set in PRLI Word 0. If it is, then that is an additional reason to create a change notification. sys/dev/isp_freebsd.c: In isp_async(), if the device changed or stayed, look at PRLI Word 0 to see if the Establish Image Pair bit is set. If it is, reset the CRN if we haven't already. MFC after: 1 week Sponsored by: Spectra Logic Differential Revision: https://reviews.freebsd.org/D19472
2019-03-11 14:21:14 +00:00
Fix FC-Tape bugs caused in part by r345008. The point of r345008 was to reset the Command Reference Number (CRN) in some situations where a device stayed in the topology, but had changed somehow. This can include moving from a switch connection to a direct connection or vice versa, or a device that temporarily goes away and comes back. (e.g. moving to a different switch port) There were a couple of bugs in that change: - We were reporting that a device had not changed whenever the Establish Image Pair bit was not set. That is not quite correct. Instead, if the Establish Image Pair bit stays the same (set or not), the device hasn't changed in that way. - We weren't setting PRLI Word0 in the port database when a new device arrived, so comparisons with the old value for the Establish Image Pair bit weren't really possible. So, make sure PRLI Word0 is set in the port database for new devices. - We were resetting the CRN whenever the Establish Image Pair bit was set for a device, even when the device had stayed the same and the value of the bit hadn't changed. Now, only reset the CRN for devices that have changed, not devices that sayed the same. The result of all of this was that if we had a single FC device on an FC port and it went away and came back, we would wind up correctly resetting the CRN. But, if we had multiple devices connected via a switch, and there was any change in one or more of those devices, all of the devices that stayed the same would also have their CRN values reset. The result, from a user standpoint, is that the tape drives, etc. would all start to time out commands and the initiator would send aborts. sys/dev/isp/isp.c: In isp_pdb_add_update(), look at whether the Establish Image Pair bit has changed as part of the check to determine whether a device is still the same. This was causing erroneous change notifications. Also, when creating a new port database entry, initialize the PRLI Word 0 values. sys/dev/isp/isp_freebsd.c: In isp_async(), in the changed/stayed case, instead of looking at the Establish Image Pair bit to determine whether to reset the CRN, look at the command value. (Changed vs. Stayed.) Only reset the CRN for devices that have changed. Sponsored by: Spectra Logic MFC after: 3 days
2019-05-24 17:58:29 +00:00
if ((cmd == ISPASYNC_DEV_CHANGED) &&
Fix CRN resets in the isp(4) driver in certain situations. The Command Reference Number (CRN) is part of the FC-Tape features that we enable when talking to tape drives. It starts at 1, and goes to 255 and wraps around to 1. There are a number of reset type conditions that result in the CRN getting reset to 1. These are detailed in section 4.10 (table 8) of the FCP-4r02b specification. One of the conditions is when a PRLI (Process Login) is sent by the initiator, and the Establish Image Pair bit is set in Word 0 of the PRLI. Previously, the isp(4) driver core sent a notification via isp_async() that the target had changed or stayed in place, but there was no indication of whether a PRLI was sent and whether the Establish Image Pair bit was set. The result of this was that in some situations, notably switching back and forth between a direct connection and a switch connection to a tape drive, the isp(4) driver would fail to reset the CRN in situations that require it according to the spec. When the CRN isn't reset in a situation that requires it, the tape drive then rejects every subsequent command that is sent to the drive. It is assuming that the commands are being sent out of order. So, modify the isp(4) driver to include Word 0 of the PRLI command when it sends isp_async() notifications of target changes. Look at the Establish Image Pair bit, and reset the CRN if that bit is set. With this change, I am able to switch a tape drive back and forth between a direct connection and a switch connection, and the isp(4) driver resets the CRN when it should. sys/dev/isp_stds.h: Add bit definitions for PRLI Word 0. sys/dev/ispmbox.h: Add PRLI Word 0 to the port database type, isp_pdb_t. sys/dev/ispvar.h Add PRLI Word 0 to fcportdb_t. sys/dev/isp.c: Populate the new prli_word0 parameter in the port database. In isp_pdb_add_update(), add a check to see if the Establish Image Pair bit is set in PRLI Word 0. If it is, then that is an additional reason to create a change notification. sys/dev/isp_freebsd.c: In isp_async(), if the device changed or stayed, look at PRLI Word 0 to see if the Establish Image Pair bit is set. If it is, reset the CRN if we haven't already. MFC after: 1 week Sponsored by: Spectra Logic Differential Revision: https://reviews.freebsd.org/D19472
2019-03-11 14:21:14 +00:00
(crn_reset_done == 0))
isp_fcp_reset_crn(isp, bus, tgt, /*tgt_set*/ 1);
Add 4Gb (24XX) support and lay the foundation for a lot of new stuff.
2006-11-02 03:21:32 +00:00
break;
Fix CRN resets in the isp(4) driver in certain situations. The Command Reference Number (CRN) is part of the FC-Tape features that we enable when talking to tape drives. It starts at 1, and goes to 255 and wraps around to 1. There are a number of reset type conditions that result in the CRN getting reset to 1. These are detailed in section 4.10 (table 8) of the FCP-4r02b specification. One of the conditions is when a PRLI (Process Login) is sent by the initiator, and the Establish Image Pair bit is set in Word 0 of the PRLI. Previously, the isp(4) driver core sent a notification via isp_async() that the target had changed or stayed in place, but there was no indication of whether a PRLI was sent and whether the Establish Image Pair bit was set. The result of this was that in some situations, notably switching back and forth between a direct connection and a switch connection to a tape drive, the isp(4) driver would fail to reset the CRN in situations that require it according to the spec. When the CRN isn't reset in a situation that requires it, the tape drive then rejects every subsequent command that is sent to the drive. It is assuming that the commands are being sent out of order. So, modify the isp(4) driver to include Word 0 of the PRLI command when it sends isp_async() notifications of target changes. Look at the Establish Image Pair bit, and reset the CRN if that bit is set. With this change, I am able to switch a tape drive back and forth between a direct connection and a switch connection, and the isp(4) driver resets the CRN when it should. sys/dev/isp_stds.h: Add bit definitions for PRLI Word 0. sys/dev/ispmbox.h: Add PRLI Word 0 to the port database type, isp_pdb_t. sys/dev/ispvar.h Add PRLI Word 0 to fcportdb_t. sys/dev/isp.c: Populate the new prli_word0 parameter in the port database. In isp_pdb_add_update(), add a check to see if the Establish Image Pair bit is set in PRLI Word 0. If it is, then that is an additional reason to create a change notification. sys/dev/isp_freebsd.c: In isp_async(), if the device changed or stayed, look at PRLI Word 0 to see if the Establish Image Pair bit is set. If it is, reset the CRN if we haven't already. MFC after: 1 week Sponsored by: Spectra Logic Differential Revision: https://reviews.freebsd.org/D19472
2019-03-11 14:21:14 +00:00
}
Add 4Gb (24XX) support and lay the foundation for a lot of new stuff.
2006-11-02 03:21:32 +00:00
case ISPASYNC_DEV_GONE:
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
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);
Fix cases where we've managed to get a Loop UP event prior to initializing the loop down counter, as well as other things. This was brought to my attention with a different fix, more for RELENG_7- this one covers the multiple channel case. PR: 140438 MFC after: 1 month
2009-12-04 03:34:12 +00:00
fc = ISP_FC_PC(isp, bus);
Unify port database use for target and initiator roles. Aside from cleaner and more consistent code, this allows ports to be both target and initiator same time, and easily switch from any role to any. Sponsored by: iXsystems, Inc.
2015-07-13 15:11:05 +00:00
tgt = FC_PORTDB_TGT(isp, bus, lp);
Push things closer to path failover by implementing loop down and gone device timers and zombie state entries. There are tunables that can be used to select a number of parameters. loop_down_limit - how long to wait for loop to come back up before declaring all devices dead (default 300 seconds) gone_device_time- how long to wait for a device that has appeared to leave the loop or fabric to reappear (default 30 seconds) Internal tunables include (which should be externalized): quick_boot_time- how long to wait when booting for loop to come up change_is_bad- whether or not to accept devices with the same WWNN/WWPN that reappear at a different PortID as being the 'same' device. Keen students of some of the subtle issues here will ask how one can keep devices from being re-accepted at all (the answer is to set a gone_device_time to zero- that effectively would be the same thing).
2006-11-14 08:45:48 +00:00
/*
Unify port database use for target and initiator roles. Aside from cleaner and more consistent code, this allows ports to be both target and initiator same time, and easily switch from any role to any. Sponsored by: iXsystems, Inc.
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.
Push things closer to path failover by implementing loop down and gone device timers and zombie state entries. There are tunables that can be used to select a number of parameters. loop_down_limit - how long to wait for loop to come back up before declaring all devices dead (default 300 seconds) gone_device_time- how long to wait for a device that has appeared to leave the loop or fabric to reappear (default 30 seconds) Internal tunables include (which should be externalized): quick_boot_time- how long to wait when booting for loop to come up change_is_bad- whether or not to accept devices with the same WWNN/WWPN that reappear at a different PortID as being the 'same' device. Keen students of some of the subtle issues here will ask how one can keep devices from being re-accepted at all (the answer is to set a gone_device_time to zero- that effectively would be the same thing).
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);
Unify port database use for target and initiator roles. Aside from cleaner and more consistent code, this allows ports to be both target and initiator same time, and easily switch from any role to any. Sponsored by: iXsystems, Inc.
2015-07-13 15:11:05 +00:00
if (lp->is_target || lp->is_initiator) {
Push things closer to path failover by implementing loop down and gone device timers and zombie state entries. There are tunables that can be used to select a number of parameters. loop_down_limit - how long to wait for loop to come back up before declaring all devices dead (default 300 seconds) gone_device_time- how long to wait for a device that has appeared to leave the loop or fabric to reappear (default 30 seconds) Internal tunables include (which should be externalized): quick_boot_time- how long to wait when booting for loop to come up change_is_bad- whether or not to accept devices with the same WWNN/WWPN that reappear at a different PortID as being the 'same' device. Keen students of some of the subtle issues here will ask how one can keep devices from being re-accepted at all (the answer is to set a gone_device_time to zero- that effectively would be the same thing).
2006-11-14 08:45:48 +00:00
lp->state = FC_PORTDB_STATE_ZOMBIE;
Unify port database use for target and initiator roles. Aside from cleaner and more consistent code, this allows ports to be both target and initiator same time, and easily switch from any role to any. Sponsored by: iXsystems, Inc.
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");
Fix cases where we've managed to get a Loop UP event prior to initializing the loop down counter, as well as other things. This was brought to my attention with a different fix, more for RELENG_7- this one covers the multiple channel case. PR: 140438 MFC after: 1 month
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);
Fix cases where we've managed to get a Loop UP event prior to initializing the loop down counter, as well as other things. This was brought to my attention with a different fix, more for RELENG_7- this one covers the multiple channel case. PR: 140438 MFC after: 1 month
2009-12-04 03:34:12 +00:00
callout_reset(&fc->gdt, hz, isp_gdt, fc);
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
}
Unify port database use for target and initiator roles. Aside from cleaner and more consistent code, this allows ports to be both target and initiator same time, and easily switch from any role to any. Sponsored by: iXsystems, Inc.
2015-07-13 15:11:05 +00:00
break;
Add 4Gb (24XX) support and lay the foundation for a lot of new stuff.
2006-11-02 03:21:32 +00:00
}
Unify port database use for target and initiator roles. Aside from cleaner and more consistent code, this allows ports to be both target and initiator same time, and easily switch from any role to any. Sponsored by: iXsystems, Inc.
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");
A wad of changes- prepping for 1080/1240 support (which caused a massive thwank in register layout goop). A different mboxcmd approach. Some PDB change infrastructure. Some better management of loopdown/loopup events (keep them distinct from resource starvation for simq freeze/unfreeze actions).
1999-03-17 05:04:39 +00:00
break;
case ISPASYNC_CHANGE_NOTIFY:
Add 4Gb (24XX) support and lay the foundation for a lot of new stuff.
2006-11-02 03:21:32 +00:00
{
char *msg;
Another round of port scanner rewrite. This change simplifies and unifies port adding/updating for loop and fabric scanners. It also fixes problems with scanning restarts due to concurrent port databases changes. It also fixes many cosmetic issues.
2015-11-19 17:43:47 +00:00
int evt, nphdl, nlstate, portid, reason;
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
va_start(ap, cmd);
bus = va_arg(ap, int);
evt = va_arg(ap, int);
Another round of port scanner rewrite. This change simplifies and unifies port adding/updating for loop and fabric scanners. It also fixes problems with scanning restarts due to concurrent port databases changes. It also fixes many cosmetic issues.
2015-11-19 17:43:47 +00:00
if (evt == ISPASYNC_CHANGE_PDB) {
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
nphdl = va_arg(ap, int);
nlstate = va_arg(ap, int);
reason = va_arg(ap, int);
Another round of port scanner rewrite. This change simplifies and unifies port adding/updating for loop and fabric scanners. It also fixes problems with scanning restarts due to concurrent port databases changes. It also fixes many cosmetic issues.
2015-11-19 17:43:47 +00:00
} else if (evt == ISPASYNC_CHANGE_SNS) {
portid = va_arg(ap, int);
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
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;
Improve Port Database Changed handling and reporting.
2015-10-25 14:34:07 +00:00
msg = "Port Database Changed";
Another round of port scanner rewrite. This change simplifies and unifies port adding/updating for loop and fabric scanners. It also fixes problems with scanning restarts due to concurrent port databases changes. It also fixes many cosmetic issues.
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 */
}
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
} else if (evt == ISPASYNC_CHANGE_SNS) {
Improve Port Database Changed handling and reporting.
2015-10-25 14:34:07 +00:00
msg = "Name Server Database Changed";
Another round of port scanner rewrite. This change simplifies and unifies port adding/updating for loop and fabric scanners. It also fixes problems with scanning restarts due to concurrent port databases changes. It also fixes many cosmetic issues.
2015-11-19 17:43:47 +00:00
isp_prt(isp, ISP_LOGINFO, "Chan %d %s (PortID 0x%06x)",
bus, msg, portid);
Add 4Gb (24XX) support and lay the foundation for a lot of new stuff.
2006-11-02 03:21:32 +00:00
} else {
Improve Port Database Changed handling and reporting.
2015-10-25 14:34:07 +00:00
msg = "Other Change Notify";
Another round of port scanner rewrite. This change simplifies and unifies port adding/updating for loop and fabric scanners. It also fixes problems with scanning restarts due to concurrent port databases changes. It also fixes many cosmetic issues.
2015-11-19 17:43:47 +00:00
isp_prt(isp, ISP_LOGINFO, "Chan %d %s", bus, msg);
Follow the ISPASYNC_PDB_CHANGED -> ISPASYNC_LOGGED_INOUT change. Also, ISPASYNC_NOTIFY_CHANGE now is for both local loop && fabric changes.
2001-01-09 02:47:15 +00:00
}
One more round of port scanner rewrite. - Make scan aborted by event restart immediately and infinitely. - Improve handling of some loop events from firmware. - Remove loop down timer, adding its functionality to scanner thread. - Some more unification and simplification.
2015-11-26 13:04:58 +00:00
isp_loop_changed(isp, bus);
A wad of changes- prepping for 1080/1240 support (which caused a massive thwank in register layout goop). A different mboxcmd approach. Some PDB change infrastructure. Some better management of loopdown/loopup events (keep them distinct from resource starvation for simq freeze/unfreeze actions).
1999-03-17 05:04:39 +00:00
break;
}
Make a static chain of isp softcs- gdb usage becomes a lot easier. Add in a very large amount of target mode support code- this is just a first pass at this. It's a difficult thing because some of the code can be in platform independent areas (see isp_target.?) but a lot has to be in platform dependent areas because of not only the tight coupling of received commands/events and the specific OS subsystem but because the platform independent code has (deliberately) no event/wait mechanisms.
2000-01-03 23:55:30 +00:00
#ifdef ISP_TARGET_MODE
First of several commits as this driver is dusted off and maybe brought up to date. Principle changes for this reelase is to support 2K Port Login firmware. This allows us to support the 2322 (and 2422 4Gb) cards which only come with the 2K Port Login firmware. The 2322 should now work- but we don't have firmware sets for it in ispfw (as the change to load 2K Port Login f/w hasn't been made- that f/w is so big it has to be loaded in more than one chunk). Other changes are the beginnings of cleaning up some long standing target mode issues. The next changes here will incorporate a lot of bug fixes from others. Finally, some copyright cleanup and attempts to make the parts of the driver that are FreeBSD specific start conforming more to FreeBSD style. MFC after: 1 month
2006-01-23 06:23:37 +00:00
case ISPASYNC_TARGET_NOTIFY:
Make a static chain of isp softcs- gdb usage becomes a lot easier. Add in a very large amount of target mode support code- this is just a first pass at this. It's a difficult thing because some of the code can be in platform independent areas (see isp_target.?) but a lot has to be in platform dependent areas because of not only the tight coupling of received commands/events and the specific OS subsystem but because the platform independent code has (deliberately) no event/wait mechanisms.
2000-01-03 23:55:30 +00:00
{
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
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:
Add partial support for QUERY TMF to CAM and isp(4). This change allows to decode respective functions in isp(4) in target mode and pass them through CAM to CTL. Unfortunately neither CAM nor isp(4) support returning response info for those task management functions now. On the other side I just have no initiator to test this functionality.
2015-10-23 18:34:18 +00:00
case NT_QUERY_TASK_SET:
case NT_QUERY_ASYNC_EVENT:
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
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:
Unify port database use for target and initiator roles. Aside from cleaner and more consistent code, this allows ports to be both target and initiator same time, and easily switch from any role to any. Sponsored by: iXsystems, Inc.
2015-07-13 15:11:05 +00:00
case NT_HBA_RESET:
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
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:
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
case NT_LOGOUT:
/*
* This is device arrival/departure notification
*/
Pass task management response information from CTL through CAM to isp(4), utilizing previously unused arg field of struct ccb_notify_acknowledge. This makes new QUERY TASK, QUERY TASK SET and QUERY ASYNC EVENT requests really functional for CAM target mode drivers.
2016-05-20 10:26:12 +00:00
isp_handle_platform_target_notify_ack(isp, notify, 0);
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
break;
Move 24xx RQSTYPE_NOTIFY handling to generic code. This code has nothing to do with specific platform. MFC after: 2 weeks
2017-03-19 09:30:03 +00:00
case NT_SRR:
isp_handle_platform_srr(isp, notify);
break;
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
default:
isp_prt(isp, ISP_LOGALL, "target notify code 0x%x", notify->nt_ncode);
Pass task management response information from CTL through CAM to isp(4), utilizing previously unused arg field of struct ccb_notify_acknowledge. This makes new QUERY TASK, QUERY TASK SET and QUERY ASYNC EVENT requests really functional for CAM target mode drivers.
2016-05-20 10:26:12 +00:00
isp_handle_platform_target_notify_ack(isp, notify, 0);
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
break;
}
Make a static chain of isp softcs- gdb usage becomes a lot easier. Add in a very large amount of target mode support code- this is just a first pass at this. It's a difficult thing because some of the code can be in platform independent areas (see isp_target.?) but a lot has to be in platform dependent areas because of not only the tight coupling of received commands/events and the specific OS subsystem but because the platform independent code has (deliberately) no event/wait mechanisms.
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;
Do some notify acks cleanup. ISPASYNC_TARGET_NOTIFY_ACK makes no sense without argument. MFC after: 2 weeks
2017-03-18 10:34:29 +00:00
memcpy(tp->data, inot, sizeof (tp->data));
tp->not = tp->data;
Convert the refire_notify_ack timer from timeout(9) to callout(9). Tested by: no one
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;
}
Make a static chain of isp softcs- gdb usage becomes a lot easier. Add in a very large amount of target mode support code- this is just a first pass at this. It's a difficult thing because some of the code can be in platform independent areas (see isp_target.?) but a lot has to be in platform dependent areas because of not only the tight coupling of received commands/events and the specific OS subsystem but because the platform independent code has (deliberately) no event/wait mechanisms.
2000-01-03 23:55:30 +00:00
case ISPASYNC_TARGET_ACTION:
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
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) {
Make a static chain of isp softcs- gdb usage becomes a lot easier. Add in a very large amount of target mode support code- this is just a first pass at this. It's a difficult thing because some of the code can be in platform independent areas (see isp_target.?) but a lot has to be in platform dependent areas because of not only the tight coupling of received commands/events and the specific OS subsystem but because the platform independent code has (deliberately) no event/wait mechanisms.
2000-01-03 23:55:30 +00:00
case RQSTYPE_ATIO:
Rip off target mode support for parallel SCSI QLogic adapters. Hacks to enable target mode there complicated code, while didn't really work. And for outdated hardware fixing it is not really interesting. Initiator mode tested with Qlogic 1080 adapter is still working fine.
2015-11-23 10:06:19 +00:00
isp_handle_platform_atio7(isp, (at7_entry_t *) hp);
Make a static chain of isp softcs- gdb usage becomes a lot easier. Add in a very large amount of target mode support code- this is just a first pass at this. It's a difficult thing because some of the code can be in platform independent areas (see isp_target.?) but a lot has to be in platform dependent areas because of not only the tight coupling of received commands/events and the specific OS subsystem but because the platform independent code has (deliberately) no event/wait mechanisms.
2000-01-03 23:55:30 +00:00
break;
case RQSTYPE_ATIO2:
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
isp_handle_platform_atio2(isp, (at2_entry_t *) hp);
Make a static chain of isp softcs- gdb usage becomes a lot easier. Add in a very large amount of target mode support code- this is just a first pass at this. It's a difficult thing because some of the code can be in platform independent areas (see isp_target.?) but a lot has to be in platform dependent areas because of not only the tight coupling of received commands/events and the specific OS subsystem but because the platform independent code has (deliberately) no event/wait mechanisms.
2000-01-03 23:55:30 +00:00
break;
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
case RQSTYPE_CTIO7:
Add missing case for RQSTYPE_CTIO3- neede for 64 bit target mode.
2006-05-22 07:07:30 +00:00
case RQSTYPE_CTIO3:
Make a static chain of isp softcs- gdb usage becomes a lot easier. Add in a very large amount of target mode support code- this is just a first pass at this. It's a difficult thing because some of the code can be in platform independent areas (see isp_target.?) but a lot has to be in platform dependent areas because of not only the tight coupling of received commands/events and the specific OS subsystem but because the platform independent code has (deliberately) no event/wait mechanisms.
2000-01-03 23:55:30 +00:00
case RQSTYPE_CTIO2:
case RQSTYPE_CTIO:
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
isp_handle_platform_ctio(isp, hp);
break;
Move 24xx RQSTYPE_NOTIFY handling to generic code. This code has nothing to do with specific platform. MFC after: 2 weeks
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;
Make a static chain of isp softcs- gdb usage becomes a lot easier. Add in a very large amount of target mode support code- this is just a first pass at this. It's a difficult thing because some of the code can be in platform independent areas (see isp_target.?) but a lot has to be in platform dependent areas because of not only the tight coupling of received commands/events and the specific OS subsystem but because the platform independent code has (deliberately) no event/wait mechanisms.
2000-01-03 23:55:30 +00:00
}
break;
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
}
Remove all pre-CAM code. Fix breakage for SCCLUN when it is in fact ISP2100_SCCLUN. Make changes for how ISPASYNC_PDB_CHANGE_COMPLETE is now ISPASYNC_PDB_CHANGED. Add in ISPASYNC_FABRIC_DEV case.
1999-07-02 23:12:58 +00:00
#endif
Add CAM_NEW_TRAN_CODE support. Use correct CAMLOCK_2_ISPLOCK macros. For fibre channel, start going for the gusto and using AC_FOUND_DEVICE and AC_LOST_DEVICE calls to xpt_async when devices appear and disappear as the loop or fabric changes. ISPASYNC_FW_CRASH is the async event code where the platform layer deals with a firmware crash.
2001-07-04 18:54:29 +00:00
case ISPASYNC_FW_CRASH:
{
a) clean up some declaration stuff (i.e., make more modern with respect to getting rid u_int for uint and so on). b) Turn back on 64 bit DAC support. Cheeze it a bit in that we have two DMA callback functions- one when we have bus_addr_t > 4 bits in width and the other which should be normal. Even Cheezier in that we turn off setting up DMA maps to be BUS_SPACE_MAXADDR if we're in ISP_TARGET_MODE. More work on this in a week or so. c) Tested under amd64 and 1MB DFLTPHYS, sparc64, i386 (PAE, but insufficient memory to really test > 4GB). LINT check under amd64. MFC after: 1 month
2006-02-15 00:31:48 +00:00
uint16_t mbox1, mbox6;
Add CAM_NEW_TRAN_CODE support. Use correct CAMLOCK_2_ISPLOCK macros. For fibre channel, start going for the gusto and using AC_FOUND_DEVICE and AC_LOST_DEVICE calls to xpt_async when devices appear and disappear as the loop or fabric changes. ISPASYNC_FW_CRASH is the async event code where the platform layer deals with a firmware crash.
2001-07-04 18:54:29 +00:00
mbox1 = ISP_READ(isp, OUTMAILBOX1);
if (IS_DUALBUS(isp)) {
mbox6 = ISP_READ(isp, OUTMAILBOX6);
} else {
mbox6 = 0;
}
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
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);
Remove some dead/broken code paths around async handling MFC after: 2 weeks
2017-03-14 18:42:33 +00:00
#if 0
Make this an MP safe driver but also still be multi-release. Seems to work on RELENG_4 through -current and also on sparc64 now. There may still be some issues with the auto attach/detach code to sort out. MFC after: 3 days
2007-05-05 20:17:23 +00:00
mbox1 = isp->isp_osinfo.mbox_sleep_ok;
isp->isp_osinfo.mbox_sleep_ok = 0;
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
isp_reinit(isp, 1);
Make this an MP safe driver but also still be multi-release. Seems to work on RELENG_4 through -current and also on sparc64 now. There may still be some issues with the auto attach/detach code to sort out. MFC after: 3 days
2007-05-05 20:17:23 +00:00
isp->isp_osinfo.mbox_sleep_ok = mbox1;
isp_async(isp, ISPASYNC_FW_RESTARTED, NULL);
Remove some dead/broken code paths around async handling MFC after: 2 weeks
2017-03-14 18:42:33 +00:00
#endif
Add CAM_NEW_TRAN_CODE support. Use correct CAMLOCK_2_ISPLOCK macros. For fibre channel, start going for the gusto and using AC_FOUND_DEVICE and AC_LOST_DEVICE calls to xpt_async when devices appear and disappear as the loop or fabric changes. ISPASYNC_FW_CRASH is the async event code where the platform layer deals with a firmware crash.
2001-07-04 18:54:29 +00:00
break;
}
Implement and use Fast Posting for both parallel && fibre. Redo a bit of the startup code. Implement a call to outer framework function so that asynchronous events can be handled (e.g., speed negotiation, target mode). Roll internal release tags.
1999-01-30 07:29:00 +00:00
default:
Core version 2.0 rewrite. In this file we replace isp_tdebug with isp_prt calls. We now use an argument to the ISPCTL_FCLINK_TEST call. We change all IDPRINTF macros to isp_prt calls. We add the isp_prt function here.
2000-08-01 06:31:44 +00:00
isp_prt(isp, ISP_LOGERR, "unknown isp_async event %d", cmd);
Implement and use Fast Posting for both parallel && fibre. Redo a bit of the startup code. Implement a call to outer framework function so that asynchronous events can be handled (e.g., speed negotiation, target mode). Roll internal release tags.
1999-01-30 07:29:00 +00:00
break;
}
}
clarify headers;move uninit to outer layer;remove watchdog
1998-12-28 19:22:27 +00:00
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
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);
Rework WWNs generation to make cards without NVRAM more useful.
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. */
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
if (isactive) {
Rework WWNs generation to make cards without NVRAM more useful.
2015-12-05 21:38:04 +00:00
seed = iswwnn ? FCPARAM(isp, chan)->isp_wwnn_nvram :
FCPARAM(isp, chan)->isp_wwpn_nvram;
if (seed)
Have at least *some* default WWN to fall back on, otherwise Sun branded FC cards won't configure. Reviewed by: Ken, Scott Approved by: re
2009-08-13 01:17:26 +00:00
return (seed);
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
}
Rework WWNs generation to make cards without NVRAM more useful.
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;
}
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
}
Rework WWNs generation to make cards without NVRAM more useful.
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;
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
}
Rework WWNs generation to make cards without NVRAM more useful.
2015-12-05 21:38:04 +00:00
/* For additional channels we have to improvise even more. */
if (!iswwnn && chan > 0) {
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
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
Rework WWNs generation to make cards without NVRAM more useful.
2015-12-05 21:38:04 +00:00
* of channel which is enough for our maximum of 255 channels.
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
*/
Rework WWNs generation to make cards without NVRAM more useful.
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;
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
}
return (seed);
}
Core version 2.0 rewrite. In this file we replace isp_tdebug with isp_prt calls. We now use an argument to the ISPCTL_FCLINK_TEST call. We change all IDPRINTF macros to isp_prt calls. We add the isp_prt function here.
2000-08-01 06:31:44 +00:00
void
Some more gratuitous format and name changes. Pull in some target mode changes from a private branch. Pull in some more RELENG_4 compilation changes. A lot of lines changed, but not much content change yet.
2006-04-21 18:30:01 +00:00
isp_prt(ispsoftc_t *isp, int level, const char *fmt, ...)
Core version 2.0 rewrite. In this file we replace isp_tdebug with isp_prt calls. We now use an argument to the ISPCTL_FCLINK_TEST call. We change all IDPRINTF macros to isp_prt calls. We add the isp_prt function here.
2000-08-01 06:31:44 +00:00
{
Fixes zombie device and loop down timers so that they work more than once. Use taskqueues to do the actual work. Fix an offset line. Fix isp_prt so that prints from just one buffer, which makes it appear cleanly cleanly in logs on SMP systems. Approved by: re (kib) MFC after: 1 month
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];
Core version 2.0 rewrite. In this file we replace isp_tdebug with isp_prt calls. We now use an argument to the ISPCTL_FCLINK_TEST call. We change all IDPRINTF macros to isp_prt calls. We add the isp_prt function here.
2000-08-01 06:31:44 +00:00
va_list ap;
Fixes zombie device and loop down timers so that they work more than once. Use taskqueues to do the actual work. Fix an offset line. Fix isp_prt so that prints from just one buffer, which makes it appear cleanly cleanly in logs on SMP systems. Approved by: re (kib) MFC after: 1 month
2011-08-12 19:51:28 +00:00
Core version 2.0 rewrite. In this file we replace isp_tdebug with isp_prt calls. We now use an argument to the ISPCTL_FCLINK_TEST call. We change all IDPRINTF macros to isp_prt calls. We add the isp_prt function here.
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));
Fixes zombie device and loop down timers so that they work more than once. Use taskqueues to do the actual work. Fix an offset line. Fix isp_prt so that prints from just one buffer, which makes it appear cleanly cleanly in logs on SMP systems. Approved by: re (kib) MFC after: 1 month
2011-08-12 19:51:28 +00:00
loc = strlen(lbuf);
Core version 2.0 rewrite. In this file we replace isp_tdebug with isp_prt calls. We now use an argument to the ISPCTL_FCLINK_TEST call. We change all IDPRINTF macros to isp_prt calls. We add the isp_prt function here.
2000-08-01 06:31:44 +00:00
va_start(ap, fmt);
Fixes zombie device and loop down timers so that they work more than once. Use taskqueues to do the actual work. Fix an offset line. Fix isp_prt so that prints from just one buffer, which makes it appear cleanly cleanly in logs on SMP systems. Approved by: re (kib) MFC after: 1 month
2011-08-12 19:51:28 +00:00
vsnprintf(&lbuf[loc], sizeof (lbuf) - loc - 1, fmt, ap);
Core version 2.0 rewrite. In this file we replace isp_tdebug with isp_prt calls. We now use an argument to the ISPCTL_FCLINK_TEST call. We change all IDPRINTF macros to isp_prt calls. We add the isp_prt function here.
2000-08-01 06:31:44 +00:00
va_end(ap);
Fixes zombie device and loop down timers so that they work more than once. Use taskqueues to do the actual work. Fix an offset line. Fix isp_prt so that prints from just one buffer, which makes it appear cleanly cleanly in logs on SMP systems. Approved by: re (kib) MFC after: 1 month
2011-08-12 19:51:28 +00:00
printf("%s\n", lbuf);
Core version 2.0 rewrite. In this file we replace isp_tdebug with isp_prt calls. We now use an argument to the ISPCTL_FCLINK_TEST call. We change all IDPRINTF macros to isp_prt calls. We add the isp_prt function here.
2000-08-01 06:31:44 +00:00
}
Push things closer to path failover by implementing loop down and gone device timers and zombie state entries. There are tunables that can be used to select a number of parameters. loop_down_limit - how long to wait for loop to come back up before declaring all devices dead (default 300 seconds) gone_device_time- how long to wait for a device that has appeared to leave the loop or fabric to reappear (default 30 seconds) Internal tunables include (which should be externalized): quick_boot_time- how long to wait when booting for loop to come up change_is_bad- whether or not to accept devices with the same WWNN/WWPN that reappear at a different PortID as being the 'same' device. Keen students of some of the subtle issues here will ask how one can keep devices from being re-accepted at all (the answer is to set a gone_device_time to zero- that effectively would be the same thing).
2006-11-14 08:45:48 +00:00
Clean up some printing stuff so that we can have a bit finer control on debug output. Add a new platform function requirement to allow for printing based upon the ITL nexus instead of the isp unit plus channel, target and lun. This allows some printouts and error messages from the core code to appear in the same format as the platform's subsystem (in FreeBSD's case, CAM path). MFC after: 1 week
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");
}
Push things closer to path failover by implementing loop down and gone device timers and zombie state entries. There are tunables that can be used to select a number of parameters. loop_down_limit - how long to wait for loop to come back up before declaring all devices dead (default 300 seconds) gone_device_time- how long to wait for a device that has appeared to leave the loop or fabric to reappear (default 30 seconds) Internal tunables include (which should be externalized): quick_boot_time- how long to wait when booting for loop to come up change_is_bad- whether or not to accept devices with the same WWNN/WWPN that reappear at a different PortID as being the 'same' device. Keen students of some of the subtle issues here will ask how one can keep devices from being re-accepted at all (the answer is to set a gone_device_time to zero- that effectively would be the same thing).
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);
Push things closer to path failover by implementing loop down and gone device timers and zombie state entries. There are tunables that can be used to select a number of parameters. loop_down_limit - how long to wait for loop to come back up before declaring all devices dead (default 300 seconds) gone_device_time- how long to wait for a device that has appeared to leave the loop or fabric to reappear (default 30 seconds) Internal tunables include (which should be externalized): quick_boot_time- how long to wait when booting for loop to come up change_is_bad- whether or not to accept devices with the same WWNN/WWPN that reappear at a different PortID as being the 'same' device. Keen students of some of the subtle issues here will ask how one can keep devices from being re-accepted at all (the answer is to set a gone_device_time to zero- that effectively would be the same thing).
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)
{
Remove tangled isp_mbox_continue() mechanism. It was implemented to reduce context switches when uploading firmware to card's RAM. But this mechanism is not used last 10 years since all mbox operations are now polled, and it was never used for cards produced in last 15 years. Newer cards can use DMA to upload firmware. MFC after: 2 weeks
2017-03-14 17:34:44 +00:00
u_int t, to;
Try an experiment with using DMA to load firmware into a 2200- VERIFY CHECKSUM fails. Oh well, but keep a couple of the changes. Avoid overflow in usec counters when waiting for mailbox completion.
2006-12-17 16:59:19 +00:00
Remove tangled isp_mbox_continue() mechanism. It was implemented to reduce context switches when uploading firmware to card's RAM. But this mechanism is not used last 10 years since all mbox operations are now polled, and it was never used for cards produced in last 15 years. Newer cards can use DMA to upload firmware. MFC after: 2 weeks
2017-03-14 17:34:44 +00:00
to = (mbp->timeout == 0) ? MBCMD_DEFAULT_TIMEOUT : mbp->timeout;
Push things closer to path failover by implementing loop down and gone device timers and zombie state entries. There are tunables that can be used to select a number of parameters. loop_down_limit - how long to wait for loop to come back up before declaring all devices dead (default 300 seconds) gone_device_time- how long to wait for a device that has appeared to leave the loop or fabric to reappear (default 30 seconds) Internal tunables include (which should be externalized): quick_boot_time- how long to wait when booting for loop to come up change_is_bad- whether or not to accept devices with the same WWNN/WWPN that reappear at a different PortID as being the 'same' device. Keen students of some of the subtle issues here will ask how one can keep devices from being re-accepted at all (the answer is to set a gone_device_time to zero- that effectively would be the same thing).
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;
Clean/unify some macro usage. MFC after: 2 weeks
2017-03-21 10:34:34 +00:00
msleep_sbt(&isp->isp_osinfo.mboxcmd_done, &isp->isp_lock,
Remove tangled isp_mbox_continue() mechanism. It was implemented to reduce context switches when uploading firmware to card's RAM. But this mechanism is not used last 10 years since all mbox operations are now polled, and it was never used for cards produced in last 15 years. Newer cards can use DMA to upload firmware. MFC after: 2 weeks
2017-03-14 17:34:44 +00:00
PRIBIO, "ispmbx_sleep", to * SBT_1US, 0, 0);
Try an experiment with using DMA to load firmware into a 2200- VERIFY CHECKSUM fails. Oh well, but keep a couple of the changes. Avoid overflow in usec counters when waiting for mailbox completion.
2006-12-17 16:59:19 +00:00
isp->isp_osinfo.mbox_sleep_ok = 1;
isp->isp_osinfo.mbox_sleeping = 0;
} else {
Remove tangled isp_mbox_continue() mechanism. It was implemented to reduce context switches when uploading firmware to card's RAM. But this mechanism is not used last 10 years since all mbox operations are now polled, and it was never used for cards produced in last 15 years. Newer cards can use DMA to upload firmware. MFC after: 2 weeks
2017-03-14 17:34:44 +00:00
for (t = 0; t < to; t += 100) {
if (isp->isp_osinfo.mboxcmd_done)
Try an experiment with using DMA to load firmware into a 2200- VERIFY CHECKSUM fails. Oh well, but keep a couple of the changes. Avoid overflow in usec counters when waiting for mailbox completion.
2006-12-17 16:59:19 +00:00
break;
Refactor interrupt handling. Instead of single isp_intr() function doing all possible magic, introduce four different functions to handle mailbox operation completions, async events, response and ATIO queues. The goal is to isolate different code paths to make code more readable, and to make easier support for multiple interrupt vectors. Even oldest hardware in many cases can identify what code path it should run on interrupt. Contemporary hardware can assign them to different interrupt vectors. MFC after: 2 weeks
2017-03-15 14:58:29 +00:00
ISP_RUN_ISR(isp);
if (isp->isp_osinfo.mboxcmd_done)
break;
Remove tangled isp_mbox_continue() mechanism. It was implemented to reduce context switches when uploading firmware to card's RAM. But this mechanism is not used last 10 years since all mbox operations are now polled, and it was never used for cards produced in last 15 years. Newer cards can use DMA to upload firmware. MFC after: 2 weeks
2017-03-14 17:34:44 +00:00
ISP_DELAY(100);
Push things closer to path failover by implementing loop down and gone device timers and zombie state entries. There are tunables that can be used to select a number of parameters. loop_down_limit - how long to wait for loop to come back up before declaring all devices dead (default 300 seconds) gone_device_time- how long to wait for a device that has appeared to leave the loop or fabric to reappear (default 30 seconds) Internal tunables include (which should be externalized): quick_boot_time- how long to wait when booting for loop to come up change_is_bad- whether or not to accept devices with the same WWNN/WWPN that reappear at a different PortID as being the 'same' device. Keen students of some of the subtle issues here will ask how one can keep devices from being re-accepted at all (the answer is to set a gone_device_time to zero- that effectively would be the same thing).
2006-11-14 08:45:48 +00:00
}
}
if (isp->isp_osinfo.mboxcmd_done == 0) {
Remove tangled isp_mbox_continue() mechanism. It was implemented to reduce context switches when uploading firmware to card's RAM. But this mechanism is not used last 10 years since all mbox operations are now polled, and it was never used for cards produced in last 15 years. Newer cards can use DMA to upload firmware. MFC after: 2 weeks
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);
Push things closer to path failover by implementing loop down and gone device timers and zombie state entries. There are tunables that can be used to select a number of parameters. loop_down_limit - how long to wait for loop to come back up before declaring all devices dead (default 300 seconds) gone_device_time- how long to wait for a device that has appeared to leave the loop or fabric to reappear (default 30 seconds) Internal tunables include (which should be externalized): quick_boot_time- how long to wait when booting for loop to come up change_is_bad- whether or not to accept devices with the same WWNN/WWPN that reappear at a different PortID as being the 'same' device. Keen students of some of the subtle issues here will ask how one can keep devices from being re-accepted at all (the answer is to set a gone_device_time to zero- that effectively would be the same thing).
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;
Remove tangled isp_mbox_continue() mechanism. It was implemented to reduce context switches when uploading firmware to card's RAM. But this mechanism is not used last 10 years since all mbox operations are now polled, and it was never used for cards produced in last 15 years. Newer cards can use DMA to upload firmware. MFC after: 2 weeks
2017-03-14 17:34:44 +00:00
if (isp->isp_osinfo.mbox_sleeping)
wakeup(&isp->isp_osinfo.mboxcmd_done);
Push things closer to path failover by implementing loop down and gone device timers and zombie state entries. There are tunables that can be used to select a number of parameters. loop_down_limit - how long to wait for loop to come back up before declaring all devices dead (default 300 seconds) gone_device_time- how long to wait for a device that has appeared to leave the loop or fabric to reappear (default 30 seconds) Internal tunables include (which should be externalized): quick_boot_time- how long to wait when booting for loop to come up change_is_bad- whether or not to accept devices with the same WWNN/WWPN that reappear at a different PortID as being the 'same' device. Keen students of some of the subtle issues here will ask how one can keep devices from being re-accepted at all (the answer is to set a gone_device_time to zero- that effectively would be the same thing).
2006-11-14 08:45:48 +00:00
}
void
isp_mbox_release(ispsoftc_t *isp)
{
isp->isp_osinfo.mboxbsy = 0;
}
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
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);
}
Make this an MP safe driver but also still be multi-release. Seems to work on RELENG_4 through -current and also on sparc64 now. There may still be some issues with the auto attach/detach code to sort out. MFC after: 3 days
2007-05-05 20:17:23 +00:00
void
isp_platform_intr(void *arg)
{
ispsoftc_t *isp = arg;
ISP_LOCK(isp);
Refactor interrupt handling. Instead of single isp_intr() function doing all possible magic, introduce four different functions to handle mailbox operation completions, async events, response and ATIO queues. The goal is to isolate different code paths to make code more readable, and to make easier support for multiple interrupt vectors. Even oldest hardware in many cases can identify what code path it should run on interrupt. Contemporary hardware can assign them to different interrupt vectors. MFC after: 2 weeks
2017-03-15 14:58:29 +00:00
ISP_RUN_ISR(isp);
Make this an MP safe driver but also still be multi-release. Seems to work on RELENG_4 through -current and also on sparc64 now. There may still be some issues with the auto attach/detach code to sort out. MFC after: 3 days
2007-05-05 20:17:23 +00:00
ISP_UNLOCK(isp);
}
Add initial support for multiple MSI-X vectors. For 24xx and above use 2 vectors (default and response queue). For 26xx and above use 3 vectors (default, response and ATIO queues). Due to global lock interrupt hardlers never run simultaneously now, but at least this allows to save one regitster read per interrupt. MFC after: 2 weeks
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);
}
Make this an MP safe driver but also still be multi-release. Seems to work on RELENG_4 through -current and also on sparc64 now. There may still be some issues with the auto attach/detach code to sort out. MFC after: 3 days
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) {
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
bus_dmamap_sync(isp->isp_osinfo.dmat, PISP_PCMD(csio)->dmap, BUS_DMASYNC_POSTREAD);
Make this an MP safe driver but also still be multi-release. Seems to work on RELENG_4 through -current and also on sparc64 now. There may still be some issues with the auto attach/detach code to sort out. MFC after: 3 days
2007-05-05 20:17:23 +00:00
} else {
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
2009-08-01 01:04:26 +00:00
bus_dmamap_sync(isp->isp_osinfo.dmat, PISP_PCMD(csio)->dmap, BUS_DMASYNC_POSTWRITE);
Make this an MP safe driver but also still be multi-release. Seems to work on RELENG_4 through -current and also on sparc64 now. There may still be some issues with the auto attach/detach code to sort out. MFC after: 3 days
2007-05-05 20:17:23 +00:00
}
bus_dmamap_unload(isp->isp_osinfo.dmat, PISP_PCMD(csio)->dmap);
}
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
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
Fix/improve CRN tracking.
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
{
Fix/improve CRN tracking.
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;
Fix/improve CRN tracking.
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)
Fix/improve CRN tracking.
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
Fix/improve CRN tracking.
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++) {
Fix/improve CRN tracking.
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)
{
Add PIM_EXTLUNS support to isp(4) driver. Now 24xx and above chips support full 8-byte LUN address space. Older FC chips may support up to 16K LUNs when firmware allows. Tested in both initiator and target modes for 23xx, 24xx and 25xx.
2015-10-24 17:34:40 +00:00
lun_id_t lun;
uint32_t chan, tgt;
Fix an oops where we wiped out DMA maps. Don't allocate extended command space for anything less than a 2300. MFC after: 1 month X-MFC: 238869
2012-08-12 20:45:47 +00:00
struct isp_fc *fc;
struct isp_nexus *nxp;
int idx;
Fix target mode support for Qlogic 2200 FC adapters. Now target mode works for all supported FC adapters except ancient 2100, which is not tested.
2015-11-23 15:49:50 +00:00
if (IS_2100(isp))
Fix an oops where we wiped out DMA maps. Don't allocate extended command space for anything less than a 2300. MFC after: 1 month X-MFC: 238869
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;
}
Fix/improve CRN tracking.
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
}
More rototilling with target mode in an attemp to get multiple CCB at a time outstanding reliable. It's not there yet, but this is the direction to go in so might as well commit. So far, multiple at a time CCBs work (see ISP_INTERNAL_TARGET test mode), but it fails if there are more downstream than the SIM wants to handle and SRR is sort of confused when this happens, plus it is not entirely quite clear what one does if a CCB/CTIO fails and you have more in flight (that don't fail, say) and more queued up at the SIM level that haven't been started yet. Some of this is driven because there apparently is no flow control to requeue XPT_CONTINUE_IO requests like there are for XPT_SCSI_IO requests. It is also more driven in that the few target mode periph drivers there are are not really set up for handling pushback- heck most of them don't even check for errors (and what would they really do with them anyway? It's the initiator's problem, really....). The data transfer arithmetic has been worked over again to handle multiple outstanding commands, so you have a notion of what's been moved already as well as what's currently in flight. It turns that this led to uncovering a REPORT_LUNS bug in the ISP_INTERNAL_TARGET code which was sending back 24 bytes of rpl data instead of the specified 16. What happened furthermore here is that sending back 16 bytes and reporting an overrun of 8 bytes made the initiator (running FC-Tape aware f/w) mad enough to request, and keep requesting, another FCP response (I guess it didn't like the answer so kept asking for it again). Sponsored by: Spectralogic MFC after: 1 month
2012-08-08 18:24:33 +00:00
/*
* We enter with the lock held
*/
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
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
More rototilling with target mode in an attemp to get multiple CCB at a time outstanding reliable. It's not there yet, but this is the direction to go in so might as well commit. So far, multiple at a time CCBs work (see ISP_INTERNAL_TARGET test mode), but it fails if there are more downstream than the SIM wants to handle and SRR is sort of confused when this happens, plus it is not entirely quite clear what one does if a CCB/CTIO fails and you have more in flight (that don't fail, say) and more queued up at the SIM level that haven't been started yet. Some of this is driven because there apparently is no flow control to requeue XPT_CONTINUE_IO requests like there are for XPT_SCSI_IO requests. It is also more driven in that the few target mode periph drivers there are are not really set up for handling pushback- heck most of them don't even check for errors (and what would they really do with them anyway? It's the initiator's problem, really....). The data transfer arithmetic has been worked over again to handle multiple outstanding commands, so you have a notion of what's been moved already as well as what's currently in flight. It turns that this led to uncovering a REPORT_LUNS bug in the ISP_INTERNAL_TARGET code which was sending back 24 bytes of rpl data instead of the specified 16. What happened furthermore here is that sending back 16 bytes and reporting an overrun of 8 bytes made the initiator (running FC-Tape aware f/w) mad enough to request, and keep requesting, another FCP response (I guess it didn't like the answer so kept asking for it again). Sponsored by: Spectralogic MFC after: 1 month
2012-08-08 18:24:33 +00:00
callout_reset(&isp->isp_osinfo.tmo, isp_timer_count, isp_timer, isp);
Add 8Gb support (isp_2500). Fix a fair number of configuration and firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
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;
}
Reference in New Issue Copy Permalink