Dan Lane | 12 Feb 04:33 2016
Picon

Re: ESX FC host connectivty issues (was target crashes with vSphere 6 hosts)

On Thu, Feb 11, 2016 at 9:44 PM, Dan Lane <dracodan <at> gmail.com> wrote:
>
> On Feb 11, 2016 8:58 PM, "Nicholas A. Bellinger" <nab <at> linux-iscsi.org>
> wrote:
>>
>> On Thu, 2016-02-11 at 20:42 -0500, Dan Lane wrote:
>> > On Thu, Feb 11, 2016 at 8:19 PM, Nicholas A. Bellinger
>> > <nab <at> linux-iscsi.org> wrote:
>> > > On Thu, 2016-02-11 at 19:54 -0500, Dan Lane wrote:
>> > >
>> > > Top posting..
>> > SORRY!  I BLAME GOOGLE!!!
>> > >
>> > >> Well, looks like it wasn't as stable as we thought...
>> > >
>> > > Like I've already said multiple times, you need to find out what
>> > > component of your FC network is dropping packets.
>> > >
>> > >> Here is a clip
>> > >> from the logs, this is the only thing other than the ABORT_TASK I
>> > >> could find in the system logs.  Unfortunately I have no idea when it
>> > >> stopped responding to my hosts.
>> > >
>> > > How do you know it's the target that stopped responding..?
>> > >
>> > > ESX will eventually take a device offline if it's not consistently
>> > > getting responses, resulting in constant generation of ABORT_TASKs.
>> > >
>> > > Again, it's a clear sign that you're having some manner of FC
>> > > connectivity issues.
(Continue reading)

Sheng Yang | 12 Feb 03:42 2016

TCMU timeout cause kernel panic

Hi Andy,

I've got several kernel panic reports when userspace connected, then
disconnected, and connect again after a while.

So I am looking into how TCMU handle expired commands, but cannot find
the proper way to do it.

I assume tcmu_device_timedout() would be triggered if one command has
been pending for 30 seconds(which defined in TCMU_TIME_OUT). In it, it
would:
1. Handle all userspace completed request, through tcmu_handle_completions.
2. Run tcmu_check_expired_cmd() for every existing command.

I noticed that there was a bug in TCMU code that the deadline of
command was wrongly compared to jiffies, result in cleanup code never
involved. I start to see kernel panic after fixing the bug, which
seems expose the bug.

In tcmu_check_expired_cmd(), which would be involved for every
commands in tcmu_device_timedout():

