Le 22/02/2012 17:48, Ralph Castain a écrit :
> On Feb 22, 2012, at 9:39 AM, Eugene Loh wrote:
>> On 2/21/2012 10:31 PM, Eugene Loh wrote:
>>> ... "sockets" is unknown and hwloc returns 0 for num_sockets and OMPI pukes on divide by zero. OS info was listed in the original message (below). Might we want to do something else? E.g., assume num_sockets==1 when num_sockets==0 (if you know what I mean)? So, which one (or more) of the following should be fixed?
>>> *) on this platform, hwloc finds no socket level
>>> *) therefore hwloc returns num_sockets==0 to OMPI
>>> *) OMPI divides by 0 and barfs on basically everything
>> Okay. So, Brice's other e-mail indicates that the first two are "not really uncommon":
>> On 2/22/2012 7:55 AM, Brice Goglin wrote:
>>> Anyway, we have seen other systems (mostly non-Linux) where lstopo
>>> reports nothing interesting (only one machine object with multiple PU
>>> children). So numsockets==0 isn't really uncommon.
>> So, it seems to me that OMPI needs to handle the num_sockets==0 case rather than just dividing by num_sockets. This is v1.5 orte_odls_base_open() since r25914.
> Unfortunately, just artificially setting the num_sockets to 1 won't solve much - you'll get past that point in the code, but attempts to bind are likely to fail down the road. Fixing it will require some significant effort.
> Given we haven't heard reports of this before, I'm not convinced it is a widespread problem. For now, let's just use the mca param and see what happens.
I am probably missing something but: Why would setting num_sockets to 1
work fine as a mca param, while artificially setting it as said above