Orz日記 by Akio Morita

_ [SAD]list2array module

内部関数の命名案

• 語幹
  • list2rarrayN - 実数配列への展開(次数 N)
  • list2carrayN - 複素数配列への展開(次数 N)
• 接尾辞
  • _alloc - allocatableへの割り当て
  • _shared - mmap_shared割り当て(pointer)
  • _private - mmap_private割り当て(pointer)

pointer型へのFortran allocate文による割り当てもありえるが、局所スコープ内で使うことが前提とする場合は、必要ない

_ [FreeBSD][雑記]12-PRERELESEへ移行

12.0-RC3も順調なようなので、主要環境をstable/11からstable/12へ切り替え実施

portsのrebuildによるpackage更新がコンパイル約12時間はよいが、portupgradeによる依存性検査に4〜6時間程度かかっているのが頂けない(Core i7 6700)

_ [SAD]list2array_utils完成

取り合えず、最低限の機能を実装して、LAPACK拡張からitfmaloc/itfcmalocを削除してみた

問題なく動いている模様なので、SAD本体側も順次置き換えて行く

実は、Fortran arrayからSADのListコンテナへ変換する関数群に実ベクトルのサポートが無いのは不便ではないだろうか

置き換え作業の順番的には

1. mapallocを含むitfmalocpをlist2array_sharedで置き換える
   • src/temap.f (itfmaloc互換の呼び出し)
   • src/tfdot.f (itfmaloc互換の呼び出し)
   • src/tffswake.f (itfmaloc互換の呼び出し)
   • src/tftrack.f (map付き呼び出し)
2. itfmalocpからmap引数を削除したitfmalocへ切り替えてmapallocをstatic関数に落とす(ifdefでlmalloc系からの内部参照がある)
3. itfmaloc/itfcmalocを置き換える

_ [SAD]itfmalocp use case

src/tfdot.fの実装にて、type mismatch時に一般化された処理へ移譲するケースで、General::memoryfullのみを報告して欲しいケースがあるので、 list2array interfaceのirtc引数の後にoptionalな制御フラグを追加する必要がある

_ [SAD]itfmaloc系の書き換え

• src/tffswake.f以外のFortranコードは書き換え完了
  • 動作確認等を実施すべき
• Cコードに当該呼び出しを含むモジュールが存在する
  • ExtendedTwiss
  • Wake
  • Standard/SpaceCharge/Scheff
  • Standard/SpaceCharge/Scheff/MatrixFunctions
  • 効率的なインターフェースを考える必要がある
  • 動的な2次元配列型をC上で効率的に扱えるか？
• 実数配列から、リストを作る操作で、書き方がブレている
  • itfm2lの様な関数で表現を統一すると読みやすくなる(要検討)
• tffswakeに関しては、beamline element毎にポテンシャルを展開した配列を管理するのに、SADのobject heapを使っている
  • ただし、ルートノードは COMMONブロック上に存在している
  • 配列pointerの割付配列を用意して書き換えることを検討する

_ [SAD]itfmaloc.fの整理作業まとめ

• tfmsize(作業完了)
  • list2array_utils内の MatrixQで置き換え可能
  • 真偽値を返す関数なので、適切にirtc/itfmessageを呼び出すコードが書く必要がある
  • また、現在は private functionなので publicへ切り替える必要がある
• itfmaloc(作業完了 2018.12.19)
  • Cモジュールからの呼び出しがある(src/sim/sad_api.cにwrapper有り)
  • list2array_utilsに、mallocしたFortran配列を返すAPIを用意するのが得策
  • bind(C)で定義して、src/sim側には関数プロトタイプのみを用意する
• itfmalocp
  • src/tffswake.fでWakePotentialを展開した2次元配列を得るのに使っている
  • 割り当てた配列は、Beamline要素毎のテーブルとして連結され、tturn等で参照される
  • pointerベースで実装しなおす
    • ルートノード及び操作コードの同定
    • 永続化させるデータ構造の設計と実装
      • 同一の2次元配列を複数箇所から参照する設計なので、destruction管理のために、参照カウンタが必要
• それ以外
  • 基本的にFortran配列からListオブジェクトの生成API
  • C bindingを考えるとbind(C)で定義したinterface moduleをuseする方が良い？
    • src/sim側のwrapperが不要になる
  • 命名規則の再設計をした方が良いか？

_ [SAD]ExternalMapでCAVIが作れない

qcopymat関連のバグ修正がらみで、見つけた問題

ExternalMapで加速・減速を定義できない

_ [FreeBSD][Ryzen]HTTオフ時にsysutils/powerdxxがクラッシュする件

loader tunable(machdep.hyperthreading_allowed=0)でHTTをdisableした状態で、起動するとsysctl(3)のENOMEMエラーで起動しない件だが、 kern.cp_times sysctlが返す配列サイズがhw.ncpuでは無く、kern.smp.maxid+1で決まっているためにsysctl(3)呼び出し時のバッファサイズ不足で落ちる

