George, Brian,
I also think my patch is icky. George's patch may be nicer.
Thanks,
Takahiro Kawashima,
MPI development team,
Fujitsu
> Takahiro,
>
> Nice catch. A nicer fix will be to check the type of the header, and copy the
> header accordingly. Attached is a patch following this idea.
>
>
Hi Sam,
On Thu, 18 Oct 2012 15:08:59 +
"Gutierrez, Samuel K" wrote:
>
> I really appreciate your pointing me in the right direction. It turns
> out that on this particular system had /etc/sysctl.d/10-ptrace.conf
> was set to 1. Changing this to 0 fixed the problem. I'm not sure if
> this is
Hmmm...this didn't just remove deprecated functions. It actually changed the
way the cmd line parser works. Was that intentional?
I haven't fully grok'd what that did to us, but wonder if the change was
intentional or just got caught in the commit?
On Oct 17, 2012, at 1:17 PM, svn-commit-mai..
On Thu, Oct 18, 2012 at 7:32 PM, Jeff Squyres wrote:
> On Oct 7, 2012, at 2:25 PM, Dmitri Gribenko wrote:
> Hmm. I'm not sure how to do that -- I don't know of any C compiler that has
> built-in #defines for what Fortran types exist.
>
> I'm open to suggestions, though -- can you suggest an easi
On Oct 7, 2012, at 2:25 PM, Dmitri Gribenko wrote:
>> Ok, this might get a little complicated. You'll probably need to use a pair
>> of them (this is trunk only; it's different in v1.6 because we wholly
>> revamped the trunk's Fortran support recently):
>>
>> 1. You can see all the OMPI_HAVE_F
If there isn't anything wrong with this approach, then I think it is worth it.
I can do the write-up.
Anyone see an issue with this approach? I'm specifically looking for answers
geared towards security.
Sam
From: devel-boun...@open-mpi.org [devel-boun.
Do we need to add this to the FAQ?
On Oct 18, 2012, at 11:08 AM, Gutierrez, Samuel K wrote:
> Hi George,
>
> I really appreciate your pointing me in the right direction. It turns out
> that on this particular system had /etc/sysctl.d/10-ptrace.conf was set to 1.
> Changing this to 0 fixed the
Hi George,
I really appreciate your pointing me in the right direction. It turns out that
on this particular system had /etc/sysctl.d/10-ptrace.conf was set to 1.
Changing this to 0 fixed the problem. I'm not sure if this is the best way of
getting things to work, but is sufficient for my purpo
Dear OpenMPI developers,
Could someone please review the attached patch?
Dmitri
On Sun, Oct 7, 2012 at 9:25 PM, Dmitri Gribenko wrote:
> On Thu, May 31, 2012 at 2:38 PM, Jeff Squyres wrote:
>> On May 31, 2012, at 7:29 AM, Jeff Squyres wrote:
>>
> We should have AC macros for all of these a
Takahiro,
Nice catch. A nicer fix will be to check the type of the header, and copy the
header accordingly. Attached is a patch following this idea.
Thanks,
george.
hdr_copy.patch
Description: Binary data
On Oct 18, 2012, at 03:06 , "Kawashima, Takahiro"
wrote:
> Hi Open MPI develop
I'm torn on this one. On the one hand, I think this is probably the most
performant solution. On the other hand, it feels icky; a more clean
solution would be to use hdr->type to determine the size to copy. What do
others think?
Brian
On 10/17/12 9:06 PM, "Kawashima, Takahiro"
wrote:
>Hi Op
In the usual place:
http://www.open-mpi.org/software/ompi/v1.6/
There's only been one change since rc1:
- Fix spawning from a singleton to multiple hosts when the "add-host"
MPI_Info key is used. Thanks to Brian Budge for pointing out the
problem.
--
Jeff Squyres
jsquy...@cisco.com
Fo
All -
I'm trying to clean up the MX situation in 1.7 with regards to the fake
mpool and have some questions. It looks like the point of the fake mpool
is to translate a memory hook release into a free call in some other
library. My question is why we're using the mpool to do that. Since opal
al
Check the permissions granted by pam. Look in the /etc/security to check for
any type of restrictions.
george.
On Oct 17, 2012, at 23:30 , "Gutierrez, Samuel K" wrote:
> Hi,
>
> I'm trying to run with CMA support, but process_vm_readv is failing with
> EPERM when trying to use it as a reg
14 matches
Mail list logo
