date:20130729

iscsi initiator disable nops

2013-07-29 Thread Yan Burman

Hi

I am trying to disable nop sending from initiator.
I tried setting node.conn[0].timeo.noop_out_interval and 
node.conn[0].timeo.noop_out_timeout to zero for a specific target using 
iscsiadm,
but I still receive nop on the target after a while.

I also tried setting node.session.timeo.replacement_timeout to 86400, but still 
I receive nop.

Am I missing something? I did what is written in README.

Yan

-- 
You received this message because you are subscribed to the Google Groups 
open-iscsi group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To post to this group, send email to open-iscsi@googlegroups.com.
Visit this group at http://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/groups/opt_out.

Re: iscsi initiator disable nops

2013-07-29 Thread Mike Christie

On 07/29/2013 09:17 AM, Yan Burman wrote:
 Hi
 
 I am trying to disable nop sending from initiator.
 I tried setting node.conn[0].timeo.noop_out_interval and 
 node.conn[0].timeo.noop_out_timeout to zero for a specific target using 
 iscsiadm,
 but I still receive nop on the target after a while.

Did you only set it in the iscsid.conf? If so did you run the discovery
command to pick it up?

Or did you run the iscsiadm -m node -o update -n setting_name -v value
to update specific targets you have already discovered?

Also are you sure your target is not sending nops and the initiator is
only responding to them?


 
 I also tried setting node.session.timeo.replacement_timeout to 86400, but 
 still I receive nop.
 
 Am I missing something? I did what is written in README.
 
 Yan
 

-- 
You received this message because you are subscribed to the Google Groups 
open-iscsi group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To post to this group, send email to open-iscsi@googlegroups.com.
Visit this group at http://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/groups/opt_out.

Re: BUG: iscsid: Can not allocate memory for receive context.

2013-07-29 Thread Mike Christie

Hi Julian,

Thanks for the reply. Could you try the patch I posted? I attached it in
this mail too. It should fix the recv context problem without having to
modify the POOL MAX setting.


On 07/18/2013 11:40 AM, Julian Freed wrote:
 Hi, you need to increase   MAX in the source file
 open-iscsiversion/usr/initiator.h   #define CONTEXT_POOL_MAX 32
 Obviously you need to download sources and compile.
 It solves this problem.
 This problem happens when you have many devices or high loasd of io
 I use it in with ISCSI-SCST  and still have other problems, when using
 many devices, and high io load
 
 
 
 On Saturday, July 6, 2013 6:34:08 PM UTC+3, myk...@gmail.com wrote:
 
 Exactly. I can log in but I do not see any LUNs.
 
 -- 
 You received this message because you are subscribed to the Google
 Groups open-iscsi group.
 To unsubscribe from this group and stop receiving emails from it, send
 an email to open-iscsi+unsubscr...@googlegroups.com.
 To post to this group, send email to open-iscsi@googlegroups.com.
 Visit this group at http://groups.google.com/group/open-iscsi.
 For more options, visit https://groups.google.com/groups/opt_out.
  
  

-- 
You received this message because you are subscribed to the Google Groups 
open-iscsi group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To post to this group, send email to open-iscsi@googlegroups.com.
Visit this group at http://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/groups/opt_out.


diff --git a/usr/event_poll.c b/usr/event_poll.c
index f36fec1..939f1a2 100644
--- a/usr/event_poll.c
+++ b/usr/event_poll.c
@@ -165,8 +165,11 @@ void event_loop(struct iscsi_ipc *ipc, int control_fd, int 
mgmt_ipc_fd)
  exiting, res, errno);
break;
}
-   } else
+   }
+
+   if (res = 0)
actor_poll();
+
reap_proc();
/*
 * flush sysfs cache since kernel objs may
diff --git a/usr/netlink.c b/usr/netlink.c
index c07fe3c..754c3ea 100644
--- a/usr/netlink.c
+++ b/usr/netlink.c
@@ -1545,8 +1545,8 @@ static int ctldev_handle(void)
 
ev_context = ipc_ev_clbk-get_ev_context(conn, ev_size);
if (!ev_context) {
-   /* retry later */
log_error(Can not allocate memory for receive context.);
+   drop_data(nlh);
return -ENOMEM;
}

