Re: Problem diagnosing iscsi failure on the initiator

2010-06-16 Thread Michal Suchanek
On 16 June 2010 05:31, Mike Christie micha...@cs.wisc.edu wrote:
 On 06/14/2010 08:52 AM, Michal Suchanek wrote:

 On 13 June 2010 21:01, Mike Christiemicha...@cs.wisc.edu  wrote:

 On 06/12/2010 06:31 AM, Michal Suchanek wrote:

 Hello

 I tried to get an iscsi setup working so I installed iscsitarget and
 open-iscsi and tried to export a file as an iSCSI lun.

 After doing so I could log in with iscsiadm but I would not get any
 disks on the initiator.

 Later I discovered that I had a typo in the ietd.conf file and the lun
 was simply not exported giving a target with no luns available for the
 initiator.

 While it is true that the error is logged in kernel logs on the target
 machine I could not find any way to list the available luns on the

 iscsiadm -m session -P 3

 Thanks, this command does print the luns if there are any.

 However, it is not obvious from the documentation that it should print
 these nor is it obvious from the output that there some part missing
 when no luns are available.

 In the README I will add more info on how -P X works for session mode.



 It also does not work when I just add -P 3 to the discovery and node
 commands which I use to log into the target and there is no obvious
 reason why it should not.


 Discovery mode just finds targets and portals. It has nothing to do with LUN
 discovery normally. And the node mode commands that print out the node db
 info also just prints the target and portal info, because it is only
 concerned with the targets.

 If for discovery and node mode, you are logging into the target (using the
 --login command) then I can print out the LUNs found if that is what you are
 asking for. But normally with the discovery and node mode commands that use
 the -P operator we are just working on the targets and portals and have not
 logged into the target so we do not know if there are LUNs.


The thing is that it is not documented what the -P option actually does.

Apparently it slightly changes the output format of discover and node
modes when nonzero but prints gobs of information in session mode when
nonzero and even more when it is 2 or3.

So I would really appreciate a short note in the man page what value
of P selects what information in what mode like:

When non-zero the output in discovery, node or session mode is printed
in tree-like format. In session mode 1 prints interfaces 2 also prints
parameters and 3 also prints devices.

Thanks

Michal

-- 
You received this message because you are subscribed to the Google Groups 
open-iscsi group.
To post to this group, send email to open-is...@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 3/3] cxgb4i_v4.3 : main driver files

2010-06-16 Thread Mike Christie

On 06/07/2010 11:59 PM, Rakesh Ranjan wrote:

From: Rakesh Ranjanrak...@chelsio.com


Signed-off-by: Rakesh Ranjanrak...@chelsio.com
---
  drivers/scsi/cxgbi/cxgb4i.h |  175 +
  drivers/scsi/cxgbi/cxgb4i_ddp.c |  653 
  drivers/scsi/cxgbi/cxgb4i_init.c|  317 
  drivers/scsi/cxgbi/cxgb4i_offload.c | 1409 +++
  4 files changed, 2554 insertions(+), 0 deletions(-)
  create mode 100644 drivers/scsi/cxgbi/cxgb4i.h
  create mode 100644 drivers/scsi/cxgbi/cxgb4i_ddp.c
  create mode 100644 drivers/scsi/cxgbi/cxgb4i_init.c
  create mode 100644 drivers/scsi/cxgbi/cxgb4i_offload.c



Do you think you can look through this patch and identify the places 
where you basically just copied a cxgb3i function or copied it but 
renamed some stuff and then move these type of things to the lib patch?


A lot of the scatter list stuff for example looks the same in each driver.

ddp_find_unused_entries - cxgb4i_ddp_find_unused_entries
ddp_unmark_entries - cxgb4i_ddp_unmark_entries
cxgb3i_ddp_find_page_index - cxgb4i_ddp_find_page_index
cxgb3i_ddp_adjust_page_table - cxgb4i_ddp_adjust_page_table
. (lots of the ddp code looks duplicated).

The *_offload.c code looks the same.

--
You received this message because you are subscribed to the Google Groups 
open-iscsi group.
To post to this group, send email to open-is...@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] cxgb3i: zero out reserved or un-used cpl message fields

2010-06-16 Thread kxie
[PATCH] cxgb3i: zero out reserved or un-used fields.

From: Karen Xie k...@chelsio.com

Zero out the reserved or un-used CPL message fields to prevent any garbage
value.

Signed-off-by: Karen Xie k...@chelsio.com
---

 drivers/scsi/cxgb3i/cxgb3i_ddp.c |2 ++
 drivers/scsi/cxgb3i/cxgb3i_offload.c |5 +
 2 files changed, 7 insertions(+), 0 deletions(-)


