Tckgen - Illegal instruction (core dumped)

,
1

I use MRtrix on a cluster running CentOS 6.6. Some of the nodes in the cluster are older, but they run the same system and have the same libraries. When I run tckgen on these older nodes I get the following error:

/opt/sge/default/spool/compute-1-13/job_scripts/7918512: line 36: 4175 Illegal instruction (core dumped) tckgen WM_FODs.mif ComissR.tck -algorithm iFOD2 -step 0.6 -angle 75 -force -nthreads 0 -seed_image Rseed.nii.gz -include Rend.nii.gz -exclude Exclusion.nii.gz -maxnum 1000000 -maxlength 250 -minlength 10 -number 300

The admin of our cluster cannot find what exactly is making tckgen fail. Using the -debug option does not help, tckgen does not even start. When run without any argument it produces the same core dumped issue instead of the usual help. At the same time, tckgen runs fine on the newer nodes of the cluster.

Any idea what might be the problem?

Dorian

UPDATE: the failure is on all MRtrix commands I have tried so far. There must be something in common that causes this.

2

The problem is that by default, we ask the compiler to generate code using all available CPU optimisations available on the system it’s being built on. This means if you take the code and run it on a different CPU where some of these instructions might not be available, you’ll get this error.

See this page for more details and what to do about it.

3

Is there a way to compile for both CPU types.

These are the infos I get:

old node

processor       : 1
vendor_id       : GenuineIntel
cpu family      : 6
model           : 23
model name      : Intel(R) Xeon(R) CPU           E5440  @ 2.83GHz
stepping        : 10
microcode       : 2571
cpu MHz         : 2834.000
cache size      : 6144 KB
physical id     : 1
siblings        : 4
core id         : 0
cpu cores       : 4
apicid          : 4
initial apicid  : 4
fpu             : yes
fpu_exception   : yes
cpuid level     : 13
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm dca sse4_1 xsave lahf_lm dts tpr_shadow vnmi flexpriority
bogomips        : 5652.54
clflush size    : 64
cache_alignment : 64
address sizes   : 38 bits physical, 48 bits virtual
power management:

newer node

processor       : 1
vendor_id       : GenuineIntel
cpu family      : 6
model           : 45
model name      : Intel(R) Xeon(R) CPU E5-2450 0 @ 2.10GHz
stepping        : 7
microcode       : 1808
cpu MHz         : 2099.995
cache size      : 20480 KB
physical id     : 1
siblings        : 8
core id         : 0
cpu cores       : 8
apicid          : 32
initial apicid  : 32
fpu             : yes
fpu_exception   : yes
cpuid level     : 13
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx lahf_lm ida arat xsaveopt pln pts dts tpr_shadow vnmi flexpriority ept vpid
bogomips        : 4199.40
clflush size    : 64
cache_alignment : 64
address sizes   : 46 bits physical, 48 bits virtual
power management:
4

This depends on exactly what you’re trying to achieve. If you just want to get the code to work, then the simplest thing to do is (requires a recent version of the code):

ARCH="" ./configure

This will just let the compiler use whatever defaults it normally would. You can also force a specific architecture like this:

ARCH="x86-64" ./configure

However, If you want to compile the code to be as fast as possible on this set of hardware, it might take quite a bit of effort to figure out the right flags. This isn’t something I’ve ever needed to do, but your best bet is to look through the gcc documentation for the -march flag, and see whether there is a generic one that will fit both of yours. If there is, just pass that through with the ARCH environment variable, e.g.:

ARCH="ivybridge" ./configure