Re: [PATCH 1/1] cxgb3i: Fix a login over vlan issue

2009-12-07 Thread Mike Christie 
Rakesh Ranjan wrote:
 Fix a login over vlan issue, when parent interface is vlan and we are using 
 cxgb3i sepecific
 private ip address in '/etc/iscsi/ifaces/' iface file.
 
 Acked-by: Karen Xie k...@chelsio.com
 Signed-off-by: Rakesh Ranjan rak...@chelsio.com
 ---
  drivers/scsi/cxgb3i/cxgb3i_offload.c |   34 
 +-
  1 files changed, 33 insertions(+), 1 deletions(-)
 
 diff --git a/drivers/scsi/cxgb3i/cxgb3i_offload.c 
 b/drivers/scsi/cxgb3i/cxgb3i_offload.c
 index c1d5be4..66d52e4 100644
 --- a/drivers/scsi/cxgb3i/cxgb3i_offload.c
 +++ b/drivers/scsi/cxgb3i/cxgb3i_offload.c
 @@ -1440,6 +1440,10 @@ void cxgb3i_c3cn_release(struct s3_conn *c3cn)
  static int is_cxgb3_dev(struct net_device *dev)
  {
   struct cxgb3i_sdev_data *cdata;
 + struct net_device *ndev = dev;
 +
 + if (dev-priv_flags  IFF_802_1Q_VLAN)
 + ndev = vlan_dev_real_dev(dev);
  
   write_lock(cdata_rwlock);
   list_for_each_entry(cdata, cdata_list, list) {
 @@ -1447,7 +1451,7 @@ static int is_cxgb3_dev(struct net_device *dev)
   int i;
  
   for (i = 0; i  ports-nports; i++)
 - if (dev == ports-lldevs[i]) {
 + if (ndev == ports-lldevs[i]) {
   write_unlock(cdata_rwlock);
   return 1;
   }
 @@ -1566,6 +1570,26 @@ out_err:
   return -1;
  }
  
 +/**
 + * cxgb3i_find_dev - find the interface associated with the given address
 + * @ipaddr: ip address
 + */
 +static struct net_device *
 +cxgb3i_find_dev(__be32 ipaddr)
 +{
 + struct flowi fl;
 + int err;
 + struct rtable *rt;
 +
 + memset(fl, 0, sizeof(fl));
 + fl.nl_u.ip4_u.daddr = ipaddr;
 +
 + err = ip_route_output_key(init_net, rt, fl);
 + if (!err)
 + return (rt-u.dst)-dev;
 +
 + return NULL;
 +}
  
  /**
   * cxgb3i_c3cn_connect - initiates an iscsi tcp connection to a given address
 @@ -1581,6 +1605,7 @@ int cxgb3i_c3cn_connect(struct net_device *dev, struct 
 s3_conn *c3cn,
   struct cxgb3i_sdev_data *cdata;
   struct t3cdev *cdev;
   __be32 sipv4;
 + struct net_device *dstdev;
   int err;
  
   c3cn_conn_debug(c3cn 0x%p, dev 0x%p.\n, c3cn, dev);
 @@ -1591,6 +1616,13 @@ int cxgb3i_c3cn_connect(struct net_device *dev, struct 
 s3_conn *c3cn,
   c3cn-daddr.sin_port = usin-sin_port;
   c3cn-daddr.sin_addr.s_addr = usin-sin_addr.s_addr;
  
 + dstdev = cxgb3i_find_dev(usin-sin_addr.s_addr);
 + if (!dstdev || !is_cxgb3_dev(dstdev))
 + return -ENETUNREACH;
 +
 + if (dstdev-priv_flags  IFF_802_1Q_VLAN)
 + dev = dstdev;
 +
   rt = find_route(dev, c3cn-saddr.sin_addr.s_addr,
   c3cn-daddr.sin_addr.s_addr,
   c3cn-saddr.sin_port,


Looks sane. I am not a expert on the networks apis being used though.

--

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.

RHEL 4 Update 7 + iSCSI + multipath

2009-12-07 Thread bilimorian 
Hello,

This is my first post on this group so please excuse my ignorance.  I
am using the combination of RHEL, iSCSI and multipath to NetApp SAN.
I attach to 9 LUNs.  On one path I can connect to all LUNs but on the
second path I am unable to see 3 of the 9 LUNs.  I have tried
'googleing' but havent come across a good solution.  So far the only
way I have been able to resolve the issue is by rebooting but after
few days it comes back again.  Any help will be very appreciated.

Thanks in advance...

Here is my system info:

OS: Red Hat Enterprise Linux AS release 4 (Nahant Update 7)
kernel: Linux 2.6.9-78.0.13.ELsmp
iscsi-initiator-utils-4.0.3.0-7
device-mapper-multipath-0.4.5-31.el4

=

# sanlun lun show all
   filer:   lun-pathnamedevice filename  adapter
protocol  lun size lun state
xxx:  /vol/lun115  /dev/sdm host2iSCSI150g
(161061273600)   GOOD
xxx:  /vol/lun118  /dev/sds host2iSCSI  500.1g
(536952700928)   GOOD
xxx:  /vol/lun113  /dev/sdh host5iSCSI100g
(107374182400)   GOOD
xxx:  /vol/lun175  /dev/sdn host5iSCSI175g
(187904819200)   GOOD
xxx:  /vol/lun117  /dev/sdp host5iSCSI150g
(161061273600)   GOOD
xxx:  /vol/lun110  /dev/sdb host5iSCSI 60g
(64424509440)GOOD
xxx:  /vol/lun118  /dev/sdr host5iSCSI  500.1g
(536952700928)   GOOD
xxx:  /vol/lun110  /dev/sdc host2iSCSI 60g
(64424509440)GOOD
xxx:  /vol/lun111  /dev/sdd host5iSCSI200g
(214748364800)   GOOD
xxx:  /vol/lun114  /dev/sdk host2iSCSI  400.0g
(429523992576)   GOOD
xxx:  /vol/lun117  /dev/sdq host2iSCSI150g
(161061273600)   GOOD
xxx:  /vol/lun112  /dev/sdf host5iSCSI100g
(107374182400)   GOOD
xxx:  /vol/lun115  /dev/sdl host5iSCSI150g
(161061273600)   GOOD
xxx:  /vol/lun114  /dev/sdj host5iSCSI  400.0g
(429523992576)   GOOD
xxx:  /vol/lun111  /dev/sde host2iSCSI200g
(214748364800)   GOOD

==

# multipath -ll
mpath2 (360a98000486e6c764e6f4d724c466e37)
[size=100 GB][features=1 queue_if_no_path][hwhandler=0]
\_ round-robin 0 [prio=2][active]
 \_ 2:0:0:112 sdg 8:96  [failed][faulty]
 \_ 5:0:0:112 sdf 8:80  [active][ready]

mpath1 (360a98000486e6c764e6f4d724d4c6844)
[size=60 GB][features=1 queue_if_no_path][hwhandler=0]
\_ round-robin 0 [prio=4][active]
 \_ 2:0:0:110 sdc 8:32  [active][ready]
 \_ 5:0:0:110 sdb 8:16  [active][ready]

mpath0 (360a98000486e6c764e6f4d724d614233)
[size=175 GB][features=1 queue_if_no_path][hwhandler=0]
\_ round-robin 0 [prio=2][active]
 \_ 5:0:0:116 sdn 8:208 [active][ready]
 \_ 2:0:0:116 sdo 8:224 [failed][faulty]

mpath8 (360a98000486e6c764e6f4d724c715a61)
[size=500 GB][features=1 queue_if_no_path][hwhandler=0]
\_ round-robin 0 [prio=4][active]
 \_ 2:0:0:118 sds 65:32 [active][ready]
 \_ 5:0:0:118 sdr 65:16 [active][ready]

mpath7 (360a98000486e6c764e6f4d724d56674a)
[size=150 GB][features=1 queue_if_no_path][hwhandler=0]
\_ round-robin 0 [prio=4][active]
 \_ 2:0:0:115 sdm 8:192 [active][ready]
 \_ 5:0:0:115 sdl 8:176 [active][ready]

mpath6 (360a98000486e6c764e6f4d724b623931)
[size=200 GB][features=1 queue_if_no_path][hwhandler=0]
\_ round-robin 0 [prio=4][active]
 \_ 2:0:0:111 sde 8:64  [active][ready]
 \_ 5:0:0:111 sdd 8:48  [active][ready]

mpath5 (360a98000486e6c764e6f4d724b756372)
[size=100 GB][features=1 queue_if_no_path][hwhandler=0]
\_ round-robin 0 [prio=2][active]
 \_ 5:0:0:113 sdh 8:112 [active][ready]
 \_ 2:0:0:113 sdi 8:128 [failed][faulty]

mpath4 (360a98000486e6c764e6f4d724d69326e)
[size=150 GB][features=1 queue_if_no_path][hwhandler=0]
\_ round-robin 0 [prio=4][active]
 \_ 5:0:0:117 sdp 8:240 [active][ready]
 \_ 2:0:0:117 sdq 65:0  [active][ready]

mpath3 (360a98000486e6c764e6f4d724c576347)
[size=400 GB][features=1 queue_if_no_path][hwhandler=0]
\_ round-robin 0 [prio=4][active]
 \_ 5:0:0:114 sdj 8:144 [active][ready]
 \_ 2:0:0:114 sdk 8:160 [active][ready]



#iscsi-ls -l

***
SFNet iSCSI Driver Version ...4:0.1.11-7(14-Apr-2008)
***
TARGET NAME : xxx
TARGET ALIAS: show
HOST ID : 2
BUS ID  : 0
TARGET ID   : 0
TARGET ADDRESS  : xxx
SESSION STATUS  : ESTABLISHED AT Wed Nov 25 11:25:43 EST 2009
SESSION ID  : ISID 00023d01 TSIH 88

DEVICE DETAILS:
---
LUN ID : 110
  Vendor: NETAPP   Model: LUN  Rev: 0.2
  Type:   Direct-AccessANSI SCSI revision: 04
  page83 type3: 60a98000486e6c764e6f4d724d4c6844
  page80:

SLES10 SP3 x86_64 - connection2:0: detected conn error (1011)

2009-12-07 Thread avora 
With SLES10 SP3 x86_64,
as soon as I start the second iscsi session2, I am very frequently
getting the connection errors/
I do not see this with SLES10 SP2 x86_64 on the same setup.

Dec  7 18:42:05 cdc-r710s1 kernel:  connection2:0: detected conn error
(1011)
Dec  7 18:42:06 cdc-r710s1 iscsid: connection2:0 is operational after
recovery (1 attempts)
Dec  7 18:42:06 cdc-r710s1 iscsid: Kernel reported iSCSI connection
2:0 error (1011) state (3)
Dec  7 18:42:08 cdc-r710s1 kernel:  connection2:0: detected conn error
(1011)

I have tried changing noop_out_interval and noop_out_timeout to
120/120 and 0/0 but did not help.
The iscsiadm settings are same on both SP2 and SP3.
Is there anything else that can be tried ?

# iscsiadm --mode node --targetname target
...

# rpm -qa | grep iscsi
iscsitarget-0.4.17-3.4.25
open-iscsi-2.0.868-0.6.11
yast2-iscsi-client-2.14.47-0.4.9
yast2-iscsi-server-2.13.26-0.3

--

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: source code for connection establishment

2009-12-07 Thread Mike Christie 
Jack Z wrote:
 Hi all,
 
 I'm a CS student and I'm trying to understand and locate the source
 code for iSCSI connection establishment. But I encountered the
 following problem. Could anyone maybe show me where I should go? Any
 help would be highly appreciated!!
 
 1. I searched in the entire open-iscsi project and added a fprintf
 (stderr, Msg No.%d, msg_num); after each connect() all. But after I
 made the project and made install, I still couldn't see any of the
 messages from fprintf when I tried to iscsiadm -m discovery -t st -p
 portal or iscsiadm -m node -T TargetName -p portal --
 login...
 
 2. Since the first method failed, I tried to trace the source code
 nearby the login messages Logging in to [iface: and Login to
 [iface:  successful and I ended up with the function
 
 static int __login_portals(void *data, int *nr_found,
 struct list_head *rec_list,
 int (* login_fn)(void *, struct list_head *,
 struct node_rec *))
 
 Is this the function that establishes the connection for login?


No. It just sends a request to iscsid to connect to the target.

Look at iscsi_io_tcp_connect in io.c. It is non blocking so also see 
iscsi_io_tcp_poll. When that returns that we have connected then we 
start the iscsi login process.

Note that iscsi_io_tcp_connect and iscsi_io_tcp_poll are called through 
the  session-t-template-ep_connect or ep_poll calls.


--

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: a deadlock (or corruption) bug in iscsid's logging

2009-12-07 Thread Mike Christie 
guy keren wrote:
 Ulrich Windl wrote:
 On 3 Nov 2009 at 2:54, guy keren wrote:

 Hi,

 the logging code in open-iscsi uses a logarea structure in shared 
 memory protected by a SysV semaphore (using semop system calls) - and 
 also places the sembuf array structure used in the semop calls in this 
 same shared-memory area (i.e. inside the logarea struct that is 
 allocated in shared memory at function logarea_init).

 as a result, both the iscsid logging process and the iscsid control 
 process attempt to use this structure in a non-synchronized manner, 
 The fact that the logging and the control process use the shared memory in a 
 unsynchronized way seems unrelated to the fact that both structures are 
 located in 
 the same memory area, or I didn't understand your statement. For performance 
 reasons it seems wise to locate the controlling semaphores close to the area 
 being 
 controlled.

 which is racy and may result either a deadlock or data corruption (we 
 saw these deadlocks several times).

 the relevant code of the logging process is in usr/log.c, function 
 log_flush(). the relevant code of the control process is in the same 
 file, function dolog().

 the deadlock senario:

 1. the logging process has the semaphore held. the control process is
doing some work.
 2. the logging process is about to release the semaphore. it sets 
 the sem_op parameter in the sembuf structure to '1'.
 3. the control process now wants to add a logging record. it sets 
 the sem_op parameter in the sembuf structure to '-1'.
 Ah, I understand: not the semaphore structure is in shared memory, but the 
 parameter structure for calling the semop(). OK, that's bad. Probably those 
 structures should be local (on the stack). I was confused with POSIX 
 semaphores 
 where shared memory is required.

 4. the control process invokes semop and gets blocked (because the 
 semaphore is held by the logging process).
 5. the logging process invokes semop and also gets blocked for the 
 same reason.

 we're in deadlock.
 Good spotting!

 Ulrich

 to get a data corruption, we'll need a slightly different scheduling - 
 i.e. that the process that wants to take the lock will update the sembuf 
 struct first - and then the process releasing the lock would modify 
 sem_op to '1' - and we'll have both processes increasing the semaphore's 
 value instead of one increasing and one decreasing it - and thus the 
 semaphore's value will later allow both processes to grab the semaphore 
 at the same time.

 solution:

 to solve this, i have created a local variable on the stack of both 
 processes, that is used with the semop calls. another possible solution 
 is to move the sembuf structure to a global variable that is NOT placed 
 in shared memory.

 before i send a patch - is there a preference either way? or some other way?

 thanks,
 --guy

 
 (finally) attached is the patch:
 
 each process must have its own semarg structure - or they step on each 
 others' toes - which could cause either deadlocks or smearing of the 
 shared memory protected by the semaphore.
 

Sorry for the late reply. Looks ok. Merged in 
3300b26934848cb674390d86f09a91edf2c71980.

--

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] Fix wrong logs in log.c

2009-12-07 Thread Mike Christie 
guy keren wrote:
 Up and Down were wrongly used in semaphore operations.
 
 Signed-off-by: guy keren c...@actcom.co.il
 
 note: this patch must be applied on top of the previous patch (that 
 fixes the semop race bug).
 

Looks ok. Thanks for all the patches!

--

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] do NOT perform illegal operations in a SIGSEGV handler

2009-12-07 Thread Mike Christie 
guy keren wrote:
 Ulrich Windl wrote:
 On 24 Nov 2009 at 13:20, guy keren wrote:

 [...]
 by the way - if the system is set to generate core files for daemons, 
 then at least in theory it is possible to write some gdb macros that 
 will extract the non-flushed part of the logs from the core file - 
 assuming the shared-memory segment is still available. i need to check 
 if it's possible to make gdb re-attach to that segment while handling 
 the core file (generally this is not possible since you cannot run 
 function without attaching to a running process. however - there's a 
 project that allows re-creating a process around a core file - and 
 perhaps using that project this will become possible).

 From my eperience, it's much easier for users to find the last lines in a 
 log 
 file, rather than find a core dump file. Not to talk about corelating the 
 core 
 file with a program plus doing something useful with it.

 I a program I wrote years ago I did this: The log handler did flush the log 
 whenever an error or more important had been output; it did not flush the 
 log for 
 debug messages or similar (I had fatal errors, errors, warnings, 
 informational 
 messages, and debug messages). Assuming that the program will crash only 
 after 
 some problem had been detected, this might help.

 Regards,
 Ulrich
 
 and then you risk that the program will not be able to terminate in 
 specific corruption cases. so the question is - what is deemed more 
 important - that the program will terminate in case of a SIGSEGV, or 
 that it'll emit the remains of the logs for the price of a (small?) 
 chance of getting stuck during this attempt.
 
 i don't really know what is the right answer.
 

Does anyone else have an opinion on this issue?

--

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] Maintain a list of nop-out PDUs that almost timed out

2009-12-07 Thread Mike Christie 
Erez Zilber wrote:
 
 Maintain a list of nop-out PDUs that almost timed out.
 With this information, you can understand and debug the
 whole system: you can check your target and see what caused
 it to be so slow on that specific time, you can see if your
 network was very busy during that time etc.
 

Thanks Erez. I was moving last week, and am looking it over now.

--

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] Maintain a list of nop-out PDUs that almost timed out

2009-12-07 Thread Mike Christie 
Ulrich Windl wrote:
 On 1 Dec 2009 at 14:57, Erez Zilber wrote:
 
 Maintain a list of nop-out PDUs that almost timed out.
 With this information, you can understand and debug the
 whole system: you can check your target and see what caused
 it to be so slow on that specific time, you can see if your
 network was very busy during that time etc.

 
 Hi!
 
 Having studied TCP overload protection and flow control mechanisms recently, 
 I 
 wondered if a look at the TCP window sizes could be a indicator equivalent to 
 timed-out nops. My idea is: Why implement something, if it's possibly already 
 there for free.
 

The problem with the nop timeout code is that it detects:

1 If the target is not reachable because something wrong is in the network.
2 If the target is dead.
3 If the network layer is not sending/receiving data fast enough (within 
the nop timeout).

#3 is a problem because we do not know if it is not sending/receiving 
data quickly because of #1 or #2 or just because we are trying to 
process more data than the network can handle within the nop timeout value.

Do you thing we should we be trying to send iscsi pdus with data 
segments that are smaller than the window size or some other value or 
something like that?  Or is there a way to get the time it is taking for 
tcp packets, and could we use that to automatically determine the nop 
value? Should we just send a network ping and forget doing the iscsi 
nop/ping?

--

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: Suggestion for new logging mechanism in open-iscsi

2009-12-07 Thread Mike Christie 
Erez Zilber wrote:
 I'd like to make some changes in the logging in open-iscsi. The
 current status is as follows:
 
 kernel modules:
 
 * We use iscsi_cls_session_printk  iscsi_cls_conn_printk in
 scsi_transport_iscsi.c. They are sometimes wrapped by macros (e.g.
 ISCSI_DBG_TRANS_SESSION). These macros use KERN_INFO and are
 controlled by module parameters.
 
 * We use iscsi_session_printk  iscsi_conn_printk for the rest of the
 kernel code.These macros wrap iscsi_cls_session_printk 
 iscsi_cls_conn_printk accordingly. They are sometimes wrapped by
 macros (e.g. ISCSI_SW_TCP_DBG). These macros use KERN_INFO and are
 controlled by module parameters.
 
 * We sometimes use printk calls.
 
 userspace:
 
 We use log_warning, log_error  log_debug. They depend on the logging
 level that we use (0-8). if (log_level  level), the log is sent to
 syslog with the appropriate log level (LOG_WARNING/LOG_ERR/LOG_DEBUG).
 
 My motivation: with the current logging mechanism, if an error occurs,
 I'm unable to tell exactly what happened. The default logging level is
 too low. Increasing it affects performance. Another problem is that
 open-iscsi has too many logging mechanisms.
 
 I suggest that:
 1. For kernel modules, we will have 'events' (or any better name that
 you suggest) like 'session', 'conn', 'eh', 'cmd' etc. For each event,
 we will have a logging level. For example, the user may want to set
 the 'conn' event to 'DEBUG'. It means that we will print all conn
 related logs that are DEBUG and above (e.g. WARNING, ERROR).
 2. For userspace code, we could do the same (i.e. have events and a
 log level per event).
 3. Userspace logging uses the 'daemon' facility. This should
 definitely be the default, but we should allow the user to use another
 facility. The motivation for doing so is that if we want to send all
 iscsid logs to a separate file, we can set it to 'local2' for example
 (instead of 'daemon').
 

Sorry for the late reply.

This sounds nice.

When you do this, could you also unify what gets printed to id what 
object is logging the message. Currently the kernel prints a session or 
conn sysfs/bus id (session1 or connection1:2), but userspace prints 
whatever it wants. Sometimes it just prints out a log with nothing so 
you have no idea where it came from, and sometimes it prints a id that 
looks like a sysfs one.

--

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: Unable to apply kernel/2.6.26_compat.patch from git master branch

2009-12-07 Thread Mike Christie 
Yangkook Kim wrote:
 Hi,
 I just wanted to report a small problem applying kernel/2.6.26_compat.patch 
 and
 provide an updated patch to fix the problem.
 

Thanks. Sometimes master does not get updated right away because I work 
from master and the current upstream kernel. It is a pain to fix up all 
the compat patches for every upstream kernel change, so I sometimes only 
update the compat patches when a release is made.

I think for your patch, you want to include open_iscsi_compat.h in it.

--

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: SLES10 SP3 x86_64 - connection2:0: detected conn error (1011)

2009-12-07 Thread Mike Christie 
avora wrote:
 With SLES10 SP3 x86_64,
 as soon as I start the second iscsi session2, I am very frequently
 getting the connection errors/
 I do not see this with SLES10 SP2 x86_64 on the same setup.
 
 Dec  7 18:42:05 cdc-r710s1 kernel:  connection2:0: detected conn error
 (1011)
 Dec  7 18:42:06 cdc-r710s1 iscsid: connection2:0 is operational after
 recovery (1 attempts)
 Dec  7 18:42:06 cdc-r710s1 iscsid: Kernel reported iSCSI connection
 2:0 error (1011) state (3)
 Dec  7 18:42:08 cdc-r710s1 kernel:  connection2:0: detected conn error
 (1011)
 
 I have tried changing noop_out_interval and noop_out_timeout to
 120/120 and 0/0 but did not help.

Did you see a ping/nop timeout message in the logs or just what you 
included above with the conn error 1011? The ping/nop message would be a 
little before the con error 1011.

What target is this with and are you doing any IO tests when this 
happens or are you just logging into the second session and then you 
start to get these errors?

--

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.

Another Kernel Oops?

2009-12-07 Thread Qinghua(Kevin) Ye 
Hi All,

I encountered another kernel oops in the open-iscsi code. Not sure if it is
fixed in the new code, but I would like to have some idea about it. Thanks.

My setup:
Ubuntu 8.04 with kernel 2.6.24-24-generic.
Open-iscsi 2.0-870.3


The kernel oops happens after my iscsi target node crashed.
Here is the kernel message.
Dec  7 10:08:21 qye-serv1 kernel: [1459378.575584]  connection3903:0:
detected conn error (1011)
Dec  7 10:08:21 qye-serv1 kernel: [1459378.826718] sd 18028:0:0:16: timing
out command, waited 180s
Dec  7 10:08:21 qye-serv1 kernel: [1459378.826827] sd 18028:0:0:16: [sdd]
Result: hostbyte=DID_BUS_BUSY driverbyte=DRIVER_OK,SUGGEST_OK
Dec  7 10:08:21 qye-serv1 kernel: [1459378.826840] end_request: I/O error,
dev sdd, sector 4505344
Dec  7 10:08:21 qye-serv1 kernel: [1459378.826897] Buffer I/O error on
device sdd, logical block 563168
Dec  7 10:10:21 qye-serv1 kernel: [1459498.629142]  session3903: session
recovery timed out after 120 secs
Dec  7 10:10:21 qye-serv1 kernel: [1459498.629618] BUG: unable to handle
kernel paging request at virtual address fcb8d006
Dec  7 10:10:21 qye-serv1 kernel: [1459498.629815] printing eip: e0a49ff7
*pde = 
Dec  7 10:10:21 qye-serv1 kernel: [1459498.630090] Oops:  [#1] SMP
Dec  7 10:10:21 qye-serv1 kernel: [1459498.630290] Modules linked in:
iscsi_tcp libiscsi scsi_transport_iscsi iscsi_trgt nls_iso8859_1 nls_cp437
vfat fat nfsd auth_rpcgss exportfs crc32c libcrc32c vmmemctl
cpufreq_conservative cpufreq_ondemand cpufreq_userspace cpufreq_stats
freq_table cpufreq_powersave sbs video output sbshc dock battery nfs lockd
nfs_acl sunrpc iptable_filter ip_tables x_tables vmhgfs lp loop ipv6
intel_agp i2c_piix4 serio_raw container ac button agpgart i2c_core shpchp
pci_hotplug parport_pc parport evdev psmouse pcspkr ext3 jbd mbcache ide_cd
cdrom sg sd_mod floppy pcnet32 mptspi mptscsih mptbase mii pata_acpi
ata_generic scsi_transport_spi ata_piix libata scsi_mod ide_generic ide_core
raid10 raid456 async_xor async_memcpy async_tx xor raid1 raid0 multipath
linear md_mod dm_mirror dm_snapshot dm_mod thermal processor fan fbcon
tileblit font bitblit softcursor fuse vmxnet
Dec  7 10:10:21 qye-serv1 kernel: [1459498.631597]
Dec  7 10:10:21 qye-serv1 kernel: [1459498.631735] Pid: 32010, comm:
iscsi_eh Not tainted (2.6.24-24-generic #1)
Dec  7 10:10:21 qye-serv1 kernel: [1459498.631837] EIP: 0060:[e0a49ff7]
EFLAGS: 00010097 CPU: 0
Dec  7 10:10:21 qye-serv1 kernel: [1459498.632168] EIP is at
iscsi_queuecommand+0x47/0x260 [libiscsi]
Dec  7 10:10:21 qye-serv1 kernel: [1459498.632273] EAX: e09776fa EBX:
d8384500 ECX: e09775e0 EDX: e0979560
Dec  7 10:10:21 qye-serv1 kernel: [1459498.632370] ESI: d8384500 EDI:
c38d9400 EBP: c38d9400 ESP: ce921eb8
Dec  7 10:10:21 qye-serv1 kernel: [1459498.632467]  DS: 007b ES: 007b FS:
00d8 GS:  SS: 0068
Dec  7 10:10:21 qye-serv1 kernel: [1459498.632583] Process iscsi_eh (pid:
32010, ti=ce92 task=c61aa000 task.ti=ce92)
Dec  7 10:10:21 qye-serv1 kernel: [1459498.633296] Stack: e0979560 
 d8384500 0287 c38d9400 0031 e0979da7
Dec  7 10:10:21 qye-serv1 kernel: [1459498.633508]dc501600 dc501600
c38d9400 d8926000 d81dc810 e098018a 0036 0016452a
Dec  7 10:10:21 qye-serv1 kernel: [1459498.633660]0006 d8926028
d8926148 d89260b0 d8384500 d81dc810 d81dc810 
Dec  7 10:10:21 qye-serv1 kernel: [1459498.633816] Call Trace:
Dec  7 10:10:21 qye-serv1 kernel: [1459498.634045]  [e0979560]
scsi_done+0x0/0x20 [scsi_mod]
Dec  7 10:10:21 qye-serv1 kernel: [1459498.708347]  [e0979da7]
scsi_dispatch_cmd+0x147/0x280 [scsi_mod]
Dec  7 10:10:21 qye-serv1 kernel: [1459498.708502]  [e098018a]
scsi_request_fn+0x1ea/0x380 [scsi_mod]
Dec  7 10:10:21 qye-serv1 kernel: [1459498.749813]  [e097e760]
device_unblock+0x0/0x10 [scsi_mod]
Dec  7 10:10:21 qye-serv1 kernel: [1459498.749930]  [c020bda2]
blk_start_queue+0x32/0x90
Dec  7 10:10:21 qye-serv1 kernel: [1459498.832531]  [c02803ce]
get_device+0xe/0x20
Dec  7 10:10:21 qye-serv1 kernel: [1459498.879473]  [e097913e]
scsi_device_get+0x1e/0x50 [scsi_mod]
Dec  7 10:10:22 qye-serv1 kernel: [1459498.879592]  [e097e735]
scsi_internal_device_unblock+0x35/0x60 [scsi_mod]
Dec  7 10:10:22 qye-serv1 kernel: [1459498.879714]  [e0979f52]
starget_for_each_device+0x72/0x80 [scsi_mod]
Dec  7 10:10:22 qye-serv1 kernel: [1459498.879966]  [e097e080]
target_unblock+0x0/0x20 [scsi_mod]
Dec  7 10:10:22 qye-serv1 kernel: [1459498.880094]  [e097e09b]
target_unblock+0x1b/0x20 [scsi_mod]
Dec  7 10:10:22 qye-serv1 kernel: [1459498.880201]  [c02805c2]
device_for_each_child+0x22/0x40
Dec  7 10:10:22 qye-serv1 kernel: [1459498.880290]  [e0969710]
session_recovery_timedout+0x0/0xc0 [scsi_transport_iscsi]
Dec  7 10:10:22 qye-serv1 kernel: [1459498.880439]  [c013ce6f]
run_workqueue+0xbf/0x160
Dec  7 10:10:22 qye-serv1 kernel: [1459498.933133]  [c013d910]
worker_thread+0x0/0xe0
Dec  7 10:10:22 qye-serv1 kernel: [1459498.933218]  [c013d994]
worker_thread+0x84/0xe0
Dec  7 10:10:22 qye-serv1

Re: Suggestion for new logging mechanism in open-iscsi

2009-12-07 Thread Erez Zilber 
On Mon, Dec 7, 2009 at 7:24 PM, Mike Christie micha...@cs.wisc.edu wrote:
 Erez Zilber wrote:
 I'd like to make some changes in the logging in open-iscsi. The
 current status is as follows:

 kernel modules:

 * We use iscsi_cls_session_printk  iscsi_cls_conn_printk in
 scsi_transport_iscsi.c. They are sometimes wrapped by macros (e.g.
 ISCSI_DBG_TRANS_SESSION). These macros use KERN_INFO and are
 controlled by module parameters.

 * We use iscsi_session_printk  iscsi_conn_printk for the rest of the
 kernel code.These macros wrap iscsi_cls_session_printk 
 iscsi_cls_conn_printk accordingly. They are sometimes wrapped by
 macros (e.g. ISCSI_SW_TCP_DBG). These macros use KERN_INFO and are
 controlled by module parameters.

 * We sometimes use printk calls.

 userspace:

 We use log_warning, log_error  log_debug. They depend on the logging
 level that we use (0-8). if (log_level  level), the log is sent to
 syslog with the appropriate log level (LOG_WARNING/LOG_ERR/LOG_DEBUG).

 My motivation: with the current logging mechanism, if an error occurs,
 I'm unable to tell exactly what happened. The default logging level is
 too low. Increasing it affects performance. Another problem is that
 open-iscsi has too many logging mechanisms.

 I suggest that:
 1. For kernel modules, we will have 'events' (or any better name that
 you suggest) like 'session', 'conn', 'eh', 'cmd' etc. For each event,
 we will have a logging level. For example, the user may want to set
 the 'conn' event to 'DEBUG'. It means that we will print all conn
 related logs that are DEBUG and above (e.g. WARNING, ERROR).
 2. For userspace code, we could do the same (i.e. have events and a
 log level per event).
 3. Userspace logging uses the 'daemon' facility. This should
 definitely be the default, but we should allow the user to use another
 facility. The motivation for doing so is that if we want to send all
 iscsid logs to a separate file, we can set it to 'local2' for example
 (instead of 'daemon').


 Sorry for the late reply.

 This sounds nice.

 When you do this, could you also unify what gets printed to id what
 object is logging the message. Currently the kernel prints a session or
 conn sysfs/bus id (session1 or connection1:2), but userspace prints
 whatever it wants. Sometimes it just prints out a log with nothing so
 you have no idea where it came from, and sometimes it prints a id that
 looks like a sysfs one.


Sure. The only thing that I don't know is how to get the
sessionX/connectionY string in userspace. Where is it stored?

Thanks,
Erez

--

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: Another Kernel Oops?

2009-12-07 Thread Mike Christie 
Qinghua(Kevin) Ye wrote:
 Hi All,
 
 I encountered another kernel oops in the open-iscsi code. Not sure if it is
 fixed in the new code, but I would like to have some idea about it. Thanks.
 

What the heck are you running, because I have not seen this oops either :)

Is this with the same failure scenario we discussed offlist where you 
login/logout and kill the network?

--

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: Suggestion for new logging mechanism in open-iscsi

2009-12-07 Thread Mike Christie 
Erez Zilber wrote:
 On Mon, Dec 7, 2009 at 7:24 PM, Mike Christie micha...@cs.wisc.edu wrote:
 Erez Zilber wrote:
 I'd like to make some changes in the logging in open-iscsi. The
 current status is as follows:

 kernel modules:

 * We use iscsi_cls_session_printk  iscsi_cls_conn_printk in
 scsi_transport_iscsi.c. They are sometimes wrapped by macros (e.g.
 ISCSI_DBG_TRANS_SESSION). These macros use KERN_INFO and are
 controlled by module parameters.

 * We use iscsi_session_printk  iscsi_conn_printk for the rest of the
 kernel code.These macros wrap iscsi_cls_session_printk 
 iscsi_cls_conn_printk accordingly. They are sometimes wrapped by
 macros (e.g. ISCSI_SW_TCP_DBG). These macros use KERN_INFO and are
 controlled by module parameters.

 * We sometimes use printk calls.

 userspace:

 We use log_warning, log_error  log_debug. They depend on the logging
 level that we use (0-8). if (log_level  level), the log is sent to
 syslog with the appropriate log level (LOG_WARNING/LOG_ERR/LOG_DEBUG).

 My motivation: with the current logging mechanism, if an error occurs,
 I'm unable to tell exactly what happened. The default logging level is
 too low. Increasing it affects performance. Another problem is that
 open-iscsi has too many logging mechanisms.

 I suggest that:
 1. For kernel modules, we will have 'events' (or any better name that
 you suggest) like 'session', 'conn', 'eh', 'cmd' etc. For each event,
 we will have a logging level. For example, the user may want to set
 the 'conn' event to 'DEBUG'. It means that we will print all conn
 related logs that are DEBUG and above (e.g. WARNING, ERROR).
 2. For userspace code, we could do the same (i.e. have events and a
 log level per event).
 3. Userspace logging uses the 'daemon' facility. This should
 definitely be the default, but we should allow the user to use another
 facility. The motivation for doing so is that if we want to send all
 iscsid logs to a separate file, we can set it to 'local2' for example
 (instead of 'daemon').

 Sorry for the late reply.

 This sounds nice.

 When you do this, could you also unify what gets printed to id what
 object is logging the message. Currently the kernel prints a session or
 conn sysfs/bus id (session1 or connection1:2), but userspace prints
 whatever it wants. Sometimes it just prints out a log with nothing so
 you have no idea where it came from, and sometimes it prints a id that
 looks like a sysfs one.

 
 Sure. The only thing that I don't know is how to get the
 sessionX/connectionY string in userspace. Where is it stored?
 

session-id is the X in sessionX and session-conn[0]-id is the Y in 
connectionY.


--

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: Another Kernel Oops?

2009-12-07 Thread Qinghua(Kevin) Ye 
Thanks Mike.

This is not same as before. This time I have a ISCSI connection created
successfully between two machine, and network is fine during the creation of
connection, and then the other machine crashed due to other reason.

I set the noop interval and timeout to be zero.

Thanks.
Kevin


On Mon, Dec 7, 2009 at 11:56 AM, Mike Christie micha...@cs.wisc.edu wrote:

 Qinghua(Kevin) Ye wrote:
  Hi All,
 
  I encountered another kernel oops in the open-iscsi code. Not sure if it
 is
  fixed in the new code, but I would like to have some idea about it.
 Thanks.
 

 What the heck are you running, because I have not seen this oops either :)

 Is this with the same failure scenario we discussed offlist where you
 login/logout and kill the network?

 --

 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.comopen-iscsi%2bunsubscr...@googlegroups.com
 .
 For more options, visit this group at
 http://groups.google.com/group/open-iscsi?hl=en.




--

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 1/5] BNX2I - Add 5771E device support to bnx2i driver

2009-12-07 Thread Anil Veerabhadrappa 
* Add code to enumerate 5771E device

Signed-off-by: Anil Veerabhadrappa ani...@broadcom.com
---
 drivers/scsi/bnx2i/bnx2i_init.c |6 +-
 1 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/drivers/scsi/bnx2i/bnx2i_init.c b/drivers/scsi/bnx2i/bnx2i_init.c
index 0c4210d..3c46458 100644
--- a/drivers/scsi/bnx2i/bnx2i_init.c
+++ b/drivers/scsi/bnx2i/bnx2i_init.c
@@ -83,8 +83,12 @@ void bnx2i_identify_device(struct bnx2i_hba *hba)
set_bit(BNX2I_NX2_DEV_5709, hba-cnic_dev_type);
hba-mail_queue_access = BNX2I_MQ_BIN_MODE;
} else if (hba-pci_did == PCI_DEVICE_ID_NX2_57710 ||
-  hba-pci_did == PCI_DEVICE_ID_NX2_57711)
+  hba-pci_did == PCI_DEVICE_ID_NX2_57711 ||
+  hba-pci_did == PCI_DEVICE_ID_NX2_57711E)
set_bit(BNX2I_NX2_DEV_57710, hba-cnic_dev_type);
+   else
+   printk(KERN_ALERT bnx2i: unknown device, 0x%x\n, 
+ hba-pci_did);
 }
 
 
-- 
1.6.5.1




--

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 2/5 ] BNX2I - Adjust sq_size module parametr to power of 2 only if a non-zero value is specified

2009-12-07 Thread Anil Veerabhadrappa 

* This issue was discovered during 10G iscsi testing
* Default value of 'sq_size' module parameter is '0' which means
  driver should use predefined SQ queue size when setting up iscsi
  connection.
* roundup_pow_of_two(0) results in '1' and forces driver to setup
  connections with send queue size of '1' and results in lower
  performance as well

Signed-off-by: Anil Veerabhadrappa ani...@broadcom.com
---
 drivers/scsi/bnx2i/bnx2i_init.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/scsi/bnx2i/bnx2i_init.c b/drivers/scsi/bnx2i/bnx2i_init.c
index 3c46458..dc6b56c 100644
--- a/drivers/scsi/bnx2i/bnx2i_init.c
+++ b/drivers/scsi/bnx2i/bnx2i_init.c
@@ -367,7 +367,7 @@ static int __init bnx2i_mod_init(void)
 
printk(KERN_INFO %s, version);
 
-   if (!is_power_of_2(sq_size))
+   if (sq_size  !is_power_of_2(sq_size))
sq_size = roundup_pow_of_two(sq_size);
 
mutex_init(bnx2i_dev_lock);
-- 
1.6.5.1




--

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 3/5] BNX2I - update CQ arming algorith for 5771x chipsets

2009-12-07 Thread Anil Veerabhadrappa 

* Only affects 5771x (10G chipsets) devices
* This is an optimized CQ arming algoritm which takes into account
  the number of outstanding tasks

Signed-off-by: Anil Veerabhadrappa ani...@broadcom.com
---
 drivers/scsi/bnx2i/bnx2i.h  |1 +
 drivers/scsi/bnx2i/bnx2i_hwi.c  |   36 +++-
 drivers/scsi/bnx2i/bnx2i_init.c |4 
 3 files changed, 32 insertions(+), 9 deletions(-)

diff --git a/drivers/scsi/bnx2i/bnx2i.h b/drivers/scsi/bnx2i/bnx2i.h
index 2b973f3..6cf9dc3 100644
--- a/drivers/scsi/bnx2i/bnx2i.h
+++ b/drivers/scsi/bnx2i/bnx2i.h
@@ -684,6 +684,7 @@ extern unsigned int error_mask1, error_mask2;
 extern u64 iscsi_error_mask;
 extern unsigned int en_tcp_dack;
 extern unsigned int event_coal_div;
+extern unsigned int event_coal_min;
 
 extern struct scsi_transport_template *bnx2i_scsi_xport_template;
 extern struct iscsi_transport bnx2i_iscsi_transport;
diff --git a/drivers/scsi/bnx2i/bnx2i_hwi.c b/drivers/scsi/bnx2i/bnx2i_hwi.c
index 5c8d763..57f4ca9 100644
--- a/drivers/scsi/bnx2i/bnx2i_hwi.c
+++ b/drivers/scsi/bnx2i/bnx2i_hwi.c
@@ -133,21 +133,39 @@ void bnx2i_arm_cq_event_coalescing(struct bnx2i_endpoint 
*ep, u8 action)
 {
struct bnx2i_5771x_cq_db *cq_db;
u16 cq_index;
+   u16 next_index;
+   u32 num_active_cmds;
 
+
+   /* Coalesce CQ entries only on 10G devices */
if (!test_bit(BNX2I_NX2_DEV_57710, ep-hba-cnic_dev_type))
return;
 
+   /* Do not update CQ DB multiple times before firmware writes
+* '0x' to CQDB-SQN field. Deviation may cause spurious
+* interrupts and other unwanted results
+*/
+   cq_db = (struct bnx2i_5771x_cq_db *) ep-qp.cq_pgtbl_virt;
+   if (cq_db-sqn[0]  cq_db-sqn[0] != 0x)
+   return;
+
if (action == CNIC_ARM_CQE) {
-   cq_index = ep-qp.cqe_exp_seq_sn +
-  ep-num_active_cmds / event_coal_div;
-   cq_index %= (ep-qp.cqe_size * 2 + 1);
-   if (!cq_index) {
+   num_active_cmds = ep-num_active_cmds;
+   if (num_active_cmds = event_coal_min)
+   next_index = 1;
+   else
+   next_index = event_coal_min +
+   (num_active_cmds - event_coal_min) / 
event_coal_div;
+   if (!next_index)
+   next_index = 1;
+   cq_index = ep-qp.cqe_exp_seq_sn + next_index - 1;
+   if (cq_index  ep-qp.cqe_size * 2)
+   cq_index -= ep-qp.cqe_size * 2;
+   if (!cq_index)
cq_index = 1;
-   cq_db = (struct bnx2i_5771x_cq_db *)
-   ep-qp.cq_pgtbl_virt;
-   cq_db-sqn[0] = cq_index;
-   }
-   }
+
+   cq_db-sqn[0] = cq_index;
+}
 }
 
 
