On Fri, Apr 5, 2013 at 1:51 PM, Michael R. Hines
mrhi...@linux.vnet.ibm.com wrote:
Sorry, I was wrong. ignore the comments about cgroups. That's still broken.
(i.e. trying to register RDMA memory while using a cgroup swap limit cause
the process get killed).
But the GIFT flag patch works (my
On Fri, Apr 5, 2013 at 1:17 PM, Michael R. Hines
mrhi...@linux.vnet.ibm.com wrote:
I also removed the IBV_*_WRITE flags on the sender-side and activated
cgroups with the memory.memsw.limit_in_bytes activated and the migration
with RDMA also succeeded without any problems (both with *and*
On Fri, Apr 5, 2013 at 11:42 AM, Markus Stockhausen
markus.stockhau...@gmx.de wrote:
this patch is better than the first one. No more lockups of the server.
Nevertheless I'm sorry to tell you that we are not finished yet. After
running some promising netperf/netserver tests I switched over to
On Fri, Apr 5, 2013 at 1:51 PM, Michael R. Hines
mrhi...@linux.vnet.ibm.com wrote:
Sorry, I was wrong. ignore the comments about cgroups. That's still broken.
(i.e. trying to register RDMA memory while using a cgroup swap limit cause
the process get killed).
But the GIFT flag patch works (my
On Fri, Apr 5, 2013 at 1:17 PM, Michael R. Hines
mrhi...@linux.vnet.ibm.com wrote:
I also removed the IBV_*_WRITE flags on the sender-side and activated
cgroups with the memory.memsw.limit_in_bytes activated and the migration
with RDMA also succeeded without any problems (both with *and*
On Fri, Apr 5, 2013 at 1:51 PM, Michael R. Hines
mrhi...@linux.vnet.ibm.com wrote:
Sorry, I was wrong. ignore the comments about cgroups. That's still broken.
(i.e. trying to register RDMA memory while using a cgroup swap limit cause
the process get killed).
But the GIFT flag patch works (my
On Wed, Apr 3, 2013 at 12:03 PM, Markus Stockhausen
markus.stockhau...@gmx.de wrote:
going through hard lessons to understand the SKBs maybe I finally
found the reason for the unnecessary memcpy commands. Even with
newest 3.9-rc5 kernel the problem persists. IPoIB creates only
fragmented SKBs
From: Roland Dreier rol...@purestorage.com
Markus Stockhausen markus.stockhau...@gmx.de noticed that IPoIB was
spending significant time doing memcpy() in __pskb_pull_tail(). He
found that this is because his adapter reports a maximum MTU of 4K,
which causes IPoIB datagram mode to receive all
On Thu, Apr 4, 2013 at 2:45 PM, Or Gerlitz or.gerl...@gmail.com wrote:
The problem that I'm trying to solve is that some IB core modules are
hanging waiting on completion queues on their remove path during error
recovery.
So maybe patch them to give up after some time?
I don't know so much
On Wed, Apr 3, 2013 at 6:13 AM, Jeff Squyres jsquy...@cisco.com wrote:
diff --git a/include/rdma/ib_verbs.h b/include/rdma/ib_verbs.h
index 8a66758..4670f6f 100644
--- a/include/rdma/ib_verbs.h
+++ b/include/rdma/ib_verbs.h
@@ -174,8 +174,10 @@ enum ib_mtu {
IB_MTU_256 = 1,
On Tue, Apr 2, 2013 at 8:51 AM, Michael S. Tsirkin wrote:
>> At the moment registering an MR breaks COW. This breaks memory
>> overcommit for users such as KVM: we have a lot of COW pages, e.g.
>> instances of the zero page or pages shared using KSM.
>>
>> If the application does not care that
On Tue, Apr 2, 2013 at 8:51 AM, Michael S. Tsirkin m...@redhat.com wrote:
At the moment registering an MR breaks COW. This breaks memory
overcommit for users such as KVM: we have a lot of COW pages, e.g.
instances of the zero page or pages shared using KSM.
If the application does not care
On Tue, Apr 2, 2013 at 8:51 AM, Michael S. Tsirkin m...@redhat.com wrote:
At the moment registering an MR breaks COW. This breaks memory
overcommit for users such as KVM: we have a lot of COW pages, e.g.
instances of the zero page or pages shared using KSM.
If the application does not care
diff --git a/drivers/infiniband/hw/mlx4/qp.c b/drivers/infiniband/hw/mlx4/qp.c
index 35cced2..0fa4f72 100644
--- a/drivers/infiniband/hw/mlx4/qp.c
+++ b/drivers/infiniband/hw/mlx4/qp.c
@@ -2216,6 +2216,9 @@ int mlx4_ib_post_send(struct ib_qp *ibqp, struct
ib_send_wr *wr,
__be32
On Tue, Apr 2, 2013 at 7:20 AM, Bart Van Assche bvanass...@acm.org wrote:
Can anyone tell me what happened with this patch series ? To me this looks
like
a useful patch series to make the mlx4_en driver faster. However, I haven't
seen
anyone posting any review comments to this series and
On Tue, Apr 2, 2013 at 8:51 AM, Michael S. Tsirkin m...@redhat.com wrote:
At the moment registering an MR breaks COW. This breaks memory
overcommit for users such as KVM: we have a lot of COW pages, e.g.
instances of the zero page or pages shared using KSM.
If the application does not care
Checkpatch recommends since some time to use sizeof(e) instead of sizeof e,
isn't it ?
I actually prefer sizeof e since sizeof is an operator, not a
function. sizeof(e) looks just as silly as return(e) to me.
I'll apply this patch soon, it's a good catch.
--
To unsubscribe from this list:
On Mon, Mar 25, 2013 at 4:48 PM, Grant Grundler grund...@google.com wrote:
Stumbled across this in 3.4 kernel but still exists in 3.9-rc3:
fgrep -n WARN_ON ./drivers/infiniband/ulp/srpt/ib_srpt.c
...
1377: WARN_ON(ERROR: unexpected command state);
...
This works but intent is
ion
Roland Dreier (1):
Merge branches 'cxgb4', 'ipoib' and 'qib' into for-next
Vinit Agnihotri (1):
IB/qib: change QLogic to Intel
Wei Yongjun (1):
RDMA/cxgb4: Fix error return code in create_qp()
drivers/infiniband/hw/cxgb4/qp.c | 4 +++-
drivers/infiniband/hw/ip
Roland Dreier (1):
Merge branches 'cxgb4', 'ipoib' and 'qib' into for-next
Vinit Agnihotri (1):
IB/qib: change QLogic to Intel
Wei Yongjun (1):
RDMA/cxgb4: Fix error return code in create_qp()
drivers/infiniband/hw/cxgb4/qp.c | 4 +++-
drivers/infiniband/hw/ipath
On Sat, Mar 23, 2013 at 2:30 PM, Dan Carpenter dan.carpen...@oracle.com wrote:
In the end, we decided this was correct as-is?
I'm about to complain to the caif network people about the
dma_alloc_coherent() - virt_to_phys() thing, but the truth is I
don't understand this stuff very well and
Roland Dreier (1):
Merge branches 'cxgb4', 'ipoib' and 'qib' into for-next
Vinit Agnihotri (1):
IB/qib: change QLogic to Intel
Wei Yongjun (1):
RDMA/cxgb4: Fix error return code in create_qp()
drivers/infiniband/hw/cxgb4/qp.c | 4 +++-
drivers/infiniband/hw/ipath
On Thu, Mar 21, 2013 at 1:51 AM, Michael S. Tsirkin wrote:
>> In that case, no, I don't see any reason for LOCAL_WRITE, since the
>> only RDMA operations that will access this memory are remote reads.
>
> What is the meaning of LOCAL_WRITE then? There are no local
> RDMA writes as far as I can
>> I think this change will break the case where userspace tries to
>> register an MR with read-only permission, but intends locally through
>> the CPU to write to the memory.
> Shouldn't it set LOCAL_WRITE then?
We're talking about the permissions for the register MR operation,
right? (That's
On Wed, Mar 20, 2013 at 11:18 PM, Michael S. Tsirkin wrote:
> core/umem.c seems to get the arguments to get_user_pages
> in the reverse order: it sets writeable flag and
> breaks COW for MAP_SHARED if and only if hardware needs to
> write the page.
>
> This breaks memory overcommit for users such
On Wed, Mar 20, 2013 at 11:18 PM, Michael S. Tsirkin m...@redhat.com wrote:
core/umem.c seems to get the arguments to get_user_pages
in the reverse order: it sets writeable flag and
breaks COW for MAP_SHARED if and only if hardware needs to
write the page.
This breaks memory overcommit for
I think this change will break the case where userspace tries to
register an MR with read-only permission, but intends locally through
the CPU to write to the memory.
Shouldn't it set LOCAL_WRITE then?
We're talking about the permissions for the register MR operation,
right? (That's what
On Thu, Mar 21, 2013 at 1:51 AM, Michael S. Tsirkin m...@redhat.com wrote:
In that case, no, I don't see any reason for LOCAL_WRITE, since the
only RDMA operations that will access this memory are remote reads.
What is the meaning of LOCAL_WRITE then? There are no local
RDMA writes as far as
I think this change will break the case where userspace tries to
register an MR with read-only permission, but intends locally through
the CPU to write to the memory.
Shouldn't it set LOCAL_WRITE then?
We're talking about the permissions for the register MR operation,
right? (That's what
On Wed, Mar 20, 2013 at 11:18 PM, Michael S. Tsirkin m...@redhat.com wrote:
core/umem.c seems to get the arguments to get_user_pages
in the reverse order: it sets writeable flag and
breaks COW for MAP_SHARED if and only if hardware needs to
write the page.
This breaks memory overcommit for
On Thu, Mar 21, 2013 at 1:51 AM, Michael S. Tsirkin m...@redhat.com wrote:
In that case, no, I don't see any reason for LOCAL_WRITE, since the
only RDMA operations that will access this memory are remote reads.
What is the meaning of LOCAL_WRITE then? There are no local
RDMA writes as far as
On Mon, Mar 11, 2013 at 11:08 AM, Mike Christie micha...@cs.wisc.edu wrote:
If at the same time a SAS fabric event goes to the HBA, what can
happen is the following:
- mpt2sas calls _scsih_block_io_all_device() -
scsi_internal_device_block(sdev)
(In response to some HBA
On Thu, Mar 7, 2013 at 10:02 PM, Nicholas A. Bellinger
n...@linux-iscsi.org wrote:
Or and I discussed this point in the last status call, and given what
the initiator did originally (eg: export iscsi_transport) he asked to
keep it under drivers/infiniband/ulp/isert/ with the extra include bits.
On Thu, Mar 7, 2013 at 10:02 PM, Nicholas A. Bellinger
n...@linux-iscsi.org wrote:
Or and I discussed this point in the last status call, and given what
the initiator did originally (eg: export iscsi_transport) he asked to
keep it under drivers/infiniband/ulp/isert/ with the extra include bits.
On Thu, Mar 7, 2013 at 5:45 PM, Nicholas A. Bellinger
n...@linux-iscsi.org wrote:
+EXPORT_SYMBOL(iscsit_get_transport);
It's not clear to me why this needs to be exported. Who would use it
outside the core iscsi target module?
--
To unsubscribe from this list: send the line unsubscribe
On Thu, Mar 7, 2013 at 5:45 PM, Nicholas A. Bellinger
n...@linux-iscsi.org wrote:
+EXPORT_SYMBOL(iscsit_get_transport);
It's not clear to me why this needs to be exported. Who would use it
outside the core iscsi target module?
--
To unsubscribe from this list: send the line unsubscribe
On Wed, Feb 27, 2013 at 11:11 AM, Or Gerlitz or.gerl...@gmail.com wrote:
You can also take a look on the upstream trees for libibverbs and
libmlx4 maintained by Roland which have a debian dir, which you
probably can re-use for the managment libraries and opensm, here are
the gitweb pointers,
Bolle (2):
RDMA/cxgb4: "cookie" can stay in host endianness
IB/mlx4: Fix compiler warning about uninitialized 'vlan' variable
Roland Dreier (3):
IB/mlx4: Convert is_xxx variables in build_mlx_header() to bool
IPoIB: Free ipoib neigh on path record failure so path r
Bolle (2):
RDMA/cxgb4: cookie can stay in host endianness
IB/mlx4: Fix compiler warning about uninitialized 'vlan' variable
Roland Dreier (3):
IB/mlx4: Convert is_xxx variables in build_mlx_header() to bool
IPoIB: Free ipoib neigh on path record failure so path rec queries
On Tue, Feb 26, 2013 at 2:32 AM, Or Gerlitz ogerl...@mellanox.com wrote:
Looking on the flow of sending ARP probes, I see that in unicast_arp_send,
if there's no AH for the path, a path query is initiated,
if (path-ah) {
ipoib_dbg(priv, Send unicast ARP to %04x\n,
Bolle (2):
RDMA/cxgb4: cookie can stay in host endianness
IB/mlx4: Fix compiler warning about uninitialized 'vlan' variable
Roland Dreier (3):
IB/mlx4: Convert is_xxx variables in build_mlx_header() to bool
IPoIB: Free ipoib neigh on path record failure so path rec queries
Nice! queued up for my next pull request, thanks.
--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Feb 26, 2013 at 11:22 PM, Ilya Nelkenbaum
il...@dev.mellanox.co.il wrote:
Does the libibumad that is installed in Debian synchronized with the upstream
version?
I'm not sure what you're asking. At appropriate times, new upstream
versions of software are added to various releases of
On Mon, Feb 25, 2013 at 8:54 AM, Roland Dreier wrote:
> I'm finally noticing that this is in the build_mlx_header() function,
> which is pretty much a slow path. Certainly another compare isn't
> going to change performance given all the other stuff we do there.
>
> Let me look
On Sun, Feb 24, 2013 at 4:34 AM, Jack Morgenstein
wrote:
> However, this approach does add the line below to processing for an IB port
> (ETH/RoCE port stays same, more or less).
> Processing time is therefore increased (at least on the IB side) relative to
> just living with the warning.
>
>
On Sun, Feb 24, 2013 at 4:34 AM, Jack Morgenstein
ja...@dev.mellanox.co.il wrote:
However, this approach does add the line below to processing for an IB port
(ETH/RoCE port stays same, more or less).
Processing time is therefore increased (at least on the IB side) relative to
just living
On Mon, Feb 25, 2013 at 8:54 AM, Roland Dreier rol...@kernel.org wrote:
I'm finally noticing that this is in the build_mlx_header() function,
which is pretty much a slow path. Certainly another compare isn't
going to change performance given all the other stuff we do there.
Let me look
On Sun, Feb 24, 2013 at 4:34 AM, Jack Morgenstein
ja...@dev.mellanox.co.il wrote:
However, this approach does add the line below to processing for an IB port
(ETH/RoCE port stays same, more or less).
Processing time is therefore increased (at least on the IB side) relative to
just living
On Mon, Feb 25, 2013 at 8:54 AM, Roland Dreier rol...@kernel.org wrote:
I'm finally noticing that this is in the build_mlx_header() function,
which is pretty much a slow path. Certainly another compare isn't
going to change performance given all the other stuff we do there.
Let me look
Thanks, applied.
--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
All look good, applied for 3.9, thanks.
--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Feb 22, 2013 at 4:17 AM, Or Gerlitz or.gerl...@gmail.com wrote:
I see now that you've picked five of the patches from this series into
for-next, anything which needs clarification or fixup in the other
five patches?
No, I think the patches are probably fine. I just wanted to get the
OK, I went through the MW patches and they all look fine, so they're
in my for-next now.
--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Feb 22, 2013 at 8:14 AM, Narayan Desai narayan.de...@gmail.com wrote:
Ah, sorry. I was speaking imprecisely; while the a bunch of the ib
libraries are pretty well maintained in debian/ubuntu, the management
tools are ancient. (this is why i built my PPA for ubuntu)
I think there would
From: Roland Dreier rol...@purestorage.com
If a SCSI device's old state is already SDEV_RUNNING and we're moving
to the same SDEV_RUNNING state, still wake the blockdev queue in
scsi_internal_device_unblock(). This fixes a case where we silently
hang SCSI commands forever during device discovery
On Thu, Feb 21, 2013 at 12:53 PM, Narayan Desai narayan.de...@gmail.com wrote:
Also, are you planning to try getting these pushed upstream into debian?
thanks.
libibumad is already packaged in Debian:
http://packages.debian.org/search?keywords=libibumad
I don't think having this (different)
Public bug reported:
I use my laptop in two setups: by itself with its 1440x900 built-in
panel, and docked/closed using an external 2560x1440 monitor only. (So
only one active screen in both cases) I use multiple unity workspaces,
with (for example) a maximized browser window in the top right
thanks, all look simple enough, applied.
--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sat, Feb 9, 2013 at 1:23 AM, Chris Boot bo...@bootc.net wrote:
+ case TCM_PARAMETER_LIST_LENGTH_ERROR:
+ /* CURRENT ERROR */
+ buffer[0] = 0x70;
+ buffer[SPC_ADD_SENSE_LEN_OFFSET] = 10;
+ /* ILLEGAL REQUEST */
+
From: Roland Dreier rol...@purestorage.com
We're supposed to return LOGICAL BLOCK ADDRESS OUT OF RANGE, not
INVALID FIELD IN CDB.
Signed-off-by: Roland Dreier rol...@purestorage.com
---
drivers/target/target_core_sbc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers
From: Roland Dreier rol...@purestorage.com
SBC-3 (revision 35) says:
The PARAMETER LIST LENGTH field specifies the length in bytes of the
UNMAP parameter list that is available to be transferred from the
Data-Out Buffer. If the parameter list length is greater than zero
and less
From: Roland Dreier rol...@purestorage.com
An empty parameter list (length == 0) is not an error, so succeed MODE
SELECT in this case. If the parameter list length is too small,
return the correct sense code of PARAMETER LIST LENGTH ERROR.
Signed-off-by: Roland Dreier rol...@purestorage.com
context behaviour
Roland Dreier (1):
Merge branches 'ipoib', 'mlx4' and 'qib' into for-next
Shlomo Pongratz (1):
IPoIB: Fix crash due to skb double destruct
drivers/infiniband/hw/qib/qib_qp.c| 11 +++
drivers/infiniband/ulp/ipoib/ipoib_cm.c | 6 +++---
drivers
context behaviour
Roland Dreier (1):
Merge branches 'ipoib', 'mlx4' and 'qib' into for-next
Shlomo Pongratz (1):
IPoIB: Fix crash due to skb double destruct
drivers/infiniband/hw/qib/qib_qp.c| 11 +++
drivers/infiniband/ulp/ipoib/ipoib_cm.c | 6 +++---
drivers
context behaviour
Roland Dreier (1):
Merge branches 'ipoib', 'mlx4' and 'qib' into for-next
Shlomo Pongratz (1):
IPoIB: Fix crash due to skb double destruct
drivers/infiniband/hw/qib/qib_qp.c| 11 +++
drivers/infiniband/ulp/ipoib/ipoib_cm.c | 6 +++---
drivers
Thanks, applied (although I wish you had included the excellent
analysis from your other email in the changelog here).
--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body of a message to majord...@vger.kernel.org
More majordomo info at
On Tue, Jan 29, 2013 at 12:14 AM, Hannes Reinecke h...@suse.de wrote:
I would like to discuss at LSF the possible implementations
and handling mechanism for this kind of failure scenarios.
I'd be interested in that discussion. With my Pure hat on, our array
can generate these thin provisioning
On Mon, Jan 21, 2013 at 3:18 AM, Hannes Reinecke h...@suse.de wrote:
The current error handler still uses a 'target reset' (or, rather, bus
reset) strategy, although the respective TMF has been obsoleted since
SAM-3. SAM-5 defines an I_T nexus loss event instead, which so far has only
been
On Wed, Jan 30, 2013 at 1:44 PM, Jason Gunthorpe
jguntho...@obsidianresearch.com wrote:
So instead of virt_to_phys you should use dma_addr??
No, you clearly can't use the bus address. That has no relationship to
the CPU view, even in cases as common as VT-d on x86.
--
To unsubscribe from this
qlvnictools (0.0.1-3) experimental; urgency=low
* Remove build dependency on libibcommon, tighten versioned dependency
on libibumad-dev to avoid FTBFS when old versions are used.
* Update to Standards-Version: 3.9.4 (no changes needed).
* Add recommended build-arch and build-indep
I hit this bug by connecting a USB headset and trying to select its
microphone as my sound input device in the sound settings dialog. I
tried Conor's suggestion in comment #6 and indeed that edit to the
config file fixes things for me -- I am able to select the USB headset
microphone and sound
FWIW, my pactl list output is the following. The Plantronics device
is the USB headset I mentioned.
Module #0
Name: module-device-restore
Argument:
Usage counter: n/a
Properties:
module.author = Lennart Poettering
I hit this bug by connecting a USB headset and trying to select its
microphone as my sound input device in the sound settings dialog. I
tried Conor's suggestion in comment #6 and indeed that edit to the
config file fixes things for me -- I am able to select the USB headset
microphone and sound
FWIW, my pactl list output is the following. The Plantronics device
is the USB headset I mentioned.
Module #0
Name: module-device-restore
Argument:
Usage counter: n/a
Properties:
module.author = Lennart Poettering
...@lists.alioth.debian.org
Changed-By: Roland Dreier r...@debian.org
Description:
qlvnictools - Tools for QLogic Virtual NICs
Changes:
qlvnictools (0.0.1-2) experimental; urgency=low
.
* 01-add-include-for-ntohll.patch: Add upstream include to fix FTBFS
due to missing declaration of ntohll
...@lists.alioth.debian.org
Changed-By: Roland Dreier r...@debian.org
Description:
ibsim-utils - InfiniBand fabric simulator utilities
libumad2sim0 - InfiniBand fabric simulator
Changes:
ibsim (0.5-3) experimental; urgency=low
.
* Add missing versioned build dependency on dpkg-dev.
Checksums
...@lists.alioth.debian.org
Changed-By: Roland Dreier r...@debian.org
Description:
ibsim-utils - InfiniBand fabric simulator utilities
libumad2sim0 - InfiniBand fabric simulator
Changes:
ibsim (0.5-4) experimental; urgency=low
.
* Tighten build depends on libibumad-dev and libibmad-dev
...@lists.alioth.debian.org
Changed-By: Roland Dreier r...@debian.org
Description:
qlvnictools - Tools for QLogic Virtual NICs
Changes:
qlvnictools (0.0.1-3) experimental; urgency=low
.
* Remove build dependency on libibcommon, tighten versioned dependency
on libibumad-dev to avoid FTBFS when
Public bug reported:
Looks like a missing dependency or an incompatibility with new
devscripts:
$ requestsync
Traceback (most recent call last):
File /usr/bin/requestsync, line 36, in module
from ubuntutools.config import UDTConfig, ubu_email
File
Public bug reported:
Looks like a missing dependency or an incompatibility with new
devscripts:
$ requestsync
Traceback (most recent call last):
File /usr/bin/requestsync, line 36, in module
from ubuntutools.config import UDTConfig, ubu_email
File
On Wed, Jan 9, 2013 at 10:27 PM, CAI Qian caiq...@redhat.com wrote:
Hi, any ACK/NAK here?
I think it could go either way. It's a pretty safe fix for a crash,
but the driver and the crash are both very obscure. So I don't think
it really matters much either way.
--
To unsubscribe from this
On Wed, Jan 9, 2013 at 10:27 PM, CAI Qian caiq...@redhat.com wrote:
any ACK/NACK here too?
Again, I don't think this matters much. But it's a trivial fix, so I
would just put it in stable.
--
To unsubscribe from this list: send the line unsubscribe stable in
the body of a message to
On Mon, Jan 7, 2013 at 5:11 AM, Vipul Pandya vi...@chelsio.com wrote:
This patch series fixes critical bugs for RDMA/cxgb4. It fixes bugs in
following
areas:
- Aborts connection in error scenarios
- Logs only critical errors
- Holds the reference of the QP untill TID is released
- Avoids
On Wed, Dec 26, 2012 at 1:33 PM, Ben Hutchings b...@decadent.org.uk wrote:
if (!(cmd-cmd_flags ICF_OOO_CMDSN) !cmd-immediate_cmd
- (cmd-cmd_sn = conn-sess-exp_cmd_sn)) {
+ iscsi_sna_gte(cmd-stat_sn, conn-sess-exp_cmd_sn)) {
From: Roland Dreier rol...@purestorage.com
Commit 64c13330a389 (iscsi-target: Fix bug in handling of ExpStatSN
ACK during u32 wrap-around) introduced a bug where we compare the
wrong SN against our ExpCmdSN.
Reported-by: Ben Hutchings b...@decadent.org.uk
Signed-off-by: Roland Dreier rol
From: Roland Dreier rol...@purestorage.com
Hi Nic,
A few fixes for TMR handling (fix crashes when a backend is really
slow, fix a reference leak if we get a TMR for a non-existent LUN) and
a couple of trivial cleanups in related code.
Roland Dreier (5):
target: Don't let abort handling free
From: Roland Dreier rol...@purestorage.com
When transport_lookup_tmr_lun() fails and we return a task management
response from target_complete_tmr_failure(), we need to call
transport_cmd_check_stop_to_fabric() to release the last ref to the
cmd after calling se_tfo-queue_tm_rsp(), or else we
From: Roland Dreier rol...@purestorage.com
The following sequence happens for write commands (or any other
commands with a data out phase):
- The transport calls target_submit_cmd(), which sets CMD_T_ACTIVE in
cmd-transport_state and sets cmd-t_state to TRANSPORT_NEW_CMD.
- Things go
From: Roland Dreier rol...@purestorage.com
Signed-off-by: Roland Dreier rol...@purestorage.com
---
include/target/target_core_base.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/include/target/target_core_base.h
b/include/target/target_core_base.h
index 7cae236..02ed017 100644
From: Roland Dreier rol...@purestorage.com
We do the same thing no matter which way the test goes, so just remove
the test and do what we're going to do.
The debug messages printed the wrong value of CMD_T_ACTIVE and don't
seem particularly useful, remove them too.
Signed-off-by: Roland Dreier
On Sat, Dec 29, 2012 at 12:08 PM, Joe Perches wrote:
> Sylvan Munaut did something similar
> https://lkml.org/lkml/2012/12/5/168
Missed that and duplicated the debugging :(
Sorry Sylvain.
I guess my patch may be preferable, since I happened to use the snprintf()
method that you suggest -- all
On Sat, Dec 29, 2012 at 9:56 AM, Greg Kroah-Hartman
wrote:
> Nice work. When did you start seeing this problem, 3.6 or so? I ask as
> it's probably something that should go to stable as well if so.
We happened to see it when we rebased to the 3.6 kernel, but as far as I
can see, the bug has
On Sat, Dec 29, 2012 at 9:56 AM, Greg Kroah-Hartman
gre...@linuxfoundation.org wrote:
Nice work. When did you start seeing this problem, 3.6 or so? I ask as
it's probably something that should go to stable as well if so.
We happened to see it when we rebased to the 3.6 kernel, but as far as I
On Sat, Dec 29, 2012 at 12:08 PM, Joe Perches j...@perches.com wrote:
Sylvan Munaut did something similar
https://lkml.org/lkml/2012/12/5/168
Missed that and duplicated the debugging :(
Sorry Sylvain.
I guess my patch may be preferable, since I happened to use the snprintf()
method that you
From: Roland Dreier
print_prefix() passes a NULL buf to print_time() to get the length of
the time prefix; when printk times are enabled, the current code just
returns the constant 15, which matches the format "[%5lu.%06lu] " used
to print the time value. However, this is obviously
From: Roland Dreier rol...@purestorage.com
print_prefix() passes a NULL buf to print_time() to get the length of
the time prefix; when printk times are enabled, the current code just
returns the constant 15, which matches the format [%5lu.%06lu] used
to print the time value. However
steering wrapper
Jack Morgenstein (2):
mlx4_core: Adjustments to Flow Steering activation logic for SR-IOV
mlx4_core: Allow choosing flow steering mode
Roland Dreier (2):
IPoIB: Call skb_dst_drop() once skb is enqueued for sending
Merge branches 'cxgb4', 'ipoib' and 'mlx4
steering wrapper
Jack Morgenstein (2):
mlx4_core: Adjustments to Flow Steering activation logic for SR-IOV
mlx4_core: Allow choosing flow steering mode
Roland Dreier (2):
IPoIB: Call skb_dst_drop() once skb is enqueued for sending
Merge branches 'cxgb4', 'ipoib' and 'mlx4
steering wrapper
Jack Morgenstein (2):
mlx4_core: Adjustments to Flow Steering activation logic for SR-IOV
mlx4_core: Allow choosing flow steering mode
Roland Dreier (2):
IPoIB: Call skb_dst_drop() once skb is enqueued for sending
Merge branches 'cxgb4', 'ipoib' and 'mlx4
On Wed, Dec 19, 2012 at 2:44 PM, Stephen Rothwell wrote:
> Hi all,
>
> After merging the infiniband tree, today's linux-next build (x86_64_
> allmodconfig) failed like this:
>
> In file included from drivers/scsi/csiostor/csio_wr.h:42:0,
> from
501 - 600 of 10769 matches
Mail list logo