Re: NULL pointer deref in iscsi_sw_tcp_host_get_param

2013-07-29 Thread Mike Christie

The iscsiadm crash is sort of expected due to where the kernel is
crashing initially.

When I get some time at work, I will make a debug patch for you run with
that should spit out some extra info.

On 07/28/2013 03:33 AM, Alex Lyakas wrote:
 Hi Mike,
 Attached is a trace of another repro, maybe it will give more info.
 The crashing iscsiadm process (2704) was spawned via fork/exec by our
 zadara_vam process (2657).
 
 Thanks,
 Alex.
 
 
 -Original Message- From: Mike Christie
 Sent: 22 July, 2013 7:14 PM
 To: open-iscsi@googlegroups.com
 Cc: Alex Lyakas ; Lev Vainblat ; Yair Hershko ; Liran Strugano
 Subject: Re: NULL pointer deref in iscsi_sw_tcp_host_get_param
 
 For me to replicate the problem I just login to the target using bnx2i.
 Just one instance of iscsiadm -m node --login using the bnx2i driver
 causes the problem.
 
 I have been trying to replicate when adding debug comments in the kernel
 but that made the problem go away. I also tried getting a crash report
 but with that enabled the problem went away.
 
 
 On 07/22/2013 09:24 AM, Alex Lyakas wrote:
 Hi Mike,
 any advice on how to proceed further with this issue?

 Thanks,
 Alex.


 -Original Message- From: Alex Lyakas
 Sent: 02 July, 2013 9:41 PM
 To: Mike Christie ; open-iscsi@googlegroups.com
 Cc: Lev Vainblat ; Yair Hershko
 Subject: Re: NULL pointer deref in iscsi_sw_tcp_host_get_param

 Hi Mike,
 For us it happened only once till now; and from our kernel log, I don't
 think anything special was going on during that time, except that we were
 reading the sysfs entry. Can you pls share how do you replicate the
 problem
 with the Oracle kernel? If this narrows us down a bit on how to
 replicate,
 then, yes, we can apply a debugging patch.

 One thing our application is doing, is to run several iscsiadm commands
 (via
 fork/exec) in parallel. Is this, in general, a safe thing to do, i.e.,
 running multiple iscsiadm processes in parallel? Each iscsiadm process
 operates against a different iSCSI target.

 Thanks,
 Alex.


 -Original Message- From: Mike Christie
 Sent: 02 July, 2013 8:23 PM
 To: open-iscsi@googlegroups.com
 Cc: Alex Lyakas ; Lev Vainblat ; Yair Hershko
 Subject: Re: NULL pointer deref in iscsi_sw_tcp_host_get_param

 Hey,

 Is it easy for you to replicate this problem and if so would it be
 possible to run with a patch that spits out some extra debugging info?

 It is easy for me to replicate with the Oracle linux kernel, but when I
 add debugging it seems to move around or become difficult to hit.


 On 06/27/2013 04:54 AM, Alex Lyakas wrote:
 Hello Mike,
 thank you for responding to my bug report.
 Here is the information you asked for:

 This issue happened within a virtual machine. The network interface,
 that is used for iscsi within the VM is a SR-IOV Virtual Function. The
 VM runs a stock ixgbevf driver from 3.8.13 mainline kernel. On the
 physical machine, the Virtual Function is spawned out of Intel 82599EB
 card. The ixgbe driver for the Intel card on the physical machine is
 3.11.33. The physical machine runs stock Ubuntu Precise kernel
 3.2.0-29-generic #46-Ubuntu, while the VM runs mainline 3.8.13 kernel.
 From within the VM, we connect to targets that live both on the same
 physical machine and on other physical machines.

 I am attaching a .config file for the VM kernel. We did not build the
 kernel ourselves, this is a mainline build done by Ubunti here:
 http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.8.13-raring/
 I am also attaching the full kernel log with the information about the
 crash, it has more stack traces.

 The iscsiadm commands that we use (from another application via
 fork()/exec()) are:
 iscsiadm --mode node --portal portal --targetname name --op new
 iscsiadm --mode node --portal portal --targetname name --login
 iscsiadm --mode node --portal portal --targetname name --logout
 iscsiadm --mode node [--print level]
 iscsiadm --mode session [--print level]
 iscsiadm --mode host [--print level]

 Occasionally we also read sysfs attributes, with a script that collects
 all system's sysfs entries for further analysis.

 We use version 2.0-871 of open-iscsi, we install them via apt-get:
 dpkg -l:
 ii  open-iscsi  2.0.871-0ubuntu9.12.04.1
 High performance, transport independent iSCSI implementation
 ii  open-iscsi-utils2.0.871-0ubuntu9.12.04.1
 iSCSI initiatior administrative utility

 We open one session to each target, but we connect to multiple targets.

 Please let me know if any other info is needed.

 Thanks for your help,
 Alex.


 -Original Message- From: Mike Christie
 Sent: 27 June, 2013 10:13 AM
 To: open-iscsi@googlegroups.com
 Cc: Alex Lyakas
 Subject: Re: NULL pointer deref in iscsi_sw_tcp_host_get_param

 On 06/26/2013 07:50 PM, Mike Christie wrote:
 On 06/26/2013 05:27 PM, Mike Christie wrote:
 We have not seen it before. I am not seeing it here.

 Oh wait, I can hit it when using bnx2i and the OEL kernel