diff --git a/drivers/scsi/bnx2i/bnx2i_init.c b/drivers/scsi/bnx2i/bnx2i_init.c
index dc6b56c..ad551c5 100644
--- a/drivers/scsi/bnx2i/bnx2i_init.c
+++ b/drivers/scsi/bnx2i/bnx2i_init.c
@@ -32,6 +32,10 @@ MODULE_VERSION(DRV_MODULE_VERSION);
 
 static DEFINE_MUTEX(bnx2i_dev_lock);
 
+unsigned int event_coal_min = 24;
+module_param(event_coal_min, int, 0664);
+MODULE_PARM_DESC(event_coal_min, Event Coalescing Minimum Commands);
+
 unsigned int event_coal_div = 1;
 module_param(event_coal_div, int, 0664);
 MODULE_PARM_DESC(event_coal_div, Event Coalescing Divide Factor);
-- 
1.6.5.1




--

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 4/5] BNX2I - Task management ABORT TASK fixes

2009-12-07 Thread Anil Veerabhadrappa 

* Due to typo error driver was failing TMF Abort Task request
  when ctask-sc != NULL. Fixed code to fail TMF ABORT Task
  request only when ctask-sc == NULL
* Clear age component (19 most significant bits) of reference ITT
  carried in iSCSI TMF PDU. Age component is internal to initiator
  side and only lower bits of ITT as defined by ISCSI_ITT_MASK is
  is sent on wire
