タグ

dumpに関するmteramotoのブックマーク (3)

  • netdumpでクラッシュダンプ取得の補足 : しげふみメモ

    2007年08月23日01:36 カテゴリLinux netdumpでクラッシュダンプ取得の補足 前回の記事で netdumpでクラッシュダンプ取得するところまでできましたが、ちょっと補足。 ダンプ解析 取得したカーネルのダンプファイルの解析には kernel-debuginfo パッケージが必要。 crashコマンドを使うようですが、まだ試したことはありません。 このあたりはまた今度やってみます。 crashコマンドの使い方については、以下の記事にある資料が参考になります。 路地裏 ソース解読研究所: 岡山カーネル勉強会 メール設定 dump開始時と終了時にメールするようにしました。 netdump-serverの /usr/share/doc/netdump-server-x.x.x/example_scripts 以下から netdump-crash と netdump-reboot

    netdumpでクラッシュダンプ取得の補足 : しげふみメモ
  • 路地裏 ソース解読研究所: dump解析(1) 二の巻

    さて、前回、buffer_headを特定したものの、なぜこのbuffer_headがロックされたままとなっているのか分かりません。 さらに調べを進めていきたいと思います。 __wait_on_buffer()でなぜ待ちつづけるかというと、__wait_on_buffer()内のsync_buffer()でバッファのロックが解除されないからです。 では、sync_buffer()を調べてみましょう。 ----- fs/buffer.c static void sync_buffer(struct buffer_head *bh) {         struct block_device *bd; smp_mb();         bd = bh->b_bdev;         if (bd)                 blk_run_address_space(bd->bd_in

  • 路地裏 ソース解読研究所: dump解析(1) 一の巻

    エントリはダンプ解析について知ってもらうために多少編集している部分がありますが、ご了承ください。 ML40でのダンプ解析には、 vmcore(ダンプ体) vmlinux(kernel-debuginfoに入っている) System.map(kernelパッケージに入っている) が必要です。 ダンプの解析開始は、通常こんな感じで始まります。 ----- # cd /var/crash/10.1.0.111-xxxx/ # crash /boot/System.map-2.6.9-34.21AXsmp /usr/lib/debug/lib/modules/2.6.9-34.21AXsmp/modules/vmlinux vmcore ---- まず何をするかというと、どこでpanicしたのか確認するために、btです。 ---- crash> bt PID: 0      TASK: c03

  • 1