> Could you also
>
> git tag v1.0.8 78e67b72a15380e93273951b63ea85f1129d5946
>
> on librdmacm?
done - also added a couple of other missing version tags
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majord...@vger.kernel.org
More majordomo i
On Thu, Oct 07, 2010 at 08:11:07AM -0700, Hefty, Sean wrote:
> > All the tags are also missing from:
> >
> > git://git.openfabrics.org/~shefty/librdmacm.git
> >
> > git push --tags ??
>
> thanks - done
Could you also
git tag v1.0.8 78e67b72a15380e93273951b63ea85f1129d5946
on librdmacm?
Thank
Otherwise running autogen.sh with a new version of autotools and then
building on a system with an older version tends to explode.
Unfortunately this is sometimes necessary since the new version is
required by the package.
This is how GNU envisions this mess works at least..
Signed-off-by: Jason
Otherwise running autogen.sh with a new version of autotools and then
building on a system with an older version tends to explode.
Unfortunately this is sometimes necessary since the new version is
required by the package.
This is how GNU envisions this mess works at least..
Signed-off-by: Jason
Otherwise running autogen.sh with a new version of autotools and then
building on a system with an older version tends to explode.
Unfortunately this is sometimes necessary since the new version is
required by the package.
This is how GNU envisions this mess works at least..
Signed-off-by: Jason
Applied, thanks!
>Allow DAPL out of band connection models to use ibacm to obtain
>path record data. This will enable support for a wider range of
>topologies, where the SL is required from the SA to prevent
>deadlock.
>
>DAPL will obtain path record data using rdma_getaddrinfo, provided
>that IB
> > > http://www.mail-archive.com/gene...@lists.openfabrics.org/msg14919.html
>
> This patches doesn't appear to be there. I honestly don't remember this
> patch at this point. I will take a look at it.
I manually added this patch based on the one provided in the link and pushed
those changes
On Thu, Oct 7, 2010 at 6:54 PM, Roland Dreier wrote:
> Dave Dillow has been involved with both kernel development and SRP for
> a long time, and I trust Dave's technical judgement and good taste
> about the SRP code. Dave has graciously agreed to serve as a
> submaintainer for the SRP initiator,
On Thu, Oct 07, 2010 at 10:16:49AM -0600, Jason Gunthorpe wrote:
> On Thu, Oct 07, 2010 at 09:16:10AM +0200, Dan Carpenter wrote:
> > If we don't limit cmd.ne then the multiplications can overflow. This
> > will allocate a small amount of RAM successfully for the "resp" and
> > "wc" buffers. The
Dave Dillow has been involved with both kernel development and SRP for
a long time, and I trust Dave's technical judgement and good taste
about the SRP code. Dave has graciously agreed to serve as a
submaintainer for the SRP initiator, which should mean that SRP
patches will get more focus and als
On Thu, Oct 07, 2010 at 08:47:18AM -0700, Jeff Becker wrote:
> It would be great if developers could move their git repo's to the new
> server so OFA can stop using (and paying) for the old server. Vlad sent
> out a note about this earlier.
I hate to say it, but could you just rsync everything ov
On Thu, Oct 07, 2010 at 09:16:10AM +0200, Dan Carpenter wrote:
> If we don't limit cmd.ne then the multiplications can overflow. This
> will allocate a small amount of RAM successfully for the "resp" and
> "wc" buffers. The heap will get corrupted when we call ib_poll_cq().
I think you could cap
On 10/06/10 19:05, Jason Gunthorpe wrote:
> On Wed, Oct 06, 2010 at 04:37:33PM -0700, Jeff Becker wrote:
>> On 10/06/10 16:32, Josh England wrote:
>>> Yeah I tried that. It gives me:
>>> fatal: The remote end hung up unexpectedly
>> You're right. Onsumaye folks - can you see what's wrong with t
Hi Jason.
On 10/06/10 19:33, Jason Gunthorpe wrote:
> Hey Sasha,
>
> Can you tell me where the latest git repository for OpenSM is these
> days? There doesn't seem to be anything recent on the OFA server,
> ie
>
> git://git.openfabrics.org/~sashak/management.git
>
> Is quite old.
Yes. The proble
> All the tags are also missing from:
>
> git://git.openfabrics.org/~shefty/librdmacm.git
>
> git push --tags ??
thanks - done
> > ls-remote --heads git://git.openfabrics.org/~shefty/libibcm.git: command
> returned error: 128
I just moved over my git trees this week. This one got skipped, but
David Dillow wrote on 10/06/2010 09:31:44 PM:
> On Wed, 2010-10-06 at 12:37 -0600, Jason Gunthorpe wrote:
> > On Wed, Oct 06, 2010 at 02:22:55PM -0400, David Dillow wrote:
> > > On Wed, 2010-10-06 at 11:25 -0600, Jason Gunthorpe wrote:
> > > > On Wed, Oct 06, 2010 at 02:52:46PM +0200, Bernard M
Fix the limit of max fast regisreation WRs that can be posted to CX to match
hardware capabilities.
Signed-off-by: Eli Cohen
---
drivers/infiniband/hw/mlx4/main.c |2 +-
drivers/infiniband/hw/mlx4/mr.c |2 +-
include/linux/mlx4/device.h |4
3 files changed, 6 insertions(
Eli Cohen wrote:
> We have successfully tested MPI, SDP, RDS, and native Verbs applications over
> IBoE.
I came across your ofed commit e5414cccaa13e6dd80d8d6fc3dafe95355facdef "sdp:
module parameter
to disable SDP over ROCEE" and wasn't sure what's behind it, can you clarify
that?
Or.
--
To
On Thu, Oct 07, 2010 at 01:21:36PM +0200, Or Gerlitz wrote:
> I would implement it for regular pages and drop a note in the
> libibverbs man page that if huge pages are used (well, the huge
> pages patch set isn't fully merged, maybe its about time to make
> this happen...) then the actual limit is
Eli Cohen wrote:
If you create a MR in kernel, it covers the entire address space and
the HCA does not pose any limit since you do not consume MTTs. And if
you use MTTs then the page size is a parameter in this calculation -
huge page, regular page etc.
I agree that the kernel case is not of la
On Thu, Oct 07, 2010 at 11:40:02AM +0200, Or Gerlitz wrote:
> Roland Dreier wrote:
> >> max_mr_size returned by calling ibv_devinfo is 0x. Does
> >> this mean the size is unlimited?
> > It means that the query function might be returning bad data. What adapter
> > is it?
>
> Yep
Roland Dreier wrote:
>> max_mr_size returned by calling ibv_devinfo is 0x. Does this
>> mean the size is unlimited?
> It means that the query function might be returning bad data. What adapter
> is it?
Yep, mlx4_ib_query_device does props->max_mr_size = ~0ull ...
Jack, what wo
linux-rdma-ow...@vger.kernel.org wrote on 10/06/2010 07:57:29 PM:
> On Tue, Oct 5, 2010 at 8:55 AM, Bernard Metzler
wrote:
> >
> > [ ... ]
> > +int
> > +siw_qp_modify(struct siw_qp *qp, struct siw_qp_attrs *attrs,
> > + enum siw_qp_attr_mask mask)
> > +{
> > [ ... ]
> > +
If we don't limit cmd.ne then the multiplications can overflow. This
will allocate a small amount of RAM successfully for the "resp" and
"wc" buffers. The heap will get corrupted when we call ib_poll_cq().
Documentation/infiniband/user_verbs.txt suggests this function is meant
for unprivileged a
24 matches
Mail list logo