static int tcmu_check_expired_cmd(int id, void *p, void *data)
{
        struct tcmu_cmd *cmd = p;

        if (test_bit(TCMU_CMD_BIT_EXPIRED, &cmd->flags))
                return 0;

        if (!time_after(jiffies, cmd->deadline))
(Continue reading)

Jason Gyorog | 12 Feb 00:11 2016

Emulex target support

Hello,

As far as I can tell, there is no support for Emulex FC cards in
target mode. Is this still correct? Does anyone know of a resource for
using Emulex as a FC target in Linux, other than using SCST?

We're trying to move to a newer kernel, but we're dependent on Emulex
target support, which we've been getting through SCST, but that locks
us in to using a 2.6.x kernel.

Jason Gyorog

Studio Network Solutions (SNS)
2436 Northline Industrial Drive
Maryland Heights, MO 63043
Direct: +1-314-733-0551
www.studionetworksolutions.com
Nicholas A. Bellinger | 11 Feb 08:02 2016

[PATCH] target: Fix incorrect unmap_zeroes_data_store return

From: Nicholas Bellinger <nab <at> linux-iscsi.org>

This patch fixes an incorrect return of zero from the new
unmap_zeroes_data_store() configfs store attribute handler
introduced in v4.5-rc1, to use the correct 'count' bytes
return value.

Signed-off-by: Nicholas Bellinger <nab <at> linux-iscsi.org>
---
 drivers/target/target_core_configfs.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/target/target_core_configfs.c b/drivers/target/target_core_configfs.c
index 3327c49..713c63d9 100644
--- a/drivers/target/target_core_configfs.c
+++ b/drivers/target/target_core_configfs.c
 <at>  <at>  -898,7 +898,7  <at>  <at>  static ssize_t unmap_zeroes_data_store(struct config_item *item,
 	da->unmap_zeroes_data = flag;
 	pr_debug("dev[%p]: SE Device Thin Provisioning LBPRZ bit: %d\n",
 		 da->da_dev, flag);
-	return 0;
+	return count;
 }

 /*
--

-- 
1.9.1

Schlacta, Christ | 11 Feb 03:36 2016

(unknown)

I'm trying to run lio with targetcli and tcm_qla2xxx and of course
qla2xxx on debian jessie with kernel debian 3.16.0-4, and I'm running
into the strangest issue.  I'm seeing everything as apparently correct
in targetcli, with no unexpected errors in dmesg or otherwise.  The
card works fine, as it functioned correctly with scst, but I get only
one device on the initiator now, and it's not any of the devices I've
configured.  It appears as follows in the client on QConvergeConsole
(The management software for the windows driver):

Product Vendor:
LIO-ORG
Product ID:
RAMDISK-MCP
Product Revision:
4.0
LUN:
0
Size:
Unknown
Type:
Unknown
WWULN:
4C-49-4F-2D-4F-52-47-00-00

I got no idea what to try, but I'm thinking about switching back to
scst even though I upgraded to debian jessie to get in-kernel lio if I
can't figure out what's wrong here.  Tell me what you'd like to see,
and I'll share it.  Below are some log snippets that I doubt will be
useful, but may be.

(Continue reading)

Dan Lane | 11 Feb 03:30 2016
Picon

Re: target crashes with vSphere 6 hosts

resending a second time... sorry!

On Wed, Feb 10, 2016 at 9:26 PM, Dan Lane <dracodan <at> gmail.com> wrote:
>
>
> On Tue, Feb 9, 2016 at 1:15 AM, Nicholas A. Bellinger <nab <at> linux-iscsi.org>
> wrote:
>>
>> Hi Dan,
>>
>> (Re-adding target-devel CC')
>>
>> On Mon, 2016-02-08 at 19:34 -0500, Dan Lane wrote:
>>
>> > Hey Nicholas, I ran into an issue trying to follow your directions and
>> > I was hoping you could assist.  I'm not familiar enough with git to
>> > understand what you're trying to do and google isn't finding anything
>> > helpful.
>> >
>> > When I run:
>> > git pull '$ORIGIN $BRANCH'
>> > I get:
>> > fatal: '$ORIGIN $BRANCH' does not appear to be a git repository
>> > fatal: Could not read from remote repository.
>> >
>> > Please make sure you have the correct access rights
>> > and the repository exists.
>>
>> git pull $ORIGIN $BRANCH is an example of doing a git pull from a remote
>> tree + branch.
(Continue reading)

Nicholas A. Bellinger | 9 Feb 07:15 2016

Re: target crashes with vSphere 6 hosts

Hi Dan,

(Re-adding target-devel CC')

On Mon, 2016-02-08 at 19:34 -0500, Dan Lane wrote:

> Hey Nicholas, I ran into an issue trying to follow your directions and
> I was hoping you could assist.  I'm not familiar enough with git to
> understand what you're trying to do and google isn't finding anything
> helpful.
> 
> When I run:
> git pull '$ORIGIN $BRANCH'
> I get:
> fatal: '$ORIGIN $BRANCH' does not appear to be a git repository
> fatal: Could not read from remote repository.
>
> Please make sure you have the correct access rights
> and the repository exists.

git pull $ORIGIN $BRANCH is an example of doing a git pull from a remote
tree + branch.

That is, you need a specify to pull from a remote $ORIGIN repository
tree, and a specific $BRANCH head within that remote tree.

When 'target-pending/4.4-stable' was referenced earlier, from git CLI
level it means to:

   git pull git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending.git refs/heads/4.4-stable
(Continue reading)

Nicholas A. Bellinger | 7 Feb 07:22 2016

[PATCH] target/iblock: Use -EAGAIN/-ENOMEM to propigate SAM BUSY/TASK_SET_FULL

From: Nicholas Bellinger <nab <at> linux-iscsi.org>

This patch updates target/iblock backend driver code to
check for bio completion status of -EAGAIN / -ENOMEM
provided by raw block drivers and scsi devices, in order
to generate the following SCSI status to initiators:

  - SAM_STAT_BUSY
  - SAM_STAT_TASK_SET_FULL

Note these two SAM status codes are useful to signal to
Linux SCSI host side that se_cmd should be retried
again, or with TASK_SET_FULL case to attempt to lower
our internal host LLD queue_depth and scsi_cmnd retry.

It also updates target_complete_cmd() to parse status
when signalling success to target_completion_wq.

Cc: Christoph Hellwig <hch <at> lst.de>
Cc: Hannes Reinecke <hare <at> suse.de>
Cc: Sagi Grimberg <sagig <at> mellanox.com>
Cc: Andy Grover <agrover <at> redhat.com>
Cc: Mike Christie <mchristi <at> redhat.com>
Signed-off-by: Nicholas Bellinger <nab <at> linux-iscsi.org>
---
 drivers/target/target_core_iblock.c    | 38 +++++++++++++++++++++++++++-------
 drivers/target/target_core_iblock.h    |  1 +
 drivers/target/target_core_transport.c | 13 ++++++++++--
 3 files changed, 43 insertions(+), 9 deletions(-)

(Continue reading)

Maged Mokhtar | 1 Feb 22:24 2016
Picon

iSCSI login failure, possible race condition

Hello,

I am seeing frequent "iSCSI Login negotiation failed." when trying to
connect  a Microsoft client initiator running inside a virtual machine
to a lio target running in another virtual machine under VMWare.
It happens in kernels 3.12, 3.16 and 3.19. It does not happen in older
kernels 3.8 and 3.10.

I did some tracing and found it is related to the changes from
PATCH-v3 0/5 9 Sep 23:38 2013 "Add support for login multi-plexing
support" .
There seems to be a race condition that happen in the newer
iscsi_target_nego.c code:

The successul logins happen when:
iscsi_target_start_negotiation() calls iscsi_target_do_login() which
returns 0, iscsi_target_start_negotiation()  sets the
LOGIN_FLAGS_READY.
iscsi_target_sk_data_ready() callback is received, finds the
LOGIN_FLAGS_READY flag set and proceed with calling
schedule_delayed_work() to handle further negotiation

The failed logins happen when
iscsi_target_start_negotiation() calls iscsi_target_do_login(), but
before the later returns, iscsi_target_sk_data_ready() callback is
received and finds the LOGIN_FLAGS_READY flag not set and exits
without calling schedule_delayed_work(). Later iscsi_target_do_login()
returns 0 and scsi_target_start_negotiation()  sets the
LOGIN_FLAGS_READY but it is too late.

(Continue reading)

Nicholas A. Bellinger | 30 Jan 08:05 2016

[PATCH-v3 00/14] target_alloc_session w/ percpu_ida+ACK_KREF conversion

From: Nicholas Bellinger <nab <at> linux-iscsi.org>

Hi all,

Here is -v3 series code for target_alloc_session() helper
support using existing percpu-ida tag pre-allocation, along
with a new (*callback)() for allowing fabric driver code
setup to complete ahead of transport_register_session()
completing I_T nexus setup.

This includes a tree-wide fabric driver conversion to use
use target_alloc_session() + associated (*callback)() with
common code.  It updates vhost/iscsi and tcm_qla2xxx code
to use the new callback to finish their internal driver
setup for se_session.

As per HCH, it also contains sbp-target, usb-gadget/tcm,
xen-scsiback, tcm_fc and ib_srpt driver percpu_ida tag
pre-allocation conversions, along with TARGET_SCF_ACK_KREF
changes for v4.6-rc code.

Please review.

--nab

v3 changes:

  - Add xen-scsiback wrapper for handling pending_req tag failure
  - Add tcm_fc conversion to TARGET_SCF_ACK_KREF
  - Add ib_srpt conversion to percpu_ida tag allocation
(Continue reading)

Sagi Grimberg | 28 Jan 14:53 2016
Picon

[LSF/MM ATTEND] dm-multipath, nvme, (remote) pmem and friends

Hi,

I'd like to attend LSF/MM 2016.

I've been working on scsi rdma transports and the target stack for some
time now. Lately I've been looking at nvme as well and I think I can
contribute to the dm-multipath discussions in the context of nvme and
blk-mq performance. If we plan to talk about nvme target then I think
I can contribute to the discussion as well.

In addition as an active contributor to the RDMA stack, I'm very
interested in discussing the possibilities of remote access to
persistent memory devices suggested by Chuck. I suspect we'll gradually
see more and more applications utilizing such a model and it would be
very beneficial if we can come up with something general enough for
everyone to use.

Cheers,
Sagi.

Gmane