Re: It seems that the iSCSI NOP In/Out statistic counters are not supported?

2012-04-25 Thread Mike Christie
On 04/24/2012 02:08 PM, Jeff Byers wrote:
 Hello,
 
 A small thing, but it seems that the iSCSI NOP In/Out 
 statistic counters 'noptx_pdus' and 'noprx_pdus' seem
 to be not supported, and are never being incremented, 
 even though I do see these PDU's are seen being
 sent/received on the wire.
 
 I did a quick grep of the source code and they don't
 appear to be incremented anywhere.
 

You are right. Working on a patch.

-- 
You received this message because you are subscribed to the Google Groups 
open-iscsi group.
To post to this group, send email to open-iscsi@googlegroups.com.
To unsubscribe from this group, send email to 
open-iscsi+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/open-iscsi?hl=en.



Re: iscsi authentication error from centos to a synology iscsi target.

2012-04-25 Thread Guillaume


Le mercredi 25 avril 2012 06:15:55 UTC+2, Mike Christie a écrit :



 Data digests are not supported in centos/rhel 5. You should get a 
 different error though. You should not get that stack trace below. If 
 you guys are getting a stack trace like below I will try to do some more 
 debugging. I did not see that below when I tested here. 



Ok.

I don't have the stack trace but whe I activate data digest on the target I 
have the error :
iscsiadm: initiator reported error (24 - iSCSI login failed due to 
authorization failure)

Is data digest supported in RedHat EL6 or CentOS 6 ? I will have to 
reinstall the server this summer on new hardware soo if it's ok I will 
install one of these.

(sorry for the double post yesterday, I did not see my post in the thread 
so I posted another one)


-- 
You received this message because you are subscribed to the Google Groups 
open-iscsi group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/open-iscsi/-/COrkv33UUSsJ.
To post to this group, send email to open-iscsi@googlegroups.com.
To unsubscribe from this group, send email to 
open-iscsi+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/open-iscsi?hl=en.



Re: [PATCH 1/3] ISCSID: Added iface_num to the ep_connect kernel call

2012-04-25 Thread Eddie Wai

On Wed, 2012-04-18 at 12:42 -0500, Mike Christie wrote:
 On 04/18/2012 11:58 AM, Eddie Wai wrote:
  
  On Wed, 2012-04-18 at 03:14 -0500, Mike Christie wrote:
  On 04/18/2012 01:21 AM, Eddie Wai wrote:
 
  On Tue, 2012-04-17 at 21:36 -0500, Mike Christie wrote:
  On 04/04/2012 06:39 PM, Eddie Wai wrote:
  struct msg_req_path {
  uint32_thost_no;
  +   uint32_tiface_num;
  } req_path;
 
  Are you using this in iscsiuo now? Do you match the host_no + iface_num
  to some iface file in /var/lib/iscsi/ifaces? How do you do it?
 
  The new iscsiuio will look for the host_no from the uevent and extract
  the iface_num accordingly.  The matching logic matches this iface_num
  with the iface struct created from the iface info received from the
  iscsid-iscsiuio socket.  It does not examine the /var/lib/iscsi/ifaces
  database directly.
 
  In the situation when multiple ifaces are supported per HBA, each iface
  info passed from iscsid will create entries to the iface struct linklist
  in iscsiuio.  The asynchronous PATH_REQ nl uevents will then supply the
  iface_num as the key for the search.  This will take the guessing work
  away from iscsiuio.
 
 
  For qla4xxx and be2iscsi the iface num is based on some fw/hw/driver
  type of limit. For the other drivers right now it is always 0. Are you
  having users set the iface_num manually then? Do we need a function to
  automatically allocate a new unique iface_num value for drivers like bnx2i?
  Currently, we are relying on the user to set the iface_num accordingly.
  We'll have to beef up the README for that.  We can definitely think
  about having it automatically allocated.  But it would only work on the
  iface files that are auto generated from iscsiadm.  Manually added iface
  files would not work here.  Another possible idea would be to make the
  iface_num field hidden so users doesn't have to deal with it at all and
 
 That would be best.
 
  the management will be all in iscsid.  But as I understand, that doesn't
  quite work for qla/be2 as the iface_num is, by design, controlled by the
  user (iface apply) to setup the different net param info for the HBA.
 
 The user does not actually have to know and probably does not know about
 the iface num for qla/be in the default use case. When you load those
 drivers they will create ifaces with specific nums and that is exported
 in the sysfs as part of the iface's sysfs name.
 iface_setup_binding_from_kern_iface will then grab that and set that up
 for the default iface creation.
 
 When the user runs a iscsiadm command they pass in the ifacename like
 normal and so the user does not really know about iface nums at all. It
 is just something for userspace/kernel to use to match on. We could have
 just passed around the iface name instead. Not sure why we did not.
 Maybe because the num is much shorter.
 
 I was asking about the iface num being auto created because we need a
 fix for the isid is not persistent problem. For that we need a 24 bit
 value that is unique and persistent for each iscsi port (initiatorname +
 isid combo). I could reuse that code for allocating unique ifacenums.
 For both cases we need to loop over some existing objects and find a
 free id, or we need to create a integer id based off of some other
 attributes of the object. Any idea for the latter?
 
 Your patches are ok as is. Let me try to make it so users do not have to
 worry about iface nums.
 
