/var/log/hdk.log

2017 年 6 月


01 (木)

%1 クラッチ

Twitter で見かけた話。

[追記あり]三十路を前にしてマニュアル(MT)スポーツカーを買って大後悔した話

めっちゃ苦労して乗れるようになりましたみたいな話。 おおまかに見て間違ったことを言っているようには見えないが、クラッチ操作にだいぶ苦労したようで、やたら難しそうに書かれている。 そんなに難しいか? 何か難しく思い込んでいるのではないか。

自分はクラッチ操作にたいして苦労しなかったのだが、最初にクラッチをつないでみた時の感覚が、これは摩擦なんだな、っていう簡単な気づきから始まったことによるものだと思っている。 自転車のブレーキだって摩擦で、滑らせるという意味では同じ。 ブレーキを走行中にいきなり全力で掛ければタイヤがロックするように、クラッチをいきなり全部離せばエンストしたり飛び出したりする。 停車中ならブレーキを全力で掛けても何も起こらないのと同じように、エンジンとトランスミッションの回転が同じくらいになっていればクラッチを離してもガクッとせずにうまくつながる。

そんなわけなので、ブレーキを普通に使えるなら、同じように考えれば良くて、ブレーキ掛ける時に遊びを飛ばして一気にある位置まで掛けて、そこで保持して、微調整をする、っていう流れと同じように、クラッチをつなぐ時には一気にある位置までつないで、そこで保持して微調整して、最後に全部つなぐ。 その位置と微調整の感覚を掴むには、アクセルを使わずクラッチだけで車を動かしてみるのがよい。 超ゆっくり動かす、それよりは速く動かす、エンスト、あたりの位置を覚えられれば、何かと役に立つ。

あとの問題はエンジン、これはものによって特性が違うので、どのくらいのトルクが出ているかをある程度は理解しなければならない。 けど、最初は吹かし気味でいいと思うんだよな。 自分はあまりふかさないようにしていたけど、今の車に変えてからは前よりも高い回転数で発進することが多くなった。

ま、でも、なんだかんだ言って、他人の運転の仕方を観察するというのも大きいか。 エンジン音・排気音の高さや間隔がそのままエンジンの回転数だ。 後はシフトレバーを見てれば何速かわかるだろうし、加速感と音の関係からクラッチを滑らせているかどうかある程度はわかる。 どうやって発進しているか、右折の時どこでギヤを変えるか、いろんな状況を見るといいと思う。 路線バスなんかいろんな運転手がいるから、本当にいろんなパターンを見られて勉強になる。

%2 ウォーキング

夜は 2 駅ウォーキング。 自分を追い越していく列車がやたらぎゅうぎゅうだなと思ったら、別の駅で非常ボタン扱いがあったようで、遅れていたか。 反対向きの列車もとまっていたのがちょうど運転再開だったみたいで、警笛を鳴らしてホームに向かって出発していった。 途中でサイゼリヤに寄った。 ちょうどいい距離。 気候的には T シャツ 1 枚にお腹に何か巻くくらいで良いレベル。

歩いている間に頭の中ではいろんなことを考えられるが、なぜかカートのことを考えていた。 それこそ上の MT の話の人じゃないけど、自分はカートは素人だ。 いや、なんだ、経験はあるけど、子供の頃からやっているような人や、相当な走り込みをした人のレベルにはほど遠い。 だからか、やたら理屈っぽく考える。 一応一番たくさん走っている藤野のコースを思い浮かべて、あそこはこうだ、こっちはこうか、こうするとどうだろう、などと、頭の中で走り込みをする。 どうすればインリフトするか、あのコーナーでインリフトがどういう効果を生むか、しないとどうなるか、なども、落ち着いて考えないと理解できない。 直近の目標は APG の耐久レースのほうのタイム改善なのだが、どうしても、たくさん走っているコースじゃないと頭の中の精度が足りないので、そっちで理屈を詰めて、他のコースでも応用できるといいなという流れになる。 アンダー出してでもアクセル全開で曲がるか、軽くブレーキ入れて加速しながら立ち上がるかなど、いろんなパターンがあるのでモータースポーツはおもしろい。

2017/06/01 のコメントを読む・書く


02 (金)

%1 きんようび

朝のバスは 5 分遅れ。 なんでだろ。 途中道路工事等も無し。 回復運転っぽかったがドア閉めを急ぎすぎて結局時間を食ってる感じがあったw 最終的に車いすのお客さんがいる時よりも早く着くくらいだったので回復成功か。

夜は飲みが新宿で。 帰りは京王直通の帰れる列車が惜しくも 5 分前に発車していたというタイミングで駅のホームに着いていたので、途中で乗り換え、準特急こんでるかなと思ったらひどくは無かったのでしばらくの我慢で最速帰宅。

話題の AMD Ryzen、Linux でなにやらトラブルがあるらしくて、楽しそう。

Ryzen上でlinuxカーネルをテストしようとしたら問題が出た(未解決) - 覚書

x86 ならちょっとはわかるから、こんなの見ると実際に試してみたくなる。 よくない。 なお Mini-ITX マザーボードも出てはいるらしいので、小さい筐体で組むことができなくはない状況のようである。 あと、現状では Windows では問題が発生していないので、将来的にこの問題が解決されない場合でも Windows PC として使うことは可能だ。 でもな、Micro-ATX ケースが 3 台並んでいる現状でこれ以上増やすのはさすがにちょっと...

2017/06/02 のコメントを読む・書く


03 (土)

%1 レンタルカート

藤野。3 回乗ってベストタイムは 39.7 秒くらい。 暑くて 2 周目ベスト。

自分的 3 コーナーの新しい攻め方、アクセルオフを 2 回やるw ほんとは 1 回で行けると思うんだけどどうもタイミングがうまく取れない。

%2 どようび

バイクで整形外科と耳鼻科行って、帰ってめし食って、レンタルカート行ってきて、めし食ったらクッソ眠くなって一眠りしてしまった。

今日、気温はそこまで高くは無かったみたいだが、日差しは暑く、バイクに乗っていると止まった時に太ももの温度が急上昇して暑かった。 なので、できるだけ左車線を走行し、信号待ちで木陰に入れるようにしていたんだけど、それも太陽と道路の角度の関係がズレるとうまくいかなくなる。 そこで、仕方の無いときは、両手・両腕を使って太ももが陰に入るようにしてた。 手のひらは熱くなるが、太ももが熱くなるのに比べればだいぶ楽。 でも高速道路だとそういうわけにもいかないだろうから、太もも用ヒートガードがいるなw (バイクのマフラーにはヒートガードがついており、その上から触れる分には走行直後でも熱くないので、ああいうのの太もも用でもあれば)

バイクの低速ターンテクニック、クラッチ滑らせてリヤブレーキを併用するというのが定番だ。 二輪車の特性により、傾けた状態で駆動力が足りないと転倒につながるので、アクセルワークで何とかしようとするのはとても難しいのだ。 おまけにハンドルを切っているからクラッチやアクセル操作の精度も怪しい。 でもリヤブレーキの引きずり加減も難しく、自分みたいなへたくそはなかなかうまくできない。 そこで、雑にリヤブレーキを踏んだり離したりを繰り返してみたら少しやりやすい気がした。 自動クラッチ車でもブレーキ併用のテクニック自体は同じなので、応用できるだろう。

バイクのサスペンションの動きというのはいろいろと使い道があるらしい。 メインスタンドをおろす時に後ろ側を押して前を持ち上げてから反動を利用しておろすというのもそうだが、乗ったままバックさせる時に前のサスペンションを縮めてからその反動を利用してバックさせるみたいなのもあるらしい。 自転車みたいな超軽い二輪車だとそういうテクニックは不要だが、重くなるにつれて知ってると役に立つ話だ。 まぁしかしその動きが原因で走行中にバランスを崩す原因にもなるんだろうから難しいんだけど。 サーキットを攻める系の人は 100km/h 以上でコーナリング中にブレーキを掛けてみたいな話をしていてちょっとなんていうか自分の頭が理解できる範囲を超えていた。

2017/06/03 のコメントを読む・書く


04 (日)

%1 にちようび

Ryzen 問題は workaround が見つかったみたいで、なにやら iret 先の仮想アドレスが関係しているらしい? ま、それはともかく、たぶん Ryzen マシン組むのに Mini-ITX では寂しいと思うので、何か Mini-ITX ケースを買って、今の MicroATX ケースに入れている Mini-ITX マザーボードな PC のどちらかを移植するのがベスト。 そうすれば MicroATX で 1 台組める。Mini-ITX マザーボードなのはバックアップ用 PC と Windows PC なのだが、稼働率が非常に低いバックアップ用 PC なら、今の Silverstone の正圧ケースを使う意味があまり無いので (正圧ケースは埃対策なのだがそもそも稼働時間が短いので負圧ケースでも問題ない)、新しいケースに移してしまってもいいかも知れない。

不動産屋さんにまた話をしに行った。 すごいな、駅から 1km あっても売れるのか。 やっぱり 100 平米あるといいね。

夜は SUPER GT+ がなくて世界卓球やってた。 ダブルスの日本対中国、少し見たがすげぇ速さでラリーが続いたりジャンプする感じで飛び込んで打ち返したりなかなか意味がわからないなw 大学の体育でやった卓球はまったりだったな。

%2 車とバイク

車を発進させる時、前のヴィッツの時は、アクセルちょっと踏んで離して、少しエンジンの回転数が上がったところでクラッチつなぐみたいなことをしていた。 って文字で書いてもわかりづらいが、以前撮った動画を見れば早い。 この乗り方は車種を選ぶようで、レンタカーのトラックの時はエンジン回転数が音でわかりにくくて、何度も煽るような発進になっていたし、今の iQ では電子制御スロットルになって、左右のペダル操作のタイミングが今までとは大きく変わったため、しばらく苦労した。 やり方を変えて、アクセルを踏み込みながらの発進操作にして、1 年くらいで慣れたと思うんだが、今はもう 6 年半経って、すっかりなじんでいる。 それで気づいたのだが、前のヴィッツの時のような発進の仕方を自然とやっていることがある。 低回転のトルクが細いのと、アクセルの反応が鈍いせいか、ゆっくり発進の時に限るものの、回転を上げないわけではなく、しかしアクセルを踏み込みながらでもない、絶妙なところ、慣れればできるもんだな。 なお、駐車場では今日もエンストさせたw

