Then the only thing that comes to mind is a possible discrepancy between 32bit 
and 64bit (presuming that your ARMS are 32bit).

Some (network) protocol structures might use field sizes that differ between 
the architectures.

Regards,

        Uwe


Am 18.02.2015 um 15:21 schrieb Luis Kornblueh:
> 
> Hi Uwe,
> 
> The ARMs are raspberrypis running raspbian and this is LittleEndian.
> 
> Cheerio,
> Luis
> 
> On 2/18/15 2:20 PM, Uwe Sauter wrote:
>>
>> Hi,
>>
>> as far as I know, ARM could be either little endian or mixed endian,
>> depending on how old the design is…
>>
>>  From Wikipedia:
>>
>> "SPARC historically used big-endian until version 9, which is bi-endian,
>> similarly the ARM architecture was little-endian before version 3 when
>> it became bi-endian, and the PowerPC and Power Architecture descendants
>> of POWER are also bi-endian."
>>
>> So it might depends on the firmware or kernel if your ARM is working in
>> little endianess mode.
>>
>>
>> Regards,
>>
>>     Uwe
>>
>>
>>
>> Am 18.02.2015 um 13:44 schrieb Luis Kornblueh:
>>>
>>> Dear Aaaron,
>>>
>>> thanks a lot, I can pick up some logging on Friday morning. The stuff is
>>> in school.
>>>
>>> Cheerio,
>>> Luis
>>>
>>> On 2/18/15 1:28 PM, Aaron Knister wrote:
>>>>
>>>> Hi Luis,
>>>>
>>>> That's surprising to me. Can you send any errors you got when the
>>>> x86_64 controller was talking to the ARM compute nodes? I'm wondering
>>>> if there's a field in one of the SLURN binary protocol structures
>>>> whose length is architecture dependent. From what I gather ARM is
>>>> little endian so I don't *think* it's an endianness issue.
>>>>
>>>> Thanks,
>>>> Aaron
>>>>
>>>> Sent from my iPhone
>>>>
>>>>> On Feb 18, 2015, at 3:16 AM, Luis Kornblueh
>>>>> <[email protected]> wrote:
>>>>>
>>>>>
>>>>> Hello,
>>>>>
>>>>> I try to use slurm on a cluster buid by school kids. The controller
>>>>> daemon (slurmctld) runs on a x86_64 box with Debian wheezy and the
>>>>> associated Debian package. The compute nodes are ARM based running
>>>>> as well Debian wheezy (slurmd). It seems that the slurmctld and
>>>>> slurmd cannot communicate which other. If I move the controller to an
>>>>> arm
>>>>> platform everything works fine. For cross testing I added a x86_64
>>>>> box as compute node and that one could communicate with the x86_64
>>>>> base controller.
>>>>>
>>>>> This allows to assume, I think, that there is some trouble with the
>>>>> communication protocol as it is not architecture/hardware independent.
>>>>>
>>>>> Could you give me any help on how to deal with this?
>>>>>
>>>>> Thanks a lot,
>>>>> Luis
>>>>> -- 
>>>>>                               \\\\\\
>>>>>                               (-0^0-)
>>>>> --------------------------oOO--(_)--OOo-----------------------------
>>>>>
>>>>> Luis Kornblueh                               Tel. : +49-40-41173289
>>>>> Max-Planck-Institute for Meteorology         Fax. : +49-40-41173298
>>>>> Bundesstr. 53
>>>>> D-20146 Hamburg                 Email: [email protected]
>>>>> Federal Republic of Germany
>>>
> 

Reply via email to