有効なcp_timesは、先頭のhw.ncpu個分だけなので、バッファ確保時とsysctl(3)呼び出し時の長さにkern.smp.maxid + 1を用いれば解決する (maxidなので、0から始まるcpu番号の最後で +1しないと個数にならない)

ちなみにkern.smp.cpusはhw.ncpu同様に現時点で有効なthread数になっている模様

別解として、+1するのが面倒ならkern.smp.maxcpusを使うという手もある(標準だと256で、Ryzen TR2 2950Xだと高々8倍なので対した消費ではないはず)

_ [雑記]家のコアスイッチが落ちた落ちたぽぃ

今朝、7時過ぎにお家ネットワークの基幹鯖のLANが変なリンクダウンして、13分後に復帰した

Dec 27 07:10:04 aeka kernel: ix0: TX(0) desc avail = 34, pidx = 1785
Dec 27 07:10:04 aeka kernel: ix0: link state changed to DOWN
Dec 27 07:10:04 aeka kernel: ix0.2: link state changed to DOWN
Dec 27 07:10:05 aeka kernel: ix0: link state changed to UP
Dec 27 07:10:05 aeka kernel: ix0.2: link state changed to UP
Dec 27 07:10:05 aeka kernel: ix0: link state changed to DOWN
Dec 27 07:10:05 aeka kernel: ix0.2: link state changed to DOWN
Dec 27 07:10:11 aeka kernel: ix0: link state changed to UP
Dec 27 07:10:11 aeka kernel: ix0.2: link state changed to UP
Dec 27 07:18:28 aeka su[97256]: amorita to root on /dev/pts/5
Dec 27 07:23:11 aeka kernel: ix0: link state changed to DOWN
Dec 27 07:23:11 aeka kernel: ix0.2: link state changed to DOWN
Dec 27 07:23:11 aeka kernel: ix0: link state changed to UP
Dec 27 07:23:11 aeka kernel: ix0: link state changed to DOWN
Dec 27 07:23:11 aeka kernel: ix0.2: link state changed to DOWN
Dec 27 07:23:12 aeka kernel: nd6_dad_timer: cancel DAD on ix0.2 because of ND6_IFF_IFDISABLED.
Dec 27 07:23:17 aeka kernel: ix0: link state changed to UP
Dec 27 07:23:17 aeka kernel: ix0.2: link state changed to UP

以後、LAN側で通信不能になっているっぽぃ

トラブルシュートの過程

1. /etc/rc.d/netif restartとDHCP鯖の再起動してもLAN側の機器と疎通確認出来ない
2. メイン鯖(DHCP鯖兼ルータ)をshutdownして、cold restartしてもLAN側の機器と疎通確認出来ない
   • wiresharkで覗くと、DHCP Requestは鯖に届いているようだが、他の通信が成立しないっぽぃ
3. LANのコアスイッチ(S3300-28X)のcold restartで、LAN側の通信復帰

どうやら、コアスイッチがハングアップしていたっぽぃ

今回の教訓

• インターフェースがリンクアップ状態でも、スイッチファブリックが機能喪失するハングアップがある
• コアスイッチのハングアップ時に鯖からリブートする手段が無い
  • PDCはUPS系外にある(コアスイッチはUPS系)
  • PDCへのネットワーク経路がTagged VLANでコアスイッチを通過する

_ [SAD]jlist掃除 in Cコード

sad_cstrマクロによるstringポインタ参照に書き換える作業を進行中

残っているのは

• src/tfProcess_.c
• src/tfFileIO_.c
• src/tfXlib_.c

_ [SAD]itflist掃除 in Cコード

itflistを使ってon-stack list constructionしているコードを明示的なlistコンテナ割り当てとtfsetlistで書き換える作業を進行中

長大なリストが戻ってくる可能性がある部分では、mstk検査をしていないので stack corruptionの危険が生じている

残っているのは

• src/tfTkInter_.c
• src/tfProcess_.c

_ [SAD]itfmalocp整理

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

_ [SAD]helper関数のアイデア

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

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

• Reals時に、Type/Addr配列ハンドルを要求された際の動作
• NonReals時に、Real配列ハンドルを要求された際の動作

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

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

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

_ [SAD]implicit宣言コード

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

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

_ [FreeBSD][Ryzen]Ryzen Threadripper 2950X

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

耐久ストレステストの内容は、最大並列度でのエンドレス 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の熱暴走によるハングアップではなさそう
  • 冷却強化状態で、Tctl 80℃程度に収まっている
• ブースト機能等が効き易くなってハングアップ頻度が上がったとすると、実行時の競合系のエラッタを踏んでいる？

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

• powerd++による P-stateの動的変更
• NVMeストレージ系の不具合

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

_ [艦これ]2019冬イベ開始

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

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

_ [FreeBSD][Ryzen]Ryzen Threadripper 2950Xストレステスト