バイクは排気量が小さいせいか車より遙かに低回転のトルクが細いので、アクセルを開けたままクラッチをつないでいくようにしている。 これ、車の運転の仕方の影響を受けたというより、何となく、自動遠心クラッチのつながり具合に近いような気もする。 原付に何年も乗った後で自動二輪の教習を受けに行ったから、自然とそうなったのかも。

車のシフトレバーの操作、自分はなんか教習で習った通りみたいなやり方だな。2 速は握って入れることもあるけど、真ん中の 3・4 速はだいたい前後方向だけ力を入れるようにしている。 ま、レーシングドライバーの谷口信輝もこんな感じみたいだし、悪いことは無かろう。 バイクはね、教習の通りにやっていると足が疲れるんだよね。 ってことで、つま先をシフトレバーの外に向けていることが多い。

2017/06/04 のコメントを読む・書く


05 (月)

%1 冷え冷え

家にいてもふと気づくとおしりや太ももなんかが冷えていますよね、なんて話をすると、なかなか同意してもらえない。 おかしい。 みんな気づいていないだけだよね!

例えば今夜は室内の温度計が 25 度を超えているくらいだけど、下着一枚でいると冷えるので、お腹から太ももに毛布一枚のせてパソコンを触っている感じである。 普通普通。

なお、手で触って太ももの冷えがわかるということは、手は冷えてないってことである。 昔は冬にパソコン触ってると手が冷え冷えになっていたけどな。 あれは夏の冷えとは違うのかな。

%2 PC

Mini-ITX ケースは IN WIN IW-BP655B/300H あたりで良さそうだな。 それなりにちっちゃそうだし電源までついてる。 どうせ使わないだろうけど USB 2.0 ポートというのも C60M1-I にはぴったりだ。 ファンレスマザーボードなので小さい筐体に収まらないという心配はいらない。

しかし Ryzen 買うとしたらグラフィックカードを選ばなきゃいけないんだな。 古いの余ってるけど UEFI 未対応という残念なお知らせ。 何でもいいんだがエントリークラスの新品を買うのと、どこかで中古を調達するのとどっちがいいか。

あと RAM もどんなのが良いのか。 冒険するつもりは無いが DDR4 は初めてだ。

あ、そういえば CPU クーラーもいるんだったっけ? 調べることがいっぱいだ。

2017/06/05 のコメントを読む・書く


06 (火)

%1 Ryzen

クーラーは純正品が付いているらしい。 ならいいや、と思って、ポチった。 マザーボードは MicroATX の安いやつ。 また ASUS かw (自宅に並んでいる MicroATX ケースの PC 3 台とも ASUS だ)

さて、ビデオカードはひっさびさの GeForce で、一番安いやつ。 発売時期が去年のようなので当然 UEFI 対応してるに違いない、みたいな。

っていうか、ビデオカードつけなきゃ動かない PC 組むのマジで久しぶりだし、CPU 単体で 3 万超える PC 組むのは... もしかしたら職場で組んだっけな?

買った Mini-ITX ケースにバックアップ PC の電源装置以外を引っ越し、Ryzen 用の電源装置は今それに使っている 400W を流用予定。CPU は消費電力低そうだしビデオカードがエントリーモデルだから問題なくいけるだろう。HDD はバックアップ PC に長らく使ってないのが 1 台入っているのでこれを使っちゃおう。 たぶん古い FreeBSD が残っている HDD な気がする。PXE ブート行けるならそれでもいいっちゃいいんだけどね。

2017/06/06 のコメントを読む・書く


07 (水)

%1 すいようび

朝は整形外科に行ってリハビリ。

原付はこの半年で 500km くらいしか走っていない計算のようで、こりゃエンジンオイル交換にはまだ早いか。 原付だからエンジン温まりきらないほどの短距離運転も少ないしまぁいいか。 今度オイル量は見ておこう。

梅雨入りだかなんだか、雨は少し降ったりやんだりみたいな、車に乗ったらワイパーの拭き具合がまずくてそろそろ交換だな。 よく考えたら 3 年半前の車検の時に交換して以来そのままじゃないか?

%2 映画

『たたら侍』。 邦画。 レイトショー。1,300 円。MOVIX 昭島。

レイトショーを探した結果、よく行くイオンシネマではやってなくて、他の映画館で一番行きやすそうなのが昭島だったので初めて行ってみた。 結構きれいなところだ。 いつもカウンターで買うので券売機使えって言われてずいぶんとまどった。

出演者逮捕に伴う打ち切り報道がされている話題の映画である。 何も打ち切らなくてもいいような気はするが、各映画館の 1 日あたりの上映回数を見れば、打ち切りでなくても早ければあと 1〜2 週間程度で上映終了していたっぽい感じもあるし、打ち切りだーという報道を見て見に行く自分みたいなやつもいるのでそこまで見込んだものかも知れないね。 だいたい洋画は逮捕歴や前科ある人出ててもそのまま上映したり DVD 出したりするんでしょ、不思議なものだよ。 『ホームアローン』とか普通にテレビ放送されてるし。

さてこの映画、たたらっていうのは製鉄の話、何かで聞いたことあるなと思っていたが、映像を見るとアレだ、『もののけ姫』だ。 『もののけ姫』はアニメーションだが、本作は実写。 しかし映像に関しては割と気合いが入っている感じで、本当に製鉄しているみたいに見える。 っていうかまさか本当にやったんだろうか? 景色もきれいだし現代で撮影した風に見えないのはさすが、お金のかかっている映画。

時代は戦国時代っていうんだっけ? 織田信長のいた時代あたり、そういえば年初に見た『本能寺ホテル』も同じ時代じゃん。 たたら製鉄で暮らす村に生まれた主人公が、戦から村を守るべく奮闘、いや、迷走? ま、そんな感じの映画だ。

戦に使う銃や火薬等、それを売る商人がいた、という設定のようだった。 映画には出てきたのだが、何を通貨としていたかがはっきりとせず、もやもやした感じが残る。 他にも、船での移動に 2 日? トイレは? とか、この人はその距離ついてきたの? とか、また船に乗ったの? とか、シーンが飛ぶところに対するもやもやがいろいろあってなんだかな。

昔の生活を表すようなシーンが盛り込まれていて興味深い点はあって、外国人にはそのへん受けるのかも。 たたら製鉄はもちろん、行水、井戸水のくみ上げ、川での洗濯... 強盗やら、戦やら、いろいろある。

そんなわけで、映像は良い。 戦のシーンではなくて、普通の生活や移動のシーンが良い。 音楽も良い感じだったと思う。 最後に突然 EXILE なのが少し違和感あったくらいだ。 ストーリーはもうちょっとうまくやれなかったのかな。 いつの間にか時間が飛んでいるというか、詰め込みすぎというわけでも無いのだろうけど、なんかね。 アレいつの間にこの人居座ってんの、的な。 あと、悩みに悩んで、意見の相違から、餅は餅屋、的な気づきがあるのかと思ったが気づいたのは観客だけだったりして。

2017/06/07 のコメントを読む・書く


08 (木)

%1 PC 組み立て

パーツが届いたので作業を開始。 まずはバックアップ PC を新しい Mini-ITX ケースに移設する。 小さいケース故 HDD の取り付けは面倒だが、特に目立ったトラブルは無く、小一時間で作業は完了した。 並べてみると、小さい。Mini-ITX ってのはこんなに小さいものなんだ。

さて。 続いて Ryzen PC の組み立てを開始。Mini-ITX から MicroATX になる分、マザーボード固定用のねじが 2 か所増える。 幸い、前のマザーボードの箱にねじが残っていたので、ケースに合わせて入れ替える。 マザーボードを取り付け、CPU を取り付ける。CPU クーラーはねじ止めらしい。 ふんふん... とやっていたが最後の 1 個がしまらない。 うーん?

外して付け直してみるか、と、ヒートシンクをひょいと引っ張ったら CPU ごと取れた。 あわわわわ。 固定レバーおりてるのに。 ま、ピンが抜けた様子は無いので、そっと付け直して見なかったことにする。 もう一度、ねじがちゃんと噛むか確かめながら少しずつしめる。 これ面倒やなー、サードパーティーの簡単な CPU クーラーのほうがいいかも。 今まで通りのレバー式で行けるんでしょ?

さて、電源を配線しようとして問題にぶち当たる。HDD が電源端子に当たることが判明して移設。 それはいい。 問題は EATX12V という規格らしいのだが 4+4 ピンの補助電源が電源装置についてない! うーん... そういえばさっき移設した Mini-ITX ケースの付属電源には付いていた。 時代は変わってきているんだな。 とりあえず、さっきの CPU 事件が心配なので、Mini-ITX ケースの電源をつないで動作確認しよう。 というわけで、ささっと RAM とビデオカードを差し込む。RAM は HDD と干渉するため、スロットが限定される。 あと 2 枚増やすのは無理か。 ビデオカードは普通に刺さる。 で、動作確認だ。Mini-ITX ケースを 90 度立てて載せて電源を配線し、通電! しーん。 あれれれ...

再確認して電源端子が奥まで刺さってなかったのに気づき、差し込みなおした。 通電! なんか光ってる! 電源ポチッ! 反応無し! あれれれ... リセットボタンポチッ! フーン... と CPU ファンが回り始めた。 ボタンの配線ミスった? しかし画面が映らない。 どうしたどうした...

D-sub のせいかと DVI-D でつなぎ直してみたが映らず、CPU かなと不安になっていたところ、RAM が奥までささっていなかったことが判明。 どんだけあわててるんだ自分。 奥まで差し込んで、通電、リセットボタン! ...き、きた! 映った!! CPU は無事だ!

試しに 4+4 ピンの片側だけ配線してみたらそれでも起動した。 マザーボードの説明書にはちゃんとつなげみたいな感じで書いてあるけどね。 電源ボタンが反応しない謎は未解明。 リセットボタンはリセットボタンとしてきちんと機能している。 テスターで見た感じ電源ボタン自体が壊れているわけではなさそう。 まぁいいや、ひとまずこれでセットアップしよう。Debian の次のリリースがもうすぐ出る予定らしいので、それを入れることにした。ISO9660 イメージをダウンロードして 7z x で USB メモリーに展開 (正しいやり方かは知らない)、それを UEFI で起動してインストール。rtl8168 のファームウェア rtl8168h-2.fw が必要だった。

Ryzen 5 でも噂の Linux での問題は再現するらしいのだが、うっかり Ryzen 7 にしてしまったので論理 CPU 16 個! 3 万円台の CPU でこれだよ、すごい時代だ。 とりあえず Linux カーネルビルドを make -j16 で 30 回ほど繰り返してみているが何とも無い。defconfig じゃ少なすぎるかな? (と言いたくなるほど速い)

