整形外科。 リハビリテーション。PC 組み立ての時にちょっと無理な姿勢をしたせいか、ここ数日あまり調子は良くない。 たまに怪しい肩こり的痛みが顔を出すし、右手はよくぴくぴくする。
何となくバイク用品店に行ってドライタイプの潤滑剤スプレーを購入。
何となくハードオフに行って PC 用電源装置を購入。 ジャンクコーナーを最初見てみたが、良さそうな感じのは 800 円くらいして、しかも使用感があって、7 年くらい経ったものとなるとリスクが高い。 ジャンクじゃないコーナーに箱付きの KT-F500-12A があったので買った。2,500 円 (税別)。 これも 2010 年頃からあるモデルだが現行品でもあり、ハードオフの 10 日間保証もあり、また、こうして中古に出ているものだから初期不良は無かろう。 一応 500W だがあまり期待しないほうがいいみたい。 まー今の 400W よりは良かろう。
バイク用に使っていた JINS めがねが崩壊してしまった。 どうしよう。
室温 31 度くらいに達していたので冷房をつけた。
テレビでやってた映画『インデペンデンス・デイ』(原題: Independence Day)。1996 年のアメリカ映画。 宇宙人になぜか派手に攻撃されるパニック物。 まー雑に言えばゴジラみたいなもんだな。
きのうの深夜からカーネルビルド make -j16 で tmpfs で 280 回以上、やっと Segmentation fault を拝めたよ。 再現はするみたいだがちまたの噂より頻度が低いんでない? こんな頻度じゃ調査困難だよ。
SATA のエラーが出る件、解決しないので、接続を変えた。B350M-A には AHCI コントローラーがふたつ積まれており、ひとつは 1022:43b7、もうひとつは 1022:7901 でどちらも AMD で、前者を使用していたが、マザーボードの側面についている端子のほうにつなぎ変えたところ、後者が使用されるようになった。 負荷を掛けている間の SATA エラーは出なくなったため、これで解決と見ている。
今朝出かける前に QEMU ビルド make -j16 で tmpfs でやっておいたら、17 回ほどで Illegal instruction が発生。 マジか SIGILL も起きるのか? そしてエラーを吐いてつながらなくなっていた。
何度か起きたハングアップ事象、実際にはたぶん一部のコアが死ぬとか、あるいは割り込みが起きなくなるとか、なんかそんなような内容だと思われる。 起きるパターンは負荷テストを止めてほんの 2, 3 分程度の頃が多い。 何時間も負荷テストをする必要もない。 電源管理まわりの設定を変えると改善するとの噂があるが、設定の仕方がまだわかってない。 目の前で見ているとつながらなくなった時に rcu_sched detected stalls on CPUs/tasks といったメッセージが出て、それから SATA のエラーなどが出てくるが、すでにネットワーク的に切れていて USB キーボードも反応しないということは SATA だけの問題ではない。 画面は映っているから PCIe バス的には生きているか。 これは割り込みが怪しいと思う。
ビルドクラッシュ問題で割り込みが関係あるかと思い、ひたすらパイプで通信し合うプロセスを動かして、割り込み回数を桁違いに増やしてみたけど特に何も起きない。
ffmpeg で動画のエンコードはさすがに速い。A10-7870K の 2 倍以上の速度が出ている気がする。 しかし 3 倍はいかない。SMT はこういう用途にはそこまできかないのかなと。 そして上の問題でエンコード後にぼけっとしてるとそのまま使えなくなってしまうから面倒だ。
あ、そうそう、あと、割り込みが CPU0 に偏ってる。 これは割り込みばらまき機能がきちんと機能していないってこと?
きのうの東名高速・新城 PA 付近でのバスと乗用車の衝突事故が話題。 下り線を走行していた乗用車が、路肩の傾斜に乗り上げて中央分離帯で宙を舞い、上り線の追い越し車線にたまたまいた観光バスに衝突したもの。 事故後停止していたバスを PA から撮ったらしき写真に 261.1 キロポストが映っており、バスは上り線を走行しており、PA 入り口より手前のところで衝突、よろよろと PA の横っちょまで来て止まったというわけだ。
この事故、観光バスのドライブレコーダーから乗用車が飛んだということはわかったが、乗用車の運転手が、よそ見、車両トラブルあるいは障害物をよけようとしたか何かで制御を失ったのか、そもそも意識が無かったのか、そのへんは周囲の車のドライブレコーダー等の情報があがってこない限り、特定困難だろう。 ワイパーが動いているのでパニックになってワイパーのレバーに手が触れたパターンかと思ったが、あの勢いでジャンプしたら何でもあり得るよな。 乗用車の運転手は亡くなってしまったが、バスの乗客乗員は怪我で済んでいるらしく、また、乗用車に同乗者はいなかったようだ。 バスの運転手の的確な判断云々とも言われているが、正直、対向車が飛んだのが見えてからぶつかるまでの 1 秒未満の間に人間にできることはほぼ無い。 自分の印象としては、右側から何かが突っ込んでくると認識して (普通の飛び出しなら一般道では交差点等でよくある光景だろう)、とっさに左にハンドルを回し、ブレーキを掛ける、のが限界かなと思う。 たぶん、なんかやばい程度の認識から実際に筋肉に力が入ってハンドルが回り始めるまでに 0.5 秒近く経つと思う。 ブレーキについては車両に搭載されている自動緊急ブレーキ等のほうが反応は早かったはず、宙を舞う車に反応するかどうかは定かでないが。
今回、相当運が良かったと思うのは、バスの屋根に乗用車が乗っかるような形になったところ、衝突のタイミングがほんの少しズレていただけで、あるいは、ジャンプの高さがちょっと低かっただけで、大きな前ガラスから車内に乗用車が突入していたかも。 また、巻き込まれた対向車が大型車でなく、乗用車や軽自動車や二輪車だったら... 運動エネルギーを考えれば当然のことだが、大型バスは乗用車より遙かに重いので、乗用車を受け止めてもスピードが残っていて、それでゆっくり止まることができた。 もし同じくらいの重さの車両が同じくらいのスピードで正面衝突すれば、双方のスピードは一気に 0 になる。 そうなると死者がもっと増えていたかも。
そして、大型車の突入防止装置の件でも思ったが、安全性が上がった近年の車でも、当たり所が悪ければ、致命傷を負うものなのだと、今回の事故でも思った。 大型貨物車の突入防止装置については、それが無いものに乗用車が追突した場合、ちょうど乗用車の前ガラスのあたりに貨物車の荷台が突っ込む形になるらしく、つまり運転手は普通に座っていたらガラスを突き破ってきた荷台に直接突っ込むことになり、シートベルトもエアーバッグも衝突安全ボディーも何の役にも立たない。 今回の事故では、乗用車は宙を舞い、回転しながら天井側から高速でバスに突っ込んでおり、これは止まっている車で考えれば空からピアノが降ってくるような... あ、いや、それは Top Gear の話だった、とにかく、そんなにものすごいエネルギーが上下方向に加わることは当然想定されていない。 あり得るのは、せいぜい、ひっくり返ってもつぶれない程度で、それなら自重に耐えられれば済む話、上から勢いよくぶつかると考えると窓ガラスなんかつけられないもんね。
主に rcu_sched detected stalls on CPUs/tasks 事象について調べてみた。 このほうが再現性高いし、実際に使う場合には滅多に出ない segfault より遙かに困るから。
この事象、どうも、CPU0 が割り込みを受け付けなくなるのがポイントのようだが詳細はわからない。 手元では負荷を掛けている間はほとんど遭遇せず (最初に遭遇した時は Linux のビルド中だったが)、負荷が下がっている時によく起きる。CPU0 に割り込みが偏るのはたぶんマザーボードが負荷分散的な機能に対応していないからで、/proc/irq/*/smp_affinity をいじれば他の CPU に処理させることはできる。 ネットワークや PS/2 キーボードの割り込みについて、他の CPU に移しておいたら、異常発生時にも引き続き使用することができた。
rcu_sched detected stalls on CPUs/tasks はたぶんスケジューラー的にコイツ動いてないよというたぐいのメッセージ。 これを放置して触っていると、TLB shootdown か何かの処理が終わらなくなるようで (CPU0 が応答しないのだとすれば当然)、他の CPU も巻き添えを食って止まり始めるが、他の CPU では NMI watchdog が出る。CPU0 も /proc/interrupts を見る限りは NMI が出続けているのだが、なぜか watchdog は出てこないんだよな。
さて、idle が怪しいと見ていろいろ試したが、cpuidle.max_cstate=5 は効果無し、cpuidle.off=1 も効果無し、idle=poll で様子を見ているがこれは効果が有りそうだ。cpuidle.off=1 の効果が無かったので idle=halt も効果は無いかなと思って試していない。 あと、cpufreq の scaling_governor を performance に変えるのはやってみたけど効果は無かった。
idle=poll で 2 時間半くらい動いてくれれば、次はこれでビルド負荷を掛けてみようか。 ビルド負荷っていってもね、どうしても make clean 等のサイクルもあり、CPU 使用率が常時 100% に張り付くわけでもなく、途中で idle はあるはずなので、それがきっかけでトラブルが起きるのなら、実は idle=poll がすべてを解決することもあり得るかなと...
idle=poll も効果無し。 ビルド負荷テスト中に CPU0 がストールしてあっけなく糸冬だった。 カーネルビルドでほんの 48 回ほどだった。
さて、Google 検索によれば nouveau が原因との説あり。 確かに NVIDIA のグラフィックカードを入れてしまっているから、nouveau が動いている。 コイツか?
まずは試しに /proc/irq/*/smp_affinity のほとんどを f000 にしてみた。 ほとんどというのは、ネットワークと PS/2 キーボードはきのうと同じにしたのと、irq 0 と 2 は変更ができなかったので ffff のままとした。 それで 2 時間半ほど動作させてみたが不具合は発生しなかった。
で、irqaffinity という起動オプションで何とかできるのかと思って、irqaffinity=1-15 としてみたが ffff で何も変わらない。 どういうことだよと irqaffinity=1 としたら 0003 になっている。 んんー? 1 から数えて SMT 無しベースか? と 2-8 としたら 01fd になった。 え? SMT 有りでいいんだけどビット 0 が強制的に 1 なのかい! 意味無い!!
そんなこんなで今は nomodeset を試し中。 画面解像度が 1280x1024 になっていなくて 1024x768 になっていて、コンソールが狭い。 なお、DVI-D に流れる信号は 1280x1024 になっているようで、どうなってんだこれ。 近年の高解像度ディスプレイに豆粒のような字が出るのを避けるための拡大表示か?
WebAssembly というのがいよいよ WebKit でもサポートされるらしい。Firefox はすでにサポートしており、徐々に始まってきたようだ。
で、WebAssembly って何だっけ、と思ったので軽く調べた。 前にあった Google Native Client (NaCl) みたいなネイティブコード系かと思ったら違った。 むしろ asm.js 的なもので仮想マシンで実行というよりも中間コードのバイナリーみたいな扱いをするのか。 まぁやっぱ今時はスマートフォンでも PC でも動くというのが当然のターゲットになってくるしな。 で、そもそも asm.js も JavaScript と互換性あるとは思えないくらい相当速かったけど、さらにアドバンテージがあるんだろうな。
しかしこの時代に新たにアセンブリ言語っぽいのを設計しているあたりはわくわくするし、仮にもしその実行環境がポータブルとなれば、UEFI に突っ込んだりカーネルに突っ込んだり、いろんな用途が想像できて楽しそうではある。
nomodeset は良さそうだ。 それで BitVisor も入れて nomodeset で立ち上げてビルドテストを行ってみたところ、11 時間以上もの間、エラーは出なかった。(nomodeset の効き目がありそうなのと、今日は涼しかったので良かろうと思って昼間も回していた。) そして、Segmentation fault が出た。 その後 6 時間以上放置していたが、ストールはしなかった。
結局たぶん、ストールには nouveau が何か影響しているのは間違いなさそうだ。 もちろん、他の CPU の環境ではこの nouveau で問題は起きていないはずで、そういう意味では何かあるに違いないのだが、CPU と密接に関わりのあるチップセットが原因の可能性もありそう。 そして、予想はしていたがやはり Segmentation fault には nouveau は関係していないし、BitVisor 上でも再現性があるので BitVisor を用いた調査も可能だろう。
しかしなぁ、下から調べるのも簡単ではない。 シリアルポート、あ、ヘッダーにポートをつなげばシリアルポートが使えるのかも知れないが、とにかく、そうでもしない限り、問題の例外が起きた瞬間に VMM が全部止めてしまってゆっくり眺めるなんて技は使えないのだ。 アドレスやらページテーブルやら何やらを見てみたいという気持ちはあるが、いろいろ仕込んで何度も試すにはこの発生頻度は厳しい。 ひとつ思いついたのは LD_PRELOAD で何か補助コードをユーザー空間に入れておいて、問題が再現したら勝手に VMM から制御を移してしまう方法、でもそれって固定アドレスに無いと都合が悪いのでは。mmap してしまえばいいんかな。
というわけで nouveau のほうから見てみようと思ったが、起きてほしい時に限ってなかなか起きてくれないトラブルである。 そもそも BitVisor 上でこっちの問題は再現するのかどうか。 これもまたしばらく放置してみるしか無いわけで...
近所のサンクスに行ったらまだサンクスだった。 サラダとかそのへんにはファミリーマートのロゴが付いていて、仕入れはもう共通化されているのか。 ここも近いうちにファミリーマートに化けてしまうのか。
帰りに吉祥寺の JINS に行ってみた。 ちょいと検索すると 2013 年の記事で都内最大規模の店舗とされている。 実際行った印象はそんなでもないけど、確かに測定機器が何台かずらりと並んでいるのは、一昨年行ったイオン幕張の JINS よりも大きいところかも知れない。
で、つるがまっすぐなフレーム、やっぱりスポーツのコーナーにあり、中でも 8 千円のやつがシンプルでつるが細くてまっすぐに近くて軽くて、良さそうに思えたのでひょいと買った。 度数は前と同じ。 目の位置の確認とかされないのも同じ。 さすがにこの値段で多くは望めないが、視力検査しなければ本当に小一時間でできてしまうので、こんな感じでぽいぽいと買い換えるタイプのめがねと言えよう。 レンズそのものはまともなメーカー製だ。 細かい調整しないぶん、合うか合わないかは個人差があるはず。
なお、店員さんにぶっ壊れためがねを見せたら懐かしいモデルだと言われたw もしかしたら 2 年前の時点でも割と型落ちに近いモデルだったのかも知れない。
きのうの夜から nouveau 入れたままの Linux を BitVisor 上で動かし続けて 24 時間超えた。 マジで rcu_sched detected stalls on CPUs/tasks のほうは BitVisor 上では再現しないたぐいの問題なのか?
で、Ubuntu 16.04 でやって報告しまくっている第一人者の話があるので、試しに debootstrap で chroot の Ubuntu 16.04 環境をこしらえた。schroot というのが便利だというので使ってみている。 それでいざカーネルビルドさせてみたらほんの 5 回ほどで segfault 出てしまったよ!
(xenial)root@best:/dev/shm/linux-4.12-rc4# a=1;while test $a -gt 0;do make clean>/dev/null&&
> make -j16 >/dev/null&&a=$(($a+1))&&echo $a `ls --full -l arch/x86/boot/bzImage`||a=0;done
2 -rw-r--r-- 1 root root 7056176 2017-06-14 13:09:50.659011924 +0000 arch/x86/boot/bzImage
3 -rw-r--r-- 1 root root 7056176 2017-06-14 13:11:08.486022378 +0000 arch/x86/boot/bzImage
4 -rw-r--r-- 1 root root 7056176 2017-06-14 13:12:26.657048388 +0000 arch/x86/boot/bzImage
5 -rw-r--r-- 1 root root 7056208 2017-06-14 13:13:43.996168354 +0000 arch/x86/boot/bzImage
net/xfrm/xfrm_policy.c: In function 'xfrm_net_init':
net/xfrm/xfrm_policy.c:2945:15: internal compiler error: Segmentation fault
htab->table = xfrm_hash_alloc(sz);
^
{standard input}: Assembler messages:
{standard input}:1985: Warning: end of file not at end of a line; newline inserted
net/xfrm/xfrm_policy.c:3003: Error: unknown pseudo-op: `.lo'
gcc: internal compiler error: Segmentation fault (program cc1)
Please submit a full bug report,
with preprocessed source if appropriate.
See <file:///usr/share/doc/gcc-5/README.Bugs> for instructions.
make[2]: *** [net/xfrm/xfrm_policy.o] Error 4
make[2]: *** Waiting for unfinished jobs....
make[1]: *** [net/xfrm] Error 2
make[1]: *** Waiting for unfinished jobs....
make: *** [net] Error 2
make: *** Waiting for unfinished jobs....
Position-independent executables の関係かと思いもう一度やっていたら、今度は rcu_sched detected stalls on CPUs/tasks が出てしまった。1 日でなかったのにこれだよ。
BitVisor から覗いて見てわかったのは、ミスって #VMEXIT の状況をうまく確認できるようにしていなかったことだw Local APIC の書き込みアクセスで #VMEXIT したところだけ見えていて、果たして NMI が出ているのかはっきりしなかった。 しょぼーん。
で、segfault を追いかけるクソみたいなアイディアを試し中。BitVisor をいじって一般保護例外時に IOPL が 3 で ring 3 だったら情報をダンプした上でアドレス 0x1000 にジャンプする機能を追加。Linux 側は LD_PRELOAD で constructor からアドレス 0x1000 に mmap して無限ループ処理を書き込み、iopl (3) を呼ぶ。 これで、何か起きたら情報が BitVisor ログにダンプされた上で、当該プロセスは無限ループに陥るので、発見したら gdb アタッチでもして、のんびりスタックダンプするとか、VMM 側からページテーブルをダンプするとか、できる予定。 ただ、過去のことはわかんない。 その瞬間に割り込みがあっただとか、割り込みリターンがあっただとか、そういうことはわからないんだよな。 なので、結局何もわからないという可能性は結構ある。 あと、stall 問題の件と同時に仕込んでしまったので、気づいたときには操作不能という笑い話もあり得る。
きのうのめがね、掛け心地は良い感じだ。 つるが細いほうがヘルメットの隙間に入れやすい感じがする。
目の距離も機械で測定されているっぽいことに気づいた。 それにしては元のレンズよりちょっと違うように感じてしまう。
そうそうきのう整形外科行ったんだけど、手のぴくぴくの件については神経圧迫から来る症状とは考えにくいとのことだった。 麻痺とかしびれとか、そういうののほうがあり得るとのことだ。 ふうむ。
Ubuntu 16.04 chroot 環境は確実に頻度が上がる。 噂の一般保護例外かと思ったらページフォールトだった。 クソみたいなアイディアを拡張して、ページフォールトも NULL ポインターアクセスみたいなアドレスっぽかったら同様に扱うようにした。 それで追っかけると... なぜか glibc 内の関数ポインターが NULL になっているパターン、原因わからないけど変な番地に飛んできてしまっているパターン、%rip が命令の途中にきてしまっているパターンなどいろいろあった。
その、命令の途中に来てしまったパターンをもう少し詳しく追いかけた。#VMEXIT の履歴では Local APIC のアクセスはだいぶ前で、直前はユーザーランドのページフォールトが続いている。malloc 絡みのよう。 クラッシュ箇所のシンボル名は不明だったが、バックトレースで見えるシンボル名からして cc1 内部か。 長い nop 命令の途中に来てしまったせいで 00 00 で add 命令、変なアドレスをアクセスしている。 少し前を見ても同じく 00 00 が来てしまうので、ピンポイントにここに飛んできたのだろう。 スタックの痕跡からしてもっと手前のここの call 命令は実行されたんだな、というところから、レジスターやメモリーの内容を確かめつつ進んでいくと、途中の cmp; je の後で、そこで分岐されていないはずだが、その後の命令が実行された形跡がない。 いや、仮に分岐されたにしても、ゼロクリアされるべきところがされていないなど、実行された形跡がない。 そのへんの命令がページ境界にあるってわけではないため、ページング、TLB 絡みの問題で変な命令を実行してしまったわけではなさそう。 フラグレジスターの内容はふたつめの cmp を実行した後の内容で矛盾はないが、ふたつめの分岐命令があるアドレスの +0x40 にワープしてしまっているわけで...
とりあえず、このあたりを実行中に割り込みが発生した可能性はあるので割り込みも BitVisor でフックしてみよう。 でもこれ、割り込みフックしたらかなり #VMEXIT が増えるので、それで事象が再現するかどうかが問題だ。 まー普通の VMM 使ってても再現するという噂ではあるから、再現するはずなのか。
また元気に page fault は出ており、今度はまた NULL pointer dereference だった。 割り込みが直前に出ていたかというと、そうでもなさそう。
今回も NULL pointer dereference に至った過程が変だ。 きのうの命令途中に %rip が飛んでいたのも変だが、今日も、そのコードが実行される場合に実行されるべき条件ジャンプ je があるが、フラグレジスターの内容が条件に一致しない。 ゼロフラグが立っていないどころか、パリティまで立っていなくて、さてこのフラグは何の演算結果なんだろうね。
そんなわけでスタックを見てみると、最後に実行した call のリターンアドレスらしきものが見えるわけだ。 その先どこまで実行されたのか。 手探りだが、スタックには当然、破壊してはいけないレジスターが push されたらしい跡も残っている。 それと一致しないレジスターがあって、何かとコードをたどっていった中にグローバルかスタティックかわからないけどそんな変数が読み込まれるらしいものがあった。 内容を確認すると一致、その辺から順に追うとある程度一致する。 こうやって見ていくと、今回の問題はシフト命令のところ、レジスターの内容はシフト結果に一致するのだが、フラグレジスターはシフト前に一致する状態! それで %rip はなぜか飛んでいるわけで、これはさすがにやっぱり CPU 内部かなという感じがとてもする。 キャッシュがどうのこうのという感じではない。 レジスターの内容はこうして追ってみると一理ある感じなので、命令の実行が何かおかしいのである。
SMT が何か関係しているのではというのは一部ユニットを共有するものなので一理あるのだが、オフにしても再現するという意見が見られる。 何もオフにしなくても、offline にしてしまえば同じだろう。 試してみようか。
そして数分後に再現... 今度は変なところで ret かな? いや、スタック壊れたか? 全く... 共通項は、直近の #VMEXIT の中に、いずれも malloc か何か、メモリー確保とおぼしき処理のシンボル名があるというか、同じ命令のところでページフォールトが記録されていることくらいだ。 もちろん正常なのだが、それくらいしか見つけられない。
Linux のコンソール (テキスト画面) を何とか遠隔から操作できないものかと思い、探してみたら conspy というドンピシャなツールを発見したので、使っている。/dev/input 系統を使っているのだろうか? 詳しくは調べていないけど、やりたいことはできている。
randomize_va_space を 0 にしてあると一晩落ちなかった。 噂通りだが、Debian GNU/Linux 9 の pie 有効版は落ちにくいっていうのは面白いところだ。
で、ページフォールトの回数に差があるせいとみて、ページフォールトで VMM から TLB フラッシュを行うようにしてみた。 それでも落ちたのだが、見ていくと、レジスターや命令におかしい点はなく、そのまま再開すれば動きそうなのである。 単に、命令と全く関係のないページフォールトが発生したようにしか見えない。 そこで試しに再開させてみたところ、普通に実行されて完了してしまったのである。 なんだそりゃ。
こんな時には、AMD SVM についている decode assists 機能のひとつ、Guest Instruction Bytes が役に立つかも知れない。 と思って見てみたんだけど、普通のページフォールトでは入らないみたいだ。 おかしいな、マニュアルには#PF でも記録されるって書かれているのに...
で、今度はまた機械語命令の途中でページフォールトである。 しかし、%rip がズレてるのも問題だが、そこにある命令とは違う内容のページフォールトなのである。 転送方向も、アドレスも。 探すと %rip から 0x40 手前にある命令がそれっぽい。 何が起きてるんだよ... 本当に、CPU 内部の問題っぽく見える。
キャッシュで何かあるかなと、#VMEXIT 時の %rip がさす機械語を記録する実装を入れてみたが、そういう時に限って %rip が不正なアドレスになってページフォールトである。 しかも 2 コア別々の cc1 プロセスで発生してどちらもアドレス 0x11 である。 うーん。 これさ、負荷かけるのも単純にあるソースファイルをひたすら gcc に食わせるとかそういうほうがやりやすいかな。
整形外科、リハビリテーション。
レンタルカート。 藤野。3 回乗ってベストタイムは 39.8 秒くらい。
温泉浸かって夜の道志みち。 道の駅どうしで PHS が完全に圏外で、あれそうだったっけ...
128 円/l。 燃費計算 20.1km/l。 燃費表示 20.6km/l。
カートレース参加のため前泊することにしていた。 することにしていたというか、探したら 4.5k 円のホテルが見つかったので。 楽天のポイントがあったので 1k 円安くなったし。 例の神経からの痛みのやつがあってあんまり無茶したくないのと、きのう藤野に行った分の高速料金と早朝にフルに高速に乗った場合の高速料金を足すと結構かかるからね。 そうそう、山道の曲がりくねった下りで 10% を超える勾配の 30km/h くらいの制限の道、1 速でおりるとブレーキに余裕ができることがわかった... iQ の場合 1 速が一番ギヤ比が大きいので、すごくうるさくなり鹿も逃げることだろう (問題はそこか?) ま、実際、下りにたどり着くまでの途中に鹿はいたけどね。
御殿場のビジネスホテルに一泊。 ホテルに着いてみたらまさかの高齢おばあちゃんが出てきて驚いた。 小さな和室だったがリフォームされているようできれいだった。
夜早く寝たら朝早く起きてしまったので、テレビつけてみたらあんまりチャネルないのねぇ。 『それいけ! アンパンマン』をやっていたので見てみたら、オープニングテーマもエンディングテーマも変わってないのね。Wikipedia 見るとエンディングは数種類あるのかな。 ほぼドンピシャ世代 (アンパンマンアニメ放送が幼稚園の最後の頃に始まった) としてちょっと感動w アンパンマンアニメのストーリーは相変わらずというか、典型的なヒーロー物というか、いや、ヒーローは一人だけじゃないんだよな。 アンパンマンのすごいところは、肌の色など関係ないという意識が自然と身に付くところなのかも知れない...?
スポーツカート耐久レース。 御殿場。 テクニカルコース。4 時間耐久レース。3 人チームから参加。
マシン運はあまり良くなかった。 最低ピット回数はだいぶ減ってはいたのだが、均等割ではガソリン量的にかなりギリギリ、おまけに交代要員をミスって最低回数を超えるしかなかった。 たぶんタイヤが変わった影響で、去年より燃費が悪くて、40 分走行できたかどうか怪しいところ、最低スティント数で均等に割って 34 分ちょっとだし、ニュートラリゼーションと呼ばれるセーフティカーみたいな走行が入るとピットイン規制されるし、なかなか。 最後に乗ったマシンだけクソ速くて、57.1 秒程度が出ていたらしい... 19 台? 中、10 位。 下位 2 台はガス欠勢。
雨が降るかも知れない予報で実際ぱらついたがその程度で済んだ。 レース後にまともに降り始めた。
今日は早く終わったのでとっとと道志みちで帰路につく。 ラジオの入りが悪いので NHK 第二にしていたら、ラジオ英会話の一週間分 (月から金?) まとめて再放送が始まったので全部聞いてしまった。 英会話入門の頃から変わらぬ遠山顕スタイルである。 なお、今はストリーミングもあるらしい。 いいねこれ。
道志みちがこんできたので藤野方向に向かい、なぜかプレジャーフォレスト方面に抜けて、津久井やまゆり園の前を通って甲州街道に入る経路。 大垂水峠はよかったが高尾山 IC 前が混雑。 その先は日野バイパスが混雑。 事故か故障車かわからないがそういうのもあったみたいでとにかく混雑していた。3 時間半。
帰って一眠りしたら 4 時間半以上も経っていたw
晴れ。
なぜか頭の中でアンパンマンのエンディングテーマがぐるぐるしている。 妙に頭にこびりつくメロディーである。 正確な歌詞は忘れてしまっているけど。 みんな大好きバタコさん、あ、違った、みたいな。
週末に新しい Debian が正式リリースされたらしいが、まだアップグレードは試していない。 どの PC から試そうか。Ubuntu のバカみたいなカーネルパッケージ増殖にはうんざりしているので、その辺の PC にほいほいと Ubuntu を入れていたのはやめたいんだけど、今度の Debian stretch に docker.io がないのは気になるところ。 サードパーティーのリポジトリーは整合性が保たれなくなることがあるのが嫌で。
BitVisor で LBR_VIRTUALIZATION_ENABLE を有効にし、仮想マシンの Last-Branch Record (LBR) を強引に有効にして最新の分岐情報を保存させ、それを #VMEXIT のたびに取り出しておいて、何か不審な点がないかを確認する作戦。 ところが不審な点だらけだ。
まず、LastExceptionToIP がなぜかユーザー空間のアドレスになっていることが多々ある。 例外の遷移先だから、カーネル空間でないとおかしい。VMM が絡んで変なことになるにしても、それなら VMM の使っているアドレス空間でなければおかしいだろう。LastExceptionFromIP もユーザー空間にあるのは別にそれでもいいとも言えるのだが、そこに明らかに LastExceptionToIP にジャンプする命令が入っているというのはこれまたおかしな話である。 マニュアルの読み間違いだろうか...? そうは思えないんだけど。
そして LastBranchFromIP と LastBranchToIP のほうで、問題が起きたときに最後にそのルーチンにジャンプしてきた要因がわかると考えた。 実際、今朝出たのは例の再開すれば動きそうなパターンで、ジャンプ元はテーブルベースのジャンプ命令、おそらく switch 文か何かをコンパイルした結果だろう。 内容に矛盾はなく、本当に、ページフォールトだけがおかしいのである。 まるで 0x40 ズレた、手前の位置の命令を実行しようとしていたかのように。 この件は、問題の処理だけを繰り返し実行すれば再発するかもと考え、その領域を書き込み可能にしないとと mmap() をよぼうとしてミスって終了させてしまった。gdb は実はコード書き換えは普通に可能だった。 夜にもう一度同じ状況が再現したので、命令を書き換えて繰り返させてみたけど再現はしなかった。 なお、朝と夜で %rip の物理アドレスが全く同じということも判明し、不気味な感じがしている。gdb によるコード書き換えをすれば物理アドレスが変わってしまうので、もし物理アドレスが関係あるなら再現性に影響があることになる。
その後、NULL pointer dereference となるパターン、ひとつはよくわからないやつで 2 プロセスに発生した。 もうひとつはなんと LastBranchFromIP がズレていた。 明らかに LastBranchToIP が call 先でスタックに call 命令の次の IP アドレスが残っているにも関わらず、LastBranchFromIP が call 命令の 0x40 後ろになっている。 何が起きているんだ...
物理アドレスの件は気になるのでもうちょっと調べてみるかな。LBR はおもしろいがこれを入れると発生頻度が下がってしまうような感じがするのでなかなか。(ページフォールトの CR2 が後ろのほうのアドレスになってしまった時が何度かあって、そうすると BitVisor に入れた検出条件を満たさないので詳細が取れなかった。)
なお、また nomodeset をつけてあるので動作は安定している。nouveau に何かあるのも間違いなさそうだが、めんどくさいので nomodeset 運用。
Powered by Tomsoft Diary System 1.7.4
Hideki EIRAKU