Unavailbe target while runing offload sample codes

[Chong_C_]

I installed drivers for Xeon phi and the /opt/intel/mic/bin/micinfo can return correct information. Also I am able to log on to the accelerator and run programe in native model.

But every time when I try to excute the offload sample programs in /opt/intel/composerxe/Samples/en-US/C++/mic_samples/intro_sampleC, it always return the result that the number of device it can be detected is 0 and the offload to accelerator failed (run at host instead of at the accelerator). Could anyone help me to fix that problem? Seems my Xeon Phi cards works fine because I can log in and run a native code, but the accelerator can't be detected within the offload samples program.

Thanks!

[Frances_R_Intel]

Did you build the code using the Makefile in that directory using the command

make mic

[Sumedh_N_Intel]

Can you also confirm that you have started the mpss before executing the code. To start the mpss use "service mpss start". 

[Ravi_N_Intel]

can you log on to the card and check if coi_daemon is running.

On MIC do
ps -a | grep coi
 4710 micuser  327:54 /bin/coi_daemon --coiuser=micuser

[Chong_C_]

Ravi Narayanaswamy (Intel) wrote:

can you log on to the card and check if coi_daemon is running.

On MIC do
ps -a | grep coi
 4710 micuser  327:54 /bin/coi_daemon --coiuser=micuser

Thanks for reply, I type the commend at mic and got this result:

4639 micuser 0:00 /bin/coi_daemon --coiuser=micuser

 I use the Makefile in the sample code folder and executed 'service MPSS start' before running the sample codes for offload. But the program can not detect the accelerator.

Thanks again!

[Loc_N_Intel]

What the version of MPSS and the version of Intel composer that use are using? Also, it would be helpful if you can show the output from the command "micinfo".

Thanks.

[Chong_C_]

loc-nguyen (Intel) wrote:

What the version of MPSS and the version of Intel composer that use are using? Also, it would be helpful if you can show the output from the command "micinfo".

Thanks.

My OS and MPSS version information is:

System Info
  HOST OS   : Linux
  OS Version  : 2.6.32-71.el6.x86_64
  Driver Version  : 5889-16
  MPSS Version  : 2.1.5889-16
  Host Physical Memory : 65944 MB

The intel composer I used is CPP_studio_xe_2013_update2. The output of the micinfo is too long so I attached it in the following txt file. Thanks!

[Chong_C_]

Ravi Narayanaswamy (Intel) wrote:

can you log on to the card and check if coi_daemon is running.

On MIC do
ps -a | grep coi
 4710 micuser  327:54 /bin/coi_daemon --coiuser=micuser

My coi_daemon is running but with

4639 micuser 0:00 /bin/coi_daemon --coiuser=micuser

is the '0:00' indicate that the coi_daemon is running incorrectly? Thanks!

[Frances_R_Intel]

Ravi asked about the coi_daemon because it is responsible for listening for offload connections requests. If the coi_daemon is not running, then offload requests will fail. The 0:00 implies that the daemon is running but has not handled any requests. It does not necessarily mean that there is something wrong with the daemon itself.

The sample code that comes with the compiler includes a lot of tests to demonstrate features. Let's back off a bit and try something simpler. What happens if you compile this with simply "icc offloadtest.c -o offloadtest", then run it.

[cpp]

#include <offload.h>

__attribute__((target(mic))) void chk_target00();

int main(int argc, char* argv[])
{
int num_devices = 0;
int offload_mode = 0;
int target_ok;
int i;

printf("Checking for Intel(R) Xeon Phi(TM) (Target CPU) devices...\n\n");

#ifdef __INTEL_OFFLOAD
num_devices = _Offload_number_of_devices();
printf("Number of Target devices installed: %d\n\n",num_devices);
#else
printf("Compiler failed to set __INTEL_OFFLOAD\n");
#endif

#pragma noinline
for (i = 0; i < num_devices; i++) {

target_ok = 0;
#pragma offload target(mic: i) in(i)
chk_target00();
}
}

__attribute__((target(mic))) void chk_target00()
{
int retval;

#ifdef __MIC__
printf("Ran on coprocessor\n");
#else
printf("Ran on host\n");
#endif
}

[/cpp]

[Mian_L_]

Hi Frances Roth,

I have the same problem, i have downloaded and run your program, it cannot detect any mic cards. However, the native program can run successfully. Do you know what's wrong?

Thanks!

[Chong_C_]

Frances Roth (Intel) wrote:

Ravi asked about the coi_daemon because it is responsible for listening for offload connections requests. If the coi_daemon is not running, then offload requests will fail. The 0:00 implies that the daemon is running but has not handled any requests. It does not necessarily mean that there is something wrong with the daemon itself.

The sample code that comes with the compiler includes a lot of tests to demonstrate features. Let's back off a bit and try something simpler. What happens if you compile this with simply "icc offloadtest.c -o offloadtest", then run it.

