Open masamichitakagi opened 3 years ago
RHEL-8.4 alphaは入手できませんので、富士通様で検証していただけないでしょうか。 また、1.7.1-0.7を使用してください。 よろしくお願いいたします。
髙木さん、
張です。
RHEL-8.4 alphaは入手できませんので、富士通様で検証していただけないでしょうか。 また、1.7.1-0.7を使用してください。 よろしくお願いいたします。
承知しました。
すみません。degradationを見つけたため、1.7.1-0.9で試していただけないでしょうか。 お手数をおかけいたしますが、よろしくお願いいたします。
髙木さん、
張です。
承知しました。
1.7.1-0.9でやり直します。
以下3点を実施し、RHEL8.4alpha上でのMcKernel起動に成功することを確認しました。 1.vdso_specのシンボル変更 2.RHEL8.4のVDSOデータ領域の情報格納場所変更によるNULLアクセスの回避 3.ビルドエラーの解消
ただし、RTを実施したところ、概算で44件のNG増加の状況になっています。
今後の対応について、相談させてください。
RTのエラーのリストを送っていただけないでしょうか。[高木] rpm作成時のオプションのミスを疑っています。
base mckernel version:1.7.1-0.92
=== RHEL8.4環境+RHEL8.4対応パッチ、RHEL8.3環境どちらもNGだった項目 ・sve#41 vl:64/32/16 mcexecに投入下GDBがSIGSEGVになる or mcexecがハングする ・munlock#0、rt_sigaction #0-5、fork#0、pause#0、sigaltstack #0,1、ptrace #0-3 prepare: Cannot allocate memory 直前に実行しているmem_stack_limits#3が影響している可能性が高い。 RHEL8.3の場合、ptrace#5までNGになっていた。 === RHEL8.4環境+RHEL8.4対応パッチだとNGだった項目 ・gettimeofday #0 ・nanosleep#0 ・setitimer#3 ・clock_gettime#0 ・clock_getres#0 ・track_syscalls#0 #vdso関連のRHEL8.4向けパッチの内容に不備がありngとなっている可能性があるため、継続調査します。 === RHEL8.3環境のみNGだった項目 ・mem_limits #3-6 prepare: Cannot allocate memory munlock#0などと類似問題?
以上
以前いただいたビルド方法を使っています。
cmake ../src/mckernel/ \ -DUNAME_R=\ -DKERNEL_DIR= \ -DBUILD_TARGET=smp-arm64 \ -DCMAKE_TOOLCHAIN_FILE=./cmake/cross-aarch64.cmake make dist -j 20 cp mckernel-1.7.1.tar.gz ~/rpmbuild/SOURCES rpmbuild -ba scripts/mckernel.spec \ --target aarch64 \ -D 'kernel_dir '
クロスでのrpm作成時には、以下を参考にcmakeのオプションの確認をお願いいたします。
https://ihkmckernel.readthedocs.io/en/latest/quick.html#installation
具体的には、mckernel.spec以下の行が以下のようになっている確認してください。
-DENABLE_TOFU=ON -DENABLE_FUGAKU_HACKS=ON \ -DENABLE_KRM_WORKAROUND=OFF -DWITH_KRM=ON \ -DENABLE_FUGAKU_DEBUG=OFF \
以前お伝えしていなかったかもしれません。申し訳ございません。
・track_syscalls #0: 以下のパッチを当ててください。
[takagi@rhel ostest]$ git remote -v origin https://github.com/RIKEN-SysSoft/mckernel-ostest-arm64.git (fetch) commit aa9db918730a5ff6f594e7a4aefd26e156809a13 (HEAD -> master, origin/master, origin/HEAD) Author: Masamichi TakagiDate: Tue Jan 5 00:39:13 2021 -0500 track_syscalls (profile): fix syscall number diff --git a/test_mck/src/track_syscalls/testsuite.h b/test_mck/src/track_syscalls/testsuite.h index ce2b471..b327993 100644 --- a/test_mck/src/track_syscalls/testsuite.h +++ b/test_mck/src/track_syscalls/testsuite.h @@ -40,9 +40,21 @@ enum profile_event_type { PROFILE_remote_page_fault, PROFILE_mpol_alloc_missed, PROFILE_mmap_anon_contig_phys, + PROFILE_mmap_anon_straight, + PROFILE_mmap_anon_not_straight, PROFILE_mmap_anon_no_contig_phys, PROFILE_mmap_regular_file, PROFILE_mmap_device_file, + PROFILE_tofu_stag_alloc, + PROFILE_tofu_stag_alloc_new_steering, + PROFILE_tofu_stag_alloc_new_steering_alloc_mbpt, + PROFILE_tofu_stag_alloc_new_steering_update_mbpt, + PROFILE_tofu_stag_free_stags, + PROFILE_tofu_stag_free_stag, + PROFILE_tofu_stag_free_stag_pre, + PROFILE_tofu_stag_free_stag_cqflush, + PROFILE_tofu_stag_free_stag_dealloc, + PROFILE_tofu_stag_free_stag_dealloc_free_pages, PROFILE_EVENT_MAX /* Should be the last event type */ };
・sve#41: 手元にソースがないようなので、いただけないでしょうか。
以下のような制限事項・注意事項を付記することで対応できないでしょうか。 ・sve#41: コアファイルにsveレジスタが正しく格納されないことがある ・mem_stack_limits: スタックに搭載メモリ量より大きな領域を確保するとMcKernelの状態が不安定になることがある ・mem_limits: brk, mmap領域に搭載メモリ量より大きな領域を確保するとMcKernelの状態が不安定になることがある ・track_syscalls: システムコール番号を直して実行したところPASSしたため、PASSとみなしてよい
なお、手元の1.7.1-0.93+kernel-4.18.0.240.8.1(RHEL8.3errata)環境では、mem_limits, mem_stack_limits,munlock#0、rt_sigaction #0-5、fork#0、pause#0、sigaltstack #0,1、ptrace #0-3, track_syscallsはPASSします。
高木様
白鳥です。
sve#41について、TPを提供致します。
実行手順は以下の通りです。
$ tar xf sve_test.tgz $ cd sve_test $ make $ gdb -x ./inf/sve41.inf ./sve_test $ mv ./sve41.log ./sve41.exp $ mcexec gdb -x ./inf/sve41.inf ./sve_test $ diff ./sve41.exp ./sve41.log $ echo $? -> diffの結果が0になることが期待
上記のmcexecがSIGSEGVとなっており、NGとなっております。
=== RHEL8.4環境+RHEL8.4対応パッチ、RHEL8.3環境どちらもNGだった項目 ・sve#41 vl:64/32/16 mcexecに投入下GDBがSIGSEGVになる or mcexecがハングする
RHEL8.3でも再現しているため、RHEL8.4αの問題ではない。
・munlock#0、rt_sigaction #0-5、fork#0、pause#0、sigaltstack #0,1、ptrace #0-3 prepare: Cannot allocate memory 直前に実行しているmem_stack_limits#3が影響している可能性が高い。 RHEL8.3の場合、ptrace#5までNGになっていた。 RHEL8.3でも再現しているため、RHEL8.4αの問題ではない。
=== RHEL8.4環境+RHEL8.4対応パッチだとNGだった項目 ・gettimeofday #0 ・nanosleep#0 ・setitimer#3 ・clock_gettime#0 ・clock_getres#0 ・track_syscalls#0
vdso関連のRHEL8.4向けパッチの内容に不備がありngとなっている可能性があるため、継続調査します。
調査が難航している。 現時点で分かったこと
・OWN/CROSSコンパイラどちらで生成したバイナリであっても発生することがある(逆にうまく行くこともある)のでコンパイラは無関係と思われる
・gettimeofdayシステムコールで獲得出来る時刻(tv_sec/tv_usec)がおかしくなる(システムコールの戻り値は0(成功))ことがある
・獲得されるtv_secの傾向は、とても大きい値(6866941895162555439など)になるか、期待値ではない固定の値(1266734699)になるかのいずれか
・期待通りの値が獲得出来る場合の処理時間は短い(ほぼ即時)が、おかしな値を返す際の処理時間は20秒前後かかる
・sve#41: コアファイルにsveレジスタが正しく格納されないことがある ⇒gdbでa.out実行中にレジスタの情報を見るときにSIGSEGVになるという現象です。 全体的に第三者にどうしてほしいかをMcKernelのドキュメントの制限事項に記載していただきたいと思います。 以下は案です。いかがでしょうか。 ・McKernel上でsve命令を発行するプログラムをgdbでdebugするときにプログラムがSIGSEGVで異常終了する場合がある。 回避策ありませんので、sve命令を発行するプログラムにおいてgdbを利用するdebugを制限とする。 ・McKernel上で大きいメモリを使用するプログラムの実行終了後(mcexecが返ってきた)、すぐ次のプログラムを実行する場合、prepare: Cannot allocate memoryのメッセージがでて、実行できない場合がある。 回避策 直前のプログラム実行終了後、数秒を置いてから次のプログラムを実行してください。
優先度を下げる。8.4betaがリリースされたときに理研に渡す。
髙木さん、
張です。
RHEL8.4のpublic beta版は2月あたりにリリースされるようです。リリースされたら、RHEL8.4向けのMcKernelの提供をお願いできないでしょうか。
また、富士通社内ではα版から検証を始めております。α版で検出したRHELの障害はβ版より容易にGA版に取り込めるからです。
理研側のほうでα版を入手できるのでしょうか。
入手できるのであれば、McKernelのパッケージを提供していただきたいと思います。
入手できない場合、富士通社内でMcKernelのRHEL8.4暫定対応を実施したいと思いますので、どの版数のMcKernelを使用すればよいかを教えていただけますでしょうか。
以上