<div dir="ltr"><div>1. Please show full call stack.</div><div>2. are you able to run a very simple omp code like just an empty "omp target"</div><div>3. My current feeling is that when you build libomptarget plugins, the cuda.h may not be consistent with /usr/local/software/jureca/Stages/2019a/software/nvidia/driver/lib64/libcuda.so.1</div><div></div><div>Ye<br></div><div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr">===================<br>
Ye Luo, Ph.D.<br>Computational Science Division & Leadership Computing Facility<br>
Argonne National Laboratory</div></div></div></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Sep 23, 2020 at 9:22 PM Itaru Kitayama via Openmp-dev <<a href="mailto:openmp-dev@lists.llvm.org">openmp-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">If I run it with CUDA-gdb I get:<br>
<br>
Target CUDA RTL --> Init requires flags to 1<br>
Target CUDA RTL --> Getting device 0<br>
Target CUDA RTL --> The primary context is inactive, set its flags to<br>
CU_CTX_SCHED_BLOCKING_SYNC<br>
[New Thread 0x2aaaae5e3700 (LWP 4154)]<br>
^C<br>
Thread 1 "nest" received signal SIGINT, Interrupt.<br>
0x00002aaaad2e5a1c in cuVDPAUCtxCreate ()<br>
   from /usr/local/software/jureca/Stages/2019a/software/nvidia/driver/lib64/libcuda.so.1<br>