#include <offload.h> __attribute__((target(mic))) void chk_target00(); int main(int argc, char* argv[]) { int num_devices = 0; int offload_mode = 0; int target_ok; int i; printf("Checking for Intel(R) Xeon Phi(TM) (Target CPU) devices...nn"); #ifdef __INTEL_OFFLOAD num_devices = _Offload_number_of_devices(); printf("Number of Target devices installed: %dnn",num_devices); #else printf("Compiler failed to set __INTEL_OFFLOADn"); #endif #pragma noinline for (i = 0; i < num_devices; i++) { target_ok = 0; #pragma offload target(mic: i) in(i) chk_target00(); } } __attribute__((target(mic))) void chk_target00() { int retval; #ifdef __MIC__ printf("Ran on coprocessorn"); #else printf("Ran on hostn"); #endif }

Thank you for the reply, I try to run the program, it returns that 0 device is detected.

I re-check the status of the device by log on to the mic card and run a sample openmp code with 240 threads in native model. It seems that in native model the accelerator works fine. The only problem is it can not be detected by the host when run the offload code. Is that the problem caused by my host operation system's environment? Thanks again! 

[Ravi_N_Intel]

Is you env setup correctly.

check this link

http://software.intel.com/en-us/comment/1734754#comment-1734754

[Frances_R_Intel]

The best way to make sure everything in your compile/runtime environment is set up properly is to execute:

source /opt/intel/composerxe/bin/compilervars.sh intel64

But if that doesn't work, can you try rerunning the commands:

[bash]

service mpss stop

micctrl --initdefaults

service mpss start

[/bash]

You will have run that command "micctrl --initdefaults" as part of your original MPSS install but rerunning the command should recheck for any changes. Then make sure you have sourced the compilervars script, recompile your code and rerun it.

[Chong_C_]

Ravi Narayanaswamy (Intel) wrote:

Is you env setup correctly.

check this link

http://software.intel.com/en-us/comment/1734754#comment-1734754

Thank you for the reply, I tried to run the "compilervars.sh interl64", it didn't report any error. But after I excuted the .sh file, when I type

echo $MIC_LD_LIBRARY_PATH,

I got nothing (a blank return).  I think that may be the problem you mentioned (incorrect setup of MIC_LD_LIBRARY_PATH).

How can I fix that problem? I executed the /opt/intel/composer_xe_2013.2.146/bin/compilervars.sh intel64 multiple time, but the PATH and env values are still not setup correctly. Seems the compilervars.sh didn't change anything.

Thanks again!

[Chong_C_]

Frances Roth (Intel) wrote:

The best way to make sure everything in your compile/runtime environment is set up properly is to execute:

source /opt/intel/composerxe/bin/compilervars.sh intel64

But if that doesn't work, can you try rerunning the commands:

service mpss stop micctrl --initdefaults service mpss start

You will have run that command "micctrl --initdefaults" as part of your original MPSS install but rerunning the command should recheck for any changes. Then make sure you have sourced the compilervars script, recompile your code and rerun it.

Problem fixed by source the compilervars script. Thank you so much!

Basically, after install the Intel composer, I should source the script instead of change the path and the environment variable manuallyy. Missing environment setting will make the compiler working for native model but inactive for the offload model.

I think this is a common mistake for the beginner of the intel composer user like me (I use gcc instead of icc before since gcc is free). Hopefully the discuss in this topic will help other people. Thank you again! 

[Sanchit_Misra]

Hi,

I had the same problem while trying to run the sample code available at /opt/intel/composerxe/Samples/en_US/C++/mic_samples/intro_sampleC/.

Here is the error I get:

$ ./intro_sampleC.out
Samples started
Checking for Intel(R) Xeon Phi(TM) (Target CPU) devices...

getting number of devices
Number of Target devices installed: 0

Offload sections will execute on: Host CPU (fallback mode)

PASS Sample01
PASS Sample02
PASS Sample03
PASS Sample04
PASS Sample05
PASS Sample06
*** FAIL Sample07 - target unavailable
PASS Sample08
PASS Sample09
PASS Sample10
PASS Sample11
*** FAIL Sample12 - target unavailable
*** FAIL Sample13 - target unavailable
*** FAIL Sample14 - target unavailable
Samples complete

I am able to run native code and I have set my MIC_LD_LIBRARY_PATH by running 

$ source /opt/intel/composerxe/bin/compilervars.sh intel64

Here is my MIC_LD_LIBRARY_PATH:

$ echo $MIC_LD_LIBRARY_PATH
/opt/intel/composer_xe_2013_sp1.1.106/compiler/lib/mic:/opt/intel/composer_xe_2013_sp1.1.106/mpirt/lib/mic:/opt/intel/mic/coi/device-linux-release/lib:/opt/intel/mic/myo/lib:/opt/intel/mic/coi/device-linux-release/lib:/opt/intel/mic/myo/lib:/opt/intel/composer_xe_2013_sp1.1.106/compiler/lib/mic:/opt/intel/composer_xe_2013_sp1.1.106/mkl/lib/mic:/opt/intel/composer_xe_2013_sp1.1.106/tbb/lib/mic

Also, the coi_daemon is running but the user is different:

$ ps -a|grep coi
 6101 root       0:00 /bin/coi_daemon

Could that be the issue? If yes, how do I change that?

Thanks and regards,

Sanchit