Re: NULL pointer deref in iscsi_sw_tcp_host_get_param

2013-07-29 Thread Alex Lyakas


Thank you, Mike.
We are running kernel 3.8.13, and now we can repro this pretty reliably.

Alex.


-Original Message- 
From: Mike Christie

Sent: 29 July, 2013 9:29 PM
To: Alex Lyakas
Cc: open-iscsi@googlegroups.com ; Lev Vainblat ; Yair Hershko ; Liran 
Strugano

Subject: Re: NULL pointer deref in iscsi_sw_tcp_host_get_param

The iscsiadm crash is sort of expected due to where the kernel is
crashing initially.

When I get some time at work, I will make a debug patch for you run with
that should spit out some extra info.

On 07/28/2013 03:33 AM, Alex Lyakas wrote:

Hi Mike,
Attached is a trace of another repro, maybe it will give more info.
The crashing iscsiadm process (2704) was spawned via fork/exec by our
zadara_vam process (2657).

Thanks,
Alex.


-Original Message- From: Mike Christie
Sent: 22 July, 2013 7:14 PM
To: open-iscsi@googlegroups.com
Cc: Alex Lyakas ; Lev Vainblat ; Yair Hershko ; Liran Strugano
Subject: Re: NULL pointer deref in iscsi_sw_tcp_host_get_param

For me to replicate the problem I just login to the target using bnx2i.
Just one instance of iscsiadm -m node --login using the bnx2i driver
causes the problem.

I have been trying to replicate when adding debug comments in the kernel
but that made the problem go away. I also tried getting a crash report
but with that enabled the problem went away.


On 07/22/2013 09:24 AM, Alex Lyakas wrote:

Hi Mike,
any advice on how to proceed further with this issue?

Thanks,
Alex.


-Original Message- From: Alex Lyakas
Sent: 02 July, 2013 9:41 PM
To: Mike Christie ; open-iscsi@googlegroups.com
Cc: Lev Vainblat ; Yair Hershko
Subject: Re: NULL pointer deref in iscsi_sw_tcp_host_get_param

Hi Mike,
For us it happened only once till now; and from our kernel log, I don't
think anything special was going on during that time, except that we were
reading the sysfs entry. Can you pls share how do you replicate the
problem
with the Oracle kernel? If this narrows us down a bit on how to
replicate,
then, yes, we can apply a debugging patch.