* Retrieve LUN directly from the ref_sc and update SQ wqe as per
  chip HSI (Host Software Interface) specification

Signed-off-by: Anil Veerabhadrappa ani...@broadcom.com
---
 drivers/scsi/bnx2i/bnx2i_hwi.c |   17 +
 1 files changed, 13 insertions(+), 4 deletions(-)

diff --git a/drivers/scsi/bnx2i/bnx2i_hwi.c b/drivers/scsi/bnx2i/bnx2i_hwi.c
index 57f4ca9..af350b2 100644
--- a/drivers/scsi/bnx2i/bnx2i_hwi.c
+++ b/drivers/scsi/bnx2i/bnx2i_hwi.c
@@ -384,6 +384,7 @@ int bnx2i_send_iscsi_tmf(struct bnx2i_conn *bnx2i_conn,
struct bnx2i_cmd *bnx2i_cmd;
struct bnx2i_tmf_request *tmfabort_wqe;
u32 dword;
+   u32 scsi_lun[2];
 
bnx2i_cmd = (struct bnx2i_cmd *)mtask-dd_data;
tmfabort_hdr = (struct iscsi_tm *)mtask-hdr;
@@ -394,27 +395,35 @@ int bnx2i_send_iscsi_tmf(struct bnx2i_conn *bnx2i_conn,
tmfabort_wqe-op_attr = 0;
tmfabort_wqe-op_attr =
ISCSI_TMF_REQUEST_ALWAYS_ONE | ISCSI_TM_FUNC_ABORT_TASK;
-   tmfabort_wqe-lun[0] = be32_to_cpu(tmfabort_hdr-lun[0]);
-   tmfabort_wqe-lun[1] = be32_to_cpu(tmfabort_hdr-lun[1]);
 
tmfabort_wqe-itt = (mtask-itt | (ISCSI_TASK_TYPE_MPATH  14));
tmfabort_wqe-reserved2 = 0;
tmfabort_wqe-cmd_sn = be32_to_cpu(tmfabort_hdr-cmdsn);
 
ctask = iscsi_itt_to_task(conn, tmfabort_hdr-rtt);
-   if (!ctask || ctask-sc)
+   if (!ctask || !ctask-sc)
/*
 * the iscsi layer must have completed the cmd while this
 * was starting up.
+* 
+* Note: In the case of a SCSI cmd timeout, the task's sc
+*   is still active; hence ctask-sc != 0
+*   In this case, the task must be aborted
 */
return 0;
+
ref_sc = ctask-sc;
 
+   /* Retrieve LUN directly from the ref_sc */
+   int_to_scsilun(ref_sc-device-lun, (struct scsi_lun *) scsi_lun);
+   tmfabort_wqe-lun[0] = be32_to_cpu(scsi_lun[0]);
+   tmfabort_wqe-lun[1] = be32_to_cpu(scsi_lun[1]);
+
if (ref_sc-sc_data_direction == DMA_TO_DEVICE)
dword = (ISCSI_TASK_TYPE_WRITE  ISCSI_CMD_REQUEST_TYPE_SHIFT);
else
dword = (ISCSI_TASK_TYPE_READ  ISCSI_CMD_REQUEST_TYPE_SHIFT);
-   tmfabort_wqe-ref_itt = (dword | tmfabort_hdr-rtt);
+   tmfabort_wqe-ref_itt = (dword | (tmfabort_hdr-rtt  ISCSI_ITT_MASK));
tmfabort_wqe-ref_cmd_sn = be32_to_cpu(tmfabort_hdr-refcmdsn);
 
tmfabort_wqe-bd_list_addr_lo = (u32) bnx2i_conn-hba-mp_bd_dma;
-- 
1.6.5.1




--

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 5/5] BNX2I - minor code cleanup and update driver version

2009-12-07 Thread Anil Veerabhadrappa 

* Removed duplicate function call and not-so-useful comment line

Signed-off-by: Anil Veerabhadrappa ani...@broadcom.com
---
 drivers/scsi/bnx2i/bnx2i_init.c  |4 ++--
 drivers/scsi/bnx2i/bnx2i_iscsi.c |2 --
 2 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/scsi/bnx2i/bnx2i_init.c b/drivers/scsi/bnx2i/bnx2i_init.c
index ad551c5..1e111ac 100644
--- a/drivers/scsi/bnx2i/bnx2i_init.c
+++ b/drivers/scsi/bnx2i/bnx2i_init.c
@@ -17,8 +17,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.0.1e
-#define DRV_MODULE_RELDATE June 22, 2009
+#define DRV_MODULE_VERSION 2.1.0
+#define DRV_MODULE_RELDATE Dec 06, 2009
 
 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 070118a..54dc251 100644
--- a/drivers/scsi/bnx2i/bnx2i_iscsi.c
+++ b/drivers/scsi/bnx2i/bnx2i_iscsi.c
@@ -485,7 +485,6 @@ static int bnx2i_setup_cmd_pool(struct bnx2i_hba *hba,
struct iscsi_task *task = session-cmds[i];
struct bnx2i_cmd *cmd = task-dd_data;
 
-   /* Anil */
task-hdr = cmd-hdr;
task-hdr_max = sizeof(struct iscsi_hdr);
 
@@ -765,7 +764,6 @@ struct bnx2i_hba *bnx2i_alloc_hba(struct cnic_dev *cnic)
hba-pci_svid = hba-pcidev-subsystem_vendor;
hba-pci_func = PCI_FUNC(hba-pcidev-devfn);
hba-pci_devno = PCI_SLOT(hba-pcidev-devfn);
-   bnx2i_identify_device(hba);
 
bnx2i_identify_device(hba);
bnx2i_setup_host_queue_size(hba, shost);
-- 
1.6.5.1




--

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.