Orz日記 by Akio Morita

_ [FreeBSD]KDBに落ちる

最近、X稼働中に固まることが多いので、KDBに落ちてるのを疑って ddb_enable=YESを設定してみたが効果なし。 ダメモトでkdb.enter.defaultをkdb.enter.panicと 同じように仕込んだところリブートしてた…

残念ながら dumpは録れていない

状況からして、

• kdb.enter.*が発生している
• kbd.enter.panicでは無い
• kdb.enter.witnessでは無い
• dump deviceへのアクセスが滞る程度に致命的状況

ようです。

ddb hookを二分法で絞り込むべきところか?

strage回りを疑って、kdb.enter.camとkdb.enter.vfslockに だけ仕込みをしてみる

_ [雑記]RedMineのレポジトリ連動について

CVSレポジトリ連動を使うには、RedMineが動作するWeb Server側と CVSレポジトリ Server側の双方に 1.12系列の開発版cvsが必要 (rlsサブコマンドが発行されるため)

Subversionレポジトリ連動を使うときは、svnの動作環境の LC_TIMEを Cに設定しておかないと logの日付のパースに失敗する

_ [SAD]暗黙の積演算子

暗黙の積演算子で問題発生 次の入力でエラーになる

  {(.04900615163214845-9.822983116787175e-14 I),(-.03673869301236704-.038768017943886436 I),(.12177086853110757-.0010701917715088265
    I),(.11626198123227845+.12420170191229517 I),(-.3131902147075775+.1147222051951141 I),(.2852859413214444-.0480098408950545 I)}

おそらく、改行を跨いだ暗黙の積演算子を構文解析出来ていない orz

(が閉じていないので、改行があっても構文的にはコンテキストが つながっているはずなのに解析出来ていませんねぇ

実はこれ、SADのWrite[]関数が生成した出力なのですが...

読み込み前に、sedで加工かな

_ [FreeBSD]ddb scripts

先日の freezeの続き

kdb.enterイベントの種別は、sys/sys/kdb.hに定義されている KDB_WHT_UNSETを除くと名前がついてるイベントは以下のとおり(stable/9 rev.228485)

• panic /* panic() was called. */
• sysctl /* Sysctl entered debugger. */
• bootflags /* Boot flags were set. */
• witness /* Witness entered debugger. */
• vfslock /* VFS detected lock problem. */
• netgraph /* Netgraph entered debugger. */
• break /* Console or serial break. */
• watchdog /* Watchdog entered debugger. */
• cam /* CAM has entered debugger. */
• ndis /* NDIS entered debugger. */
• acpi /* ACPI entered debugger. */
• trapsig /* Sparc fault. */
• powerfail /* Powerfail NMI. */
• mac /* MAC Framework. */
• powerpc /* Unhandled powerpc intr. */
• unionfs /* Unionfs bug. */
• dtrace /* DTrace action entered debugger. */

kdb.enter.defaultに resetを仕込むと再起動するようなので、 kdbに突入していることは確実なので、標準でdump&resetになるpanic以外の どの イベントでkdbに突入したかを洗い出そうと調査中

kdb.enter.camとkdb.enter.vfslockに reset仕込んだ状態で freezeしたので、それ以外ぽぃ orz

amd64なシステムで発生しないはずのイベント

• trapsig(sys/sparc64/sparc64/trap.c)
• powerfail(sys/sparc64/pci/psycho.c)
• powerpc(sys/powerpc/powermac/pswitch.c)

kernelに組み込んでないので発生しないはずのイベント

• watchdog(sys/kern/kern_clock.c by SW_WATCHDOG)
• watchdog(sys/amd64/amd64/mp_watchdog.c by MP_WATCHDOG)
• ndis(sys/compat/ndis/subr_ntoskrnl.c)
• unionfs(sys/fs/unionfs/union_subr.c)
• dtrace(sys/cddl/contrib/opensolaris/uts/common/dtrace/dtrace.c)

明示的な呼び出しによるイベント

• bootflags(boot_ddb boot flagで制御される kernel起動時の ddb trap)
• sysctl(debug.kdb.enter sysctlで制御される sysctlの ddb trap)
• break(debug.kdb.break_to_debugger sysctlで制御される break trap)

したがって、panic以外の調査対象イベントは...

• witness /* Witness entered debugger. */
• vfslock /* VFS detected lock problem. */
• netgraph /* Netgraph entered debugger. */
• cam /* CAM has entered debugger. */
• acpi /* ACPI entered debugger. */
• mac /* MAC Framework. */
• unknown /* KDB_WHY_UNSET */

に絞られる

この仮設の妥当性を証明するのが第一段階かな？

まあ、なんで crash dumpが取れてないかも大問題なんだけどねぇ