Changes in V3:
Fixed missed protocol argument when calling find_mgm in mlx4_multicast_detach
function.
Newest firmware does a IB/ETH protocol distiction.
There are two bits in members_count field of multicast group table
that store this info and its meaning : 0 - Infiniband, 1 - Ethernet.
While
On 12/02/2010 12:59 AM, Tom Tucker wrote:
Spelic,
I have seen this problem before, but have not been able to reliably
reproduce it. When I saw the problem, there were no transport errors
and it appeared as if the I/O had actually completed, but that the
waiter was not being awoken. I was not
On Thu, Dec 2, 2010 at 2:19 AM, Or Gerlitz ogerl...@voltaire.com wrote:
Alan, kernel patches posted to this mailing list are against the mainline
(upstream) Linux kernel
Thanks for pointing me to the correct kernel.
I found Tom's patch from July, but was unsure if that was the patch in
Adding Dave Chinner to the cc list, since he's both an XFS guru as well
as being very familiar with NFS and RDMA...
Dave, if you read below, it seems there is some strange behavior
exporting XFS with NFS/RDMA.
- R.
On 12/02/2010 12:59 AM, Tom Tucker wrote:
Spelic,
I have seen this
Linus, please pull from
master.kernel.org:/pub/scm/linux/kernel/git/roland/infiniband.git for-linus
This tree is also available from kernel.org mirrors at:
git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband.git
for-linus
Just a few small things here:
- Fix a minor leak
This patch series adds the ability for a user-mode program to register
mmapped memory. The capability was developed to support the sharing of
device memory, for example PCI-E static/flash ram devices, on the network
with RDMA. It is also useful for sharing kernel resident data with distributed
Hello all
please be aware that the file oversize bug is reproducible also
without infiniband, with just nfs over ethernet over xfs over ramdisk
(but it doesn't hang, so it's a different bug than the one I posted here
at the RDMA mailing list)
I have posted another thread regarding the file
ib_response_mad classifies trap represses and BM sends w/ response as
attribute modifier
as well as strict responses (R bit in method set) as responses. Shouldn't
busy be
ignored for the trap repress case ?
Ugh. I know that was in this patch at one point; it must have gotten lost in
Personally I think the biggest issue is that I don't think the pfn to dma
address mapping logic is portable.
On 12/2/10 1:35 PM, Ralph Campbell wrote:
I understand the need for something like this patch since
the GPU folks would also like to mmap memory (although the
memory is marked as
Fixed the loss of the trap repress handling, which must have gotten lost
somewhere between May and now...
Hal - your formatting nit, when I looked at the patch file, I see the correct
spacing around the '' in the if statement.
---
This patch provides a new module parameter for ib_mad that
On Thu, 2010-12-02 at 12:24 -0800, Tom Tucker wrote:
Personally I think the biggest issue is that I don't think the pfn to dma
address mapping logic is portable.
Perhaps. That is why the core Linux VM folks should be
involved.
On 12/2/10 1:35 PM, Ralph Campbell wrote:
I understand the need
11 matches
Mail list logo