%2 買ったほうがいいかも知れない追加パーツ等

現在の構成:

2012 年購入のパーツから 2 つ流用。 明らかに電源装置は EATX12V とやらに対応したものにかえたほうが良い気がする。 しかし make -j16 を繰り返していても何ともなさそうなので別にいいのかな...

HDD は Ultra 20 についてきた 250GB だ。10 年以上経っている代物で今となっては性能が悪いかも知れないし、5 年くらいはまともに使ってきたものなので故障リスクもある。 今時のマザーボードで M.2 もあり SSD も搭載しやすい。

ケースファンは Silverstone の正圧ケースのため吸気ファンだ。 排気は電源装置のみだ。 たぶん排気ファンを追加したほうが良い気はする。

他に必要なのは、スイッチングハブとネットワーク通信ケーブルだ。 ギガビットで 5 ポートあれば十分だろと思っていたけど、ついに 5 ポートじゃどうしようも無い時が来てしまった。 インターネット用、自宅サーバー PC、Windows PC、Ubuntu PC、バックアップ PC で埋まっていたのだった。iMac は最初から無線 LAN で使っているが、今回の PC は、Linux でのトラブルに興味津々で特に用途を決めないで買ったので、コンパイルとかエンコードとか、そういう高負荷用途用になってしまうのは間違いないのである。 そうするとたぶんネットワーク経由でファイルシステムをマウントして作業することになるだろうから、無線 LAN ってわけにはいかないのである。 今はバックアップ PC を外してある。 どうせ買うなら tagged VLAN くらい対応しているやつにすれば、PXE ブート用の DHCP サーバーなんか立てたい時に好都合かもね。

2017/06/08 のコメントを読む・書く


09 (金)

%1 PC

夜中にずっと Linux のビルドを繰り返し実行させていたら、早朝に止まっていた。 コアが一個応答しなくなったみたいで、噂の Segmentation fault では無かった。 どうやら 223 回くらいのところで止まったみたいで、問題発生頻度的にはちまたで噂のツイートよりも遙かに少ない。

で、よく見ると電源 LED と HDD LED が両方とも点灯している。 やっぱり配線ミスってるのか。 改めて見直すと、隣のスピーカー用のヘッダーに電源 LED と電源ボタンをさしてあって、電源 LED と電源ボタンのヘッダーに HDD LED とリセットボタンをさしてあった。 おいおい... っていうかスピーカー (ビープ用) って 4 ピンで、その中に常時電源もあるのか。 という新たな発見。 きちんと電源ボタンも使えるようになった。 ビープつないでおけばきのうのメモリーちゃんとささってない問題もちゃんと音でわかったはずなのにね。 ここにささるスピーカーや圧電ブザーは持ってない気がする。

CPU ファン自体は A10-7870K のものより静かに感じるが、Seagate の HDD はシーク音が大変うるさく、Linux のビルド中にゴリゴリゴリゴリとなかなか厳しい。 昔懐かしいジーというような音もよく聞こえてくる。 さすがにピーシュルルルというようなヘッド位置微調整音は聞こえないけど、ジーとかゴーとか時々鳴るのは 2GB くらいの HDD を思い出して懐かしいのである。 なお、Linux のビルドは /dev/shm (tmpfs) でやってみるとかなり静かだった。QEMU などのビルドだと結構 HDD にあるファイルを読みに行ってしまうようでそこまで静かにならない。

BitVisor は ACPI_DSDT=0 にしてビルドすれば動いた。 噂の問題が再現するなら BitVisor から例外を観察する等の楽しみがあるのだが、再現しないものだから困る。Segmentation fault は見てみたいことがいろいろあるが、ハングアップ問題は調べるのが本当に大変なので。

ハングアップには何度か遭遇した。 タイミング的には関係ないが、謎の SATA エラーも出ていたため、ケーブルを疑って配線を見直した。 前部ケースファンの配線が SATA ケーブルと絡んでいたため、引き離して、差し込み具合を再確認した。SATA ケーブル再確認後は、エラーは出ていないかも。 ハングアップ的事象にも関係があるか? make -j256 で様子見。 このくらいまでなら RAM ピーク時 10GB 程度で間に合う。 しかし、load average が 200 超えてきてもそこそこ操作できるあたりがさすが 8 コア 16 スレッド。

%2 今時の GNU/Linux

dmesg が一般ユーザー権限でできなくて、何それと思って調べたら、sysctl で kernel.dmesg_restrict = 0 と設定しておけば今まで通りになるらしい。 へぇ。 てっきり setcap みたいなのやらないといけないのかと思ったよ。

PIE... Position-independent executables というのがあって、再配置可能な実行可能ファイルということだ。 これまでももちろんダイナミックリンクライブラリーは再配置可能だったが、GNU/Linux の場合、メインのプログラムが使用するアドレスは固定になっていることが多かった。 それを再配置可能にしてしまおうというのがこの PIE というわけだ。 そのメリットは、乱数に基づいて毎回異なるアドレスを使用することにより、特定のアドレスに特定のコードが存在することをあてにした攻撃が成立しにくくなるということのようだ。 なので、これが有効になっている環境であれば、コンパイル時に -fPIC のようなコンパイラーオプションを使わなくても再配置可能なオブジェクトが生成されており、おかげで BitVisor のコンパイルに引っかかるというわけのようである。 どうも -no-pie オプションで無効にできるようだが、このオプションが古いコンパイラーには使えないというのがやっかいなところである。

2017/06/09 のコメントを読む・書く


10 (土)

%1 どようび

整形外科。 リハビリテーション。PC 組み立ての時にちょっと無理な姿勢をしたせいか、ここ数日あまり調子は良くない。 たまに怪しい肩こり的痛みが顔を出すし、右手はよくぴくぴくする。

何となくバイク用品店に行ってドライタイプの潤滑剤スプレーを購入。

何となくハードオフに行って PC 用電源装置を購入。 ジャンクコーナーを最初見てみたが、良さそうな感じのは 800 円くらいして、しかも使用感があって、7 年くらい経ったものとなるとリスクが高い。 ジャンクじゃないコーナーに箱付きの KT-F500-12A があったので買った。2,500 円 (税別)。 これも 2010 年頃からあるモデルだが現行品でもあり、ハードオフの 10 日間保証もあり、また、こうして中古に出ているものだから初期不良は無かろう。 一応 500W だがあまり期待しないほうがいいみたい。 まー今の 400W よりは良かろう。

バイク用に使っていた JINS めがねが崩壊してしまった。 どうしよう。

室温 31 度くらいに達していたので冷房をつけた。

テレビでやってた映画『インデペンデンス・デイ』(原題: Independence Day)。1996 年のアメリカ映画。 宇宙人になぜか派手に攻撃されるパニック物。 まー雑に言えばゴジラみたいなもんだな。

%2 Ryzen

きのうの深夜からカーネルビルド 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 に偏ってる。 これは割り込みばらまき機能がきちんと機能していないってこと?

2017/06/10 のコメントを読む・書く


11 (日)

%1 きのうの話題

きのうの東名高速・新城 PA 付近でのバスと乗用車の衝突事故が話題。 下り線を走行していた乗用車が、路肩の傾斜に乗り上げて中央分離帯で宙を舞い、上り線の追い越し車線にたまたまいた観光バスに衝突したもの。 事故後停止していたバスを PA から撮ったらしき写真に 261.1 キロポストが映っており、バスは上り線を走行しており、PA 入り口より手前のところで衝突、よろよろと PA の横っちょまで来て止まったというわけだ。

この事故、観光バスのドライブレコーダーから乗用車が飛んだということはわかったが、乗用車の運転手が、よそ見、車両トラブルあるいは障害物をよけようとしたか何かで制御を失ったのか、そもそも意識が無かったのか、そのへんは周囲の車のドライブレコーダー等の情報があがってこない限り、特定困難だろう。 ワイパーが動いているのでパニックになってワイパーのレバーに手が触れたパターンかと思ったが、あの勢いでジャンプしたら何でもあり得るよな。 乗用車の運転手は亡くなってしまったが、バスの乗客乗員は怪我で済んでいるらしく、また、乗用車に同乗者はいなかったようだ。 バスの運転手の的確な判断云々とも言われているが、正直、対向車が飛んだのが見えてからぶつかるまでの 1 秒未満の間に人間にできることはほぼ無い。 自分の印象としては、右側から何かが突っ込んでくると認識して (普通の飛び出しなら一般道では交差点等でよくある光景だろう)、とっさに左にハンドルを回し、ブレーキを掛ける、のが限界かなと思う。 たぶん、なんかやばい程度の認識から実際に筋肉に力が入ってハンドルが回り始めるまでに 0.5 秒近く経つと思う。 ブレーキについては車両に搭載されている自動緊急ブレーキ等のほうが反応は早かったはず、宙を舞う車に反応するかどうかは定かでないが。

今回、相当運が良かったと思うのは、バスの屋根に乗用車が乗っかるような形になったところ、衝突のタイミングがほんの少しズレていただけで、あるいは、ジャンプの高さがちょっと低かっただけで、大きな前ガラスから車内に乗用車が突入していたかも。 また、巻き込まれた対向車が大型車でなく、乗用車や軽自動車や二輪車だったら... 運動エネルギーを考えれば当然のことだが、大型バスは乗用車より遙かに重いので、乗用車を受け止めてもスピードが残っていて、それでゆっくり止まることができた。 もし同じくらいの重さの車両が同じくらいのスピードで正面衝突すれば、双方のスピードは一気に 0 になる。 そうなると死者がもっと増えていたかも。

そして、大型車の突入防止装置の件でも思ったが、安全性が上がった近年の車でも、当たり所が悪ければ、致命傷を負うものなのだと、今回の事故でも思った。 大型貨物車の突入防止装置については、それが無いものに乗用車が追突した場合、ちょうど乗用車の前ガラスのあたりに貨物車の荷台が突っ込む形になるらしく、つまり運転手は普通に座っていたらガラスを突き破ってきた荷台に直接突っ込むことになり、シートベルトもエアーバッグも衝突安全ボディーも何の役にも立たない。 今回の事故では、乗用車は宙を舞い、回転しながら天井側から高速でバスに突っ込んでおり、これは止まっている車で考えれば空からピアノが降ってくるような... あ、いや、それは Top Gear の話だった、とにかく、そんなにものすごいエネルギーが上下方向に加わることは当然想定されていない。 あり得るのは、せいぜい、ひっくり返ってもつぶれない程度で、それなら自重に耐えられれば済む話、上から勢いよくぶつかると考えると窓ガラスなんかつけられないもんね。