Our current solution also expects the iface_num to be unique only within
its IP type as well.  Same idea as qla/be.  So we'll need to define two
arrays of free ids instead.  I guess you need unique 24-bit numbers to
resolve the persistent isid problem...  Currently, the iface_num is
defined to be 16 bits long.  So perhaps some kind of combined format can
work here.  Something like using only the lower 16-bit of this unique
24-bit number for iface_num usage.  Perhaps the upper 8-bit can be
derived from host# + ipv4/6?
 
 


-- 
You received this message because you are subscribed to the Google Groups 
open-iscsi group.
To post to this group, send email to open-iscsi@googlegroups.com.
To unsubscribe from this group, send email to 
open-iscsi+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/open-iscsi?hl=en.



[PATCH 1/2] BNX2I: Added the setting of target can_queue via target_alloc

2012-04-25 Thread Eddie Wai
This will set the target can_queue limit to the number of preallocated
session tasks set during creation.

Could not send nopout messages were observed without this when the
iSCSI connection experiences dropped frames under heavy I/O stress.

Signed-off-by: Eddie Wai eddie@broadcom.com
---
 drivers/scsi/bnx2i/bnx2i_iscsi.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/scsi/bnx2i/bnx2i_iscsi.c b/drivers/scsi/bnx2i/bnx2i_iscsi.c