One thing our application is doing, is to run several iscsiadm commands
(via
fork/exec) in parallel. Is this, in general, a safe thing to do, i.e.,
running multiple iscsiadm processes in parallel? Each iscsiadm process
operates against a different iSCSI target.

Thanks,
Alex.


-Original Message- From: Mike Christie
Sent: 02 July, 2013 8:23 PM
To: open-iscsi@googlegroups.com
Cc: Alex Lyakas ; Lev Vainblat ; Yair Hershko
Subject: Re: NULL pointer deref in iscsi_sw_tcp_host_get_param

Hey,

Is it easy for you to replicate this problem and if so would it be
possible to run with a patch that spits out some extra debugging info?

It is easy for me to replicate with the Oracle linux kernel, but when I
add debugging it seems to move around or become difficult to hit.


On 06/27/2013 04:54 AM, Alex Lyakas wrote:

Hello Mike,
thank you for responding to my bug report.
Here is the information you asked for:

This issue happened within a virtual machine. The network interface,
that is used for iscsi within the VM is a SR-IOV Virtual Function. The
VM runs a stock ixgbevf driver from 3.8.13 mainline kernel. On the
physical machine, the Virtual Function is spawned out of Intel 82599EB
card. The ixgbe driver for the Intel card on the physical machine is
3.11.33. The physical machine runs stock Ubuntu Precise kernel
3.2.0-29-generic #46-Ubuntu, while the VM runs mainline 3.8.13 kernel.
From within the VM, we connect to targets that live both on the same
physical machine and on other physical machines.

I am attaching a .config file for the VM kernel. We did not build the
kernel ourselves, this is a mainline build done by Ubunti here:
http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.8.13-raring/
I am also attaching the full kernel log with the information about the
crash, it has more stack traces.

The iscsiadm commands that we use (from another application via
fork()/exec()) are:
iscsiadm --mode node --portal portal --targetname name --op new
iscsiadm --mode node --portal portal --targetname name --login
iscsiadm --mode node --portal portal --targetname name --logout
iscsiadm --mode node [--print level]
iscsiadm --mode session [--print level]
iscsiadm --mode host [--print level]

Occasionally we also read sysfs attributes, with a script that collects
all system's sysfs entries for further analysis.

We use version 2.0-871 of open-iscsi, we install them via apt-get:
dpkg -l:
ii  open-iscsi  2.0.871-0ubuntu9.12.04.1
High performance, transport independent iSCSI implementation
ii  open-iscsi-utils2.0.871-0ubuntu9.12.04.1
iSCSI initiatior administrative utility

We open one session to each target, but we connect to multiple targets.

Please let me know if any other info is needed.

Thanks for your help,
Alex.


-Original Message- From: Mike Christie
Sent: 27 June, 2013 10:13 AM
To: open-iscsi@googlegroups.com
Cc: Alex Lyakas
Subject: Re: NULL pointer deref

Re: [PATCH] Make rescan run in parallel

2013-07-29 Thread Mike Christie

On 07/11/2013 07:40 AM, Saggi Mizrahi wrote:
 
 
 - Original Message -
 From: Mike Christie micha...@cs.wisc.edu
 To: open-iscsi@googlegroups.com
 Cc: Saggi Mizrahi smizr...@redhat.com
 Sent: Tuesday, July 9, 2013 6:55:17 PM
 Subject: Re: [PATCH] Make rescan run in parallel

 On 07/02/2013 08:30 AM, Saggi Mizrahi wrote:
 +   if (wait(chldrc)  0) {
 +   // ECHILD means no more children which is
 +   // expected to happen sooner or later.
 +   if (errno != ECHILD) {
 +   rc = errno;
 +   }
 +   break;
 +   }
 +
 +   if ((chldrc  0)  (rc == 0)) {
 +   // The non-parallel code path returns the first
 +   // error so this keeps the same semantics.
 +   rc = chldrc;
 +   } else if (chldrc == 0) {
 +   (*nr_found)++;
 +   }
 +   }
 }

 Thanks for the patch. It looks ok. When I merge I am going to fix up the
 comments above for you. We use C /* */ style comments. You used them in
 part of the patch but mixed it with the // style above.

 Just one questions. Does your app run the iscsiadm rescan command or is
 this a result of users running it? It does not matter. I am just wondering.
 Our app runs it. I know we could just go poke sysfs ourselves but we figure
 that you guys will do a way better job with it.
 
 No problem about the comment style. C99 is for weaklings anyway :).
 
 What do I need to do to get this in to RHEL6.X?