%2 Ryzen の話

主に 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 がすべてを解決することもあり得るかなと...

2017/06/11 のコメントを読む・書く


12 (月)

%1 Ryzen...

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 になっているようで、どうなってんだこれ。 近年の高解像度ディスプレイに豆粒のような字が出るのを避けるための拡大表示か?

%2 WebAssembly

WebAssembly というのがいよいよ WebKit でもサポートされるらしい。Firefox はすでにサポートしており、徐々に始まってきたようだ。

で、WebAssembly って何だっけ、と思ったので軽く調べた。 前にあった Google Native Client (NaCl) みたいなネイティブコード系かと思ったら違った。 むしろ asm.js 的なもので仮想マシンで実行というよりも中間コードのバイナリーみたいな扱いをするのか。 まぁやっぱ今時はスマートフォンでも PC でも動くというのが当然のターゲットになってくるしな。 で、そもそも asm.js も JavaScript と互換性あるとは思えないくらい相当速かったけど、さらにアドバンテージがあるんだろうな。

しかしこの時代に新たにアセンブリ言語っぽいのを設計しているあたりはわくわくするし、仮にもしその実行環境がポータブルとなれば、UEFI に突っ込んだりカーネルに突っ込んだり、いろんな用途が想像できて楽しそうではある。

2017/06/12 のコメントを読む・書く


13 (火)

%1 毎日 Ryzen

nomodeset は良さそうだ。 それで BitVisor も入れて nomodeset で立ち上げてビルドテストを行ってみたところ、11 時間以上もの間、エラーは出なかった。(nomodeset の効き目がありそうなのと、今日は涼しかったので良かろうと思って昼間も回していた。) そして、Segmentation fault が出た。 その後 6 時間以上放置していたが、ストールはしなかった。

結局たぶん、ストールには nouveau が何か影響しているのは間違いなさそうだ。 もちろん、他の CPU の環境ではこの nouveau で問題は起きていないはずで、そういう意味では何かあるに違いないのだが、CPU と密接に関わりのあるチップセットが原因の可能性もありそう。 そして、予想はしていたがやはり Segmentation fault には nouveau は関係していないし、BitVisor 上でも再現性があるので BitVisor を用いた調査も可能だろう。

しかしなぁ、下から調べるのも簡単ではない。 シリアルポート、あ、ヘッダーにポートをつなげばシリアルポートが使えるのかも知れないが、とにかく、そうでもしない限り、問題の例外が起きた瞬間に VMM が全部止めてしまってゆっくり眺めるなんて技は使えないのだ。 アドレスやらページテーブルやら何やらを見てみたいという気持ちはあるが、いろいろ仕込んで何度も試すにはこの発生頻度は厳しい。 ひとつ思いついたのは LD_PRELOAD で何か補助コードをユーザー空間に入れておいて、問題が再現したら勝手に VMM から制御を移してしまう方法、でもそれって固定アドレスに無いと都合が悪いのでは。mmap してしまえばいいんかな。

というわけで nouveau のほうから見てみようと思ったが、起きてほしい時に限ってなかなか起きてくれないトラブルである。 そもそも BitVisor 上でこっちの問題は再現するのかどうか。 これもまたしばらく放置してみるしか無いわけで...

%2 サンクス

近所のサンクスに行ったらまだサンクスだった。 サラダとかそのへんにはファミリーマートのロゴが付いていて、仕入れはもう共通化されているのか。 ここも近いうちにファミリーマートに化けてしまうのか。

2017/06/13 のコメントを読む・書く


14 (水)

%1 めがね

帰りに吉祥寺の JINS に行ってみた。 ちょいと検索すると 2013 年の記事で都内最大規模の店舗とされている。 実際行った印象はそんなでもないけど、確かに測定機器が何台かずらりと並んでいるのは、一昨年行ったイオン幕張の JINS よりも大きいところかも知れない。

で、つるがまっすぐなフレーム、やっぱりスポーツのコーナーにあり、中でも 8 千円のやつがシンプルでつるが細くてまっすぐに近くて軽くて、良さそうに思えたのでひょいと買った。 度数は前と同じ。 目の位置の確認とかされないのも同じ。 さすがにこの値段で多くは望めないが、視力検査しなければ本当に小一時間でできてしまうので、こんな感じでぽいぽいと買い換えるタイプのめがねと言えよう。 レンズそのものはまともなメーカー製だ。 細かい調整しないぶん、合うか合わないかは個人差があるはず。

なお、店員さんにぶっ壊れためがねを見せたら懐かしいモデルだと言われたw もしかしたら 2 年前の時点でも割と型落ちに近いモデルだったのかも知れない。

%2 今日の Ryzen

きのうの夜から 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 問題の件と同時に仕込んでしまったので、気づいたときには操作不能という笑い話もあり得る。

2017/06/14 のコメントを読む・書く


15 (木)

%1 めがね + ヘルメット

きのうのめがね、掛け心地は良い感じだ。 つるが細いほうがヘルメットの隙間に入れやすい感じがする。

目の距離も機械で測定されているっぽいことに気づいた。 それにしては元のレンズよりちょっと違うように感じてしまう。

%2 整形外科

そうそうきのう整形外科行ったんだけど、手のぴくぴくの件については神経圧迫から来る症状とは考えにくいとのことだった。 麻痺とかしびれとか、そういうののほうがあり得るとのことだ。 ふうむ。

%3 今日も Ryzen

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 使ってても再現するという噂ではあるから、再現するはずなのか。

2017/06/15 のコメントを読む・書く


16 (金)

%1 今朝の Ryzen

また元気に page fault は出ており、今度はまた NULL pointer dereference だった。 割り込みが直前に出ていたかというと、そうでもなさそう。

今回も NULL pointer dereference に至った過程が変だ。 きのうの命令途中に %rip が飛んでいたのも変だが、今日も、そのコードが実行される場合に実行されるべき条件ジャンプ je があるが、フラグレジスターの内容が条件に一致しない。 ゼロフラグが立っていないどころか、パリティまで立っていなくて、さてこのフラグは何の演算結果なんだろうね。

そんなわけでスタックを見てみると、最後に実行した call のリターンアドレスらしきものが見えるわけだ。 その先どこまで実行されたのか。 手探りだが、スタックには当然、破壊してはいけないレジスターが push されたらしい跡も残っている。 それと一致しないレジスターがあって、何かとコードをたどっていった中にグローバルかスタティックかわからないけどそんな変数が読み込まれるらしいものがあった。 内容を確認すると一致、その辺から順に追うとある程度一致する。 こうやって見ていくと、今回の問題はシフト命令のところ、レジスターの内容はシフト結果に一致するのだが、フラグレジスターはシフト前に一致する状態! それで %rip はなぜか飛んでいるわけで、これはさすがにやっぱり CPU 内部かなという感じがとてもする。 キャッシュがどうのこうのという感じではない。 レジスターの内容はこうして追ってみると一理ある感じなので、命令の実行が何かおかしいのである。

SMT が何か関係しているのではというのは一部ユニットを共有するものなので一理あるのだが、オフにしても再現するという意見が見られる。 何もオフにしなくても、offline にしてしまえば同じだろう。 試してみようか。

そして数分後に再現... 今度は変なところで ret かな? いや、スタック壊れたか? 全く... 共通項は、直近の #VMEXIT の中に、いずれも malloc か何か、メモリー確保とおぼしき処理のシンボル名があるというか、同じ命令のところでページフォールトが記録されていることくらいだ。 もちろん正常なのだが、それくらいしか見つけられない。

%2 Conspy

Linux のコンソール (テキスト画面) を何とか遠隔から操作できないものかと思い、探してみたら conspy というドンピシャなツールを発見したので、使っている。/dev/input 系統を使っているのだろうか? 詳しくは調べていないけど、やりたいことはできている。

2017/06/16 のコメントを読む・書く


17 (土)

%1 Ryzen の謎

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 に食わせるとかそういうほうがやりやすいかな。

%2 土曜日

整形外科、リハビリテーション。

レンタルカート。 藤野。3 回乗ってベストタイムは 39.8 秒くらい。

温泉浸かって夜の道志みち。 道の駅どうしで PHS が完全に圏外で、あれそうだったっけ...

2017/06/17 のコメントを読む・書く


18 (日)

%1 きのうの給油

128 円/l。 燃費計算 20.1km/l。 燃費表示 20.6km/l。

%2 昨日の夜〜今朝

カートレース参加のため前泊することにしていた。 することにしていたというか、探したら 4.5k 円のホテルが見つかったので。 楽天のポイントがあったので 1k 円安くなったし。 例の神経からの痛みのやつがあってあんまり無茶したくないのと、きのう藤野に行った分の高速料金と早朝にフルに高速に乗った場合の高速料金を足すと結構かかるからね。 そうそう、山道の曲がりくねった下りで 10% を超える勾配の 30km/h くらいの制限の道、1 速でおりるとブレーキに余裕ができることがわかった... iQ の場合 1 速が一番ギヤ比が大きいので、すごくうるさくなり鹿も逃げることだろう (問題はそこか?) ま、実際、下りにたどり着くまでの途中に鹿はいたけどね。

御殿場のビジネスホテルに一泊。 ホテルに着いてみたらまさかの高齢おばあちゃんが出てきて驚いた。 小さな和室だったがリフォームされているようできれいだった。

夜早く寝たら朝早く起きてしまったので、テレビつけてみたらあんまりチャネルないのねぇ。 『それいけ! アンパンマン』をやっていたので見てみたら、オープニングテーマもエンディングテーマも変わってないのね。Wikipedia 見るとエンディングは数種類あるのかな。 ほぼドンピシャ世代 (アンパンマンアニメ放送が幼稚園の最後の頃に始まった) としてちょっと感動w アンパンマンアニメのストーリーは相変わらずというか、典型的なヒーロー物というか、いや、ヒーローは一人だけじゃないんだよな。 アンパンマンのすごいところは、肌の色など関係ないという意識が自然と身に付くところなのかも知れない...?

%3 レンタルカート

スポーツカート耐久レース。 御殿場。 テクニカルコース。4 時間耐久レース。3 人チームから参加。

