Here are a few bug fixes across libfc, libfcoe and fcoe.
---
Neil Horman (1):
fcoe: Cleanup locking on fcoe_percpu_receive_thread
Robert Love (1):
fcoe: Remove redundant 'less than zero' check
Vasu Dev (2):
libfc: add exch timer debug info
libfc: fix retries with FDMI
From: Vasu Dev vasu@intel.com
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
strtoul returns an 'unsigned long' so there is no
reason to check if the value is less than zero.
strtoul already checks for the '-' character deep
in its bowels. It will return an error if the user
has provided a negative value and fcoe_str_to_dev_loss
will return that error to its caller.
This
From: Vasu Dev vasu@intel.com
The FC-GS-3 sepc requires to wait for least 3 times R_A_TOV per
sec 4.6.1 If the Requesting_CT does not receive a Response
CT_IU from the Responding_CT within three times R_A_TOV,
it shall consider this to be a protocol error.
This means added four new states
From: Yi Zou yi@intel.com
The lport_recv(), i.e., fc_lport_recv_req() may get called w/o the sequence ptr
being set in fr_seq(), particularly in the case of vn2vn mode, this may happen
if the passive fcp provider, e.g., tcm_fc, has not been registered yet.
Signed-off-by: Yi Zou
From: Yi Zou yi@intel.com
This is exposed in the case the FCP_DATA frames somehow got lost and fc_fcp got
the FCP_RSP, in fc_fcp_recv_resp(), since xfer_len is less than the expected_len
it resets the the timer to wait to 2 more jiffies in case the data frames are
already queued locally.
From: Neil Horman nhor...@tuxdriver.com
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
frames in a single
On Fri, 2012-07-06 at 17:49 +0400, James Bottomley wrote:
On Fri, 2012-07-06 at 02:13 -0700, Nicholas A. Bellinger wrote:
On Fri, 2012-07-06 at 09:43 +0400, James Bottomley wrote:
On Thu, 2012-07-05 at 20:01 -0700, Nicholas A. Bellinger wrote:
SNIP
This bottleneck has been
From: Alan Cox a...@linux.intel.com
Based upon Alan's patch from Coverity scan id 793583, these debug
messages in qlt_async_event() should be starting from byte 0, which is
always the Asynchronous Event Status Code from the parent switch statement.
Also, rename reason_code - login_code following
From: Nicholas Bellinger n...@linux-iscsi.org
This patch changes virtio-scsi to use a new virtio_driver-scan() callback
so that scsi_scan_host() can be properly invoked once virtio_dev_probe() has
set add_status(dev, VIRTIO_CONFIG_S_DRIVER_OK) to signal active virtio-ring
operation, instead of
Hi James,
Please consider picking this one up for your next scsi-rc-fixes PULL,
and it's CC'ed to stable following Paolo's request.
Thank you,
--nab
On Fri, 2012-07-06 at 20:15 +, Nicholas A. Bellinger wrote:
From: Nicholas Bellinger n...@linux-iscsi.org
This patch changes virtio-scsi
On Fri, 6 Jul 2012, James Bottomley wrote:
What people might pay attention to is evidence that there's a problem in
3.5-rc6 (without any OFED crap). If you're not going to bother
investigating, it has to be in an environment they can reproduce (so
ordinary hardware, not infiniband) otherwise
Hello Linus,
Please pull the following two minor target fixes for v3.5-rc6 from the
usual location here:
git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending.git master
There is really nothing exciting and/or controversial this time around.
There's one fix from MDR for a RCU
On Fri, 2012-07-06 at 15:30 -0500, Christoph Lameter wrote:
On Fri, 6 Jul 2012, James Bottomley wrote:
What people might pay attention to is evidence that there's a problem in
3.5-rc6 (without any OFED crap). If you're not going to bother
investigating, it has to be in an environment
14 matches
Mail list logo