<br>
On Thu, Sep 24, 2020 at 8:56 AM Itaru Kitayama <<a href="mailto:itaru.kitayama@gmail.com" target="_blank">itaru.kitayama@gmail.com</a>> wrote:<br>
><br>
>  With the Trunk Clang running with CUDA Toolkit 10.1.105 on JURECA at<br>
> JSC, I started seeing a hang up:<br>
><br>
> Libomptarget --> Call to omp_get_num_devices returning 1<br>
> Libomptarget --> Default TARGET OFFLOAD policy is now mandatory<br>
> (devices were found)<br>
> Libomptarget --> Entering data begin region for device -1 with 1 mappings<br>
> Libomptarget --> Use default device id 0<br>
> Libomptarget --> Checking whether device 0 is ready.<br>
> Libomptarget --> Is the device 0 (local ID 0) initialized? 0<br>
> Target CUDA RTL --> Init requires flags to 1<br>
> Target CUDA RTL --> Getting device 0<br>
> Target CUDA RTL --> The primary context is inactive, set its flags to<br>
> CU_CTX_SCHED_BLOCKING_SYNC<br>
><br>
> Getting back to the prompt takes time or I needed to hit Ctrl + C or Z<br>
> hard many times.<br>
><br>
> On Thu, Sep 24, 2020 at 7:31 AM Itaru Kitayama <<a href="mailto:itaru.kitayama@gmail.com" target="_blank">itaru.kitayama@gmail.com</a>> wrote:<br>
> ><br>
> > Should I back off from my ThunderX2 while fix is being developed?<br>
> ><br>
> > On Thu, Sep 24, 2020 at 5:36 AM Johannes Doerfert<br>
> > <<a href="mailto:johannesdoerfert@gmail.com" target="_blank">johannesdoerfert@gmail.com</a>> wrote:<br>
> > ><br>
> > > This could be a side effect of something else, namely the runtime<br>
> > > unloading order.<br>
> > > @Jon @Shilei where are we with fixing those issues?<br>
> > ><br>
> > > On 9/23/20 2:58 AM, Itaru Kitayama wrote:<br>
> > > > I think I was running my offloading app with CUDA Toolkit which is<br>
> > > > I've loaded via Spack, but<br>
> > > > the app itself is built with Clang (+CUDA Toolkit local admin provided<br>
> > > > via modules).<br>
> > > ><br>
> > > > However, the effect is this drastic; I mean locking totally up a<br>
> > > > ThunderX2 node?<br>
> > > ><br>
> > > > On Mon, Sep 21, 2020 at 9:58 PM Huber, Joseph <<a href="mailto:huberjn@ornl.gov" target="_blank">huberjn@ornl.gov</a>> wrote:<br>
> > > >> The runtime library just calls abort() immediately after printing that last "Failure while offloading was mandatory" message. I'm not sure what would be causing the process to hang after that if SIGABRT isn't being caught.<br>
> > > >> ________________________________<br>
> > > >> From: Itaru Kitayama <<a href="mailto:itaru.kitayama@gmail.com" target="_blank">itaru.kitayama@gmail.com</a>><br>
> > > >> Sent: Saturday, September 19, 2020 2:52 AM<br>
> > > >> To: Johannes Doerfert <<a href="mailto:johannesdoerfert@gmail.com" target="_blank">johannesdoerfert@gmail.com</a>><br>
> > > >> Cc: openmp-dev <<a href="mailto:openmp-dev@lists.llvm.org" target="_blank">openmp-dev@lists.llvm.org</a>>; Huber, Joseph <<a href="mailto:huberjn@ornl.gov" target="_blank">huberjn@ornl.gov</a>><br>
> > > >> Subject: [EXTERNAL] Re: [Openmp-dev] OpenMP offloading app gets in unresponsive<br>
> > > >><br>
> > > >> I mean; the kernel gets aborted and I see a session prompt on JURECA at JSC.<br>
> > > >><br>
> > > >> On Sat, Sep 19, 2020 at 3:38 PM Itaru Kitayama <<a href="mailto:itaru.kitayama@gmail.com" target="_blank">itaru.kitayama@gmail.com</a>> wrote:<br>
> > > >>> While it was observed on ThunderX2 with V100 system, I don't see it on<br>
> > > >>> JURECA (with GPUs).<br>
> > > >>><br>
> > > >>> On Sat, Sep 19, 2020 at 1:21 PM Johannes Doerfert<br>
> > > >>> <<a href="mailto:johannesdoerfert@gmail.com" target="_blank">johannesdoerfert@gmail.com</a>> wrote:<br>
> > > >>>> I don't think so.<br>
> > > >>>> The only thing that comes to mind is that we switched to `abort` instead<br>
> > > >>>> of `exit` after the fatal error message.<br>
> > > >>>> Though, I'm not sure why that would cause the program to hang, except if<br>
> > > >>>> SIGABRT is somehow caught.<br>
> > > >>>><br>
> > > >>>> ~ Johannes<br>
> > > >>>><br>
> > > >>>> On 9/18/20 9:35 PM, Itaru Kitayama via Openmp-dev wrote:<br>
> > > >>>>> [...]<br>
> > > >>>>> Libomptarget error: Failed to synchronize device.<br>
> > > >>>>> Libomptarget error: Call to targetDataEnd failed, abort target.<br>
> > > >>>>> Libomptarget error: Failed to process data after launching the kernel.<br>
> > > >>>>> Libomptarget error: run with env LIBOMPTARGET_INFO>1 to dump<br>
> > > >>>>> host-targetpointer maps<br>
> > > >>>>> Libomptarget fatal error 1: failure of target construct while<br>
> > > >>>>> offloading is mandatory<br>
> > > >>>>><br>
> > > >>>>> after this point, the process gets in the state of unresponsive and<br>
> > > >>>>> don't receive a signal from the user. Is this due to a new feature of<br>
> > > >>>>> LLVM?<br>
> > > >>>>> _______________________________________________<br>
> > > >>>>> Openmp-dev mailing list<br>
> > > >>>>> <a href="mailto:Openmp-dev@lists.llvm.org" target="_blank">Openmp-dev@lists.llvm.org</a><br>
> > > >>>>> <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/openmp-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/openmp-dev</a><br>
_______________________________________________<br>
Openmp-dev mailing list<br>
<a href="mailto:Openmp-dev@lists.llvm.org" target="_blank">Openmp-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/openmp-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/openmp-dev</a><br>
</blockquote></div>