マシン運はあまり良くなかった。 最低ピット回数はだいぶ減ってはいたのだが、均等割ではガソリン量的にかなりギリギリ、おまけに交代要員をミスって最低回数を超えるしかなかった。 たぶんタイヤが変わった影響で、去年より燃費が悪くて、40 分走行できたかどうか怪しいところ、最低スティント数で均等に割って 34 分ちょっとだし、ニュートラリゼーションと呼ばれるセーフティカーみたいな走行が入るとピットイン規制されるし、なかなか。 最後に乗ったマシンだけクソ速くて、57.1 秒程度が出ていたらしい... 19 台? 中、10 位。 下位 2 台はガス欠勢。

雨が降るかも知れない予報で実際ぱらついたがその程度で済んだ。 レース後にまともに降り始めた。

%4 帰り

今日は早く終わったのでとっとと道志みちで帰路につく。 ラジオの入りが悪いので NHK 第二にしていたら、ラジオ英会話の一週間分 (月から金?) まとめて再放送が始まったので全部聞いてしまった。 英会話入門の頃から変わらぬ遠山顕スタイルである。 なお、今はストリーミングもあるらしい。 いいねこれ。

道志みちがこんできたので藤野方向に向かい、なぜかプレジャーフォレスト方面に抜けて、津久井やまゆり園の前を通って甲州街道に入る経路。 大垂水峠はよかったが高尾山 IC 前が混雑。 その先は日野バイパスが混雑。 事故か故障車かわからないがそういうのもあったみたいでとにかく混雑していた。3 時間半。

帰って一眠りしたら 4 時間半以上も経っていたw

2017/06/18 のコメントを読む・書く


19 (月)

%1 げつようび

晴れ。

なぜか頭の中でアンパンマンのエンディングテーマがぐるぐるしている。 妙に頭にこびりつくメロディーである。 正確な歌詞は忘れてしまっているけど。 みんな大好きバタコさん、あ、違った、みたいな。

週末に新しい Debian が正式リリースされたらしいが、まだアップグレードは試していない。 どの PC から試そうか。Ubuntu のバカみたいなカーネルパッケージ増殖にはうんざりしているので、その辺の PC にほいほいと Ubuntu を入れていたのはやめたいんだけど、今度の Debian stretch に docker.io がないのは気になるところ。 サードパーティーのリポジトリーは整合性が保たれなくなることがあるのが嫌で。

%2 Ryzen と 0x40

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 運用。

2017/06/19 のコメントを読む・書く


20 (火)

%1 かようび

朝は整形外科でリハビリテーション。 牽引こんでなかった。

%2 Ryzen General Protection Exception

やっと噂の一般保護例外が出た。 例によって cc1 だがとても楽しいことになっている。

 GPE  flags 00003202 err 00000000 0033:0101356e *
 RAX 00000001    RCX 00000AED    RDX A656C63796320    RBX 012B7050
 RSP 7FFE731E3668    RBP 00000000    RSI 00000007    RDI 015B7AED
 R8  015B7AED    R9  0000007F    R10 00000005    R11 00000007
 R12 7F146FCAB410    R13 7F146FCC0078    R14 015B7AED    R15 7F146FC8C248

表示しているのは VMM 内に自分で追加したテストプログラムなので表示がいい加減なのはそのせい。 とにかく %rip=0x0101356e で一般保護例外だ。 フラグは IOPL=3, IF=1, bit1=1 以外は 0 だ。

[31] cs 33 ip 0101356e sp 7ffe731e3668 code 04d info1 00000000 info2 00000000 (
00b78900 c3ff5fd0/2be81872 85ff56df) br[00c67aee->01013560] ex[7f146ff13828->7f
146ff13860]

これも自分が追加したプログラムによる出力なので意味がわからないと思うが、code 04d が一般保護例外による #VMEXIT を表す。 謎の 00b78900 は Guest Instruction Bytes を出したもので、一般保護例外は対象でないので記録されておらず、下位 4 ビットは 0 になっている。 その後ろの 2be81872 85ff56df のところは、%rip を同じ論理 CPU 上で VMM から読み出したもので、キャッシュが壊れているわけではないことを確かめるためにやってみたものだ。br のところが LastBranchFromIP と LastBranchToIP である。 最後の分岐が 0x00c67aee から 0x01013560 だと言っている。

%rip のところを gdb で逆アセンブルすると以下のように出た:

=> 0x101356e <_Z22private_is_attribute_pPKcmPK9tree_node+14>:
    jb     0x1013588 <_Z22private_is_attribute_pPKcmPK9tree_node+40>
ここまでなら、「条件ジャンプで一般保護例外が出るなんて!」で終わる。 そのまま再開すれば動くんじゃないのとも言いたくなる。 しかし、そうじゃないんだな。 スタックを見てみよう。
0x7ffe731e3668: 0x0000000000c67af3      0x000000fb00000010

0x0000000000c67af3 は 0x00c67aee+5 であり、call 命令のようである。 そこは正しい。 呼び出しもとの call 命令は以下のようにちゃんとある。

 c67aee:       e8 6d ba 3a 00          callq  1013560

なので、分岐の情報は合っている。 じゃ、その先は?

 1013560:       48 83 ec 08             sub    $0x8,%rsp
 1013564:       8b 42 20                mov    0x20(%rdx),%eax
 1013567:       48 39 f0                cmp    %rsi,%rax
 101356a:       75 1c                   jne    1013588
 101356c:       48 8b 72 18             mov    0x18(%rdx),%rsi

一発目にスタックポインターの減算である。 上のスタックダンプを見ての通り、これは実行されていないとしか思えない。 しかも、%rip が指しているのは 4 バイトの mov 命令の 3 バイト目である。 ますますおかしい。

ここで頭をよぎるのが、何度も見ている 0x40 問題。 まさか、このサブルーチンの 0x40 手前に何かあるのだろうか?

 1013520:       48 8b 57 10             mov    0x10(%rdi),%rdx
 1013524:       b8 01 00 00 00          mov    $0x1,%eax
 1013529:       48 85 d2                test   %rdx,%rdx
 101352c:       74 e9                   je     1013517
 101352e:       48 8b 4a 10             mov    0x10(%rdx),%rcx

それっぽい命令が並んでいる。 順に検証しよう。 最初の mov 命令が読み取るメモリーの内容を確認する。

(gdb) x/xg 0x10+$rdi
0x15b7afd:      0x000a656c63796320
(gdb) p/x $rdx
$5 = 0xa656c63796320

完全に一致。 次の mov 命令がセットするレジスターの内容を確認する。

(gdb) p/x $rax
$6 = 0x1

これも完全に一致。 その次の test は上で確かめた %rdx の値に対してで、これを実行すると必ず CF=0, OF=0 になる。 また、%rdx の下位 8 ビットで立っているビットはひとつだから、PF=0 だ。 値はゼロでないので ZF=0 だ。 つまりフラグレジスターの値にも矛盾はない。 当然その次の条件ジャンプはジャンプせず、その次の mov 命令でアクセスすることになるのが %rdx+0x10 番地。 この番地は 48bit の符号付き整数で表せる範囲を超えているので、そこにアクセスすれば一般保護例外が発生する。 そしてこの命令がある番地 0x101352e は、見事に %rip-0x40 だ。 うわぁぁぁ。

さて、これを再開するとしたら、まず、いくつかのレジスターの値を復旧させなければならない。callq 1013560 の直前を見ると %r12->%rdx, %rax->%rsi だったことがわかるので、そこから %r12->%rdx をもう一度と、%rsi->%rax をすれば復旧完了。 あとは %rip=0x1013560 にして再開だ。 予想通り成功した。

そんなわけでね、ここ数日の印象としては、命令デコーダーか何か、その辺がひどく変な感じがする。 命令関係のキャッシュが原因の可能性もありそう。 番地の違うキャッシュをなぜか使っちゃってる、みたいな? そしてそのキャッシュだかなんだかわからないがたぶん 64 バイト単位なのでは。 でも分岐アドレスがズレて記録されていたのもあったな。 あれは何だ。

2017/06/20 のコメントを読む・書く


21 (水)

%1 久々に

自宅サーバー PC につながらなくなり、自宅電話にもつながらない状態。 だいぶ不安になりながら帰宅し、ルーターの状態を確認。 電話は「auひかり電話サービス利用不可」という表示。WAN 側 IP アドレスは表示されていたが、再起動を行ったところそれも消えてしまった。

ダイナミック DNS の更新のログを見ると 16 時過ぎにはつながらなくなっていた模様。KDDI に電話で聞いてみたところ、建物全体で問題があるようで原因調査中とのこと。 なんだろうねぇ。 だいぶ前に一度あったんだよね、こういうの。

2017/06/21 のコメントを読む・書く


22 (木)

%1 KDDI

au ひかりは、結局、きのうの 16 時 17 分には使えなくなっていたのが、今日の 19 時 17 分も使えなかったようで、そこから 20 時頃までの間に復活したようだ。7 年前にトラブった時は迷惑掛けましたって紙がポストに入っていたと思ったが、今回はそのときより長く 24 時間超えたけど何も無し。

%2 Debian 9

職場のノート PC にむち打って (冷却ファンがとまっていて熱々に...) Debian GNU/Linux 9 へのアップグレードを実行した結果、systemd を消そうとして停止するという被害にあった。

#854041 - systemd: dpkg fails for systemd package when upgrading from jessie to stretch - Debian Bug report logs

おっかしいな、なおってるってことになっているっぽいな。 まあいい、手で何とかした。 これは sysvinit にしてある他の環境では問題にはならないと思う。 他には、console-setup のフォント設定が起動時に反映されない被害に遭っている。

これは不思議なことに自宅の Ryzen PC では問題が起きていないので、UEFI ブートかどうかが関係しているのかも。 まー原因はともかく、最近の高解像度ディスプレイともなればデフォルトのフォントサイズは目つぶしでしかないと思うので、最初からもっと大きくしてていいんでないのかな。1024x768 でテキスト 80x25 が収まるくらいのサイズで十分でしょう。

%3 Ryzen のなぞ

64 バイトズレの問題のきっかけはやはり、先日出た不思議なページフォールトの件だ。 この問題は TLB フラッシュやら分岐の記録やらしなくても何度か再現している。 今日見た 2 回分 (1 秒以内に連続して発生) を下に載せてみる。 前のと表示内容は変えてある。

[31] cs 33 ip 0113f57d sp 7ffeb1823680 code 04e info1 00000006 info2 0000000a pte 00000003be53c025

