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 agord...@redhat.com
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: e1000-de...@lists.sourceforge.net
Cc:
%pa format already prints in hexadecimal format, so remove the '0x' annotation
to avoid a double '0x0x' pattern.
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
drivers/infiniband/hw/usnic/usnic_uiom.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
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:
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 from Feb 5,
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
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 rol...@kernel.org
Cc: Sean Hefty
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 agord...@redhat.com
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 agord...@redhat.com
Cc:
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 in
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
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
From: CQ Tang cq.t...@intel.com
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
Subject: [PATCH v2] IB/qib: Change SDMA progression mode depending on
single- or mulit-rail.
From: CQ Tang cq.t...@intel.com
I got the author wrong on the original.
Mike
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
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? it
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 sa...@mellanox.com
---
drivers/target/target_core_transport.c | 12
1 files changed, 12 insertions(+),
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 sa...@mellanox.com
---
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:
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 patchset
From: Alexander Gordeev agord...@redhat.com
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
From: Jan Kara j...@suse.cz
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
From: Jan Kara j...@suse.cz
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
Ping.
Any info on this?
Regards,
Sébastien.
On Thu, 13 Feb 2014 09:58:35 +0100
Sébastien Dugué sebastien.du...@bull.net 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
24 matches
Mail list logo