diff --git a/drivers/scsi/cxgb3i/cxgb3i_ddp.c b/drivers/scsi/cxgb3i/cxgb3i_ddp.c
index b58d913..be0e230 100644
--- a/drivers/scsi/cxgb3i/cxgb3i_ddp.c
+++ b/drivers/scsi/cxgb3i/cxgb3i_ddp.c
@@ -499,6 +499,7 @@ static int setup_conn_pgidx(struct t3cdev *tdev, unsigned 
int tid, int pg_idx,
/* set up ulp submode and page size */
req = (struct cpl_set_tcb_field *)skb_put(skb, sizeof(*req));
req-wr.wr_hi = htonl(V_WR_OP(FW_WROPCODE_FORWARD));
+   req-wr.wr_lo = 0;
OPCODE_TID(req) = htonl(MK_OPCODE_TID(CPL_SET_TCB_FIELD, tid));
req-reply = V_NO_REPLY(reply ? 0 : 1);
req-cpu_idx = 0;
@@ -564,6 +565,7 @@ int cxgb3i_setup_conn_digest(struct t3cdev *tdev, unsigned 
int tid,
/* set up ulp submode and page size */
req = (struct cpl_set_tcb_field *)skb_put(skb, sizeof(*req));
req-wr.wr_hi = htonl(V_WR_OP(FW_WROPCODE_FORWARD));
+   req-wr.wr_lo = 0;
OPCODE_TID(req) = htonl(MK_OPCODE_TID(CPL_SET_TCB_FIELD, tid));
req-reply = V_NO_REPLY(reply ? 0 : 1);
req-cpu_idx = 0;
diff --git a/drivers/scsi/cxgb3i/cxgb3i_offload.c 
b/drivers/scsi/cxgb3i/cxgb3i_offload.c
index a175be9..246a6c2 100644
--- a/drivers/scsi/cxgb3i/cxgb3i_offload.c
+++ b/drivers/scsi/cxgb3i/cxgb3i_offload.c
@@ -264,6 +264,7 @@ static void make_act_open_req(struct s3_conn *c3cn, struct 
sk_buff *skb,
skb-priority = CPL_PRIORITY_SETUP;
req = (struct cpl_act_open_req *)__skb_put(skb, sizeof(*req));
req-wr.wr_hi = htonl(V_WR_OP(FW_WROPCODE_FORWARD));
+   req-wr.wr_lo = 0;
OPCODE_TID(req) = htonl(MK_OPCODE_TID(CPL_ACT_OPEN_REQ, atid));
req-local_port = c3cn-saddr.sin_port;
req-peer_port = c3cn-daddr.sin_port;
@@ -273,6 +274,7 @@ static void make_act_open_req(struct s3_conn *c3cn, struct 
sk_buff *skb,
   V_TX_CHANNEL(e-smt_idx));
req-opt0l = htonl(calc_opt0l(c3cn));
req-params = 0;
+   req-opt2 = 0;
 }
 
 static void fail_act_open(struct s3_conn *c3cn, int errno)
@@ -379,6 +381,7 @@ static void send_abort_req(struct s3_conn *c3cn)
 
c3cn-cpl_abort_req = NULL;
req = (struct cpl_abort_req *)skb-head;
+   memset(req, 0, sizeof(*req));
 
skb-priority = CPL_PRIORITY_DATA;
set_arp_failure_handler(skb, abort_arp_failure);
@@ -406,6 +409,7 @@ static void send_abort_rpl(struct s3_conn *c3cn, int 
rst_status)
c3cn-cpl_abort_rpl = NULL;
 
skb-priority = CPL_PRIORITY_DATA;
+   memset(rpl, 0, sizeof(*rpl));
rpl-wr.wr_hi = htonl(V_WR_OP(FW_WROPCODE_OFLD_HOST_ABORT_CON_RPL));
rpl-wr.wr_lo = htonl(V_WR_TID(c3cn-tid));
OPCODE_TID(rpl) = htonl(MK_OPCODE_TID(CPL_ABORT_RPL, c3cn-tid));
@@ -430,6 +434,7 @@ static u32 send_rx_credits(struct s3_conn *c3cn, u32 
credits, u32 dack)
 
req = (struct cpl_rx_data_ack *)__skb_put(skb, sizeof(*req));
req-wr.wr_hi = htonl(V_WR_OP(FW_WROPCODE_FORWARD));
+   req-wr.wr_lo = 0;
OPCODE_TID(req) = htonl(MK_OPCODE_TID(CPL_RX_DATA_ACK, c3cn-tid));
req-credit_dack = htonl(dack | V_RX_CREDITS(credits));
skb-priority = CPL_PRIORITY_ACK;

-- 
You received this message because you are subscribed to the Google Groups 
open-iscsi group.
To post to this group, send email to open-is...@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.