PF   flags 00003206 err 00000006 cr2 a 0033:0113f57d *
RAX 00002000    RCX 00000007    RDX 00000000    RBX 02867F40
RSP 7FFEB1823680    RBP 7FFEB1823698    RSI 00000001    RDI 7F2E8E9CF000
R8  000009BA    R9  7F2E8E987DD0    R10 7F2E8E983000    R11 000001F2
R12 0289B9D0    R13 0000000A    R14 0000000A    R15 0289D410

[31] cs 33 ip 0113f57d sp 7ffd7de01330 code 04e info1 00000006 info2 0000000a pte 00000003be53c025

PF   flags 00003202 err 00000006 cr2 a 0033:0113f57d *
RAX 0000F680    RCX 00000007    RDX 00000000    RBX 02E15F40
RSP 7FFD7DE01330    RBP 7FFD7DE01348    RSI 0000001F    RDI 7FB0E8021000
R8  00001513    R9  7FB0E7FDF898    R10 7FB0E7FD5000    R11 00000437
R12 02E51DB8    R13 0000000A    R14 0000000A    R15 02E535E0

 113f57d:       45 8b 69 10             mov    0x10(%r9),%r13d

 113f53d:       49 89 55 00             mov    %rdx,0x0(%r13)

これ。 エラーコードが 6 で、書き込み時のページフォールトを表し、アクセス先のアドレスは 0xa。 しかし %rip が指す命令は、全然違うアドレスの読み取り。 そしてちょうど 64 バイト手前にそれっぽい命令があるという形。 この 64 バイトはただの偶然の可能性もあったが、その後も LBR や call 先のズレなどの形で現れたというわけ。 なお、このページフォールトの件ではこの 0x113f57d の直前にジャンプ命令などなく、レジスターの中身を見ても直前までは順番に実行されてきたとしか思えない状態。

美しく説明できるのはこのくらいで、他はいきなりアドレス 0x11 にアクセスとか、アドレス 0x11 にジャンプとか、アドレス 0 にジャンプとか、そんなふうにいまいちわからないものも多い。 ま、たまに以下のようにファイルサイズのことなるイメージが出力されていることもあるしな。 問題が起きてもクラッシュに至らないケースもあるということだろう。

104 -rw-r--r-- 1 root root 7056208 2017-06-22 16:35:45.535340840 +0000 arch/x86/boot/bzImage
105 -rw-r--r-- 1 root root 7056176 2017-06-22 16:37:15.741843546 +0000 arch/x86/boot/bzImage

2017/06/22 のコメントを読む・書く


23 (金)

%1 合掌

『恋のから騒ぎ』の小林麻央出演のところ、YouTube で少し見てみた。 こんな声だったかな、と思ったけど、説教部屋のシーン見てたら思い出してきたよ。 やっぱこの頃は見てたなーこれ。 同学年だし。 番組おもしろいし。

【ノーカット】市川海老蔵、妻・小林麻央さん死去を報告「愛してる」と言って旅立つ - YouTube

あごに転移とか、退院・在宅医療とか、最期が近づきつつあるともとらえられるニュースはちらほらあったけど、ついに。35 歳をむかえる前に。 同年代の人が病気で旅立つというのはやはり寂しい。 合掌。

2017/06/23 のコメントを読む・書く


24 (土)

%1 じゃがいも掘り

きのう、今日と天気が良かったので掘りやすかったけど、今年は小さめのが多かったな。 畑が変わって何か違うのかな。

帰って洗って乾かして段ボール箱に。 一個はスコップを突き刺してしまったので夜には食べた。

%2 株主総会

ブックオフの株主総会には行こうかと思っていたけどやめた。 おみやげ無くなったみたいだしな。

ディーエヌエーの株主総会には行った。 今回は渋谷だから大変行きやすい。 品川より本社に近いし (同じビル)、多摩地域だけでなく埼玉も横浜も新宿・渋谷あたりは行きやすいと思うのだが、なぜ今まで品川でやっていたのか。 キュレーション関係の問題で突っ込む人はそんなにいなかった。 確かに結構中の仕組みを入れ替えて来ている感じがするし。 最後の人は Google やら YouTube やらはいいのにといった感じの擁護意見、それはでも自分は違うような気がするけどな。 お金を払って書かせていたってのがね。

%3 映画

テレビでやってた映画『マーキュリー・ライジング』(原題: Mercury Rising)。1998 年のアメリカ映画。 日本語吹き替え版。 ブルース・ウィリス主演。 自閉症の子供が重要な役割を果たす。 自閉症は病気ではない、など、知的障害者と見なした人に対する反論も映画の中に出てきており、誤解を招かないよう注意深く描写されているような感じ。 前にもそういう障害を持つ人が出てくる映画見たな。 『レインマン』だ。 あれはサヴァン症候群だったけど。

暗号を解けてしまう自閉症の子供とその家族を消そうとするアメリカ国家安全保障局というアホな設定である。 他の自閉症の子供が解けないとでも思ったのだろうかという間抜けな話である。 ま、いいや、それで連邦捜査局に勤める主人公が何とか子供を守ろうとするのだった。

出てくるコンピューターがブラウン管ディスプレイ... なのはいいんだが、1998 年にしては、Windows 95 などの影響を受けていない感じの、昔風のインターフェイスが出てくる。 物語としては電話は盗聴されているしコンピューターを使うのもまずい、なんて話になり、タイプライターにカーボンコピーが使われ、そのカーボン紙が証拠になる。 自分は子供の頃にカーボン紙を触ったことがあって知っているが、今時の、2000 年頃以降に生まれた人達から見れば何がなんだかわからないかも知れない。 あ、一応、携帯電話は出てきたな。 大きくて、しかもそれを人に借りるという...

この映画、ちょっとした銃の撃ち合いがある程度で基本的には静かな映画なのかと思いきや、鉄道は出てくるし、ヘリコプターも出てくるし、派手な銃撃戦が最後に待っていた。 結構どかどかと派手にやってすっきりするタイプの映画だった。

%4 F1 予選

映画を見ていたので裏番組の F1 アゼルバイジャン GP 予選を見ようと思って iMac を起動した。DAZN は Safari に Silverlight プラグインを入れると見られる。Mozilla Firefox でも見られるのかも知れない。iMac のディスプレイは動画向きではなく、残像が残るというかにじんだ感じになるが、画面が大きいのでタイムは見やすいし、映画の横でチラチラ見る分にはさほど気にならない。 というか、それより 25fps なのが気になる。

予選はさすがメルセデス。 ポールポジション獲得回数一覧に未だにアイルトンセナの名前が残っているわけだが、ついにハミルトンが抜いた。 もうちょっとでミハエルシューマッハの記録に到達だ。 このトリッキーな市街地コースでこのタイムだし、本当にすごいなぁ。

2017/06/24 のコメントを読む・書く


25 (日)

%1 ワイパーゴム交換

車のワイパーゴムを初めて自分で交換した。 特に工具もいらない簡単な作業。 ゴムの溝にブレードのつめが引っかけてある形、ゴムの溝の端っこにストッパーのためのふくらみがあり、端っこのつめがそこにはまって取れにくくなっている。 それと、金属製の棒がはまっていて、これがブレードと合わせてバネの効果を出しているみたい。

そんなわけなので、ストッパーを無視して無理やり引っこ抜き、金属棒を新しいゴムに移して、またブレードのつめに引っかかるように差し込み、最後にストッパーに引っかかるように押し込めば完了。 抜くとき、ブレードを外さずに行うと、ワイパーを立てるとガラスに当たって抜けないので、少し浮かせたくらいの角度で引っこ抜き、ブレードがガラスに当たらないようにワイパーを立てておく。 入れる時もまた似たような角度で入れる。

%2 スイッチングハブ

NETGEAR の GS108E を導入。 これで Ryzen PC とバックアップ用 PC をちゃんとつなぐことができた。8 ポートで VLAN にも QoS にも対応、お手頃価格でちょっと PC が増えてきた家庭用にぴったりである。 なお、ルーターとつないでいる LAN ケーブル (自宅にある LAN ケーブルの中では一番長い) が思っていたより 10cm くらい短くて、当初考えたところにスイッチングハブを置けなかったけど、まいっか。

%3 にちようび

よく寝た日。

今回の Formula One アゼルバイジャン GP は本当にぐだぐだだった。 いくら市街地コースとはいえここまでひどいのは久しぶりでは。 セーフティカーが機能していないと言ったらアレだが、タイヤ温度が下がってしまって、再開のたびにアクシデントが起こるという悪循環、結局赤旗。 そもそもはセーフティカーがなかなか入らなかったのも謎だが、その結果、レース序盤では想像もしなかったメンツが表彰台、ルーキーのストロールは初表彰台。 ドライバーズポイントを争うふたりもぐだぐだとは言え 4・5 位完走。 ペレスやライコネンは結局リタイヤ。 まーでも今回の見てても、フェラーリやメルセデスや、フォースインディアもかな、ちょっとホイールが接触した程度ではサスペンションが壊れることはないんだよな。 今年のマクラーレンは何かとすぐ壊れる感じ。

2017/06/25 のコメントを読む・書く


26 (月)

%1 睡眠薬運転の話

そういえば 2 週間ほど前に睡眠薬を飲んで車を運転して単独の物損事故を起こした芸人のニュースがあった。 たいした事故じゃなかったのは良かったが睡眠薬を飲んで運転とは何事かという話であった。

自分は睡眠薬は飲んだことがないが、眠気を催すおそれのある薬というのはいくらでもあり、そういう注意書きがある薬を飲んで車両 (車やバイクや自転車) を運転したことは何度もある。 そういう意味では他人事ではないのだが、明らかに眠くなった経験のある薬を飲んで眠くなる前に運転をしたというのはないと思う。 たぶん。 普通の総合感冒薬にもその手の成分は入っているが、何度も飲んでいてそれで眠くなった経験がないものは自分的には大丈夫なのかなという判断。

もちろん、いつも大丈夫だったからといって次も大丈夫とは限らないといえばそうで、体調次第では変なふうに効き目が現れるおそれもある。 しかし、それを言うなら、薬を飲んでいなければ大丈夫という話ではなくて、睡眠不足とか体調不良とか、そういうところに気をつけなければならない。 まぁでも現実は、旅客運送などのプロドライバーの方を除いて、ちょっと体調が変だからとか、ちょっと睡眠時間が短かったからとか、そんな理由で運転を完全に取りやめることはないものかも。 病院に行くにも車がないとという環境もあるだろうし、そういう時に体調がすぐれない場合は、休み休みいくとか、人通りの少ない道と時間を選んでゆっくりいくとか、万が一のことがあっても被害を最小限に食い止める工夫も必要だろうか。

