Ping.
Any info on this?
Regards,
Sébastien.
On Thu, 13 Feb 2014 09:58:35 +0100
Sébastien Dugué wrote:
> Hi,
>
> I'm currently running tests with a Connect-IB board under the current
> OFED-3.12 of the day:
>
> - compat: 407b205 compat: Add kthread support for kernels <= 2.
From: Jan Kara
commit 603e7729920e42b3c2f4dbfab9eef4878cb6e8fa upstream.
qib_user_sdma_queue_pkts() gets called with mmap_sem held for
writing. Except for get_user_pages() deep down in
qib_user_sdma_pin_pages() we don't seem to need mmap_sem at all. Even
more interestingly the function qib_user
From: Jan Kara
commit 603e7729920e42b3c2f4dbfab9eef4878cb6e8fa upstream.
qib_user_sdma_queue_pkts() gets called with mmap_sem held for
writing. Except for get_user_pages() deep down in
qib_user_sdma_pin_pages() we don't seem to need mmap_sem at all. Even
more interestingly the function qib_user
From: Alexander Gordeev
Date: Tue, 18 Feb 2014 11:07:52 +0100
> As result of deprecation of MSI-X/MSI enablement functions
> pci_enable_msix() and pci_enable_msi_block() all drivers
> using these two interfaces need to be updated to use the
> new pci_enable_msi_range() and pci_enable_msix_range()
On Sun, 2014-02-16 at 19:38 +0200, Sagi Grimberg wrote:
> Hey Nic and folks,
>
> This patchset introduces target side T10-PI offload support over
> RDMA. Currently the implementation is for iSER transport but can
> be easily extended to SRP (or FCoE in the future).
>
> Should mention that this pa
On Sun, 2014-02-16 at 19:38 +0200, Sagi Grimberg wrote:
> For transports which use generic new command these
> buffers have yet to be allocated. Instead check afterwards
> if command required prot buffers but none are provided.
>
> Also this way, target may support protection information
> against
On Sun, 2014-02-16 at 19:38 +0200, Sagi Grimberg wrote:
> SBC-3 mandates the protection checks that must be
> performed in the rdprotect/wrprotect field. Use them.
> According to backstore device pi_attributes and
> cdb rdprotect/wrprotect.
>
> Signed-off-by: Sagi Grimberg
> ---
> drivers/target
On Sun, 2014-02-16 at 19:38 +0200, Sagi Grimberg wrote:
> In case protection information is involved, allocate
> protection SG-list for transport.
>
> Signed-off-by: Sagi Grimberg
> ---
> drivers/target/target_core_transport.c | 12
> 1 files changed, 12 insertions(+), 0 deletions
On 02/18/14 18:25, Sagi Grimberg wrote:
> Regarding the FMR unmap crash, I experienced it when running our
> distro-backported MLNX_OFED
> and hadn't got a chance to see if it reproduces in upstream yet. Thanks
> for confirming this reproduces here as well.
> Bart, Are you familiar with this issue?
On 2/18/2014 7:05 PM, Bart Van Assche wrote:
On 02/18/14 17:47, Sebastian Riemer wrote:
I've also noticed the added target locking around target->free_tx
handling in srp_rport_reconnect(). There are cases e.g. in
srp_queuecommand() where holding the rport mutex isn't enough to protect
it. So for
> Subject: [PATCH v2] IB/qib: Change SDMA progression mode depending on
> single- or mulit-rail.
>
> From: CQ Tang
I got the author wrong on the original.
Mike
From: CQ Tang
Improve performance by changing the behavour of the driver when all SDMA
descriptors are in use, and the processes adding new descriptors are
single- or multi-rail.
For single-rail processes, the driver will block the call and finish
posting all SDMA descriptors onto the hardware q
On 02/18/14 17:47, Sebastian Riemer wrote:
> I've also noticed the added target locking around target->free_tx
> handling in srp_rport_reconnect(). There are cases e.g. in
> srp_queuecommand() where holding the rport mutex isn't enough to protect
> it. So for me this looks right.
>
> Then, in srp_
Hi Sagi,
is that "/mswg/git/mlnx_ofed/mlnx-ofed-2.x-kernel.git" tree from the
MLNX_OFED public by any chance?
There are fixes included relevant for the mainline. Would be strange if
I would send the patches as somebody at Mellanox discovered and fixed
the issues.
I've hit a kernel panic today du
> Subject: [PATCH 2/2] qib: Use pci_enable_msix_range() instead of
> pci_enable_msix()
>
We are testing this now.
I suggest a subject/summary adding the IB/:
IB/qib: Use pci_enable_msix_range() instead of pci_enable_msix()
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma"
As result of deprecation of MSI-X/MSI enablement functions
pci_enable_msix() and pci_enable_msi_block() all drivers
using these two interfaces need to be updated to use the
new pci_enable_msi_range() and pci_enable_msix_range()
interfaces.
Signed-off-by: Alexander Gordeev
Cc: Mike Marciniszyn
Cc
As result of deprecation of MSI-X/MSI enablement functions
pci_enable_msix() and pci_enable_msi_block() all drivers
using these two interfaces need to be updated to use the
new pci_enable_msi_range() and pci_enable_msix_range()
interfaces.
Cc: Roland Dreier
Cc: Sean Hefty
Cc: Hal Rosenstock
Cc:
As result of deprecation of MSI-X/MSI enablement functions
pci_enable_msix() and pci_enable_msi_block() all drivers
using these two interfaces need to be updated to use the
new pci_enable_msi_range() and pci_enable_msix_range()
interfaces.
Signed-off-by: Alexander Gordeev
Cc: Roland Dreier
Cc: S
Ha ha. Take another look. That's what I was just explaining about! :) On
line 1743 when curr_master is non-NULL then Smatch doesn't complain
because it understands about the relationship between curr_master and
curr_netdev. But here it is complaining about line 1749 where
curr_master is NULL so
On Tue, Feb 18, 2014 at 04:13:28PM +0200, Moni Shoua wrote:
> On 2/17/2014 1:52 PM, Dan Carpenter wrote:
> >Hello Moni Shoua,
> >
> >This is a semi-automatic email about new static checker warnings.
> >
> >The patch ad4885d279b6: "IB/mlx4: Build the port IBoE GID table
> >properly under bonding" fr
On 2/17/2014 1:52 PM, Dan Carpenter wrote:
Hello Moni Shoua,
This is a semi-automatic email about new static checker warnings.
The patch ad4885d279b6: "IB/mlx4: Build the port IBoE GID table
properly under bonding" from Feb 5, 2014, leads to the following
Smatch complaint:
drivers/infiniband/h
%pa format already prints in hexadecimal format, so remove the '0x' annotation
to avoid a double '0x0x' pattern.
Signed-off-by: Fabio Estevam
---
drivers/infiniband/hw/usnic/usnic_uiom.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/infiniband/hw/usnic/usnic_uiom.c
As result of deprecation of MSI-X/MSI enablement functions
pci_enable_msix() and pci_enable_msi_block() all drivers
using these two interfaces need to be updated to use the
new pci_enable_msi_range() and pci_enable_msix_range()
interfaces.
Cc: e1000-de...@lists.sourceforge.net
Cc: linux-dri...@qlo
As result of deprecation of MSI-X/MSI enablement functions
pci_enable_msix() and pci_enable_msi_block() all drivers
using these two interfaces need to be updated to use the
new pci_enable_msi_range() and pci_enable_msix_range()
interfaces.
Signed-off-by: Alexander Gordeev
Cc: Eli Cohen
Cc: linux
24 matches
Mail list logo