> diff --git a/MAINTAINERS b/MAINTAINERS
> index e1b090f..70af8c0 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -4661,7 +4661,7 @@ S: Maintained
> F: drivers/staging/fbtft/
>
> FCOE SUBSYSTEM (libfc, libfcoe, fcoe)
> -M: Vasu Dev <vasu@int
On Mon, 2016-06-20 at 11:49 +0200, Johannes Thumshirn wrote:
> On Thu, Jun 16, 2016 at 09:56:12AM -0700, Vasu Dev wrote:
> > Intel enabled open-fcoe support in the kernel back in 2007, since
> > then
> > it has maintained that code as an open source project hosted at
&
Intel enabled open-fcoe support in the kernel back in 2007, since then
it has maintained that code as an open source project hosted at open-
fcoe.org and at the OSU Open Source Lab. Today, the software enabling
FCoE is very mature and self-sufficient. Due to the maturity of the
project, a less
On Thu, 2016-02-04 at 17:12 +0100, Johannes Thumshirn wrote:
> Hi Vasu,
>
> On Thu, Oct 15, 2015 at 10:54:57AM -0700, Vasu Dev wrote:
> > On Fri, 2015-10-09 at 13:12 +0200, Johannes Thumshirn wrote:
>
> [...]
>
> > So far only I've been reviewing actively and
- if (scsi_pkt_cachep)
> - kmem_cache_destroy(scsi_pkt_cachep);
> + kmem_cache_destroy(scsi_pkt_cachep);
> }
>
> /**
Looks good.
Acked-by: Vasu Dev <vasu@intel.com>
___
fcoe-devel mailing list
fcoe-devel@open-fcoe.org
http://lists.open-fcoe.org/mailman/listinfo/fcoe-devel
from fp_check_data_len() while keep the free along its
allocation in fp_check_data_len() caller.
Signed-off-by: Vasu Dev <vasu@intel.com>
---
fcping.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/fcping.c b/fcping.c
index 66f7a9d..a992d01 100644
--- a/fc
On Thu, 2015-10-01 at 15:17 +0200, Johannes Thumshirn wrote:
> This patch series replaces all usage of libHBAAPIv2 and libhbalinux2 from
> fcoe-utils and replaces them with an internal version operating directly on
> the
> respective sysfs files.
>
> This removes the two dependencies but pulls
instance
* @vport: fc_vport structure from scsi_transport_fc
* @privsize: driver private data size to allocate along with the Scsi_Host
*/
struct fc_lport *libfc_vport_create(struct fc_vport *vport, int privsize)
_
Looks good.
Acked-by: Vasu Dev vasu@intel.com
might want
to know that it is broken instead silently defaulting a vlan. If you
still want this then fix the issue I reported with the patch below
beside updating documentation for new default vlan option.
Thanks,
Vasu
Thanks,
Sawan
-Original Message-
From: Vasu Dev [mailto:vasu
On Tue, 2014-12-16 at 16:51 +0100, Bart Van Assche wrote:
On 12/15/14 19:25, Vasu Dev wrote:
On Mon, 2014-12-15 at 16:22 +0100, Bart Van Assche wrote:
Hello Vasu,
Every now and then I receive an e-mail from an FCoE user who runs an
older kernel reporting an issue that was fixed
On Mon, 2014-12-15 at 16:22 +0100, Bart Van Assche wrote:
Hello Vasu,
Every now and then I receive an e-mail from an FCoE user who runs an
older kernel reporting an issue that was fixed by the patches that were
accepted upstream in kernel 3.13 (see also
On Mon, 2014-10-13 at 16:13 -0700, Chris Leech wrote:
Hi, this is the start of a conversion from directly reading sysfs to using
libudev for finding devices and their attributes for libhbalinux. I wanted to
see what others felt about this before continuing any further, so please
comment away.
Changed host link event to debug macro so that it doesn't clutter
log with events details when debug mode is not enabled.
Signed-off-by: Vasu Dev vasu@intel.com
Tested-by: Jack Morganjack.mor...@intel.com
---
fcoemon.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions
On Thu, 2014-06-19 at 17:17 -0700, Jun Wu wrote:
On Thu, Jun 19, 2014 at 10:00 AM, Vasu Dev vasu@linux.intel.com wrote:
On Thu, 2014-06-12 at 18:20 -0700, Jun Wu wrote:
On Thu, Jun 12, 2014 at 5:43 PM, Vasu Dev vasu@linux.intel.com wrote:
On Thu, 2014-06-12 at 15:18 -0700, Jun Wu
:33 PM, Nicholas A. Bellinger
n...@linux-iscsi.org wrote:
On Tue, 2014-06-10 at 19:40 -0700, Jun Wu wrote:
On Tue, Jun 10, 2014 at 3:38 PM, Vasu Dev vasu@linux.intel.com wrote:
On Tue, 2014-06-10 at 09:46 -0700, Jun Wu wrote:
This a Supermicro chassis with redundant power supplies. We
On Thu, 2014-06-12 at 18:20 -0700, Jun Wu wrote:
On Thu, Jun 12, 2014 at 5:43 PM, Vasu Dev vasu@linux.intel.com wrote:
On Thu, 2014-06-12 at 15:18 -0700, Jun Wu wrote:
On Wed, Jun 11, 2014 at 11:19 AM, Vasu Dev vasu@linux.intel.com
wrote:
On Tue, 2014-06-10 at 19:40 -0700, Jun
On Tue, 2014-06-10 at 19:40 -0700, Jun Wu wrote:
On Tue, Jun 10, 2014 at 3:38 PM, Vasu Dev vasu@linux.intel.com wrote:
On Tue, 2014-06-10 at 09:46 -0700, Jun Wu wrote:
This a Supermicro chassis with redundant power supplies. We see the
same failures with both SSDs or HDDs.
The same
On Fri, 2014-06-06 at 14:09 -0700, Nicholas A. Bellinger wrote:
So if you don't mind I'll go ahead and queue these up for now in
target-pending/for-next, given they are pretty straight-forward fixes.
If they end up being problematic, they can be dropped before the v3.16
PULL request goes
On Fri, 2014-06-06 at 14:11 -0700, Nicholas A. Bellinger wrote:
nod, changing this to pr_info_ratelimited and doing the same in
ft_queue_data_in() well.
Since doing more places and therefore can be done in separate patch.
//Vasu
___
fcoe-devel
On Fri, 2014-06-06 at 14:02 -0700, Nicholas A. Bellinger wrote:
The break aborts the DataIN send loop and invokes ft_queue_status()
below in an attempt to send TASK_SET_FULL status.
If the ft_queue_status() - lport-tt.seq_send() also fails, then
-ENOMEM will be returned to the target and a
On Mon, 2014-06-09 at 17:00 +, Rustad, Mark D wrote:
On Jun 6, 2014, at 2:45 PM, Jun Wu j...@stormojo.com wrote:
The queue_depth is 32 by default. So all my previous tests were based
on 32 queue_depth.
The result of my tests today confirms that with higher queue_depth,
there are
On Fri, 2014-06-06 at 16:54 -0400, Neil Horman wrote:
On Mon, Jun 02, 2014 at 04:22:50PM -0700, Vasu Dev wrote:
On Fri, 2014-05-30 at 10:59 -0400, Neil Horman wrote:
debugfs caught this:
WARNING: at lib/debugobjects.c:260 debug_print_object+0x83/0xa0()
ODEBUG: free active (active state
On Thu, 2014-06-05 at 15:43 -0700, Nicholas A. Bellinger wrote:
On Wed, 2014-06-04 at 17:22 -0700, Jun Wu wrote:
Is there design limit for the number of target drives that we should
not cross? Is 10 a reasonable number? We did notice that lower number
of target has less problems from our
On Thu, 2014-06-05 at 23:30 +, Nicholas A. Bellinger wrote:
From: Nicholas Bellinger n...@linux-iscsi.org
Hi Vasu,
This series generates SAM_STAT_TASK_SET_FULL status for lport-tt.seq_send()
failures in DataIN + response status codepaths, which is done in order to get
the initiator to
DataIN if TASK_SET_FULL status
has already been set due to a response lport-tt.seq_send()
failure, that has asked target-core to requeue a response.
Reported-by: Vasu Dev vasu@linux.intel.com
Cc: Vasu Dev vasu@linux.intel.com
Cc: Jun Wu j...@stormojo.com
Signed-off-by: Nicholas Bellinger
.
It also does the same for a fc_frame_alloc() failures, in order to
signal the initiator that it should try to reduce it's current
queue_depth, to lower the number of outstanding I/Os on the wire.
Reported-by: Vasu Dev vasu@linux.intel.com
Cc: Vasu Dev vasu@linux.intel.com
Cc: Jun
timeout?
No target doesn't initiate abort and these prints are on receipt of
abort handling and once exchange aborted then seq_send will fail with
noisy prints.
//Vasu
Thanks,
Jun
On Mon, Jun 2, 2014 at 5:21 PM, Vasu Dev vasu@linux.intel.com wrote:
On Mon, 2014-06-02 at 16:55 -0700, Jun Wu
On Wed, 2014-06-04 at 15:21 -0700, Nicholas A. Bellinger wrote:
On Wed, 2014-06-04 at 11:45 -0700, Jun Wu wrote:
The test setup includes one host and one target. The target exposes 10
hard drives (or 10 LUNs) on one fcoe port. The single initiator runs
10 fio processes simultaneously to the
18930795:May 27 10:44:48 poc2 kernel: [ 1942.452136] host7: xid ac4:
f_ctl 9 seq 1
18930796:May 27 10:44:48 poc2 kernel: [ 1942.452139] host7: xid ac4:
Exchange timer armed : 2 msecs
Thanks
On Fri, May 23, 2014 at 9:23 AM, Vasu Dev vasu@linux.intel.com wrote:
On Wed
On Wed, 2014-05-21 at 15:23 -0700, Jun Wu wrote:
18630751 May 21 11:01:53 poc2 kernel: [ 1528.191740] host7: xid
6e4:
Exchange timer armed : 0 msecs
18630752 May 21 11:01:53 poc2 kernel: [ 1528.191747] host7: xid
6e4:
f_ctl 80 seq 1
18630753 May 21 11:01:53 poc2 kernel: [
-existing uses.
Signed-off-by: Vasu Dev vasu@intel.com
Tested-by: Marcus Dennis marcusx.e.den...@intel.com
---
fcoeadm.c|4
fcoemon.c| 54 --
include/fcoe_utils.h |1 +
3 files changed, 31 insertions(+), 28
such that enable has to be followed by disable once DCB is operational
again on link up and that prevents enabling interface on netlink event
w/o DCB being operational.
Signed-off-by: Vasu Dev vasu@intel.com
Tested-by: Ross Brattain ross.b.bratt...@intel.com
---
fcoemon.c | 17 +++--
1
Removes the retry code block not reachable for the configured
auto vlan interface since the block condition will always fail
and that prevents executing retry code block.
This condition will always fail, !(p-fcoe_enable p-auto_vlan)
Also removed unused FCM_VLAN_DISC_MAX
Signed-off-by: Vasu Dev
clearing
FC_RP_FLAGS_REC_SUPPORTED on failed IO with target not supporting
FC_RP_FLAGS_REC_SUPPORTED, since retry on failed IO would succeed.
Signed-off-by: Vasu Dev vasu@intel.com
Tested-by: Ross Brattain ross.b.bratt...@intel.com
---
drivers/scsi/libfc/fc_fcp.c |6 +++---
1 files
On Thu, 2012-08-16 at 11:24 -0500, Andrew Theurer wrote:
Aug 16 09:02:01 spv-20 fcoemon: eth9, DONE - INIT
I just need to get FIP VLAN requests to work now :)
You would need FCF to respond to the FIP VLAN request with DCBX FCoE
APP TLV in sync.
Aug 16 09:02:02 spv-20 fcoemon: eth9:
significant delay with multiple retries
on default 12 second timeout(3 * R_A_TOV), so instead
just skip these states on very first timeout on any of
these states to not stuck with states for such longer
period.
Signed-off-by: Vasu Dev vasu@intel.com
Tested-by: Marcus Dennis marcusx.e.den
Add exch timeout info to have debug log with exch timeout
value to match with retries, also add debug info
on exch timer cancel.
Added common fc_exch_timer_cancel() func and grouped this
along with fc_exch_timer_set() function, so that
added debug code is not repeated.
Signed-off-by: Vasu Dev
On Wed, 2012-06-20 at 08:48 -0400, Neil Horman wrote:
Noticed that we can shuffle the code around in fcoe_percpu_receive_thread a
bit
and avoid taking the fcoe_rx_list lock twice per iteration. This should
improve
throughput somewhat. With this change we take the lock, and check for new
On Thu, 2012-06-21 at 15:19 -0400, Neil Horman wrote:
On Thu, Jun 21, 2012 at 10:13:17AM -0700, Vasu Dev wrote:
On Wed, 2012-06-20 at 08:48 -0400, Neil Horman wrote:
Noticed that we can shuffle the code around in fcoe_percpu_receive_thread
a bit
and avoid taking the fcoe_rx_list lock
. This allows
me
to change the inner while loop to an if conditional and remove the sencond
check
of kthread_should_stop. Based on suggestion from Vasu Dev.
Signed-off-by: Neil Horman nhor...@tuxdriver.com
CC: Robert Love robert.w.l...@intel.com
CC: Vasu Dev vasu@linux.intel.com
---
drivers
The libfc is used by fcoe but fcoe agnostic,
and therefore should not have any fcoe references.
So renaming fcoe_dev_stats from libfc as its for fc_stats.
After that libfc is fcoe string free except some strings for
Open-FCoE.org.
Signed-off-by: Vasu Dev vasu@intel.com
Acked-by : Robert Love
Adds stats to track FCP pkt and frame alloc
failure.
Signed-off-by: Vasu Dev vasu@intel.com
Acked-by : Robert Love robert.w.l...@intel.com
Tested-by: Ross Brattain ross.b.bratt...@intel.com
---
drivers/scsi/libfc/fc_fcp.c |8
include/scsi/libfc.h|6 ++
2 files
Updates newly added stats from fc_get_host_stats,
added new function fc_exch_update_stats to
update exches related stats from fc_exch.c
by going thru internal ema_list elements.
Signed-off-by: Vasu Dev vasu@intel.com
Acked-by : Robert Love robert.w.l...@intel.com
Tested-by: Ross Brattain
FC stats already has, however anyway
still added commentary along their definition
to describe them.
CC: James Smart james.sm...@emulex.com
Signed-off-by: Vasu Dev vasu@intel.com
Acked-by : Robert Love robert.w.l...@intel.com
Tested-by: Ross Brattain ross.b.bratt...@intel.com
---
drivers
On Mon, 2012-03-26 at 00:07 -0700, Bhanu Prakash Gollapudi wrote:
On 3/22/2012 12:23 PM, Bhanu Prakash Gollapudi wrote:
On 3/22/2012 10:38 AM, Vasu Dev wrote:
On Thu, 2012-03-22 at 11:03 -0700, Bhanu Prakash Gollapudi wrote:
On 2/14/2012 5:34 PM, Vasu Dev wrote:
Currently fc_host mfs
On Thu, 2012-03-22 at 11:03 -0700, Bhanu Prakash Gollapudi wrote:
On 2/14/2012 5:34 PM, Vasu Dev wrote:
Currently fc_host mfs is not getting updated in
case its changed during FLOGI and that leaves fc_host
to show its initial old value in sysfs, so instead
have fc_host mfs updated along
discovered interface.
3) The RTM_GETLINK dump request is sent only once and if that
fails to find any interfaces then no vlan discovery done,
instead try RTM_GETLINK again few time before giving up.
4) confusing error message in case the fcoe stack not loaded.
---
Vasu Dev (4):
fipvlan
Creation of fip socket sends rtnl for DCB, so don't
do that along new link rtnl processing, instead create
fip socket once interface is selected for fipvlan.
Signed-off-by: Vasu Dev vasu@intel.com
Tested-by: John Bishop johnx.bis...@intel.com
---
fipvlan.c | 29
be error:0 pfd:1
fipvlan: RTM_NEWLINK: ifindex 5, type 1, flags 1003
fipvlan: rtnl_recv_newlink: error 19 No such device
fipvlan: rtnl_recv_newlink: VLAN found without parent
fipvlan: main: error 19 No such device
fipvlan: main: no interfaces to perform discovery on
Signed-off-by: Vasu Dev vasu
During stressed DCB interface toggling, sometimes
fipvlan finds none interfaces and exits without
any vlan discovery, so instead add more retries
for this to find interfaces again.
Signed-off-by: Vasu Dev vasu@intel.com
Tested-by: John Bishop johnx.bis...@intel.com
---
fipvlan.c |5
fipvlan: fcoe_instance_start: failed to open fcoe create file
Starting FCoE on interface eth4.228
fipvlan: fcoe_instance_start: error 2 No such file or directory
fipvlan: fcoe_instance_start: failed to open fcoe create file
Signed-off-by: Vasu Dev vasu@intel.com
Tested-by: Ross Brattain ross.b.bratt
with Neil's other patch to avoid soft irq context
on ingress will avoid passing up frames on disabled lport as
discussed in this mail thread:-
http://lists.open-fcoe.org/pipermail/devel/2012-February/011947.html
Signed-off-by: Vasu Dev vasu@intel.com
Acked-by: Neil Horman nhor...@tuxdriver.com
Tested
The fcoe controller has back references, therefore defer
releasing master lport which gets freed along scsi_host_put
and then free it once fcoe interface is fully cleaned.
Signed-off-by: Vasu Dev vasu@intel.com
Acked-by: Neil Horman nhor...@tuxdriver.com
Tested-by: Ross Brattain ross.b.bratt
baa5f88db4325f95ba67ab09db94db5db9d0dda2
Author: Steven Clark scl...@crossbeam.com
Date: Tue Feb 28 03:30:40 2012 +
---
Vasu Dev (3):
libfc: defer releasing master lport until complete fcoe interface
cleanuped up
libfc: flush lport worker after its disabled
fcoe: remove lport
[13192.954278] [814edbb0] ? gs_change+0x13/0x13
[13192.954911] ---[ end trace 9763213b95bbd803 ]---
Signed-off-by: Vasu Dev vasu@intel.com
Acked-by: Neil Horman nhor...@tuxdriver.com
Tested-by: Ross Brattain ross.b.bratt...@intel.com
---
drivers/scsi/libfc/fc_lport.c |2 +-
1
Regards,
Nirmal
On Thu, Mar 1, 2012 at 5:07 AM, Vasu Dev vasu@linux.intel.com
wrote:
On Wed, 2012-02-29 at 17:11 +0530, nirmal r wrote:
Hi All,
I have a couple of configuration questions with respect to
VN2VN.
1) How do I configure PTP mode
On Thu, 2012-03-01 at 08:39 -0500, Neil Horman wrote:
On Wed, Feb 29, 2012 at 03:19:57PM -0800, Vasu Dev wrote:
On Mon, 2012-02-27 at 14:22 -0500, Neil Horman wrote:
Since commit 853d3cbbe431571c3ae822c8f5df43acff344ded went in, we are
guaranteed a clean division beteen fcoe code
Horman nhor...@tuxdriver.com
CC: Robert Love robert.w.l...@intel.com
CC: Vasu Dev vasu@linux.intel.com
CC: James E.J. Bottomley jbottom...@parallels.com
---
Change notes:
v2)
As per Vasu's note, remove the get_more_skbs label as its unused
---
drivers/scsi/fcoe/fcoe.c | 23
On Mon, 2012-02-27 at 14:22 -0500, Neil Horman wrote:
Since commit 853d3cbbe431571c3ae822c8f5df43acff344ded went in, we are
guaranteed a clean division beteen fcoe code that runs in softirq context and
code that runs in process context. This opens the door for us to implement
some
minor
the frame. Convert spin_*_bh calls in that function to their
lock-only equivalents
Signed-off-by: Neil Horman nhor...@tuxdriver.com
CC: Robert Love robert.w.l...@intel.com
CC: Vasu Dev vasu@linux.intel.com
CC: James E.J. Bottomley jbottom...@parallels.com
---
drivers/scsi/fcoe/fcoe.c
the
list first, dropping any arriving frames.
Good cleanup, in fact this was not needed before above mentioned commit
also.
Acked-by: Vasu Dev vasu@intel.com
Signed-off-by: Neil Horman nhor...@tuxdriver.com
CC: Robert Love robert.w.l...@intel.com
CC: Vasu Dev vasu@linux.intel.com
CC
Horman nhor...@tuxdriver.com
CC: Robert Love robert.w.l...@intel.com
CC: Vasu Dev vasu@linux.intel.com
CC: James E.J. Bottomley jbottom...@parallels.com
---
drivers/scsi/fcoe/fcoe.c | 24
1 files changed, 16 insertions(+), 8 deletions(-)
diff --git a/drivers
On Wed, 2012-02-29 at 17:11 +0530, nirmal r wrote:
Hi All,
I have a couple of configuration questions with respect to VN2VN.
1) How do I configure PTP mode?
Use VN2VN as you are doing in 2) below.
2) I tried fcc.sh create-vn eth0 and vconfig add eth0 200. After capturing
the packets, I see
Moved entries is causing fcc to fail for create/destory with
this error message:
fcc.sh: file /sys/module/fcoe/parameters/create doesn't exist.
Check for fcoe module.
Signed-off-by: Vasu Dev vasu@intel.com
Tested-by: Ross Brattain ross.b.bratt...@intel.com
---
contrib/fcc.sh |7
with flogi.
Signed-off-by: Vasu Dev vasu@intel.com
Tested-by: Ross Brattain ross.b.bratt...@intel.com
---
drivers/scsi/libfc/fc_lport.c |9 -
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/drivers/scsi/libfc/fc_lport.c b/drivers/scsi/libfc/fc_lport.c
index 9a0b2a9
On Fri, 2012-02-10 at 22:05 -0500, Neil Horman wrote:
This approach looks fine as we discussed before, it might be worth
checking to restore soft irq later by checking perf if we could see
possible fix even with added rcu locking is fine as rcu are cheap
but at
the moment don't know how.
first and then will get them out once tested.
Reviewed-by: Vasu Dev vasu@intel.com
Signed-off-by: Neil Horman nhor...@tuxdriver.com
CC: kiran.pa...@intel.com
CC: bprak...@broadcom.com
CC: robert.w.l...@intel.com
CC: Chris Leech christopher.le...@intel.com
CC: John Fastabend
with Neil's other patch to avoid soft irq context
on ingress will avoid passing up frames on disabled lport as
discussed in this mail thread for his patch.
http://lists.open-fcoe.org/pipermail/devel/2012-February/011947.html
Signed-off-by: Vasu Dev vasu@intel.com
CC: Neil Horman nhor...@tuxdriver.com
[13192.954278] [814edbb0] ? gs_change+0x13/0x13
[13192.954911] ---[ end trace 9763213b95bbd803 ]---
Signed-off-by: Vasu Dev vasu@intel.com
---
drivers/scsi/libfc/fc_lport.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/scsi/libfc/fc_lport.c b
The fcoe controller has back references, therefore defer
releasing master lport which gets freed along scsi_host_put
and then free it once fcoe interface is fully cleaned.
Signed-off-by: Vasu Dev vasu@intel.com
---
drivers/scsi/fcoe/fcoe.c |9 +++--
1 files changed, 7 insertions
On Tue, 2012-02-07 at 06:59 -0500, Neil Horman wrote:
On Mon, Feb 06, 2012 at 03:34:00PM -0800, Vasu Dev wrote:
On Thu, 2012-02-02 at 16:03 -0500, Neil Horman wrote:
fc_port-ema_list is being accessed in multiple parallel contexts with no
locking around it leading to potential corruption
On Thu, 2012-02-02 at 16:03 -0500, Neil Horman wrote:
fc_port-ema_list is being accessed in multiple parallel contexts with no
locking around it leading to potential corruption.
I don't see any possibility of ema_list corruption here and if there is
any such possible case/s then we should fix
On Wed, 2011-12-14 at 20:52 +0100, Nicolas de Pesloüan wrote:
If a protocol handler is registered on a particular device (instead of
NULL), then the handler will
receive whatever is received on this device. This is true for bridge,
for bonding and probably for
all other stackable devices. I
orig_dev uses as it was prior to that commit but still w/o
recursive calling to __netif_receive_skb.
Signed-off-by: Vasu Dev vasu@intel.com
---
net/core/dev.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index
On Mon, 2011-10-24 at 20:39 -0700, Bhanu Prakash Gollapudi wrote:
On 10/24/2011 5:22 PM, Vasu Dev wrote:
On Mon, 2011-10-24 at 14:36 -0700, Bhanu Prakash Gollapudi wrote:
On 10/24/2011 1:42 PM, Neil Horman wrote:
On Mon, Oct 24, 2011 at 11:59:52AM -0700, Zou, Yi wrote:
On 10/21/2011 4
On Mon, 2011-10-24 at 14:36 -0700, Bhanu Prakash Gollapudi wrote:
On 10/24/2011 1:42 PM, Neil Horman wrote:
On Mon, Oct 24, 2011 at 11:59:52AM -0700, Zou, Yi wrote:
On 10/21/2011 4:36 PM, Neil Horman wrote:
This oops was reported to me recently:
PID: 5176 TASK: 880215274100
On Tue, 2011-10-18 at 23:23 -0700, Bhanu Prakash Gollapudi wrote:
- fcoe_update_src_mac(lport, mac);
+ /* pre-FIP */
+ if (is_zero_ether_addr(mac))
+ fcoe_ctlr_recv_flogi(fip, lport, fp);
Vasu, what is the reason for not checking the return value for this?
what
after this series.
The series is also under testing and Yi
will add Tested-By liner before applied for
upstream.
---
Vasu Dev (3):
libfc: improve flogi retries to avoid lport stuck
libfc: avoid exchanges collision during lport reset
libfc: fix checking FC_TYPE_BLS
drivers
Currently timer delay is large and is using msleep to avoid
avoid exchanges collision across lport reset, so instead
do this by initializing exches pool indexes during
reset also.
Signed-off-by: Vasu Dev vasu@intel.com
---
drivers/scsi/libfc/fc_exch.c |4
drivers/scsi/libfc
Adds more cases to do flogi retry, now also retry
on getting bad response due to either no ELS response
or flogi response payload length not large enough.
In those cases flogi was not retried and that
was leaving lport offline.
Signed-off-by: Vasu Dev vasu@intel.com
---
drivers/scsi/fcoe
Its checked after skb freed, so instead have fh_type
cached and then check FC_TYPE_BLS against cached
fh_type value.
This wrong check was causing double exch locking as
reported by Bhanu at
https://lists.open-fcoe.org/pipermail/devel/2011-October/011793.html
Signed-off-by: Vasu Dev vasu
On Fri, 2011-09-30 at 15:36 -0700, Bhanu Prakash Gollapudi wrote:
+static int fc_exch_abort_locked(struct fc_exch *ep,
+ unsigned int timer_msec)
Vasu, this patch causes a deadlock when the fcoe interface is
destroyed.
The reason is, holding the exch_lock, we
On Wed, 2011-10-12 at 01:43 -0700, Zou, Yi wrote:
On 8/9/2011 2:20 PM, Vasu Dev wrote:
Current fc_eh_host_reset leaves lport offline
permanently due to FLOGI response getting
handled by LOGO response from last reset as both
had same exchange id.
So fix this by having end
On Wed, 2011-10-12 at 12:52 -0700, Bhanu Prakash Gollapudi wrote:
On 10/12/2011 10:16 AM, Vasu Dev wrote:
On Fri, 2011-09-30 at 15:36 -0700, Bhanu Prakash Gollapudi wrote:
+static int fc_exch_abort_locked(struct fc_exch *ep,
+ unsigned int timer_msec)
Vasu
On Wed, 2011-09-21 at 18:01 -0700, Zou, Yi wrote:
We are doing ' fcoe_ddp_min' check right now,
Yes and set threshold tested and works with existing '' check, so keep
the check as-is.
Thanks
Vasu
___
devel mailing list
devel@open-fcoe.org
Currently fcoe_ddp_min doesn't have default value
so by default not used, so setting up default value
as 4k as this works better by avoiding overhead
of programing DDP for small IOs.
Signed-off-by: Vasu Dev vasu@intel.com
Tested-by: Ross Brattain ross.b.bratt...@intel.com
---
drivers/scsi
Use real dev in case it has HW vlan acceleration
support since in this case the real dev would
do needed vlan processing, this way unnecessary
vlan layer processing avoided and it gives
slightly better IOPS with 512B size IOs.
Signed-off-by: Vasu Dev vasu@intel.com
Tested-by: Ross Brattain
together.
Tested-by: Ross Brattain ross.b.bratt...@intel.com
Signed-off-by: Vasu Dev vasu@intel.com
---
drivers/scsi/libfc/fc_fcp.c |2 --
include/scsi/libfc.h| 49 ++-
2 files changed, 21 insertions(+), 30 deletions(-)
diff --git a/drivers
cache aligned xid and ex_lock beside
removing holes.
Tested-by: Ross Brattain ross.b.bratt...@intel.com
Signed-off-by: Vasu Dev vasu@intel.com
---
include/scsi/libfc.h | 27 ---
1 files changed, 12 insertions(+), 15 deletions(-)
diff --git a/include/scsi/libfc.h b
fix holes and better cache aligned fields.
Tested-by: Ross Brattain ross.b.bratt...@intel.com
Signed-off-by: Vasu Dev vasu@intel.com
---
drivers/scsi/libfc/fc_exch.c | 11 +--
1 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/scsi/libfc/fc_exch.c b/drivers
On Thu, 2011-08-11 at 16:48 -0500, Mike Christie wrote:
Where are you seeing such large IO? Block/fs IO is limited by
q-max_sectors which is 1024 already.
I was using block IO and yeah upstream already has limit as 1024 and no
need to restrict by changing hard limit for this case. I was getting
18.03.00 - 4e.00.0b FC ELS ACC (LOGO) 0x223
626 86.443683 b6.02.00 - 4e.00.0b FC ELS ACC (LOGO) 0x213
627 86.447693 18.01.00 - 4e.00.0b FC ELS ACC (LOGO) 0x243
628 86.453499 18.02.00 - 4e.00.0b FC ELS ACC (LOGO) 0x233
Signed-off-by: Vasu Dev vasu@intel.com
Tested
Call fc_block_scsi_eh() in all fcoe eh to blocks
the scsi_eh thread for blocked rports.
Signed-off-by: Vasu Dev vasu@intel.com
Tested-by: Ross Brattain ross.b.bratt...@intel.com
---
drivers/scsi/libfc/fc_fcp.c | 11 +--
1 files changed, 9 insertions(+), 2 deletions(-)
diff --git
Currently default max_sectors size is too large
given sg elements set to SG_ALL(128) and some IOs
could be too large with large segments, so have
it set to 1024 as default for fcoe. Anycase
fcoe HBA could override this default.
Signed-off-by: Vasu Dev vasu@intel.com
Tested-by: Ross Brattain
On Sun, 2011-07-31 at 00:55 -0700, Bhanu Prakash Gollapudi wrote:
Would happen only link up event was missed by fcoe stack but not by
I meant only *if* link up here.
fcoemon, but that is not possible as stack would get thru notifier.
You're right, but there lies the problem. There is a
On Wed, 2011-07-27 at 18:22 -0700, Bhanu Prakash Gollapudi wrote:
When there are rapid link events the network stack may not deliver all
the events to the application and to the driver. Only the last event
will be delivered. Because of this, when there is a Link UP event
without the Link
On Fri, 2011-07-29 at 16:39 -0700, Bhanu Prakash Gollapudi wrote:
On 7/29/2011 3:10 PM, Vasu Dev wrote:
Thanks for your reply, Vasu.
On Wed, 2011-07-27 at 18:22 -0700, Bhanu Prakash Gollapudi wrote:
When there are rapid link events the network stack may not deliver all
the events
On Wed, 2011-07-20 at 22:01 +0800, Hillf Danton wrote:
In TM response handler, the following code
fsp-seq_ptr = NULL;
fsp-lp-tt.exch_done(seq);
is execed without precondition, and if @seq == fsp-seq_ptr, the
-exch_done
method is called likely more than once for same
fixes possibly infinite loop in case
of curr_cpu is the only cpu while iterating in the loop.
This cleanup mainly applies to target as incoming request are
mostly for target, therefore Kiran has verified the patch
with target also.
Signed-off-by: Vasu Dev vasu@intel.com
Tested-by: Kiran
[488200.091561] [ cut here ]
Jun 22 03:16:32 10.0.16.6 [488200.091586] WARNING: at
drivers/scsi/libfc/fc_lport.c:1355 fc_lport_timeout+0xd9/0xe0 [libfc]()
Signed-off-by: Vasu Dev vasu@intel.com
Tested-by: Ross Brattain ross.b.bratt...@intel.com
---
drivers/scsi/libfc/fc_lport.c
1 - 100 of 441 matches
Mail list logo