なお、今処方されている薬の中にモービック錠というのがあり、視力や眠気に関する注意書きが書かれていることに最近気づいた。 薬局でも特に口頭で言われたことはないし、もう 2 週間くらい飲んでいるけど (分量は変わったけど) そういう症状は何も出ていない。 過去に何かですごく眠くなる薬を処方されたことはあった気がする。 でもあのときも毎回だいたい眠くなるタイミングってものがあったような...

あ、この問題って運転に限らないな。 歩いていても、駅や踏切でばったり倒れて線路の中に入ってしまったら一大事だ。

2017/06/26 のコメントを読む・書く


27 (火)

%1 Ryzen gcc core dump

Ryzen PC の gcc (cc1) が吐いた core dump。Segmentation fault と出て、さらに、dmesg を見ると segfault が出ていた。 何か、core dump を吐かせるためにわざとシグナルハンドラーを消して再実行でもしているのかと思っていたが、core dump をよく見るとどうやら違ったみたいだ。

dmesg に残った segfault と core を見ればアドレス 0x11 を読み取ろうとしてクラッシュしており、アドレス以外に不審な点が見当たらない。 何度か見ていたなぜかアドレス 0x11 にジャンプする事象、それと関係はあるのだろうとは思っていたが、バックトレースには internal_error() などの関数名が出ており、よくよく追ってみたところ、全く同じ事象だった。 真相はこうだ。

  1. アドレス 0x11 にジャンプして segmentation fault が発生、gcc のシグナルハンドラーへ
  2. シグナルの無限ループを避けるためシグナルハンドラーの登録解除
  3. Internal error の処理へ遷移、その中で backtrace_full() を呼び出すらしい
  4. バックトレースをたどろうとした結果、壊れたスタックの 0x11 にたどり着き、そのアドレスをスタックとみて読み取ろうとして 2 度目の segfault, これが core を吐き dmesg にログを残した (たぶん)

そんなわけで、シグナルハンドラーらしきところにフレームを戻し p/x *(struct sigcontext *)($sp+0x38) でそれっぽいレジスター状況が確認できた。 プログラム的に $sp には push %rbx の内容、+8 には戻り番地が入っているはずで、その先のオフセットは手探り。IA-32 なら引数はスタックに積まれるのが普通なので、戻り番地の次にシンプルにシグナル番号と struct sigcontext が見えるはずなのだが、AMD64 ではレジスター渡しが普通なので、struct はどうやって渡されるんだったかな。 でもどっか近くにあるだろということで、フラグレジスターや %cs レジスターの値が合うようにずらしたらこの +0x38 で出た。 で、中身を見ていくと見事にアドレス 0x11 へのジャンプ。 なんでそんなところにジャンプしてしまうのかは、まだ特定できていない。

ま、とりあえず、core dump がはかれるケースがある理由が特定できたのは進歩だ。 別にクラッシュ原因を深く追う意味はないんだけど、こういうパズルは楽しいので。

2017/06/27 のコメントを読む・書く


28 (水)

%1 Ryzen 0x11 問題

謎が解けてきたぞ。%rip=0x11 で停止した時のスタックポインター 0x7ffc95e3ed48 の手前を見るとこうだ。

0x7ffc95e3ed28: 0x00007ff14f638dc8      0x00007ff14f638db0
0x7ffc95e3ed38: 0x0000000000d858e0      0x0000000000000011
0x7ffc95e3ed48: 0x0000000000000011      0x0000000000000000

0x11 に ret してしまったらしいこれ、その前にある 0x0000000000d858e0 が、実は 0x40 ズレた位置の戻り番地だ。(以下、シンボル名は長いので削ってある。)

  d8589b:       e8 90 d2 2b 00          callq  1042b30
  d858a0:       8b 54 24 7c             mov    0x7c(%rsp),%edx

%rip が本来の位置とはズレたまま call を呼んだわけだ。 相対番地なので call 先もズレてしまうようだ。

 1042b70:       39 c2                   cmp    %eax,%edx
 1042b72:       0f 47 d0                cmova  %eax,%edx
 1042b75:       83 fa 01                cmp    $0x1,%edx
 1042b78:       0f 85 97 00 00 00       jne    1042c15
 1042b7e:       b8 01 00 00 00          mov    $0x1,%eax
 1042b83:       5b                      pop    %rbx
 1042b84:       c3                      retq

来た来た。push していないのに pop して ret したらそりゃズレる。 レジスターの値をいくつか確認したがそれっぽい。 例えば %rbx は 0x0000000000d858e0 になっている。 だがここでいくつかのレジスターを壊してしまうから追いにくい。 それをもうちょっと調べられるといいなと思ったわけだ。 そこで、call 先がズレた時に int3 が実行されるように cc1 をバイナリーエディターで改造してみた。

2808992,2808993c2808992,2808993
<  1042b26:     66 2e 0f 1f 84 00 00    nopw   %cs:0x0(%rax,%rax,1)
<  1042b2d:     00 00 00
---
>  1042b26:     e9 ee 72 89 ff          jmpq   8d9e19
>  1042b2b:     e9 e5 00 00 00          jmpq   1042c15
2809013,2809018c2809013,2809020
<  1042b67:     0f 84 ac 72 89 ff       je     8d9e19
<  1042b6d:     c1 e8 06                shr    $0x6,%eax
<  1042b70:     39 c2                   cmp    %eax,%edx
<  1042b72:     0f 47 d0                cmova  %eax,%edx
<  1042b75:     83 fa 01                cmp    $0x1,%edx
<  1042b78:     0f 85 97 00 00 00       jne    1042c15
---
>  1042b67:     74 bd                   je     1042b26
>  1042b69:     c1 e8 06                shr    $0x6,%eax
>  1042b6c:     0f 1f 44 00 cc          nopl   -0x34(%rax,%rax,1)
>  1042b71:     39 c2                   cmp    %eax,%edx
>  1042b73:     0f 47 d0                cmova  %eax,%edx
>  1042b76:     83 fa 01                cmp    $0x1,%edx
>  1042b79:     75 b0                   jne    1042b2b
>  1042b7b:     0f 1f 00                nopl   (%rax)

ちょうどルーチンの手前にある長い長い nop と、遠距離条件ジャンプがふたつもあったおかげで工夫がきいた。 長い nop のところに遠距離無条件ジャンプをふたつ入れ、遠距離条件ジャンプふたつを近距離条件ジャンプに変えることで 8 バイトを手に入れ、それを 5 バイトと 3 バイトの nop で消費、5 バイトの nop の最後に cc (int3) を仕込んでおいた。 これで通常動作は OK だが、1042b70 に飛び込めば int3 が実行される。int3 は segfault とは異なりシグナルハンドラーが登録されておらず、いきなり落ちるので都合が良い。 再現実験は cc1 の繰り返しで見事成功した。

Program terminated with signal SIGTRAP, Trace/breakpoint trap.
(gdb) info reg
rax            0x1      1
rbx            0x7f39d6851930   139886388910384
rcx            0x40     64
rdx            0x40     64
rsi            0x7f39d6851940   139886388910400
rdi            0x7ffc56f4d870   140721767372912
rbp            0x7ffc56f4d870   0x7ffc56f4d870
rsp            0x7ffc56f4d808   0x7ffc56f4d808
r8             0x0      0
r9             0x1      1
r10            0x40     64
r11            0x7f39d6b080a8   139886391754920
r12            0x0      0
r13            0x7f39d6b080a8   139886391754920
r14            0x11     17
r15            0x0      0
rip            0x1042b71        0x1042b71
eflags         0x202    [ IF ]
cs             0x33     51
ss             0x2b     43
ds             0x0      0
es             0x0      0
fs             0x0      0
gs             0x0      0
(gdb) x/40xg $rsp-0x40
0x7ffc56f4d7c8: 0x00007ffc56f4d8a8      0x00007f39d5d32440
0x7ffc56f4d7d8: 0x00007f39d5ff1b40      0x0000000000000000
0x7ffc56f4d7e8: 0x0000000000000003      0x00007f39d6c7a540
0x7ffc56f4d7f8: 0x0000000001ee38d0      0x00007f39d6851930
0x7ffc56f4d808: 0x0000000000d858e0      0x0000000000000011
0x7ffc56f4d818: 0x0000000000000000      0x00007f3900000000
0x7ffc56f4d828: 0x0000000000000000      0x00007f39d5d0e000
0x7ffc56f4d838: 0x0000000000000000      0x0000000000000000
0x7ffc56f4d848: 0x0000000000000000      0x0000000000000000
0x7ffc56f4d858: 0x0000000000000001      0x00007f39d6c66e70
0x7ffc56f4d868: 0x00007f39d5d0e0a8      0x00000000000000d0
0x7ffc56f4d878: 0x0000000000000000      0x00007f39d5d0e0a8
0x7ffc56f4d888: 0x0000000000000001      0x000000000000001a
0x7ffc56f4d898: 0x0000000000da0bcd      0x000000000136874d
0x7ffc56f4d8a8: 0x00007f39d6b08bd0      0x000000000000001a
0x7ffc56f4d8b8: 0x00007f39d6b080a8      0x0000000000000000
0x7ffc56f4d8c8: 0x0000000000000000      0x0000000000000000
0x7ffc56f4d8d8: 0x000000ffffffffff      0xffffffff80000001
0x7ffc56f4d8e8: 0x00007f39d6851930      0x00007f39d5ff1b40
0x7ffc56f4d8f8: 0x0000000000000000      0x00007ffc56f4da00

たぶん、ズレは d858b9 のあたりだ。

  d85873:       48 98                   cltq
  d85875:       0f b6 53 04             movzbl 0x4(%rbx),%edx
  d85879:       44 0f b7 84 00 a0 a6    movzwl 0x12ca6a0(%rax,%rax,1),%r8d
  d85880:       2c 01
  d85882:       48 8d 73 10             lea    0x10(%rbx),%rsi
  d85886:       48 8d 7c 24 60          lea    0x60(%rsp),%rdi
  d8588b:       41 0f b7 4b 34          movzwl 0x34(%r11),%ecx
  d85890:       44 89 44 24 7c          mov    %r8d,0x7c(%rsp)
  d85895:       81 e1 ff 03 00 00       and    $0x3ff,%ecx
  d8589b:       e8 90 d2 2b 00          callq  1042b30
  d858a0:       8b 54 24 7c             mov    0x7c(%rsp),%edx
  d858a4:       41 89 c2                mov    %eax,%r10d
  d858a7:       89 44 24 78             mov    %eax,0x78(%rsp)
  d858ab:       41 c1 e2 06             shl    $0x6,%r10d
  d858af:       41 39 d2                cmp    %edx,%r10d
  d858b2:       77 44                   ja     d858f8
  d858b4:       48 8d 6c 24 60          lea    0x60(%rsp),%rbp
  d858b9:       48 8d bc 24 80 00 00    lea    0x80(%rsp),%rdi
  d858c0:       00