下記の試験条件で、34時間25分でハングアップ

• ASRock X399M Taichi beta BIOS 3.22A(ThreadRipperPI-SP3r2 1.1.0.2)
• SMT off(machdep.hyperthreading_allowed=0)
• Errata workaround適用(1021, 1033, 1049, 1091, 1095, 1109)
• powerdなしで、P-state固定(dev.cpu.0.freq=2200)
• NVMeなし・SATA SSD1台構成
• Tctl 80℃以下を維持する冷却
• FreeBSD 12-STABLEにて、make -j16 buildworld buildkernelをエンドレス実行

どうやら、動的なP-state変更とNVMeは直接の原因では無い模様

万策尽きてきた感が…

まだ、冷却系を出力全開にしていないので、CPU系の動作不良が原因ならさらに動作温度を下げるとか、コア電圧を盛って改善するかを確かめるという手が残っている(Threadripper1の初期出荷版で起こったRayzen SEGV Battleでは、電圧を盛ると動作が改善するケースが報告されていたようだったがはたして)

_ [雑記]家LAN障害再び

一昨日のLAN落ちと似た障害が発生

前回と異なり、今度は ix0が再リンクせずにダウンしっ放しの状態に Orz

1. ifconfigでdown/upしたり、LANケーブルを抜き差ししても再リンクしない(status: no carrierでNIC側のLED消灯状態)
2. ix0は Intel X550-T2の第一ポートなので、予備の第二ポート(ix1)にケーブルを差し替えてifconfig upするとリンクする

どうやら予備のix1側のポートは稼働するので、ケーブル差し替え＆鯖の設定を変更してリブート(ホットリスタート)して家LANを復帰させる

どうやら、スイッチ側ではなく、鯖のNIC側の問題の模様

/var/log/messageによれば、14:05頃からdhcpdがパケットの送出に失敗している

Dec 29 13:53:19 aeka sshguard[1507]: Attack from "122.226.181.167" on service 100 with danger 10.
Dec 29 13:55:23 aeka sshguard[1507]: Attack from "36.156.24.94" on service 100 with danger 10.
Dec 29 13:56:14 aeka sshguard[1507]: Attack from "124.13.47.41" on service 100 with danger 10.
Dec 29 14:05:54 aeka dhcpd[1405]: send_packet: Host is down
Dec 29 14:05:54 aeka dhcpd[1405]: dhcp.c:4023: Failed to send 307 byte long packet over fallback interface.

14:53頃に一瞬リンクが途絶し、直後に再度リンクダウンし以降復帰していない

Dec 29 14:41:26 aeka sshguard[1507]: Attack from "59.11.138.177" on service 100 with danger 10.
Dec 29 14:45:46 aeka sshguard[1507]: Attack from "71.6.232.6" on service 100 with danger 10.
Dec 29 14:53:02 aeka kernel: ix0: TX(0) desc avail = 34, pidx = 1264
Dec 29 14:53:02 aeka kernel: ix0: link state changed to DOWN
Dec 29 14:53:02 aeka kernel: ix0.2: link state changed to DOWN
Dec 29 14:53:02 aeka kernel: ix0: link state changed to UP
Dec 29 14:53:02 aeka kernel: ix0.2: link state changed to UP
Dec 29 14:53:03 aeka kernel: ix0: link state changed to DOWN
Dec 29 14:53:03 aeka kernel: ix0.2: link state changed to DOWN
Dec 29 14:53:04 aeka kernel: ix0: TX(0) desc avail = 2048, pidx = 0
Dec 29 14:53:33 aeka syslogd: last message repeated 16 times

その後は、ix0: TX(0) desc avail = 2048, pidx = 0を出しつづけている (メッセージの出力元は、sys/net/iflib.c)

状況からすると、可能性としては

• X550-T2の第一ポートのハードウェアの不良
• ix driverの不具合で、ethernetコントローラがおかしな状態に入っている
  • 12/27の障害時のようにコールドリスタートした際に第一ポートが復帰するか確認していない
  • ホットリスタート後の状態で、第一ポートをifconfig upしてケーブルを挿すと物理リンクは確立する(IPレベルの通信は検証していない)

ポート単位のハードウェア障害だとすると、症状が進行している？

それとも、12/27の障害後にスイッチのファームウェア更新で挙動が変わった？

ix driver側の更新は、直近は 2018/12/04の r341427、その前は 2018-10-14の r339354

現在のカーネルは 12/15にビルドした r342079M

その前のカーネルは 12/09にビルドした r341726M

単純に ix driver起因なら、最初の発生が12/27でコールドリスタート後の再発生が12/29なので発生頻度的に、もっと前に起こっていた可能性が高いと考えられる

やはり、NICのポート故障の線かなぁ… 予備を用意しないと Orz

X550-T2の購入時期は2016/08頃、運用投入は2016/11/12なので、運用期間だと2年強なので寿命にしては短い気が…