44337 2022-11-17 13:55:33 +0300 Не определено значение MAXCPU для платформы x86_64 2022-11-21 11:12:23 +0300 1 1 4 Development Sisyphus rpm-build-vm-run unstable x86_64 Linux CLOSED FIXED P5 normal --- 1 nickel vt vt qa-sisyphus oldest_to_newest 217532 0 nickel 2022-11-17 13:55:33 +0300 Падают тесты при сборке ядра в hasher на машине с 256 логическими ядрами из-за превышения количеством ядер передельного значения в 255 штук. Задание --nprocs в параметрах hasher на это значение не влияет. + time qemu-system-x86_64 -M accel=tcg -m 250428M -smp cores=256 -nodefaults -nographic -no-reboot -fsdev local,id=root,path=/,security_model=none,multidevs=remap -device virtio-9p-pci,fsdev=root,mount_tag=/dev/root -device virtio-rng-pci -serial mon:stdio -kernel /usr/src/tmp/kernel-image-std-def-buildroot/boot/vmlinuz-5.10.153-std-def-alt1 -initrd /usr/src/tmp/initramfs-5.10.153-std-def-alt1.img -sandbox on,spawn=deny -bios bios.bin -append 'console=ttyS0 mitigations=off nokaslr panic=-1 SCRIPT=/usr/src/tmp/tmp.cPZpHdjOtb NOTTY no_timer_check' **qemu-system-x86_64: Invalid SMP CPUs 256. The max CPUs supported by machine 'pc-i440fx-6.2' is 255** Command exited with non-zero status 1 0.01user 0.02system 0:00.03elapsed 97%CPU (0avgtext+0avgdata 27064maxresident)k 0inputs+0outputs (0major+2052minor)pagefaults 0swaps error: Bad exit status from /usr/src/tmp/rpm-tmp.43032 (%check) 217534 1 11880 nickel 2022-11-17 13:59:37 +0300 Created attachment 11880 предлагаемое исправление могу собрать исправленную версию в Сизиф, если нет возражений 217535 2 vt 2022-11-17 14:12:02 +0300 "6.2" это значит qemu не из Сизифа? Не могли бы вы проверить что в Сизифе 256 тоже дает ошибку? Мне кажется, что мы уде что-то где-то исправляли на эту тему, но не нашел где и что. > могу собрать исправленную версию в Сизиф, если нет возражений Нету. TODO: Может потом придумаем как это исправить лучше. И думаю --nprocs должно поддерживаться. 217540 3 nickel 2022-11-17 14:36:28 +0300 (Ответ для Vitaly Chikunov на комментарий #2) > "6.2" это значит qemu не из Сизифа? Не могли бы вы проверить что в Сизифе > 256 тоже дает ошибку? > > Мне кажется, что мы уде что-то где-то исправляли на эту тему, но не нашел > где и что. > > > могу собрать исправленную версию в Сизиф, если нет возражений > > Нету. > > TODO: Может потом придумаем как это исправить лучше. И думаю --nprocs должно > поддерживаться. Мне тоже кажется, что умолчание в vm-run должно переопределяться внешним заданным --nprocs, т.к. пользователь ожидает этого поведения 217570 4 nickel 2022-11-17 18:07:36 +0300 Пока не стал собирать пакет: может быть, все таки починить более кардинально? Пока тестируемое ядро Linux калибрует задержку для всех ядер процессора успевает выстрелить таймаут. Или просто задерем значение таймаута? Каких-то 7 ядер не успели откалибровать. [ 36.090884] #245 [ 0.000000] calibrate_delay_direct() dropping max bogoMips estimate 0 = 72277125 [ 0.000000] calibrate_delay_direct() dropping min bogoMips estimate 2 = 45102819 [ 0.000000] calibrate_delay_direct() dropping max bogoMips estimate 4 = 59594272 [ 36.271485] #246 [ 0.000000] calibrate_delay_direct() dropping max bogoMips estimate 3 = 61494541 [ 0.000000] calibrate_delay_direct() dropping min bogoMips estimate 4 = 28948026 [ 36.438659] #247 [ 0.000000] calibrate_delay_direct() dropping max bogoMips estimate 1 = 63350304 [ 0.000000] calibrate_delay_direct() dropping min bogoMips estimate 0 = 41171103 [ 36.654829] #248 [ 0.000000] calibrate_delay_direct() dropping min bogoMips estimate 4 = 33144271 [ 0.000000] calibrate_delay_direct() dropping min bogoMips estimate 0 = 46793985 qemu-system-x86_64: terminating on signal 15 from pid 3987491 (timeout) /usr/bin/vm-run: line 442: 3987559 Terminated ( if grep -sq systemd-coredump /proc/sys/kernel/core_pattern; then ulimit -c unlimited; else VM_RUN_LIBSEGFAULT=$(set +f; echo /usr/lib*/libSegFault.so); if [ -f "$VM_RUN_LIBSEGFAULT" ]; then LD_PRELOAD=${LD_PRELOAD:+${LD_PRELOAD}:}$VM_RUN_LIBSEGFAULT; SEGFAULT_USE_ALTSTACK=1; export LD_PRELOAD SEGFAULT_USE_ALTSTACK; fi; fi; test "$NOCMD" || set -x; $TIME $QEMU $DEF -nodefaults -nographic -no-reboot -fsdev local,id=root,path=/,security_model=none,multidevs=remap -device virtio-9p-$VIRTIOBUS,fsdev=root,mount_tag=/dev/root -device virtio-rng-$VIRTIOBUS -serial mon:stdio -kernel $KERNEL -initrd $INITRD $OPTS -append "console=$CONSOLE mitigations=off nokaslr $QUIET panic=-1 SCRIPT=$SCRIPT$APPEND" ) error: Bad exit status from /usr/src/tmp/rpm-tmp.75441 (%check) 217572 5 vt 2022-11-17 18:13:14 +0300 А что это за пакет таймаутит? 217573 6 vt 2022-11-17 18:27:26 +0300 (In reply to Vitaly Chikunov from comment #5) > А что это за пакет таймаутит? Если std/un-def ядро, то там же таймаут 300 и 999 секунд. (А во втором случае еще надо время чтоб прогнать все тесты.) Неужто ядро грузится больше 300 секунд? 217574 7 vt 2022-11-17 18:29:41 +0300 (In reply to Vitaly Chikunov from comment #6) > Неужто ядро грузится больше 300 секунд? Если да, то это не связанная проблема. И вам надо или пропускать %check или придумывать решение, может есть какие-то опции чтоб ускорить загрузку с 255 cpu. Есть ли лог? 217576 8 nickel 2022-11-17 18:38:10 +0300 (Ответ для Vitaly Chikunov на комментарий #7) > (In reply to Vitaly Chikunov from comment #6) > > Неужто ядро грузится больше 300 секунд? > > [...] Скорее всего виновато отстутствие проброса /dev/kvm в хэшер и, соответственно, отсутствие аппаратной виртуализации - поэтому так долго. Если существуют сценарии такого использования, то таймаут маловат. Если не существует, то после проброса должно заработать. Проверю. 217579 9 vt 2022-11-17 18:41:28 +0300 Одно из решений, но видимо не оптимальное - добавить в append lpj= lpj=n [KNL] Sets loops_per_jiffy to given constant, thus avoiding time-consuming boot-time autodetection (up to 250 ms per CPU). 0 enables autodetection (default). To determine the correct value for your kernel, boot with normal autodetection and see what value is printed. Note that on SMP systems the preset will be applied to all CPUs, which is likely to cause problems if your CPUs need significantly divergent settings. An incorrect value will cause delays in the kernel to be wrong, leading to unpredictable I/O errors and other breakage. Although unlikely, in the extreme case this might damage your hardware. Но требует 1 загрузки, чтоб узнать правильное значение (то есть не универсально и нельзя выставить заранее) и при неправильном значении может приводить к ошибкам в работе ядра. 217580 10 vt 2022-11-17 18:43:53 +0300 (In reply to Николай Костригин from comment #8) > Скорее всего виновато отстутствие проброса /dev/kvm в хэшер и, > соответственно, отсутствие аппаратной виртуализации - поэтому так долго. То есть это 1й тест на полной эмуляции с таймаутом 300. timeout 300 vm-run uname -a 217582 11 vt 2022-11-17 18:44:48 +0300 (In reply to Vitaly Chikunov from comment #10) > (In reply to Николай Костригин from comment #8) > > Скорее всего виновато отстутствие проброса /dev/kvm в хэшер и, > > соответственно, отсутствие аппаратной виртуализации - поэтому так долго. > > То есть это 1й тест на полной эмуляции с таймаутом 300. > > timeout 300 vm-run uname -a Тогда было ошибкой делать такое же число cpu как в host системе! 217585 12 nickel 2022-11-17 18:54:41 +0300 (Ответ для Николай Костригин на комментарий #8) > > [...] > > Скорее всего виновато отстутствие проброса /dev/kvm в хэшер > [...] > Проверю. Все так и есть. C /dev/kvm собирается нормально и проходит тесты. task #310175: try #1 is AWAITING 217587 13 vt 2022-11-17 19:05:51 +0300 (In reply to Николай Костригин from comment #12) > (Ответ для Николай Костригин на комментарий #8) > > > [...] > > > > Скорее всего виновато отстутствие проброса /dev/kvm в хэшер > > [...] > > Проверю. > > Все так и есть. C /dev/kvm собирается нормально и проходит тесты. > task #310175: try #1 is AWAITING Ок я потом сделаю - если точно нет kvm то maxcpu, скажем, 4. 217599 14 vt 2022-11-17 23:59:15 +0300 (In reply to Vitaly Chikunov from comment #2) > И думаю --nprocs должно поддерживаться. Понял почему не работает, опечатка. [ -v NPROC ] || NPROC=$(nproc) 217600 15 vt 2022-11-18 01:39:03 +0300 Сделал тестовое задание https://git.altlinux.org/tasks/310189/ - vm-run: Define MAXCPU=255 for x86_64 - пофикшена поддержка NPROCS - при отсутствии KVM ограничивает MAXCPU=4 - Экспериментально, --cpu= устанавливает любое кол-во ядер, которое запросил пользователь, то есть эта опция для экспериментов в hsh-shell "что будет если столько-то ядер", а не для спеков/продакшена. 217601 16 vt 2022-11-18 01:45:22 +0300 Кстати, у меня без KVM (-M accel=tcg -smp cores=255) 255 ядер грузится всего за ~25 секунд. [ 4.406779] smp: Bringing up secondary CPUs ... [ 4.411196] x86: Booting SMP configuration: ... [ 26.284550] smp: Brought up 1 node, 255 CPUs 217602 17 repository-robot 2022-11-18 07:00:30 +0300 rpm-build-vm-1.37-alt3 -> sisyphus: Thu Nov 17 2022 Nikolai Kostrigin <nickel@altlinux> 1.37-alt3 - vm-run: Define MAXCPU=255 for x86_64 (closes: #44337). 217633 18 nickel 2022-11-18 15:37:44 +0300 (Ответ для Vitaly Chikunov на комментарий #15) > Сделал тестовое задание > https://git.altlinux.org/tasks/310189/ > [...] Из-за того, что мое задание уже провалилось в Сизиф придется немного переделать. Плюс, хотелось бы видеть эти изменения в p10, но бэкпорту мешает поломка сборки с gcc10. Патчик прилагаю. С предложенными изменениями потестировал. С аппаратной виртуализацией отрабатывают оба теста секции check с 255 ядрами. Без аппаратной - тоже (калибровка пропускается, выбрано 4 ядра, запускается только 1й тест): [...] [ 9.249991] Calibrating delay loop (skipped), value calculated using timer frequency.. 4899.99 BogoMIPS (lpj=2449998) [ 9.251060] pid_max: default: 32768 minimum: 301 [ 9.252136] LSM: Security Framework initializing [ 9.253065] Yama: becoming mindful. [ 9.254079] AltHa disabled. [ 9.254642] Kiosk: Netlink family registered. [ 9.257554] Mount-cache hash table entries: 262144 (order: 9, 2097152 bytes, linear) [ 9.260001] Mountpoint-cache hash table entries: 262144 (order: 9, 2097152 bytes, linear) [ 9.282601] process: using AMD E400 aware idle routine [ 9.282924] Last level iTLB entries: 4KB 512, 2MB 255, 4MB 127 [ 9.283026] Last level dTLB entries: 4KB 512, 2MB 255, 4MB 127, 1GB 0 [ 9.440226] Freeing SMP alternatives memory: 36K [ 9.572359] smpboot: CPU0: AMD QEMU Virtual CPU version 2.5+ (family: 0xf, model: 0x6b, stepping: 0x1) [ 9.579388] Performance Events: PMU not available due to virtualization, using software events only. [ 9.581419] rcu: Hierarchical SRCU implementation. [ 9.586782] NMI watchdog: Perf NMI watchdog permanently disabled [ 9.591036] smp: Bringing up secondary CPUs ... [ 9.594336] x86: Booting SMP configuration: [ 9.594446] .... node #0, CPUs: #1 #2 #3 [ 9.793931] smp: Brought up 1 node, 4 CPUs [ 9.794082] smpboot: Max logical packages: 1 [ 9.794157] ---------------- [ 9.794201] | NMI testsuite: [ 9.794242] -------------------- [ 9.794289] remote IPI: ok | [ 9.795434] local IPI: ok | [ 9.795851] -------------------- [ 9.795934] Good, all 2 testcases passed! | [...] При передаче --nprocs=230 хэшеру (при аппаратной виртуализации) сквозной передачи в vm-run не произошло. [...] + time qemu-system-x86_64 -M accel=kvm:tcg -m 230555M -smp cores=255 -nodefaults -nographic -no-reboot -fsdev local,id=root,path=/,security_model=none,multidevs=remap -device virtio-9p-pci,fsdev=root,mount_tag=virtio-9p:/ -device virtio-rng-pci -serial mon:stdio -kernel /usr/src/tmp/kernel-image-std-def-buildroot/boot/vmlinuz-5.10.153-std-def-alt1 -initrd /usr/src/tmp/initramfs-5.10.153-std-def-alt1.img -sandbox on,spawn=deny -bios bios.bin -append 'console=ttyS0 mitigations=off nokaslr panic=-1 SCRIPT=/usr/src/tmp/tmp.qIxfAdCnPy NOTTY no_timer_check' qemu-system-x86_64: warning: Number of SMP cpus requested (255) exceeds the recommended cpus supported by KVM (240) qemu-system-x86_64: warning: Number of hotpluggable cpus requested (255) exceeds the recommended cpus supported by KVM (240) [...] [ 3.144898] #249 [ 0.089863] kvm-clock: cpu 249, msr 1012a2e41, secondary cpu clock [ 3.147006] kvm-guest: stealtime: cpu 249, msr 37a8276080 [ 3.151836] #250 [ 0.089863] kvm-clock: cpu 250, msr 1012a2e81, secondary cpu clock [ 3.154579] kvm-guest: stealtime: cpu 250, msr 37a82b6080 [ 3.159829] #251 [ 0.089863] kvm-clock: cpu 251, msr 1012a2ec1, secondary cpu clock [ 3.162104] kvm-guest: stealtime: cpu 251, msr 37a82f6080 [ 3.167941] #252 [ 0.089863] kvm-clock: cpu 252, msr 1012a2f01, secondary cpu clock [ 3.169951] kvm-guest: stealtime: cpu 252, msr 37a8336080 [ 3.174829] #253 [ 0.089863] kvm-clock: cpu 253, msr 1012a2f41, secondary cpu clock [ 3.177637] kvm-guest: stealtime: cpu 253, msr 37a8376080 [ 3.182867] #254 [ 0.089863] kvm-clock: cpu 254, msr 1012a2f81, secondary cpu clock [ 3.184655] kvm-guest: stealtime: cpu 254, msr 37a83b6080 [ 3.189602] smp: Brought up 1 node, 255 CPUs [ 3.190583] smpboot: Max logical packages: 1 [ 3.191582] ---------------- [ 3.192583] | NMI testsuite: [ 3.193581] -------------------- [ 3.194581] remote IPI: ok | [ 3.196581] local IPI: ok | [ 3.197610] -------------------- [ 3.198581] Good, all 2 testcases passed! | [ 3.199581] --------------------------------- [ 3.200592] smpboot: Total of 255 processors activated (1249500.00 BogoMIPS) [ 3.227644] devtmpfs: initialized [ 3.228630] x86/mm: Memory block size: 128MB [ 3.240662] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 1911260446275000 ns После исправления spec-файла ядра и передачи vm-run параметра --cpu=220 количество ядер VM изменилось соответствующим образом: [ 4.458201] kvm-guest: stealtime: cpu 218, msr 37874b6080^M [ 4.463041] #219^M [ 0.086574] kvm-clock: cpu 219, msr 1011766c1, secondary cpu clock^M [ 4.465454] kvm-guest: stealtime: cpu 219, msr 37874f6080^M [ 4.472809] smp: Brought up 1 node, 220 CPUs^M [ 4.473794] smpboot: Max logical packages: 1^M [ 4.474793] ----------------^M [ 4.475792] | NMI testsuite:^M [ 4.476792] --------------------^M [ 4.477792] remote IPI: ok |^M [ 4.479793] local IPI: ok |^M [ 4.480830] --------------------^M [ 4.481793] Good, all 2 testcases passed! |^M [ 4.482792] ---------------------------------^M [ 4.483805] smpboot: Total of 220 processors activated (1078000.00 BogoMIPS)^M Вроде, все как задумано? 217634 19 11898 nickel 2022-11-18 15:39:37 +0300 Created attachment 11898 исправление сборки с gcc10 при бэкпорте в p10 Просьба эти изменения бэкпортировать и в p10. Спасибо. 217648 20 vt 2022-11-18 18:52:14 +0300 > При передаче --nprocs=230 хэшеру (при аппаратной виртуализации) сквозной передачи в vm-run не произошло. На что влияет --nprocs= в hsh я не знаю. Я "пофиксил" лишь поддержку NPROCS переменной окружения - она задает максимальное значение (которое может быть и меньше в зависимости от других причин). 217649 21 vt 2022-11-18 19:01:25 +0300 (In reply to Vitaly Chikunov from comment #20) > На что влияет --nprocs= в hsh я не знаю. На макрос %__nprocs, тогда можно добавить еще его поддержку. 217653 22 vt 2022-11-18 20:00:00 +0300 Послал на сборку задание #310189 - должно все работать, наверное через час сделаю ему коммит и можно отправлять в p10. 217701 23 nickel 2022-11-21 11:12:23 +0300 (Ответ для Vitaly Chikunov на комментарий #22) > Послал на сборку задание #310189 - должно все работать, наверное через час > сделаю ему коммит и можно отправлять в p10. Спасибо. Отправил на тестирование в p10 в #310378 11880 2022-11-17 13:59:37 +0300 2022-11-17 13:59:37 +0300 предлагаемое исправление 0001-vm-run-Define-MAXCPU-255-for-x86_64.patch text/plain 871 nickel RnJvbSA4N2M4NmUyMjAxN2ZhZjA1MmNlYWUwODNkMDFmNGY4YjA4ZGM4ZGQ1IE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBOaWtvbGFpIEtvc3RyaWdpbiA8bmlja2VsQGFsdGxpbnV4Lm9y Zz4KRGF0ZTogVGh1LCAxNyBOb3YgMjAyMiAxMzozMDo1MCArMDMwMApTdWJqZWN0OiBbUEFUQ0hd IHZtLXJ1bjogRGVmaW5lIE1BWENQVT0yNTUgZm9yIHg4Nl82NAoKVGhpcyBmaXhlcyBhdXRvZGV0 ZWN0aW9uIGlzc3VlIGZvciBtYWNoaW5lIHdpdGggbW9yZSB0aGFuIDI1NSBsb2dpY2FsIGNvcmVz OgoKInFlbXUtc3lzdGVtLXg4Nl82NDogSW52YWxpZCBTTVAgQ1BVcyAyNTYuIFRoZSBtYXggQ1BV cyBzdXBwb3J0ZWQgYnkgbWFjaGluZQoncGMtaTQ0MGZ4LTYuMicgaXMgMjU1IgoKTGluazogaHR0 cHM6Ly9idWd6aWxsYS5hbHRsaW51eC5vcmcvNDQzMzcKU2lnbmVkLW9mZi1ieTogTmlrb2xhaSBL b3N0cmlnaW4gPG5pY2tlbEBhbHRsaW51eC5vcmc+Ci0tLQogdm0tcnVuIHwgMSArCiAxIGZpbGUg Y2hhbmdlZCwgMSBpbnNlcnRpb24oKykKCmRpZmYgLS1naXQgYS92bS1ydW4gYi92bS1ydW4KaW5k ZXggMDI4ZjY5MS4uNTRiODM0NSAxMDA3NTUKLS0tIGEvdm0tcnVuCisrKyBiL3ZtLXJ1bgpAQCAt Mjc0LDYgKzI3NCw3IEBAIGNhc2UgIiRIT1NUVFlQRSIgaW4KIAkJUEFDS0FHRT1xZW11LXN5c3Rl bS14ODYtY29yZQogCQlDT05TT0xFPXR0eVMwCiAJCVFFTVU9cWVtdS1zeXN0ZW0teDg2XzY0CisJ CU1BWENQVT0yNTUKIAkJRURLMj0vdXNyL3NoYXJlL09WTUYKIAkJRUZJX0NPREU9T1ZNRl9DT0RF LmZkCiAJCVNCX1BGTEFTSD0iT1ZNRl9DT0RFLnNlY2Jvb3QuZmQgT1ZNRl9WQVJTLnNlY2Jvb3Qu ZmQiCi0tIAoyLjMzLjUKCg== 11898 2022-11-18 15:39:37 +0300 2022-11-18 15:39:37 +0300 исправление сборки с gcc10 при бэкпорте в p10 0001-fakesudo.c-fix-build-with-gcc10.patch text/plain 1039 nickel RnJvbSA3Y2EwMDEwNzczNzlkZTczZTg5ZDMyYTlhOWM2ZDc3M2NkM2FhOGMzIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBOaWtvbGFpIEtvc3RyaWdpbiA8bmlja2VsQGFsdGxpbnV4Lm9y Zz4KRGF0ZTogRnJpLCAxOCBOb3YgMjAyMiAxNDoyMzo0MiArMDMwMApTdWJqZWN0OiBbUEFUQ0hd IGZha2VzdWRvLmM6IGZpeCBidWlsZCB3aXRoIGdjYzEwCgpDOTkgZG9lc24ndCBhbGxvdyB0byBw dXQgZGVjbGFyYXJpb24gcmlnaHQgYWZ0ZXIgYSBsYWJlbCwgc28gcHV0CmFuIGVtcHR5IHN0YXRl bWVudCBiZXR3ZWVuIHRoZW0uCgpmYWtlc3Vkby5jOjExOTo1OiBlcnJvcjogYSBsYWJlbCBjYW4g b25seSBiZSBwYXJ0IG9mIGEgc3RhdGVtZW50IGFuZAphIGRlY2xhcmF0aW9uIGlzIG5vdCBhIHN0 YXRlbWVudAogIDExOSB8ICAgICBjaGFyIGhuW0hPU1RfTkFNRV9NQVhdID0ge307CiAgICAgIHwg ICAgIF5+fn4KClNpZ25lZC1vZmYtYnk6IE5pa29sYWkgS29zdHJpZ2luIDxuaWNrZWxAYWx0bGlu dXgub3JnPgotLS0KIGZha2VzdWRvLmMgfCAyICstCiAxIGZpbGUgY2hhbmdlZCwgMSBpbnNlcnRp b24oKyksIDEgZGVsZXRpb24oLSkKCmRpZmYgLS1naXQgYS9mYWtlc3Vkby5jIGIvZmFrZXN1ZG8u YwppbmRleCA2YjFlMTE1Li4xYmVmYWNjIDEwMDY0NAotLS0gYS9mYWtlc3Vkby5jCisrKyBiL2Zh a2VzdWRvLmMKQEAgLTExNSw3ICsxMTUsNyBAQCBpbnQgbWFpbihpbnQgYXJnYywgY2hhciAqKmFy Z3YpCiAJCQljYXNlICdUJzoKIAkJCQlwcmludGYoImZha2VzdWRvOiB5b3UgYXJlIG5vdCBwZXJt aXR0ZWQgdG8gdXNlIHRoZSAtJWMgb3B0aW9uXG4iLCBjaCk7CiAJCQkJZXhpdCgxKTsKLQkJCWNh c2UgJ2wnOgorCQkJY2FzZSAnbCc6IDsKIAkJCQljaGFyIGhuW0hPU1RfTkFNRV9NQVhdID0ge307 CiAJCQkJZ2V0aG9zdG5hbWUoaG4sIHNpemVvZiBobik7CiAJCQkJcHJpbnRmKCJVc2VyICVzIG1h eSBydW4gdGhlIGZvbGxvd2luZyBjb21tYW5kcyBvbiAlczpcbiIsIG1lLT5wd19uYW1lLCBobik7 Ci0tIAoyLjMzLjUKCg==