process works, we really don't
do releases all that often, and when we do, we can coordinate with
the maintainer.
--
Doug Ledford [EMAIL PROTECTED]
GPG KeyID: CFBFF194
http://people.redhat.com/dledford
Infiniband specific RPMs available at
http
that. It
doesn't solve package version comparison issues (aka, telling which
package is newer by the number), but it does help to solve
identification issues.
--
Doug Ledford [EMAIL PROTECTED]
GPG KeyID: CFBFF194
http://people.redhat.com/dledford
Infiniband specific RPMs
as they can get to production is fine with
me. The more issues they find while I'm still actually working on it
and making new revisions, the less issues they'll find after I stupidly
think I'm done.
--
Doug Ledford [EMAIL PROTECTED]
GPG KeyID: CFBFF194
http://people.redhat.com
to have rhel4.5 resp sles10 ppc64
in their daily build runs too.
Thanks
Nam
All of the kernel rpms from our U5 kernel have been on my web page in my
sig for *ages*. All you need to do is download the needed rpms and
install.
--
Doug Ledford [EMAIL PROTECTED]
GPG KeyID: CFBFF194
machine you are on and
installs it without involving the rpm database.
If someone cares enough about SLES/RHEL on ppc support in OFED,
she can upload the unpacked kernel devel headers for these distros
to ofa server and we'll use these to cross-compile OFED kernel bits,
nightly.
--
Doug Ledford
to download. Like Roland mentioned,
what I need is a release, not a distribution.
--
Doug Ledford [EMAIL PROTECTED]
GPG KeyID: CFBFF194
http://people.redhat.com/dledford
Infiniband specific RPMs available at
http://people.redhat.com/dledford/Infiniband
the build system and that's our release cycle.
Tziporet
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
--
Doug Ledford [EMAIL PROTECTED]
GPG KeyID: CFBFF194
http
actually available on the download server. While that works for the
rcs, they really need to have a tarball up there for final.
--
Doug Ledford [EMAIL PROTECTED]
GPG KeyID: CFBFF194
http://people.redhat.com/dledford
Infiniband specific RPMs available at
http
. As for the user space packages though, you guys
*are* the upstream. There's no one to merge upstream to and very little
oversight by anyone. So, it's entirely up to all of you just how much
your package seems to be a feature of the day change-athon versus a
solid, stable program.
--
Doug Ledford [EMAIL
the released tarball. So, I currently
have Roland's libibverbs, libmthca, and libmlx4.
--
Doug Ledford [EMAIL PROTECTED]
GPG KeyID: CFBFF194
http://people.redhat.com/dledford
Infiniband specific RPMs available at
http://people.redhat.com/dledford/Infiniband
that don't understand they are
private.
--
Doug Ledford [EMAIL PROTECTED]
GPG KeyID: CFBFF194
http://people.redhat.com/dledford
Infiniband specific RPMs available at
http://people.redhat.com/dledford/Infiniband
signature.asc
Description
as you'll just
overwrite the last entry when you exit the loop.
--
Doug Ledford [EMAIL PROTECTED]
GPG KeyID: CFBFF194
http://people.redhat.com/dledford
Infiniband specific RPMs available at
http://people.redhat.com/dledford/Infiniband
signature.asc
be referencing it, you'll be calculating it's address,
saving that calculated result into a valid spot in the array, and then
immediately overwriting that result with NULL. That's perfectly valid.
--
Doug Ledford [EMAIL PROTECTED]
GPG KeyID: CFBFF194
http://people.redhat.com
one. Does the
ofa_kernel tarball properly patch up for other people?
--
Doug Ledford dledf...@redhat.com
GPG KeyID: CFBFF194
http://people.redhat.com/dledford
Infiniband specific RPMs available at
http://people.redhat.com/dledford/Infiniband
On Sun, 2009-01-04 at 11:12 +0200, Vladimir Sokolovsky wrote:
Doug Ledford wrote:
So I downloaded the OFED-1.4.tar.gz file, unpacked it, went into
OFED-1.4/SRPMS and ran rpm2cpio on ofa_kernel-ofed-1.4.src.rpm, then ran
cpio on the output, then unpacked the ofa_kernel-1.4.tar.gz file. I
, or slated for inclusion, then I
don't include it in our kernel. Hence why xrc and rds support still
isn't in our products.
--
Doug Ledford dledf...@redhat.com
GPG KeyID: CFBFF194
http://people.redhat.com/dledford
Infiniband specific RPMs available at
http
@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
--
Doug Ledford dledf...@redhat.com
GPG KeyID: CFBFF194
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
--
Doug Ledford dledf...@redhat.com
GPG KeyID: CFBFF194
http://people.redhat.com/dledford
Infiniband specific RPMs available at
http://people.redhat.com
On Wed, 2009-01-28 at 09:38 -0600, Steve Wise wrote:
Doug Ledford wrote:
On Thu, 2009-01-22 at 16:07 -0600, Steve Wise wrote:
I understand the desire to not release new features in a point release,
but at the same time, these features are ready or near ready now. And
prior
upgrade doesn't trigger a firmware upgrade on the
file system which can render the previous kernel unusable.
--
Doug Ledford dledf...@redhat.com
GPG KeyID: CFBFF194
http://people.redhat.com/dledford
Infiniband specific RPMs available at
http
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
--
Doug Ledford dledf...@redhat.com
GPG KeyID: CFBFF194
http://people.redhat.com/dledford
InfiniBand Specific RPMS
http://people.redhat.com/dledford/Infiniband
PGP.sig
Description: This is a digitally signed message part
On Wed, 2009-06-03 at 19:14 +0200, Pawel Dziekonski wrote:
On Wed, 03 Jun 2009 at 10:14:07AM -0400, Doug Ledford wrote:
On Jun 3, 2009, at 3:39 AM, Pawel Dziekonski wrote:
On Tue, 02 Jun 2009 at 10:30:07PM +0300, Tziporet Koren wrote:
Main reasons to keep MPI in OFED:
- All participants
/mailman/listinfo/ewg
--
Doug Ledford dledf...@redhat.com
GPG KeyID: CFBFF194
http://people.redhat.com/dledford
Infiniband specific RPMs available at
http://people.redhat.com/dledford/Infiniband
signature.asc
Description: This is a digitally signed
.
You're right, API issues *can* be resolved even if the latest MPIs are
shipped with OFED. It's just that this hasn't been the case in the
past, and throwing everything in the same bucket is a strong incentive
not to worry about it in the future.
--
Doug Ledford dledf...@redhat.com
GPG
contrast to the rest of our entire operating
system where we isolate and target things that need fixed and only
things that need fixed.
--
Doug Ledford dledf...@redhat.com
GPG KeyID: CFBFF194
http://people.redhat.com/dledford
Infiniband specific RPMs available
the
case, then I would question whether that's decoupled from OFED, or just
not in the OFED tarball.
--
Doug Ledford dledf...@redhat.com
GPG KeyID: CFBFF194
http://people.redhat.com/dledford
Infiniband specific RPMs available at
http://people.redhat.com
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
- --
Doug Ledford dledf...@redhat.com
GPG KeyID: CFBFF194
http://people.redhat.com/dledford
Infiniband specific RPMs available at
http://people.redhat.com/dledford
requests larger than 128k (at least in this code path,
there may be others lurking too, I'll forward additional patches if I
find they are needed).
bz508902.patch
Description: Binary data
--
Doug Ledford dledf...@redhat.com
GPG KeyID: CFBFF194
http://people.redhat.com/dledford
InfiniBand
On Jul 23, 2009, at 4:20 AM, Jack Morgenstein wrote:
On Thursday 16 July 2009 21:08, Doug Ledford wrote:
On rhel4 and rhel5 machines, the kmalloc implementation does not
automatically forward kmalloc requests 128kb to __get_free_pages.
Please include this patch in all rhel4 and rhel5 backport
: on large allocations
forward to __g_f_p(). See include/linux/slub_def.h's definition of
kmalloc_large and kmalloc.
--
Doug Ledford dledf...@redhat.com
GPG KeyID: CFBFF194
http://people.redhat.com/dledford
InfiniBand Specific RPMS
http://people.redhat.com/dledford/Infiniband
.
--
Doug Ledford dledf...@redhat.com
GPG KeyID: CFBFF194
http://people.redhat.com/dledford
InfiniBand Specific RPMS
http://people.redhat.com/dledford/Infiniband
PGP.sig
Description: This is a digitally signed message part
___
ewg mailing list
ewg
.
--
Doug Ledford dledf...@redhat.com
GPG KeyID: CFBFF194
http://people.redhat.com/dledford
Infiniband specific RPMs available at
http://people.redhat.com/dledford/Infiniband
signature.asc
Description: OpenPGP digital signature
into the brick wall you ran
into before.
--
Doug Ledford dledf...@redhat.com
GPG KeyID: CFBFF194
http://people.redhat.com/dledford
Infiniband specific RPMs available at
http://people.redhat.com/dledford/Infiniband
signature.asc
Description: OpenPGP digital
and
minimize the threat. Smaller programs where you can inspect and
understand the program are more trustable than large complex programs.
This part is very true.
--
Doug Ledford dledf...@redhat.com
GPG KeyID: CFBFF194
http://people.redhat.com/dledford
Infiniband specific
it.
--
Doug Ledford dledf...@redhat.com
GPG KeyID: CFBFF194
http://people.redhat.com/dledford
Infiniband specific RPMs available at
http://people.redhat.com/dledford/Infiniband
signature.asc
Description: OpenPGP digital signature
will be used for easy installation of all packages in a
friendly manner
Yay!!! I'm all in favor.
--
Doug Ledford dledf...@redhat.com
GPG KeyID: 0E572FDD
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi
-example.c, the address for the FSF is incorrect). Just
an FYI for any companies whose legal teams are as strict as ours about
not redistributing code without a proper, legal license. I hope an
rds-tools-2.0.8 should be rolled soon to resolve the issue.
--
Doug Ledford dledf...@redhat.com
. There is very little impetus to maintain two
versions of software to make sockets based apps work on RDMA fabrics
when the relative gain of one over the other isn't that high and it has
legal encumbrances to negate the positive performance benefit.
--
Doug Ledford dledf...@redhat.com
GPG
from rhel6.4 where this is no longer an issue.
--
Doug Ledford dledf...@redhat.com
GPG KeyID: 0E572FDD
http://people.redhat.com/dledford
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin
;
--
Doug Ledford dledf...@redhat.com
GPG KeyID: 0E572FDD
signature.asc
Description: This is a digitally signed message part
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/mailman/listinfo/ewg
On 05/16/2016 12:36 PM, Steve Wise wrote:
>
>
>> -Original Message-----
>> From: Doug Ledford [mailto:dledf...@redhat.com]
>> Sent: Monday, May 16, 2016 11:27 AM
>> To: Steve Wise; ewg@lists.openfabrics.org
>> Subject: Re: libibverbs not compiling against
On 05/16/2016 12:09 PM, Steve Wise wrote:
> See: http://bugs.openfabrics.org/bugzilla/show_bug.cgi?id=2598
>
> Looks like some compilation problem against RHEL6.6. Who should own
> this? It is assigned to Doug Ledford, but I'm not sure he's the correct
> person?
I'm not, but
d in the least if backports to an EL6 kernel are
a simple no-go for current upstream code.
--
Doug Ledford <dledf...@redhat.com>
GPG KeyID: 0E572FDD
signature.asc
Description: OpenPGP digital signature
___
ewg mailing list
ewg@list
MA stack and out. I suspect this backport cycle may be worse than
those in the past. But I could be wrong...
--
Doug Ledford <dledf...@redhat.com>
GPG KeyID: 0E572FDD
signature.asc
Description: OpenPGP digital signature
_
On 5/4/2017 3:14 PM, Woodruff, Robert J wrote:
> Doug Ledford wrote,
>> The OFA has already learned their lesson once with XRC. I wonder
>> if they are getting ready to get hit with another lesson over this.
>> The issue is if the OFA ships an API and it isn't upstream, t
s here are those
> people running Xeon Phi with Mellanox HCAs who are being forced to
> use OFED, rather than upstream code.
I suspect there are legitimate grounds to complain about the fact that
it is shipped in the OFA OFED and not limited to an Intel OFED
derivative similar to Mellanox OFED.
r to peer PCI
operations and such without any input from the Xeon Phi folks.
--
Doug Ledford <dledf...@redhat.com>
GPG Key ID: B826A3330E572FDD
Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD
signature.asc
Description: OpenPGP digital signature
___
of wanting to get
along with the upstream linux community. As long as they want to
preserve that relationship, then they should listen when the community
has something to say. It might well be their decision, but the
ramifications of that decision might sabotage their other interests.
--
Doug Ledford <
48 matches
Mail list logo