log.utashiro.com

今度は kernel_task だよ (4)

リンク: log.utashiro.com: 今度は kernel_task だよ (3).

アップルが「仕様」というのは kernel_task のロードを増やすというのが本来狙った動作だといことでしょう（バグなんかでなく）。想像ですが、kernel_task があのようになるのは、通常のプロセスの動作を減らしてCPUの発熱を減らす手段なんだと思います。 その根拠ですが、あまりシステム熱くないときに負荷の高いプロセス（たとえば、シェルスクリプトで while true ループ）を二つも動かしてやると、瞬間的に CPU の温度は 80 度以上になります。ところが、しばらくして kernel_task が 50% も動くようになると CPU 温度は 65度くらいに下がるんですね。これは、kernel_task が実はダミータスクで、ハードウェア的にはスリープしている証左ではないかと。

設計段階からの仕様で、それが日常的に発生することを想定しているのなら「仕様」と言ってくれてもいいけど、他に言いようがあるよねえ。「苦肉の策ではありますが想定された動作です」くらいにしとけばいいのに。

実は、挙動が微妙に僕のマシンと違います。CPU だけ使うアプリを走らせればもちろん CPU の利用率は 100% (200%) になるのですが、それだけでは kernel_task は出しゃばってきません。CPU の温度も一時期90度近くまで上がり、ヒートシンクやパワーサプライも60度を超えますが、徐々に落ち着いて70度ちょいくらいで安定します。これはべったりした机の上に置いて、吹き出し口も塞ぎがちにした、あまりいいとは言えない条件で実験してみた結果です。

あ、でも続けたら再現することもできた。何かのきっかけでスイッチが入っちゃうんだなあ。

これに本当に必要な kernel_task の処理が重なると、利用率が 160% を超えるようになってしまうのでしょう。

あとやっぱり USB デバイスとの関係はあるような気がしています。でも、間接的な要因は何であれ、直接的には熱が上がりすぎることが kernel_task の暴走 (事情がわかってみると「暴走」は正しくないような気もするが) の原因になっているのは間違いなさそうです。

今度は kernel_task だよ (3)

森山さんからのコメント：

うちの MBA の場合 kernel_task が出てくるのもシングルコア化問題と同じく単に温度の問題のようです。
シェルスクリプトで無限ループ回すプロセスを二つばかり上げて、そこで YouTube などの動画を流せばあっという間に kernel_task が 80％くらいになっちゃいますね。扇風機で冷やすとすぐに直りますけど。
今使っているのは二台目の MBA です。一台目のも同じ症状でしたが、アップルに聞いても修理法は確立していないとのことなので、初期不良ということで交換してもらいました。二台目も同じ症状ですので、結局、熱設計があまり良くないということなのではないかと思っています。

そうだよなあ、そうですよねー。やっぱりそれを疑わなくちゃいけないよねえ。でもまさかそんなことはと思ってたんだけどなあ…
今ちょっと不自由な環境にいるもんでそれを試せずにいたのですが、うちからクーラーパッド を持って来てもらって半日程実験していました。結果としては、森山さんの仰る通りオーバーヒートを防げば kernel_task の暴走もなくなりました。前の記事で、こんなことになんで気づかないのかと書いたのがお恥ずかしい。

実際には、ファンを回さなくても、クーラーパッドに乗せるだけで、かなり状況は改善します。

kernel_task の問題についてアップルのテクニカルサポートから回答がありました。「発熱すると kernel_task が CPU タイムを食いつぶすのは『仕様』」。だそうです。 え～！？ 発熱がひどくなるとダミータスク(kernel_task)をスケジュールして、実際には CPU を休ませておくことによって擬似的にパワーセーブしているんじゃないかと思っていましたが、それにしても「仕様」と言い切られるとは。

それは、ひどいなあ…

どこかで「kernel_task って殺しちゃいけませんか?」と訊いてる人がいて微笑ましく見ていたんだが、僕も殺したくなってきたぞ。

kill -9 0

今度は kernel_task だよ (2)

kernel_task 問題はまだ解決していないが、どうやらやはり USB の関係があるような気はしてきた。事情があって、現在常時イーモバイルを使った接続なので、ネットにつながっているときには常に USB が使われている状況なのだ。

USB でバイスとマルチメディア関連の処理が重なると特にまずいような気がする。だから、ネットで YouTube の動画を再生なんてのが最悪の組み合わせで、必ずはまる。この場合、kernel_task が CPU を 160% 以上使う。

この状態でモデムの接続を切っても状態は変わらない。ただし、接続を切って一度再生を中止すると kernel_task の暴走は止まる (こともある)。そして、もう一度再生を開始しても暴走は発生しないのだ。

なんか、割り込み処理に問題があるような気がするなあ。

片肺直ったと思ったら今度は kernel_task だよ

MacBook Air の片肺問題は、shigeya さんの言う通り、一応 8/22 に出たアップデートで対応されたようだ。このアップデートを当てて以来、多分一度も目にしていない。

MacBook Air のシングルコア化については、いろいろなところで話題になっているが、多くのところで原因がよくわからないという結論になっているのが不思議である。直接的な原因は明らかに熱だからだ。中には冷蔵庫に入れて熱が原因だと結論づけているところもあるが、そんなことしなくてももっと簡単にわかるだろうに。とにかく、だから、単純に過熱しないようにしてやれば片肺化は防ぐことができる。

僕は SANWA SUPPLY の TK-CLN7USV ノート用クーラーパッド シルバー TK-CLN7USV というのを導入したが、これを使っていれば問題はなかった。ちなみに、まつもとさんと違ってメーカーが勝手に送って来てくれたりはしないので、自分で買った。

