-ffixed-reg などというオプションをコメントで教えて頂いた。 なんとまぁこれほどまでにドンピシャなオプションがあるものだろうか...
ま、それはともかく、きのうのやつで一晩ビルドテストを回した。linux-4.12-rc4 の defconfig build で -j16 で、あの改造で少し 1 サイクルの時間は延びて、80 秒あたりになっている。 それでも速い... さて、どんな core ができたかな?
-rw-r--r-- 1 root root 62722048 Jul 10 00:11 dbg-1499613093.56/core -rw-r--r-- 1 root root 26812416 Jul 10 00:12 dbg-1499613171.57/core -rw-r--r-- 1 root root 87371776 Jul 10 00:34 dbg-1499614440.73/core -rw-r--r-- 1 root root 72695808 Jul 10 01:58 dbg-1499619536.136/core -rw-r--r-- 1 root root 54448128 Jul 10 02:51 dbg-1499622678.175/core -rw-r--r-- 1 root root 63148032 Jul 10 02:55 dbg-1499622916.178/core -rw-r--r-- 1 root root 0 Jul 10 04:47 dbg-1499629623.261/core -rw-r--r-- 1 root root 37683200 Jul 10 04:54 dbg-1499630090.267/core -rw-r--r-- 1 root root 0 Jul 10 04:59 dbg-1499630359.271/core -rw-r--r-- 1 root root 39424000 Jul 10 05:00 dbg-1499630433.272/core -rw-r--r-- 1 root root 145039360 Jul 10 05:15 dbg-1499631320.283/core -rw-r--r-- 1 root root 22560768 Jul 10 05:29 dbg-1499632187.294/core -rw-r--r-- 1 root root 104542208 Jul 10 05:40 dbg-1499632829.302/core -rw-r--r-- 1 root root 61767680 Jul 10 05:46 dbg-1499633180.307/core -rw-r--r-- 1 root root 34443264 Jul 10 06:28 dbg-1499635712.339/core -rw-r--r-- 1 root root 4599808 Jul 10 06:33 dbg-1499636023.343/core
一部 0 バイトとあるのは実は core がはかれなかったところ、今回シグナルハンドラーのほうは何もしていなかったので、普通に SIGSEGV/SIGILL 等が起きると core 無しになってしまうのだった。 出力メッセージもとってあり、いずれも Segmentation fault でバックトレースは出ているが、それ以上の詳細は出ていないみたいだ。 ただ、これはまだ何かありそうで気になるところではある。
ま、分析できないものはしょうがない。 残りは core が出ているのだから、調べようがある。 まずは $pc の観察。
dbg-1499613093.56 (gdb) => 0x15e0421 <hoge_fail+65>: int3 dbg-1499613171.57 (gdb) => 0x16a7201 <hoge_fail+65>: int3 dbg-1499614440.73 (gdb) => 0x1687181 <hoge_fail+65>: int3 dbg-1499619536.136 (gdb) => 0x1640b41 <hoge_fail+65>: int3 dbg-1499622678.175 (gdb) => 0x1640b41 <hoge_fail+65>: int3 dbg-1499622916.178 (gdb) => 0x1617cd1 <hoge_fail+65>: int3 dbg-1499629623.261 dbg-1499630090.267 (gdb) => 0x1640b41 <hoge_fail+65>: int3 dbg-1499630359.271 dbg-1499630433.272 (gdb) => 0x1640b41 <hoge_fail+65>: int3 dbg-1499631320.283 (gdb) => 0x16e1a01 <hoge_fail+65>: int3 dbg-1499632187.294 (gdb) => 0x1617cd1 <hoge_fail+65>: int3 dbg-1499632829.302 (gdb) => 0x1640b41 <hoge_fail+65>: int3 dbg-1499633180.307 (gdb) => 0x1617cd1 <hoge_fail+65>: int3 dbg-1499635712.339 (gdb) => 0x16dbf01 <hoge_fail+65>: int3 dbg-1499636023.343 (gdb) => 0x1510761 <hoge_fail+65>: int3
全部 +65 で、期待が持てる。 次に $r10-64 を見てみよう。
dbg-1499613093.56 (gdb) 0xf80363 <_ZL13calc_dfs_treeP8dom_infob+243>: cmp $0xf80363,%r10
dbg-1499613171.57 (gdb) 0x1358079 <_Z16compare_tree_intPK9tree_nodem+73>: cmp $0x1358079,%r10
dbg-1499614440.73 (gdb) 0x130d941 <_Z18thread_across_edgeP5gcondP8edge_defbP3vecIP9tree_node7va_heap6vl_ptrEPFS5_P21gimple_statement_baseSB_E+1409>: cmp $0x130d941,%r10
dbg-1499619536.136 (gdb) 0x1161a7a <_ZN12_GLOBAL__N_118pass_cprop_hardreg7executeEP8function+10394>: cmp $0x1161a7a,%r10
dbg-1499622678.175 (gdb) 0x1161a7a <_ZN12_GLOBAL__N_118pass_cprop_hardreg7executeEP8function+10394>: cmp $0x1161a7a,%r10
dbg-1499622916.178 (gdb) 0x10b545e <_ZL20record_operand_costsP8rtx_insnP9reg_class+4766>:
sub %dl,%cs:0x0(%rsi)
dbg-1499629623.261 (gdb) (gdb) quit
dbg-1499630090.267 (gdb) 0x1161a7a <_ZN12_GLOBAL__N_118pass_cprop_hardreg7executeEP8function+10394>: cmp $0x1161a7a,%r10
dbg-1499630359.271 (gdb) (gdb) quit
dbg-1499630433.272 (gdb) 0x1161a7a <_ZN12_GLOBAL__N_118pass_cprop_hardreg7executeEP8function+10394>: cmp $0x1161a7a,%r10
dbg-1499631320.283 (gdb) 0x148536a <_ZN12_GLOBAL__N_115pass_rtl_fwprop7executeEP8function+3658>: cmp $0x148536a,%r10
dbg-1499632187.294 (gdb) 0x10b545e <_ZL20record_operand_costsP8rtx_insnP9reg_class+4766>:
sub %dl,%cs:0x0(%rsi)
dbg-1499632829.302 (gdb) 0x1161a7a <_ZN12_GLOBAL__N_118pass_cprop_hardreg7executeEP8function+10394>: cmp $0x1161a7a,%r10
dbg-1499633180.307 (gdb) 0x10b545e <_ZL20record_operand_costsP8rtx_insnP9reg_class+4766>:
sub %dl,%cs:0x0(%rsi)
dbg-1499635712.339 (gdb) 0x1440281 <_ZL22mark_used_regs_combineP7rtx_def+353>:
cmp $0x1440281,%r10
dbg-1499636023.343 (gdb) 0x151c275 <c_builtin_function(tree_node*)+261>: cmp $0x151c275,%r10
あ、あれ? あれれ? %r10 と比較する cmp 命令があって、そのオペランドと命令のアドレスが一致しているやつは想定通りなのだが、一部そうじゃないやつがある。dbg-1499622916.178 と dbg-1499632187.294 と dbg-1499633180.307 だ。 いずれも 64 引いたアドレスは 0x10b545e だ。 なお、これらの %r10 が指すアドレス 10b549e にはきちんとプログラムがあり、ここを実行していたなら変なことになるようには見えない。
10b5497: 4c 8d 15 00 00 00 00 lea 0x0(%rip),%r10 10b549e: 49 81 fa 9e 54 0b 01 cmp $0x10b549e,%r10 10b54a5: 0f 85 e5 27 56 00 jne 1617c90 <hoge_fail>
うーん... ジャンプ先のアドレスからして 64 バイトのズレということにはなるのに、64 バイトズレたところにきれいに命令があるわけではないというのはどう見ればよいのか...
10b544e: 4c 8d 15 00 00 00 00 lea 0x0(%rip),%r10 10b5455: 49 81 fa 55 54 0b 01 cmp $0x10b5455,%r10 10b545c: 0f 85 2e 28 56 00 jne 1617c90 <hoge_fail>
ここにはあるけどね、ここに合わせたら 73 バイトになっちゃうもんな。 わからん。
ああー。
10b5472: 4c 8d 15 00 00 00 00 lea 0x0(%rip),%r10 10b5479: 49 81 fa 79 54 0b 01 cmp $0x10b5479,%r10 10b5480: 0f 85 0a 28 56 00 jne 1617c90 <hoge_fail> (snip) 10b5497: 4c 8d 15 00 00 00 00 lea 0x0(%rip),%r10 10b549e: 49 81 fa 9e 54 0b 01 cmp $0x10b549e,%r10 10b54a5: 0f 85 e5 27 56 00 jne 1617c90 <hoge_fail> 10b54ab: 42 83 3c 85 08 27 fb cmpl $0x2,0x1fb2708(,%r8,4) 10b54b2: 01 02 10b54b4: 4c 8b 64 24 30 mov 0x30(%rsp),%r12 10b54b9: 4a 8b bc c6 08 01 00 mov 0x108(%rsi,%r8,8),%rdi 10b54c0: 00
発見した。10b5497 を実行したことで %r10 には 0x10b549e が入る。 もちろん 10b54a5 ではジャンプせず実行が続く。 その後 cmpl を実行し、mov で %r12 に値をロードしたところで、64 バイトズレ問題が起きて、10b54b9 の命令を実行せず 10b5479 の命令を実行すれば、%r10 は変更されることなく、cmp での値は当然一致せず、10b5480 の命令のところでジャンプしてしまう。 これで 64 バイトズレで説明が付く。 確認のため %r12 と %rdi の内容を見る。
(gdb) x/x 0x30+$rsp 0x7ffd64fd3e50: 0x0000000003c815c0 (gdb) p/x $r12 $7 = 0x3c815c0 (gdb) x/x 0x108+$rsi+$r8*8 0x1f3d6a8 <default_target_ira_int+264>: 0x0000000003b74740 (gdb) p/x $rdi $8 = 0x0
矛盾無し。 後は segfault の謎だけ、この cmp hack でズレたまま実行される事象をすべてつぶしたかったが、そううまくはいかないもんだねというところである。 ま、それも、残されたバックトレースが若干変なのはアレだが (なぜか同じアドレスで違うファイル名・関数名が出ている部分が多々ある)、ひとつはシグナルハンドラーの直前のアドレスが命令の途中になっていて、その 64 バイト手前だといい感じに命令の区切りが合うのでそれかなという感じはする。
後は UEFI ファームウェアのアップデートや Linux カーネルのアップデートなど、やってみるべきことはある。 どうもうちではやっぱり 64 バイトズレしか起きていない感じなので、まずは今のファームウェア 0514 03/30/2017 にそろそろおさらばするべきか。 まぁ、あるいは再現プログラムが作れればいいなとは思っているんだけど、それはなかなか難しそうな気が。
プラスの電池かえて順調に「モンスターボールがありません」を連発したw プラスではポケストップよりポケモン発見が優先されてしまう仕組み上、いつまで経ってもボールが増えない悪循環に陥る。
ま、それはともかく、最近接続エラーが増えていたのは電池切れのせいだったのかな、と思ったら、やっぱりあんまり関係ないみたいだ。ZenFone Max との相性の問題なのかも知れない。 いくらボタンを押しても全く見つからないケースは、アプリ側を強制終了してやり直せばだいたい OK。 よくあるのはぶるっと振動して「接続しています」みたいな表示になってからしばらくして黙って切れる、あるいは、エラーが出てブルブルと振動して切れるパターン。 これはしつこくやり直すしか。
他にエラーと出た癖に結局つながっているパターンや、つながっている (画面のアイコンがそうなっていて、ボタンを押すと振動する) のに全くポケストップ等に反応しないパターンもある。 あと、使えていたのがしれっと切れていることがあるし、アプリ側のプラス関連表示だけが固まってしまって、切ろうにも切れず、プラスが事実上使えなくなるケースもある。
アプリ自体も操作によっては操作不能に陥ることがあるが、逆にプラス側は生きていることも多々ある。 しかし、アプリ側が操作不能の場合、プラスはポケモン発見優先の関係で、ポケストップに手を出せなくなってしまうので様子を見てアプリの再起動である。
あと、つながっているのを切ろうとしてアイコンを押すと「探しています」表示になることもある。 これは通知から停止すれば正常に停止できる。 見た目上は普通に切れてもボタンを押すと振動するパターンもあり、そのような場合は、通知も消えていて、アプリを戻るキーで終了しても、プラスのボタンを押すと引き続き振動する状態となる。 あるいは再接続しようとしてもプラス側は接続された状態のままなので再接続できない。 そういう時はいったん Bluetooth をオフにしてからオンにすると再接続できるようになる。 アプリ終了後に切れていない場合アプリの強制終了で切ることができる。(つまりアプリの一部が生き残っているということ...)
九州北部は豪雨被害がひどいらしくって、まだ行方不明者もいるらしいし大変そう。
鹿児島市で震度 5 強とニュースが流れたのがきのう。 地震にある程度慣れてしまった自分でも、震度 5 強は経験したことがないので少し心配ではある。 でも、たぶん、ちょっと物が落ちたり壊れたりはあるかも知れないが、大けがをするほどではないかな? 実際、あまり地震被害のニュースは出ていない気がする。1997 年に川内にいた人は震度 5 強や 6 弱を経験しているだろうけど、あの時鹿児島市は震度 5 弱があったかなー、震度 4 までだったかな、そんな感じだった。
そうそう、川内原発は当然通常運転だ。 何しろ 1997 年のすぐそばで震度 6 弱でも通常運転継続していたんだから、数十キロも離れた鹿児島市で震度 5 強程度では止まるわけがない。
Ryzen の件で as のマクロでへんてこなことをやったが、他にもいろいろできるんだなこれ。.if の式に . (現在のアドレス、MASM の $ みたいなもの) を含む式を書くこともできて、それでこの label からここまで何バイトあったらこれを入れる、みたいなのも表現できるみたい。 あと、知らなかったけど .align に最大バイト数なんて指定があるのね。 アラインメント調整のために必要な領域が最大バイト数を超えるようならアラインメントを合わせないという機能。 古いバージョンにはなかったのかな?
今年の 7 月はやたら暑い気がする。 今朝も朝 8 時台に窓を開けてみたら外がすでにむわーっとすごい温度になっていた。 アメダスの記録をたどると 2011 年が似たような暑さの感じだったっぽい。 ただし 7 月後半は下がっていて、そういえばあの年は、震災の後、電気使用量がやばいんじゃないかと言っていたのが気温が落ち着いて何とかなったんだっけ。 なお、エアコンは相変わらず冷房 30 度設定で夜から朝まで付けっぱなし。 エアコンの風が通る側の温度計は 27 度前後、ベッドあたりの温度計は 28 度前後を指している。
JR 東日本の指定席券売機で回数券を購入し、不要な表紙を駅員の目で券売機の前に放置するだけの簡単な作業。(何も言われなかったw)
GNU as で 1〜数個前のマクロで定義した label を参照する術を考えていたが、連番を振ろうと思ったら、うまいアイディアが浮かばず。 例のマクロの中でマクロを定義するやつなので、それに引数を与えて数字を入れて +1 していけばいいかなと思ったら、+1 してもそれがそのまま計算されずに展開されてしまうため label の名前には入れられない。 数字じゃなくてアルファベットを 1 文字ずつ増やしていくならできるが、そんなことするくらいなら \@ を使って定義して、数個前までの分を引数にずらずらと並べてしまうのが簡単かなと。 見苦しいがマクロといったらたいていそんなものだろう。
東京港フェリーターミナル、なんか見覚えがあるなーと思えば一度ここから新門司まで往復したことがあるんだった。 新門司行きの写真がないが東京行きに乗る前のフェリーの写真はある。 そういえばやたら閑散としたターミナルだったような気はするが、まさか大洗から北海道に行くフェリーがもともとはここから出ていたとはね。 なおフェリーは新型になったみたいなので、また乗ってみたい気もするが、とにかく時間が掛かるんだよなこれ。 四国観光あるいはツーリングでもするんなら有りかな。 でも新門司行きの徳島着が 14 時台で、東京行きの徳島発が 11 時台か、なかなか...
Label の引き算で命令のバイト数を決定できるかと思ったが、ジャンプ命令が挟まるとジャンプ先によってバイト数が変化してしまうため、定数にはならない。 そうすると .if の条件判定には使えないようだ。 うーん。 でも .space は使えるのか...
そんなわけで、新たな実験コードはこんな感じ (途中行が長すぎるので折り返してある):
.macro defhoge2 a,b,c,i
.macro \i o:vararg
hoge \a,\b,\c,\i,\o
.endm
.endm
.macro undefhoge2 i
.purgem \i
.endm
.macro defhoge a,b,c
defhoge2 \a,\b,\c,cmpb
defhoge2 \a,\b,\c,cmpw
defhoge2 \a,\b,\c,cmpl
defhoge2 \a,\b,\c,cmpq
.endm
.macro undefhoge
undefhoge2 cmpb
undefhoge2 cmpw
undefhoge2 cmpl
undefhoge2 cmpq
.endm
.macro alignhoge a,b,c
.space (.-\a==64)*0-(.-\a==63)*1-(.-\a==62)*2-(.-\a==61)*3-(.-\a==60)*4-
(.-\a==59)*5-(.-\a==58)*6-(.-\a==57)*7-(.-\a==56)*8-(.-\a==55)*9-(.-\a==54)*10-(
.-\a==53)*11-(.-\a==52)*12-(.-\a==51)*13-(.-\a==50)*14-(.-\a==49)*15,0x90
.space (.-\b==64)*0-(.-\b==63)*1-(.-\b==62)*2-(.-\b==61)*3-(.-\b==60)*4-
(.-\b==59)*5-(.-\b==58)*6-(.-\b==57)*7-(.-\b==56)*8-(.-\b==55)*9-(.-\b==54)*10-(
.-\b==53)*11-(.-\b==52)*12-(.-\b==51)*13-(.-\b==50)*14-(.-\b==49)*15,0x90
.space (.-\c==64)*0-(.-\c==63)*1-(.-\c==62)*2-(.-\c==61)*3-(.-\c==60)*4-
(.-\c==59)*5-(.-\c==58)*6-(.-\c==57)*7-(.-\c==56)*8-(.-\c==55)*9-(.-\c==54)*10-(
.-\c==53)*11-(.-\c==52)*12-(.-\c==51)*13-(.-\c==50)*14-(.-\c==49)*15,0x90
.endm
.macro hoge a,b,c,i,o:vararg
undefhoge
alignhoge \a,\b,\c
.L_hoge_\@ :
lea (%rip),%r10
cmp $.,%r10
jne hoge_fail
\i \o
defhoge .L_hoge_\@,\a,\b
.endm
defhoge hoge_fail,hoge_fail,hoge_fail
.text
.rept 512
int3
.endr
hoge_fail:
.rept 512
int3
.endr
だいぶ見苦しいが、大小比較を使うとどうもうまくいかなかったので == にしてみた。cmp の位置にテストコードを挿入する時に、15 バイト以内の nop 挿入で前のコードから 64 バイトの位置に合わせられるなら nop を入れてしまおうという代物である。 これで 64 バイトズレた位置に命令がある率が上がるため、問題発生頻度が上がるとおもしろいなと思っているが、果たして。
頻度が上がるようなら、次のステップとしてファームウェアアップデートというのも考えている。 これは後戻りができなさそうな気がするので、今のうちに問題の起きやすい環境を用意しておきたい。 あ、でも、その前に ASLR をオフにしても頻発する状態に持ち込むのが先かな?
ヤマト運輸の宅急便、本当に平日の再配達による自宅での受け取りが厳しくなってしまった。 主に以下の 2 点:
今までどちらも 19 時のところが 20 時だったため、普通に帰宅しても受け取りが可能だったが、19 時から家にいろと言われると無理だ。 これだったら営業所受け取りにして朝取りに行ったほうが簡単だ。 なお、つい先日受け取ったゆうパックは、今のところ 20 時〜21 時の再配達指定が可能だし、ドライバー携帯電話も 20 時まで OK だったので、ますますヤマト運輸がいまいちに見えてしまう。 営業所も 21 時に閉まっちゃうしな、って、それは近くの郵便局もゆうゆう窓口が無くなってしまって残念な感じになっている。
自宅での受け取りを諦めるなら、PUDO ステーションという共同宅配ボックスが一部の最近のセブンイレブンにはあるようで、そこに配達してもらう手はあるらしい。 時代は変わってきている。 また、コンビニ受け取りというのもあるらしい。 いずれにしてもヤマト運輸の会員登録が必要? だかなんだかで、めんどくさそう。 通販だったら最初から営業所止めの指定もできないことは無いのかな? この 6 月・7 月によく受け取るのはだいたい、配達方法の指定もできない & 宛先にこちらの電話番号すら入っていない株主優待の荷物...
アドレス比較のテストコードが 64 バイト手前付近にあればそこに合わせるみたいなやつで、頻度をすごく高めることには成功した。
-rw-r--r-- 1 root root 142835712 Jul 14 23:10 dbg-1500041451.4/core -rw-r--r-- 1 root root 53772288 Jul 14 23:14 dbg-1500041693.7/core -rw-r--r-- 1 root root 48943104 Jul 14 23:18 dbg-1500041939.10/core -rw-r--r-- 1 root root 58232832 Jul 14 23:20 dbg-1500042001.11/core -rw-r--r-- 1 root root 0 Jul 14 23:23 dbg-1500042226.14/core -rw-r--r-- 1 root root 36225024 Jul 14 23:28 dbg-1500042502.18/core -rw-r--r-- 1 root root 53669888 Jul 14 23:30 dbg-1500042656.20/core -rw-r--r-- 1 root root 31170560 Jul 14 23:36 dbg-1500043010.25/core -rw-r--r-- 1 root root 64176128 Jul 14 23:44 dbg-1500043453.31/core -rw-r--r-- 1 root root 0 Jul 14 23:50 dbg-1500043853.36/core -rw-r--r-- 1 root root 19714048 Jul 15 00:08 dbg-1500044925.49/core -rw-r--r-- 1 root root 33472512 Jul 15 00:15 dbg-1500045330.54/core -rw-r--r-- 1 root root 0 Jul 15 00:19 dbg-1500045574.57/core -rw-r--r-- 1 root root 22044672 Jul 15 00:20 dbg-1500045634.58/core -rw-r--r-- 1 root root 21573632 Jul 15 00:23 dbg-1500045796.60/core -rw-r--r-- 1 root root 28372992 Jul 15 00:33 dbg-1500046438.68/core -rw-r--r-- 1 root root 32063488 Jul 15 00:38 dbg-1500046682.71/core -rw-r--r-- 1 root root 47169536 Jul 15 00:47 dbg-1500047241.78/core
よしこれなら、と思って、sysctl kernel.randomize_va_space=0 で ASLR をオフにしてみたら、そのまま朝まで 6 時間以上も一切クラッシュ無し。 うーん、そうなのか... ASLR がどう影響しているというのか... そこがわからない...
スポーツカート耐久レース。 御殿場。 ハイスピードコース。2.5 時間耐久ナイトレース。2 人チームから参加。
スタート車両が予想外に速いことが練習走行で発覚したため、最初のスティントを長くとり、2 人チームの利点を生かし、75 分も走ってもらった。60 代なんですけどね... トラブルは特に無かったが、最初に長いスティントを持ってきたため、自分のスティントで一時トップを走行していたものの、体重の重さと腕の問題でラップタイムは悪いという、何とも珍しい (?) パターン。 スリップストリームが使えた周回は少しマシだったけどなぁ... 順位は 8 位、全部で何台いたんだっけか。
行きは高速、三連休初日故の大渋滞。 渋滞中に事故情報が増えるし、相模湖まで一時間を超え、談合坂 SA はもちろん藤野 PA にまで行列ができていて、なんだこりゃ状態。 でも談合坂を過ぎた後は比較的スムーズだったな。
帰りは富士スピードウェイの前を通って、峠道を抜けた。 峠道の急勾配は真っ暗でいつ動物が飛び出してくるかもわからないところ、途中でいきなり濃霧になり、視界が 10m ほどで心細さが半端ない。 電脳コイルだったらイリーガルに鍵穴が出てきそうな不気味さである (笑)。 帰り方向なので下る側のほうが鹿が出てきそうで慎重に走ったが、こっち側は結構人や車がいた。 コンビニの案内を頼りに道志みち、そこから城山・野猿街道経由で帰宅、2 時間半。 深夜だから最後のほうはそこそこハイペースだったけど、このコースが速いかどうかは謎だな。 相模原 IC のほうに行くほうが速いと思うんだけど、橋本あたりの地図が頭に入っていないのが最大の問題だ。
給油した。131 円/l。 燃費計算 16.7km/l。 燃費表示 17.2km/l。
よく寝た日。
きのうの APG のレースでは合計 70 分近く乗った計算になる。 特にロングスティントで 50 分以上走った時があり、他の人に付いていくのはいろいろ勉強になった。 走り方が正直わからんコーナーというのがいくつかあり、それらで他の人と差が付くかどうか。 体重重い組は、タイヤのグリップは良くても、加速も減速も不利で、唯一有利な可能性があるのが高速コーナーだ。 それも、その後の加速が長ければ取り戻されてしまうから、本当に限られたところだけ。 実際差の付き方を見ているとそんな感じがあって、でもちょっとでもミスれば加速が悪いので一気に離されるし、バトルになってラインがズレると厳しい。 あとおもしろい発見は、勾配の関係でフッと前が一瞬浮いたような感じでハンドルが軽くなる高速コーナーがあるのだが、そこに入るラインを間違えるとかなりアンダーステアになる。 思わずアクセルを抜いちゃうくらい。 たぶん、前が浮く前に姿勢を作っておけばいいのだが、姿勢ができる前に浮いてしまうとアンダーステアなんだな。 こういうの、気づくのにも時間がかかるし、どう対処したらいいかその場ですぐに判断できないあたりが、自分の下手クソなところである。 本当なら、練習走行の間にすべて把握しておくべきところなのだ。
DAZN の今回の Formula One イギリス GP はカクカクしていて 25fps っぽかった。 なんだよ前回だけ特別だったんか? 25fps って昔の 24fps 映画と同じようにぱっと見でわかっちゃうんだよな。
DAZN アプリは KALOS2 ではエラーになって動かない。Nexus 10 でも試してみたら、動くことは動くが、動画再生にスペックが足りないらしく、ぎこちないフレーム落ちが続いた後に映像が止まって音だけになってしまう。
肝心の GP のほうは、途中のベッテル絡みの激しいバトルと、最後の数周のタイヤトラブルが見所だった。 ベッテルはピットストップでアンダーカットを成功させたのは良かったが、それで距離が長くなってしまった上ボッタスとのバトルもありタイヤが持たなかったようだ。 ライコネンはほとんど一人旅でタイヤに負担を掛けることは無かったと思うし、ピットインのタイミングも余裕があったはずなのに、タイヤのトラブルが出て 2 位から予定外ピットストップ、でも 3 位で、なんでかと思えば下にいたフェルスタッペンもタイヤが怪しかったのかフェラーリに合わせて最後にピットインしたんだな。 なんという幸運。
朝方ちょっと雨が降ったが、その後は天気がよさそうなので、ちょっとバイクを動かした。
GSR250S L5 東京〜東名川崎 100km/h 走行 - YouTube
遠出したら帰りの渋滞がやばいことは目に見えていたので、空いている範囲でと思って、単にこの動画を撮りに行っただけなのだが... エンジンの熱気がすごかった (笑) 以前グラストラッカーで同じところを走ったが、こうして動画で見比べると 100km/h 走行がずいぶん楽ちんなのがわかる。 グラストラッカーも、80km/h あたりまでなら十分速いのだが、その先の加速がとてもゆっくりだったし、とにかく振動がすごかった。 もちろん、さすがに単気筒と二気筒の違いは大きいし、エンジン自体がグラストラッカーは低い回転数での力強さが重視されていて、あまり上まで回す仕様では無かったためである。 東名のこの区間はちょっと登るところがあるのだが、確かそこはアクセル全開でやっとかっと 100km/h キープみたいな感じだった。 それに比べれば当然のことながら二気筒の GSR250S は楽勝である。 今回もあえて ETC を使わずに料金所から加速してみたのだが (アクセル全開にはしたが回転数はそんなに上まで回してはいない)、出口の看板よりも手前で悠々と 100km/h に到達してしまっている。
最近の GIXXER なんかは 150cc 単気筒だが意外と速いみたいだ。 最初からそういうのを買っていたら二気筒には変えなかったかも知れない... でも当時は無かったし、二気筒は振動の少なさも魅力なんだよな。 本当にスムーズ。
今にして思えば、中古で 15 万くらいで売られていたスズキ・イナズマ 400、アレにエンジンガードを付けてもらえばそれで多少こかしつつ乗っていたかもなとも思う。 イナズマ 400 がどのくらい速いかわからないけど、レンタルで CB400SF 乗った時にこれに乗ってたらスピード出し過ぎていつか死ぬなというようなことを思ったので、初めてでああいう速そうな四気筒というのはどうなっていたかわからないな。 ま、でも、グラストラッカーの、軽くて足つき良くて原付感覚でほいほいとなぜか高速まで走れる感じはあれはあれで良い経験だった。 ほんと、二輪は車体が軽ければ、多少操縦が下手でも何とかなるというのはある。
電圧が話題なので CPU と何とかの両方を上げてみたが、症状は今まで通り。 まぁ AGESA 古いしね。 正直なところ ASLR 絡みの影響を調べる方法を思いつかないんで、もうファームウェアアップデートしてしまおうかな。
整形外科の待合室で暇なので Gunpei をやっている。 やっぱりパズルモードが楽しい。 地味に難しくなっていくのだが、アクション要素がないのでじっくり考えて解けば良いわけで。 ステージ 32 あたりまでいった。
っていうか、待合室では携帯電話のご利用はご遠慮くださいとなっているので堂々とワンダースワンカラーを使っているわけなのだが、マジ電池持ちが良すぎ。 単三電池 1 本でこの電池持ちはこの手のゲーム機の中では驚異的でしょ...
引き続き整形外科には通っている。 薬は最近はノイロトロピンだけになっている。 頓服で痛み止めをもらっているが、これは 1 回 2 錠なんだけど、軽い痛みが続くような時は 1 錠でもいいから飲んでねとのこと。 例のアレだな、痛みが出ていると脳が反応してしまって悪循環に陥るやつだ。
痛みの症状としては妙で、やっぱり何となくはっきりはしないんだけど、横向いて寝ると何かやらかしやすい感じと、下向くのもやっぱりよくなさそうなのと、カートレースの時はちょっと変かなと思ったがまたしてもなぜかその後は調子が良いというやつ。 いや、まぁ、筋肉痛が出ている間はちょっと変だったけど。
ちょっと興味のあるチラシや、株式関係の書類や、時間がある時にシュレッダーに掛けるつもりの書類など、そういうのをとりあえず目に付くところ、例えば机の上に置く。 次々に増えるそれらをその上に積んでいく。 いつしかそれらはあふれ、あるいは、何かの拍子に崩してしまうなどして、床に散らばる。 早く何とかしないとと思っている間にも、どんどん増える。 そのうち、ゴミ箱やゴミ袋に入れ損ねたちょっとした紙くずなどが床の上で交ざる。 もちろん、埃は区別無く全体に積もる。 その結果、床の上には、古くなって役に立たなくなった書類、シュレッダーに掛けるつもりの書類、紙くずに埃まで、すべて混ざったゴミが堆積する。
みたいな感じ。 ここ数日、久しぶりに片づけをしている。 自分の行動を大きく矯正するのは難しいだろうが、注意すべきは「とりあえず」のところで、せめてそれを時系列に積む、いや、並べてあれば、古いほうから処分するのがだいぶたやすくなる。 特に株式関係の議決権の行使は、株主総会に出席するかその前日までに郵送する等の期限があるので、それまでは意味があるのだが期限を過ぎた瞬間ゴミである。 そういうのが散らかってしまうケースが多発しているので、時系列に並べておきたい。
なお、レシートが財布からあふれそうになっていた時期もあったが、最近はそういうのはあえて服のポケットに突っ込んで、早急に処理するように意識している。 さすがにポケットにあると 1 枚でも結構邪魔なので、このアイディアは思ったよりうまくいっている。
日経平均 (225) は 2 万円をいったり来たり。 手持ちの損益のプラス上位は何年か持っているミクシィと寿スピリッツで、見たこともないすげぇプラス額になっている。 なんでもっと買っておかなかったんだ、みたいな。 特にミクシィなんて分割前に取引単位分は持っておくべきだったよな。 あのときおそるおそる S 株で持っていたんだもんな。
その下に来るのがシャープ、これはまぁギャンブルに当たったみたいなものだが、台湾の会社に買われて本当に良かった。400 円くらいで安定してくれるならそれでいい。
それら以外は地味にプラスなやつと、派手にマイナスなやつがいろいろある。 最近はホンダがマイナス転落である。 一時期グリーの損が減っていたが、また増えてしまった... 損益順でコロプラが最下位にいるのもしばらく続いている。 郵政関連株もゆうちょ銀行以外はぼろぼろだ。 ネタで 20 株だけ買った東芝株はプラスだが、取引単位 1000 なのでプラスマイナスなどどうでもいい額だ。 たぶん 1000 株買っていたら下がっていたに違いない。
ってな感じでやっぱり損益 (買った時と現在の評価額の差分) を見てしまうのだけど、実際のところ減ってしまったものは仕方が無いわけだし、増えたものも減ってしまえば損していると言えるわけで、もっとちゃんと動きを見ておかないとな、と思っても、70 銘柄も持ってれば頭では把握しきれない。 日々の変動をデータ化しておかないとなぁ。 で、損益は何に役立つかと言えば、年末に節税目的で利益額に見合う損が出ているやつを損切りする時かな。
Powered by Tomsoft Diary System 1.7.4
Hideki EIRAKU