I merged it in the upstream tree here. I do not know how to get it into
RHEL 6. I do not work at red hat anymore. You should talk to Chris Leech
or Andy Grover at red hat.

I attached the patch I ended up merging. It has the comment fix up and I
ported some of the other code that was missed in the original patch. I
think we could also enable parallel for the sync_session path which
would speed up boot, but I do not have time to test. Will leave that for
the distros/vendors supporting boot until I get time.

Thanks.

-- 
You received this message because you are subscribed to the Google Groups 
open-iscsi group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To post to this group, send email to open-iscsi@googlegroups.com.
Visit this group at http://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/groups/opt_out.


diff --git a/usr/host.c b/usr/host.c
index b03e50f..1fcb350 100644
--- a/usr/host.c
+++ b/usr/host.c
@@ -242,7 +242,7 @@ static int host_info_print_tree(void *data, struct 
host_info *hinfo)
link_info.data = hinfo-host_no;
 
err = iscsi_sysfs_for_each_session(link_info, num_found,
-  session_info_create_list);
+  session_info_create_list, 0);
if (err || !num_found)
return 0;
 
diff --git a/usr/initiator.c b/usr/initiator.c
index 86df222..a3b24b7 100644
--- a/usr/initiator.c
+++ b/usr/initiator.c
@@ -1855,7 +1855,8 @@ static int session_is_running(node_rec_t *rec)
if (session_find_by_rec(rec))
return 1;
 
-   if (iscsi_sysfs_for_each_session(rec, nr_found, iscsi_match_session))
+   if (iscsi_sysfs_for_each_session(rec, nr_found, iscsi_match_session,
+0))
return 1;
 
return 0;
diff --git a/usr/iscsi_sysfs.c b/usr/iscsi_sysfs.c
index 64a4ce7..aed10a3 100644
--- a/usr/iscsi_sysfs.c
+++ b/usr/iscsi_sysfs.c
@@ -24,6 +24,7 @@
 #include dirent.h
 #include sys/types.h
 #include sys/stat.h
+#include sys/wait.h
 
 #include log.h
 #include initiator.h
@@ -1167,11 +1168,13 @@ int iscsi_sysfs_get_sessioninfo_by_id(struct 
session_info *info, char *session)
 }
 
 int iscsi_sysfs_for_each_session(void *data, int *nr_found,
-iscsi_sysfs_session_op_fn *fn)
+iscsi_sysfs_session_op_fn *fn,
+int in_parallel)
 {
struct dirent **namelist;
-   int rc = 0, n, i;
+   int rc = 0, n, i, chldrc = 0;
struct session_info *info;
+   pid_t pid = 0;
 
info = calloc(1, sizeof(*info));
if (!info)
@@ -1193,14 +1196,52 @@ int iscsi_sysfs_for_each_session(void *data, int 
*nr_found,
continue;
}
 
-   rc = fn(data, info);
-   if (rc  0)
-   break;
-   else if (rc == 0)
-   (*nr_found)++;
-   else
-   /* if less than zero it means it was not a match */
-   rc = 0;
+   if (in_parallel) {
+   pid = fork();
+

iscsi initiator disable nops

Re: iscsi initiator disable nops

Re: BUG: iscsid: Can not allocate memory for receive context.

Re: NULL pointer deref in iscsi_sw_tcp_host_get_param

Re: NULL pointer deref in iscsi_sw_tcp_host_get_param

Re: [PATCH] Make rescan run in parallel

6 matches

Site Navigation

Mail list logo

Footer information