Hermitux get stuck in the call of an OpenMP function.

[p-jacquot]

This morning, I discovered that there are machines where I can't boot Hermitux. The machines uses the same OS image, and there is one where it work, and one where it doesn't work. (I'm using machines of the Grid'5000 platform : https://www.grid5000.fr/w/Grid5000:Home)

I was trying to compile & run a simple static OpenMP program (basically, just printing a thread number in a parallel-for loop). The code compile without any warning, with hermitux's musl-gcc and libiomp5 library. And it run fine when I launch it in the shell.

When executing the program with Hermitux, it seems that uhyve get stuck in the vcpu_loop, because it don't do anything while usually this step is very very short.

With the following command :

$ HERMIT_ISLE=uhyve HERMIT_TUX=1 HERMIT_VERBOSE=1 \
 ../hermitux/hermitux-kernel/prefix/bin/proxy \
../hermitux/hermitux-kernel/prefix/x86_64-hermit/extra/tests/hermitux \
omp-for

I get this log :

Uhyve's elf loader starts, considering: omp-for
Uhyve's elf loader found entry point at 0x401200 in file omp-for
Load elf file at 0x400000, file size 0x220, memory size 0x220
Load elf file at 0x401000, file size 0x7cfaa, memory size 0x7cfaa
Load elf file at 0x47e000, file size 0x1fa78, memory size 0x1fa78
Load elf file at 0x49ed1c, file size 0x4a44, memory size 0xf564
uhyve is entering vcpu_loop

I tried to recompile hermitux's kernel to be sure that it was correctly built for this machine, but it doesn't change anything.

What should I check to get more detail on this problem ?

[olivierpierre]

Hi, thanks for the report, 2 questions:

• does the problem happen with all applications or only a subset?
• what is the model of the CPU used on this machine?

[p-jacquot]

Hello ! Thanks you for your answer.

I've run other applications, and I think I've understood what's the real problem.

I noticed that another application of the npb-omp bench suite can get stuck too. (it is cg bench)

I think that the real culprits are in fact the omp functions, such as omp_set_num_threads( int ), because when I try to compile this program :

#include <stdio.h>
#include <omp.h>

int main()
{
    printf("Hello ! This is the omp-for test program !\n");
    omp_set_num_threads(4);
    int i;
#pragma omp parallel for
    for(i = 0; i < 100; ++i)
    {
        int thread = omp_get_thread_num();
    printf("Thread %d is doing iteration %d !\n", thread, i);
    }
    return 0;
}

I get this before the program get stuck :

Uhyve's elf loader starts, considering: omp-for
Uhyve's elf loader found entry point at 0x401200 in file omp-for
Load elf file at 0x400000, file size 0x220, memory size 0x220
Load elf file at 0x401000, file size 0x7a1aa, memory size 0x7a1aa
Load elf file at 0x47c000, file size 0x1e4d8, memory size 0x1e4d8
Load elf file at 0x49bd1c, file size 0x41c4, memory size 0xed04
uhyve is entering vcpu_loop
Hello ! This is the omp-for test program !

So it seems that the problem is not uhyve. But still, I have this problem only for a few machines. Here's what lscpu printed me for a machine where the program get stuck :

Architecture:        x86_64
CPU op-mode(s):      32-bit, 64-bit
Byte Order:          Little Endian
Address sizes:       46 bits physical, 48 bits virtual
CPU(s):              24
On-line CPU(s) list: 0-23
Thread(s) per core:  2
Core(s) per socket:  6
Socket(s):           2
NUMA node(s):        2
Vendor ID:           GenuineIntel
CPU family:          6
Model:               45
Model name:          Intel(R) Xeon(R) CPU E5-2630 0 @ 2.30GHz
Stepping:            7
CPU MHz:             2800.438
CPU max MHz:         2800.0000
CPU min MHz:         1200.0000
BogoMIPS:            4599.77
Virtualization:      VT-x
L1d cache:           32K
L1i cache:           32K
L2 cache:            256K
L3 cache:            15360K
NUMA node0 CPU(s):   0,2,4,6,8,10,12,14,16,18,20,22
NUMA node1 CPU(s):   1,3,5,7,9,11,13,15,17,19,21,23
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 nopl xtopology nonstop_tsc cpuid 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 epb pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid xsaveopt dtherm ida arat pln pts md_clear flush_l1d

[olivierpierre]

I have checked on Grid'5000 and I assume that this is one of the "taurus" machines you get by default on the Lyon cluster. These are very old processors (2012) and I encourage you to try on a more recent one ("nova" for example).

[p-jacquot]

Yup, that's already what I did.

I was just wondering if this issue had something particular or not.

Thanks for your help, I'll close the issue !

[olivierpierre]

Salut Pierre, j'ai fait tourne vite fait un exemple des benchs dont tu as parle (FFT) et j'ai decouvert un bug relativement simple a fixer, je te conseille de faire un git pull du repo du kernel, ca devrait te faciliter la tache.

Avec le fix, le bench FFT ne plante qu'environ 1 fois sur 4 😄 Pierre

---

From: Pierre Jacquot notifications@github.com Sent: Tuesday, March 2, 2021 7:24 AM To: ssrg-vt/hermitux hermitux@noreply.github.com Cc: Pierre Olivier pierre.olivier@manchester.ac.uk; Comment comment@noreply.github.com Subject: Re: [ssrg-vt/hermitux] uhyve stuck in vcpu_loop for some machines (#13)

Yup, that's already what I did.

I was just wondering if this issue had something particular or not.

Thanks for your help, I'll close the issue !

— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/ssrg-vt/hermitux/issues/13#issuecomment-788682397, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ABIXWOICA6WY2KA2OR2CXMTTBSHEVANCNFSM4YIPUMFA.