唯一の参照元src/tffswake.fが管理するデータ構造と影響範囲の解析完了
新しいデータ構造の基本設計完了
common block上の iwakeoldpと一部関係があるが、こっちはどうする？
- k64系では、データ構造は廃止されている
- FFSコマンドに関しては、WAKEコマンドのみSADScriptによる再実装、その他の関連コマンドは廃止されている(要解析)

list containerからReal配列ハンドルや Type/Addr配列ハンドルを取り出す操作があるが、内部のデータ構造を隠蔽する為の抽象化helperを用意すべきでは？

検討すべきコーナーケース

多分、NULLを返すのが妥当？

container生成時だけは、書き込みの為にnon-constである必要があるが、参照用途では、constハンドルを返すべきと考えられる

const/non-constで、helperを分離すべきか？ (C++と異なり、proxy objectによるtype dispatchは行えない)

includeされているcommon宣言をmoldule化作業で自動検査の障害となるimplicit宣言を含むsrc/inc/*.incの参照

数量的には、TMACRO.incからやっつけるべき？

基本的な仕込みは終わったので、耐久ストレステストに入ったのだが、未だに安定しない

耐久ストレステストの内容は、最大並列度でのエンドレス buildworld + buildkernel

現在の最長記録は36時間程度で、なぜかハングアップする状況

少なくとも、Ryzen TR1の初期出荷分で発生したSEGV系の不具合ではない

原因の洗い出しと対策のために色々試しているが未だに解決していない Orz

UEFI firmware ASRockの最新のbeta版(Threadripper回りのCPU firmwareが更新されている為)
kernel 最新の12-STABLEを使用
AMD RyzenのErrataリストから 1021, 1033, 1049, 1057, 1091, 1095, 1109に関してはcputontolによるMSRパッチとmachdep syscltによるworkaroundを適用(データーレース・ハグアップ系の対策可能なエラッタ)

この状態でもハングアップするので、さらにSMT回りのデータレース等を疑ってmachdep.hyperthreading_allowed=0にてSMTを殺した状態も試したが、ハングアップする

Tjmaxの超過による熱暴走系を疑って、冷却系の設定を変更してTjを10℃程度低下させたところ、24時間も持たずに30分以内にハングアップした(2回)

CPUのエラッタ以外の可能性として疑っているのは

現在、メインストレージを SATA SSDに切り替えNVMeを切り離した状態かつい、CPU P-stateを固定した状態で、ストレステストを実施中

E-1甲作戦 18:48スタート、20:53 クリア

E-1からラスダン編成が固い Orz