index 1a44b45..e4029327 100644
--- a/drivers/scsi/bnx2i/bnx2i_iscsi.c
+++ b/drivers/scsi/bnx2i/bnx2i_iscsi.c
@@ -2244,6 +2244,7 @@ static struct scsi_host_template bnx2i_host_template = {
.eh_device_reset_handler = iscsi_eh_device_reset,
.eh_target_reset_handler = iscsi_eh_recover_target,
.change_queue_depth = iscsi_change_queue_depth,
+   .target_alloc   = iscsi_target_alloc,
.can_queue  = 2048,
.max_sectors= 127,
.cmd_per_lun= 128,
-- 
1.7.7.4


-- 
You received this message because you are subscribed to the Google Groups 
open-iscsi group.
To post to this group, send email to open-iscsi@googlegroups.com.
To unsubscribe from this group, send email to 
open-iscsi+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/open-iscsi?hl=en.



[PATCH 2/2] BNX2I: Updated version and copyright year

2012-04-25 Thread Eddie Wai
Old version: 2.7.0.3
New version: 2.7.2.2

Signed-off-by: Eddie Wai eddie@broadcom.com
---
 drivers/scsi/bnx2i/57xx_iscsi_constants.h |2 +-
 drivers/scsi/bnx2i/57xx_iscsi_hsi.h   |2 +-
 drivers/scsi/bnx2i/bnx2i.h|2 +-
 drivers/scsi/bnx2i/bnx2i_hwi.c|2 +-
 drivers/scsi/bnx2i/bnx2i_init.c   |6 +++---
 drivers/scsi/bnx2i/bnx2i_iscsi.c  |2 +-
 drivers/scsi/bnx2i/bnx2i_sysfs.c  |2 +-
 7 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/scsi/bnx2i/57xx_iscsi_constants.h 
b/drivers/scsi/bnx2i/57xx_iscsi_constants.h
index 495a841..25093a0 100644
--- a/drivers/scsi/bnx2i/57xx_iscsi_constants.h
+++ b/drivers/scsi/bnx2i/57xx_iscsi_constants.h
@@ -1,6 +1,6 @@
 /* 57xx_iscsi_constants.h: Broadcom NetXtreme II iSCSI HSI
  *
- * Copyright (c) 2006 - 2011 Broadcom Corporation
+ * Copyright (c) 2006 - 2012 Broadcom Corporation
  *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License as published by
diff --git a/drivers/scsi/bnx2i/57xx_iscsi_hsi.h 
b/drivers/scsi/bnx2i/57xx_iscsi_hsi.h
index 72118db..dc0a08e 100644
--- a/drivers/scsi/bnx2i/57xx_iscsi_hsi.h
+++ b/drivers/scsi/bnx2i/57xx_iscsi_hsi.h
@@ -1,6 +1,6 @@
 /* 57xx_iscsi_hsi.h: Broadcom NetXtreme II iSCSI HSI.
  *
- * Copyright (c) 2006 - 2011 Broadcom Corporation
+ * Copyright (c) 2006 - 2012 Broadcom Corporation
  *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License as published by
diff --git a/drivers/scsi/bnx2i/bnx2i.h b/drivers/scsi/bnx2i/bnx2i.h
index 0bd70e8..0c53c28 100644
--- a/drivers/scsi/bnx2i/bnx2i.h
+++ b/drivers/scsi/bnx2i/bnx2i.h
@@ -1,6 +1,6 @@
 /* bnx2i.h: Broadcom NetXtreme II iSCSI driver.
  *
- * Copyright (c) 2006 - 2011 Broadcom Corporation
+ * Copyright (c) 2006 - 2012 Broadcom Corporation
  * Copyright (c) 2007, 2008 Red Hat, Inc.  All rights reserved.
  * Copyright (c) 2007, 2008 Mike Christie
  *
diff --git a/drivers/scsi/bnx2i/bnx2i_hwi.c b/drivers/scsi/bnx2i/bnx2i_hwi.c
index f9d6f41..ece47e5 100644
--- a/drivers/scsi/bnx2i/bnx2i_hwi.c
+++ b/drivers/scsi/bnx2i/bnx2i_hwi.c
@@ -1,6 +1,6 @@
 /* bnx2i_hwi.c: Broadcom NetXtreme II iSCSI driver.
  *
- * Copyright (c) 2006 - 2011 Broadcom Corporation
+ * Copyright (c) 2006 - 2012 Broadcom Corporation
  * Copyright (c) 2007, 2008 Red Hat, Inc.  All rights reserved.
  * Copyright (c) 2007, 2008 Mike Christie
  *
diff --git a/drivers/scsi/bnx2i/bnx2i_init.c b/drivers/scsi/bnx2i/bnx2i_init.c
index 4927cca..8b68167 100644
--- a/drivers/scsi/bnx2i/bnx2i_init.c
+++ b/drivers/scsi/bnx2i/bnx2i_init.c
@@ -1,6 +1,6 @@
 /* bnx2i.c: Broadcom NetXtreme II iSCSI driver.
  *
- * Copyright (c) 2006 - 2011 Broadcom Corporation
+ * Copyright (c) 2006 - 2012 Broadcom Corporation
  * Copyright (c) 2007, 2008 Red Hat, Inc.  All rights reserved.
  * Copyright (c) 2007, 2008 Mike Christie
  *
@@ -18,8 +18,8 @@ static struct list_head adapter_list = 
LIST_HEAD_INIT(adapter_list);
 static u32 adapter_count;
 
 #define DRV_MODULE_NAMEbnx2i
-#define DRV_MODULE_VERSION 2.7.0.3
-#define DRV_MODULE_RELDATE Jun 15, 2011
+#define DRV_MODULE_VERSION 2.7.2.2
+#define DRV_MODULE_RELDATE Apr 25, 2012
 
 static char version[] __devinitdata =
Broadcom NetXtreme II iSCSI Driver  DRV_MODULE_NAME \
diff --git a/drivers/scsi/bnx2i/bnx2i_iscsi.c b/drivers/scsi/bnx2i/bnx2i_iscsi.c
index e4029327..f8d516b 100644
--- a/drivers/scsi/bnx2i/bnx2i_iscsi.c
+++ b/drivers/scsi/bnx2i/bnx2i_iscsi.c
@@ -1,7 +1,7 @@
 /*
  * bnx2i_iscsi.c: Broadcom NetXtreme II iSCSI driver.
  *
- * Copyright (c) 2006 - 2011 Broadcom Corporation
+ * Copyright (c) 2006 - 2012 Broadcom Corporation
  * Copyright (c) 2007, 2008 Red Hat, Inc.  All rights reserved.
  * Copyright (c) 2007, 2008 Mike Christie
  *
diff --git a/drivers/scsi/bnx2i/bnx2i_sysfs.c b/drivers/scsi/bnx2i/bnx2i_sysfs.c
index 83a77f7..c61cf7a 100644
--- a/drivers/scsi/bnx2i/bnx2i_sysfs.c
+++ b/drivers/scsi/bnx2i/bnx2i_sysfs.c
@@ -1,6 +1,6 @@
 /* bnx2i_sysfs.c: Broadcom NetXtreme II iSCSI driver.
  *
- * Copyright (c) 2004 - 2011 Broadcom Corporation
+ * Copyright (c) 2004 - 2012 Broadcom Corporation
  *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License as published by
-- 
1.7.7.4


-- 
You received this message because you are subscribed to the Google Groups 
open-iscsi group.
To post to this group, send email to open-iscsi@googlegroups.com.
To unsubscribe from this group, send email to 
open-iscsi+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/open-iscsi?hl=en.



A Question about iSCSI boot

2012-04-25 Thread Lee Duncan
Hi:

I am trying to better understand iSCSI boot. Towards that end, I'm trying to 
understand how, during iSCSI boot, the system gets the interface attributes.

In my case, I am using a QLogic 8262 CNA card in my server. When the system 
comes up, I run iscsiadm -m fw, and I get iscsiadm: Could not get list of 
targets from firmware. (err 21).

I'm running on SLES 11 SP2, with a 3.1.0-1.2 kernel. Iscsiadm says the version 
is 2.0-872.suse.

An ls mod | fgrep iscsi return:

iscsi_boot_sysfs   16000  0 
iscsi_tcp  18534  1 
libiscsi_tcp   29211  1 iscsi_tcp
libiscsi   57546  2 iscsi_tcp,libiscsi_tcp
scsi_transport_iscsi50417  4 qla4xxx,iscsi_tcp,libiscsi
iscsi_trgt117284  5 

My adapter is not yet connected to any target -- it doesn't even have a Phy 
installed yet. But I thought I should still see interface attributes, such as 
iface.initiatorname.

Thanks for any help you can supply.
-- 
Lee Duncan

-- 
You received this message because you are subscribed to the Google Groups 
open-iscsi group.
To post to this group, send email to open-iscsi@googlegroups.com.
To unsubscribe from this group, send email to 
open-iscsi+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/open-iscsi?hl=en.



Re: A Question about iSCSI boot

2012-04-25 Thread Mike Christie
On 04/25/2012 08:39 PM, Lee Duncan wrote:
 Hi:
 
 I am trying to better understand iSCSI boot. Towards that end, I'm trying to 
 understand how, during iSCSI boot, the system gets the interface attributes.
 
 In my case, I am using a QLogic 8262 CNA card in my server. When the system 
 comes up, I run iscsiadm -m fw, and I get iscsiadm: Could not get list of 
 targets from firmware. (err 21).
 
 I'm running on SLES 11 SP2, with a 3.1.0-1.2 kernel. Iscsiadm says the 
 version is 2.0-872.suse.
 

I am not sure what is in SLES kernels. The qla drivers you are using
might not support iscsi_boot_sysfs (this displays boot info in a
iscsi_boot dir in /sys/firmware). If it does then I think it would
normally have it listed in lsmod as one of the modules using it.

If you do

modinfo qla4xxx

does your qla4xxx driver have a ql4xdisablesysfsboot modparam? If not
then iscsi boot using iscsiadm is not supported. If you do have that
param then you need it to be 1.

 An ls mod | fgrep iscsi return:
 
 iscsi_boot_sysfs   16000  0 
 iscsi_tcp  18534  1 
 libiscsi_tcp   29211  1 iscsi_tcp
 libiscsi   57546  2 iscsi_tcp,libiscsi_tcp
 scsi_transport_iscsi50417  4 qla4xxx,iscsi_tcp,libiscsi
 iscsi_trgt117284  5 
 
 My adapter is not yet connected to any target -- it doesn't even have a Phy 
 installed yet. But I thought I should still see interface attributes, such as 
 iface.initiatorname.

I think you need to have the boot targets configured.
qla4xxx_get_boot_info looks like it only exports boot info if that is done.

Info like the intiatorname that the card is setup with would be
displayed in a command like iscsiadm -m host P 1. that command is more
generic.

-- 
You received this message because you are subscribed to the Google Groups 
open-iscsi group.
To post to this group, send email to open-iscsi@googlegroups.com.
To unsubscribe from this group, send email to 
open-iscsi+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/open-iscsi?hl=en.



Re: [PATCH 1/2] BNX2I: Added the setting of target can_queue via target_alloc

2012-04-25 Thread Mike Christie
On 04/25/2012 05:03 PM, Eddie Wai wrote:
 This will set the target can_queue limit to the number of preallocated
 session tasks set during creation.
 
 Could not send nopout messages were observed without this when the
 iSCSI connection experiences dropped frames under heavy I/O stress.
 
 Signed-off-by: Eddie Wai eddie@broadcom.com


Both patches look ok to me.

Reviewed-by: Mike Christie micha...@cs.wisc.edu

-- 
You received this message because you are subscribed to the Google Groups 
open-iscsi group.
To post to this group, send email to open-iscsi@googlegroups.com.
To unsubscribe from this group, send email to 
open-iscsi+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/open-iscsi?hl=en.