さて、片肺問題は解決したかに見えるが、どうもアップデート以来 kernel_task がすぐに CPU を 130-140% も食いつぶすという状態になってしまった。以前から kernel_task が暴走気味になることはあって、それが片肺化の原因だと取り沙汰されてもいたのだが、140% というのはいかにも異常である。

しかも、きっかけがわからない。一説によれば USB デバイスが原因だとかも言われているが、そうとも限らないような気がする (あ、でも今試しにイーモバイルのモデムを抜いてみたら下がったなあ…)。まったくの印象だが、何らかのリソースが競合していて、複数の事象の複合的な組み合わせによって発生するような気がするのだ。

しかし、これははっきり言って片肺よりも質が悪い。片肺の直接的な原因はわかっているので、とにかく冷やしてさえやれば解決するし、少なくとも一度スリープしてファンが止まるまで待てば回復するのだ。kernel_task の暴走は原因がわからないし、解消したかに見えてもすぐに再発してしまう。前途多難なのだ。

久々の lost+found

MacOS X で、Unix 的ホームディレクトリは UFS のディスクイメージを使っているのだが、さっき rsync でバックアップを取ったら lost+found が出来ていた。

フリーズした後は起動時に fsck するので時間がかかるのだが、今まで致命的な壊れ方をしたことはなかった。まとまって lost+found に移されたのは今回が初めてだ。

しかし、ファイルの内容が全然違うファイルのものになってしまうことがちょくちょくあって困る。どうも MacOS X の Unix 的ファイル操作 API には問題があるのだ。HFS ならいいかというと、HFS を Unix API で操作すると、さらに悪いことが起きるような気がしている。どうしたものか…

フローティングCPUウィンドウが出ない

最近、なぜかアクティビティモニタのフローティングCPUウィンドウが表示されなくなってしまっていた。ウィンドウメニューで非表示にして再度表示に設定すれば出てくるかと思ったら、なぜか非表示の状態に変更することができない。仕方なく「CPU使用率」ウィンドウを表示していたが、これはやっぱり邪魔だ。なんとかしようと思い、

~/Library/Preferences/com.apple.ActivityMonitor.plist

を探し出して消したところ、めでたく元に戻った。

以前のファイルを Property List Editor で見てみると、FloatingWindowFrame の最初の値がマイナスになっている。画面からはみ出した場所に表示しているつもりだったのか。プレゼンで外部モニタを接続したせいかもしれない。

StopFold

リンク: StopFold

最近、一部のメール処理に Mail.app を使っているが、行を途中で勝手に折り返すのが不満だった。しかもアスキー文字が入ると改行位置が滅茶苦茶になってしまう。format=flowed の問題はずっと以前から指摘されているはずなのに、Apple はどうして対応しようとしないのか。

致命的な問題ではないので放置していたが、思いついて探してみると StopFold というプラグインが見つかった。試しに入れてみたら快調に動いているようだ。

フリーソフトなので、お礼に作者さんの著書を注文した。Mac OS 上で LaTeX を使いたかったが、インストール方法を調べるのが面倒で放置していたので丁度よかった。

emacs でメールを書く時は、auto-fill-mode と fill-paragraph を使っているので、本当はそれと同じことができるといいのだけど。

X11 が表に出てこない

Tiger にしたら、コマンド-タブで X11 を選んでも、ウィンドウが前に出てこなくなった。とっても使いにくい。そこでコマンド-タブで再度 X11 を選ぶと出てくる。何かの処理の順番を間違っているっぽい。どうしたら直るんだ?

---

(2005.11.02)
10.4.3 にアップグレードしたらなおった。
http://docs.info.apple.com/article.html?artnum=301984-ja

Dock から、または Application Switcher を使って X11 アプリケーションを選択した後に、X11 ウインドウがバックグラウンドに残らなくなりました。

そうか、コマンド-タブは Application Switcher というのか。
Dock でも同じだということには気がついていなかった。なぜなら事情によりシェルスクリプトからしか起動できなかったから。

Tiger でファイルが消える?

リンク: Tiger

ファイルがランダムに消えるという話だけど、本当だろうか?
ディスク障害じゃないんでしょうか。

とりあえず、怖くて仕事用 PowerBook にはまだインストールできない…

しかし、だいたい HFS は以前から信用できなかったのだ。短期間だけ HFS をホームに使用していた時期があるが、ファイルが存在するのに ls で表示されないとか、大文字小文字が違うだけの２つのファイルができてしまって、アクセスに往生するとかの現象があったので、Unix的に使うホームディレクトリとしては絶対に使うべきではなかった。

以前はパーティションを切って HFS と UFS を使い分けていたが、インストールし直すのが面倒になって、最近は UFS のディスクイメージを Unix 的ホームとして使っている。暗号化して。これは快適。クラッシュしても再起動が早い。マウントする時に fsck が走るけど。

ただし、~/Library とかは HFS でないとちゃんと動かないこともある。だから MacOS のホームは /User の下に置いて、UFS のホームを HOME に設定してから X を起動する。これであまり不自由していない。

で、最初の話題に戻ると、この dmg ファイルが消えるとダメージ大きすぎ。dmg が damage の略に見えてきた…

lzh が展開できないよ

受け取った lzh アーカイブを StaffIt Expander で展開したがどうも内容がおかしい。8.0.2 にしてもやはり変わらない。
みかちゃんフォントをMacOS Xで使おうには、『Stuffit Expander6.5はLZHファイルの解凍はちっともうまくできません』と書いてある。
LHA Expander というのもあるらしいが、これは Classic 環境でしか動かないらしい。

仕方がないので、SourceForge.jp: Project Info - LHa for UNIXからソースを持ってきてコンパイルしたらあっさり展開できました。