d858b9 が実行されたかどうかは定かでないが、call の後そこまでは正常に実行されていたとおぼしき内容は確認できる。 残念ながらズレた時の d85890 の実行で 0x7c(%rsp) は破壊されているので d858a0 の内容の検証はできないが、今回は int3 のおかげでそのときのレジスターの値は残っている。%r10 に 0x40 (1<<6) が入っていること、0x78(%rsp) (0x7ffc56f4d888) に 1 が入っていること、%r10d と %edx が等しいこと、%rbp に 0x60(%rsp) (0x7ffc56f4d870) のアドレスが入っていることから、d858b4 までは実行されたと考えて矛盾はない。 また、0x4(%rbx) には以下のように 1 が入っているため、ズレた時に d85875 は実行されなかったと考えるのが自然。

(gdb) x/bx $rbx+4
0x7f39d6851934: 0x01

d85879 の 0x12ca6a0(%rax,%rax,1) は以下の内容でレジスターと一致。

(gdb) x/hx 0x12ca6a0+$rax+$rax
0x12ca6a2 <mode_precision+2>:   0x0000

次の d85882 と d85886 もレジスターの内容が一致。その次の d8588b もメモリーの内容が一致。

(gdb) x/hx 0x34+$r11
0x7f39d6b080dc: 0x0040

d85890 による書き込み結果は上にある通り 0x7c(%rsp) (0x7ffc56f4d88c) には 0 が書き込まれているため一致しており、d85895 の and 結果もフラグレジスターの内容も一致するので、たぶん、d858b9 を実行しようとした時になぜか d85879 からの命令列を実行していたということで、これで 0x11 問題は説明できていると思う。

%2 休暇

マルハニチロの株主総会。 今日は土産をもらいに行っただけ。 ここは株主総会のおみやげもちょっと豪華。 鯖水煮缶詰と鮭フレークとゼリーと DHA 何とか、都心の人なら交通費分くらいはあるし、9 時ちょっと過ぎの時点でもう土産持って歩いている人を見たので、近辺に勤めている人なら、朝イチに寄って土産もらってから出勤なんて人もいるかも。

続いて FFRI の株主総会。 初。 来ている株主はそんなに多くはない印象。 報告はシンプル、ナレーションがちゃんと入ってると思ったが、招集ご通知の内容をスライドに貼ってナレーションはそれを読み上げているだけだったw 海外展開始めますよー、ってのが新たなポイントなのか。 まずは北米から。 個人向けは特に Android 等向けは販促費がかかるとのことで、見直していくつもりのよう。 昨今のランサムウェアの被害増大に伴い需要は増えているもよう。 あんまり質問も出ないので、平均勤続年数 2.1 年ってどうなんですかと聞いてみたら、2014 年頃から新卒採用や中途採用をしてきた人数が結構あるらしくて、それで短くなってますーとのことだった。

FFRI は株主総会後に休憩を挟み、代表と取締役もう 1 人が出てきて、今後の展望についての説明があった。 海外向けを伸ばしていきたいもくろみらしい。 まぁあの主力製品をメンテし続けていられるなら技術力的にはそんなに心配はないだろうと思う。 こういう製品があるんだ、とユーザーに認知してもらうところのハードルは確かにあるよなぁ。

%3 移動

朝 6 時台に目覚めてしまったので、テキトーに移動を開始。 すでに雨は降りだしていた。 バスで三鷹まで出て、各駅停車の始発を狙う作戦。 バスは混んでいた。7 時台はこんなに込むものなのか。 府中からなので余裕で座っていたのだけど、前の一人席にいたら、混雑してきて横に立っていた女子高生がだんだん近寄ってきて... 途中からもうバス停スキップしてたな、なんかアナウンスしてたからたぶん後続のバスに乗ってくれということなんだろう。 バス専用レーンのあるところはすいすいだ。 まぁこのあたりはバスの本数が多いから、バス専用レーンの渋滞回避効果は高いだろう。 原付で通ったことはあるが、バスからその景色を見るのは初めてだった。

三鷹の整列乗車はやっぱり意味わかんない。 何がなんだか。 都営三田線の停車駅を調べた結果、地下鉄東西線直通で、大手町まで出ることにした。 これもまぁ席は埋まる程度には混雑するが、ぎゅうぎゅうにはならない。 九段下あたりで降りる人と乗る人が多く、大手町は案外誰も降りなくて人をかき分けることになってしまったが...

やっぱり大手町で見る通勤客の皆さんの足音は怖い。 ざっざっざっ、と、どこぞの軍隊か。 まぁでも端っこをゆっくり歩く分にはみんなスルーだ。 途中で迷ってきょろきょろしてるとちょっと邪魔っぽいけど、こんなところたまにしか来ないから仕方ないだろ!

時間が早かったので三田線の改札前にあったドトールで朝食を取った。 ドトールの中の仕組みも知らなかったよ。 朝は席取りは決済後。 水はセルフサービス。 意外と新聞なんか読んでのんびりしている人は多いように見えた。 んで三田線がまた意外と混雑しているような... 芝公園まで行ってメルパルクホール。

そこから今度は浜松町に出てみることにした。 そしたら山手線遅れてた。 京浜東北線に乗ったが田町で乗り換えるべきだった。 そしたら目の前だったし空いていたはず。 品川まで行ったら階段登っての乗り換えになった上、山手線ホームが遅れの影響で人だらけ。 田町だったらうまくいけば座れていたと思う。 まーそんなこんなで割とぎゅうぎゅうで恵比寿行った。 恵比寿で何度か靴が滑って危なかった。

帰りは渋谷経由で明大前でカレーを食って帰った。

2017/06/28 のコメントを読む・書く


29 (木)

%1 ポケモン GO

レイドバトルだかなんだかそういうのができて、ジムがずいぶん変わったのだが、コマ落ちがひどくてなんだかよくわからず、一度バトルをしようとしたら、カウントダウンが出てきて、始まるぞというところで「ネットワークエラー」。 うーん。 それで、ジムにポケモンをおくというのは一応できて、以前のようにボーナスをもらおうとショップを開いたら、ない。 ボーナスのシステム変わったのか。 帰ってきた後で確認したら増えていた。

ポケストップがジムに化けたところがけっこうあって、アイテムもらえないのかと思えばそうでもなくて、一応ジムでもアイテムをもらえるようになっている。 今までジムだったところもアイテムをもらえるのでむしろアイテムをもらえるところが増えたとも言える。 しかし、ポケモン GO Plus がジムからアイテムを拾ってくれるわけではなさそうだ。 三鷹駅だと南口の通りの商店街にあるたくさんのポケストップは割とそのままで、駅前のケヤキだっけ、主にバス・タクシーのロータリーみたいになっているところがひとつジムになった。 多磨駅でも近くの体育館だったかな、そこがジムに化けた。 人見街道の、新撰組の何とかかんとか、近藤神社だっけ、そこも。 他にもいくつか。

%2 cc1 core dump

cc1 のシグナルハンドラーが正常に機能すると core dump が出てこないので、何とかならないか、と考えていたが、ふと簡単な方法を思いついた。 この前、シグナルハンドラーから internal error が呼ばれている、というのがわかったとき、シグナルハンドラーのアドレスもわかってしまったのだ。 そこに int3 を仕込めば、core dump が出る。 しかも、struct sigcontext が残るので、ページフォールトの詳細などもわかる。 画期的!

632318c632318
<   7d6572:     53                      push   %rbx
---
>   7d6572:     cc                      int3

後はたくさん試行してたくさんの core dump をゲットすれば楽しみが増える。 なお、Debian GNU/Linux 9 のカーネルパッケージのアップデートに伴い、若干挙動が変わったようだが、前と同じ segfault も出ることは出るみたいなので、一晩実行して収集してみよう。

2017/06/29 のコメントを読む・書く


30 (金)

%1 映画

テレビでやってた映画『藁の楯』。2013 年の邦画。 約 2 年ぶり。 相変わらず読めない。

最初のほうはあまり記憶に残っていなかったが、移送を始めたところから記憶がよみがえってきた。 ただし詳細は覚えておらず、何か起こるたびに、ああそうだった、の繰り返し。 藤原竜也の狂った犯人の演技、大沢たかおのガチ SP っぽい演技などが見所だなぁ。 なお、拳銃を撃つシーンはいまいち迫力に欠ける。 反動がわざとらしいというか。

%2 きのうの core dump

いくつか取れたが、試しにそのうちのひとつを調べ始めたらこれがよくわからない。 なぜか %rip=0 になっているので、当然、スタックを見て、戻り番地らしきものがあって、そこにはメモリーからジャンプ先アドレスを取得する call 命令があり、確かにそこから来てしまったもののよう。 さらにさかのぼって見ていったのだが、不審な点が見当たらない...

なお、こないだの int3 ハックを残してあるので、いくつかはその番地でクラッシュしている。 それらは全く同じパターンと見て良いだろう。 あと、クラッシュせずに internal error が出てしまうケースも発生した。

0x40 バイトズレ問題で気になるのは、ズレた時点ではきれいに命令境界にまたがることなくズレている点で、その後の call 等で変なアドレスに飛んでしまうことはあっても、ズレた瞬間に変な命令を実行しているケースはまだ確認できていない。 もしかしたら、変な位置にズレたら Machine Check Exception が出るのかな、なんて想像はしている。 それを検証するには、同じファイルのビルド繰り返しで同じトラブルが発生するパターンを使って、cc1 の一部のバイナリーを書き換えてわざと該当部分の命令をわずかに変えればいいのかな? うまくいくかどうかはわからないが。

2017/06/30 のコメントを読む・書く


Powered by Tomsoft Diary System 1.7.4

/var/log/hdk.log コメント一覧

トップ / 日記索引 / 日記 (2017 年 6 月)

Hideki EIRAKU