Am făcut upgrade de la IBM LSF Suite for Enterprise 10.2.0.10 la versiunea 10.2.0.12, iar acum, pe doar unul dintre serverele noastre de cluster GPU (1 din 8), nu pot face ca serviciul LIM să rămână în funcțiune. Continuă să se blocheze cu o eroare de segmentare:
lim[42062]: segfault la 0 ip 00007f63476c07f7 sp 00007f6345218958 eroare 4 în libc-2.27.so[7f6347607000+1e7000]
Procesul seg defecte în general după ce o lucrare a fost trimisă la server sau s-a terminat acolo. Dacă există o sarcină care rulează pe server, LIM și procesele sale secundare eșuează după aproximativ un minut după pornire.
Deoarece folosim „Inițiativa Academică” IBM într-o catedra universitară de Bioinformatică, nu avem acces la suport sau pachete de corecții, în afară de versiunile majore.
nvidia-smi arată următoarele, în prezent:
+--------------------------------------------- ----------------------------+
| NVIDIA-SMI 470.82.01 Versiune driver: 470.82.01 Versiune CUDA: 11.4 |
|-------------------------------+------------------ -----+----------------------+
| Persistența numelui GPU-M| Autobuz-Id Disp.A | Volatil Uncorr. ECC |
| Fan Temp Perf Pwr:Utilizare/Cap| Utilizarea memoriei | GPU-Util Compute M. |
| | | MIG M. |
|================================+================== =====+=======================|
| 0 Quadro RTX 8000 Pornit | 00000000:1A:00.0 Dezactivat | Off |
| 33% 40C P8 25W / 260W | 3968MiB / 48601MiB | 0% E. Proces |
| | | N/A |
+-------------------------------+----------------- -----+----------------------+
| 1 Quadro RTX 8000 Pornit | 00000000:3E:00.0 Dezactivat | Off |
| 33% 25C P8 12W / 260W | 1 MiB / 48601 MiB | 0% Implicit |
| | | N/A |
+-------------------------------+----------------- -----+----------------------+
| 2 Quadro RTX 8000 Pornit | 00000000:89:00.0 Dezactivat | Off |
| 33% 24C P8 21W / 260W | 1 MiB / 48601 MiB | 0% Implicit |
| | | N/A |
+-------------------------------+----------------- -----+----------------------+
| 3 Quadro RTX 8000 Pornit | 00000000:B1:00.0 Dezactivat | Off |
| 33% 24C P8 15W / 260W | 1 MiB / 48601 MiB | 0% Implicit |
| | | N/A |
+-------------------------------+----------------- -----+----------------------+
Am reușit să obțin un dump de miez al defecțiunii de segmentare și am trecut prin el gdb. Iată următorul următor, o inspecție suplimentară:
(gdb) bt
#0 __strcat_sse2_unaligned () la ../sysdeps/x86_64/multiarch/strcpy-sse2-unaligned.S:298
#1 0x00000000004efa5c în getNvidiaGpu (index=-1408930708, dev=0x7f7dac056810, allDevices=0xbdd9, errorGPU=0x0, errorCount=0, warningGPU=0x7f7dac2, warningGPU=0x7f7dac.
#2 0x00000000004f074b în getGpuReportFullThreadFunc () la lim.gpu.c:858
#3 0x00000000004f11ad în collectGpuInfoThread (arg=0x7f7dac056c6d) la lim.gpu.c:949
#4 0x00007f7db92756db în start_thread (arg=0x7f7db5ec8700) la pthread_create.c:463
#5 0x00007f7db83d771f în clone () la ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
Iată ansamblul unde eșuează:
=> 0x00007f7db836f7f7 <+1255>: movdqu (%rsi),%xmm1
Și aici vedem că adresa de memorie a rsi este 0, sau pointerul NULL
rsi 0x0 0
#0 __strcat_sse2_unaligned () la ../sysdeps/x86_64/multiarch/strcpy-sse2-unaligned.S:298
Fără localnici.
#1 0x00000000004efa5c în getNvidiaGpu (index=-1408930708, dev=0x7f7dac056810, allDevices=0xbdd9, errorGPU=0x0, errorCount=0, warningGPU=0x7f7dac2, warningGPU=0x7f7dac.
fname = 0x7d6878 "getNvidiaGpu"
nume model = „QuadroRTX8000”, „\000” <se repetă de 242 de ori>
dispozitiv = 0x7f7db79b3e58
memorie = {total = 50962169856, liber = 42197254144, folosit = 8764915712}
pState = NVML_PSTATE_2
utilizare = {gpu = 100, memorie = 49}
computeMode = NVML_COMPUTEMODE_DEFAULT
temperatura = 83
vsbecc = 0
vdbecc = 0
putere = 249652
i = 0
j = 0
#2 0x00000000004f074b în getGpuReportFullThreadFunc () la lim.gpu.c:858
dev = 0x7f7dac056810
fname = "getGpuReportFullThreadFunc"
dGlobal = 0x7f7dac001c70
errorGPU = 0x0
warningGPU = 0x7f7dac011730
allDevices = 0x7f7dac00a850
ret = 2886036588
ret1 = 2886036588
ver = {major = 2885721120, minor = 32637, patch = 4294967168, build = 0x11 <eroare: Nu se poate accesa memoria la adresa 0x11>}
rsmi_cnt = 0
nvml_cnt = 4
majorTmp = "11\000\000\000\000\000"
compMajorV = <optimizat afară>
compMinorV = <optimizat afară>
majorVer = <optimizat afară>
majorV = 470
minorV = 57
errorCount = 0
warningCnt = 2
i = 0
gpu_lib = -1408931824
nvmlOpened = 1
#3 0x00000000004f11ad în collectGpuInfoThread (arg=0x7f7dac056c6d) la lim.gpu.c:949
fname = "colectațiGpuInfoThread"
gpuinfo = 0x7f7dac001c70
gpuinfoError = 0
sampleInterval = 5
#4 0x00007f7db92756db în start_thread (arg=0x7f7db5ec8700) la pthread_create.c:463
pd = 0x7f7db5ec8700
acum = <optimizat afară>
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140177899816704, -4327163297919163674, 140177899814848, 0, 0, 10252544, 4398249031032873702, 4398224247775797990}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, curățare = 0x0, canceltype = 0}}}
not_first_call = <optimizat afară>
#5 0x00007f7db83d771f în clone () la ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
Cu toate acestea, avem un alt server, cu exact aceleași specificații, care nu are această problemă. Versiunile NVIDIA CUDA și driverele sunt, de asemenea, aceleași, rulând aceeași versiune de Ubuntu, versiunea 18.04.06 LTS.
Instalarea LSF utilizează o configurație partajată prin NFS - ceea ce înseamnă că fiecare server accesează aceleași fișiere de configurare și scripturi.
Singurele diferențe pe care le pot vedea între celelalte servere și cel cu problema este în opțiunea de comandă folosită pentru a porni LIM:
Pe toate celelalte servere:
rădăcină 53635 1,8 0,0 277728 18844 ? S<sl Feb07 472:40 /opt/ibm/lsfsuite/lsf/10.1/linux2.6-glibc2.3-x86_64/etc/lim -d /opt/ibm/lsfsuite/lsf/conf/ego/rost_lsf_cluster_1/kernel
rădăcină 53639 0,0 0,0 18652 5976 ? S<s Feb07 0:11 \_ /opt/ibm/lsfsuite/lsf/10.1/linux2.6-glibc2.3-x86_64/etc/melim
rădăcină 53645 0,0 0,0 4681288 14400 ? S<l Feb07 6:26 | \_ /opt/ibm/lsfsuite/lsf/10.1/linux2.6-glibc2.3-x86_64/etc/lsfbeat -c /opt/ibm/lsfsuite/lsf/conf/lsfbeats/lsfbeat.yml
rădăcină 53640 0,0 0,0 21268 9136 ? S Feb07 7:56 \_ /opt/ibm/lsfsuite/lsf/10.1/linux2.6-glibc2.3-x86_64/etc/pim -d /opt/ibm/lsfsuite/lsf/conf/ego/rost_lsf_cluster_1/kernel
rădăcină 53641 0,0 0,0 39576 9604 ? Sl Feb07 0:42 \_ /opt/ibm/lsfsuite/lsf/10.1/linux2.6-glibc2.3-x86_64/etc/pem
Pe cel cu defect de segmentare:
rădăcină 44902 1,8 0,0 272472 16680 ? D<sl 12:17 0:00 /opt/ibm/lsfsuite/lsf/10.1/linux2.6-glibc2.3-x86_64/etc/lim
rădăcină 44919 4,4 0,0 18656 6500 ? S<s 12:17 0:00 \_ /opt/ibm/lsfsuite/lsf/10.1/linux2.6-glibc2.3-x86_64/etc/melim
rădăcină 44924 2,2 0,0 468764 11280 ? S<l 12:17 0:00 | \_ /opt/ibm/lsfsuite/lsf/10.1/linux2.6-glibc2.3-x86_64/etc/lsfbeat -c /opt/ibm/lsfsuite/lsf/conf/lsfbeats/lsfbeat.yml
rădăcină 44920 5,6 0,0 19276 7364 ? S 12:17 0:00 \_ /opt/ibm/lsfsuite/lsf/10.1/linux2.6-glibc2.3-x86_64/etc/pim
rădăcină 44921 4,6 0,0 39576 10288 ? Sl 12:17 0:00 \_ /opt/ibm/lsfsuite/lsf/10.1/linux2.6-glibc2.3-x86_64/etc/pem
Am încercat să repornesc serviciile folosind bctrld atât pe master, cât și pe server, pe lângă utilizarea lsfd.service unitate... chiar pornind lim service manual folosind -d /opt/ibm/lsfsuite/lsf/conf/ego/rost_lsf_cluster_1/kernel Opțiuni. Toate produc o eroare de segmentare.
Are cineva idee care este problema sau cum se poate rezolva? înnebunesc aici.
Vă mulțumesc foarte mult pentru că ați acordat timp pentru a citi acest lucru și pentru a oferi feedback-ul dvs.!
