Linuxカーネルパニックの原因の特定
私はUbuntu 12.04派生（AMD64）を実行していますが、最近非常に奇妙な問題が発生しています。突然、一見すると、Xはしばらく（1〜3分？）完全にフリーズし、システムが再起動します。このシステムはオーバークロックされていますが、Windowsで確認されているように非常に安定しています。そのため、カーネルパニックが発生している、またはモジュールの1つに問題があると思います。 LinuxでもLINPACKを実行できますが、CPUにとんでもない負荷をかけてもクラッシュしません。マシンがアイドル状態でも、クラッシュはランダムなタイミングで発生するようです。
システムをクラッシュさせる原因をデバッグするにはどうすればよいですか？
プロプライエタリのNVIDIAドライバーである可能性があるという直感で、私はドライバーの安定したバージョンであるバージョン304までずっと戻しましたが、それでもクラッシュが発生します。
クラッシュ後のデバッグ手順を教えてもらえますか？私はサムドライブで起動して、クラッシュ後の構成ファイルをすべて投稿できれば幸いです。それがどうなるかわかりません。システムをクラッシュさせている原因を調べるにはどうすればよいですか？
ここに、通常の原因であるログの束があります。
。xsession-errors： http://Pastebin.com/EEDtVkVm
/ var/log/Xorg.0.log： http://Pastebin.com/ftsG5VAn
/ var/log/kern.log： http://Pastebin.com/Hsy7jcHZ
/ var/log/syslog： http://Pastebin.com/9Fkp3FMz
クラッシュの記録もまったく見当たらないようです。
クラッシュのトリガーはそれほど単純ではなく、GPUが一度に複数のものを描画しようとしたときに発生するようです。 YouTubeビデオを全画面で表示して、しばらく繰り返すか、大量のGIFをスクロールすると、Skypeの通知がポップアップ表示され、クラッシュすることがあります。これで頭をすっかり引っ掻いた。
CPUは4.8GHzにオーバークロックされていますが、完全に安定しており、昨日の巨大なLINPACK実行とPrime95の9時間を1回のクラッシュなしで乗り切りました。
更新
kdump、crash、linux-crashdump、およびカーネルバージョン3.2.0-35のカーネルデバッグシンボルをインストールしました。クラッシュしたカーネルファイルでapport-unpackを実行し、crashクラッシュダンプでVmCoreを実行すると、次のようになります。
KERNEL: /usr/lib/debug/boot/vmlinux-3.2.0-35-generic
DUMPFILE: Downloads/crash/VmCore
CPUS: 8
DATE: Thu Jan 10 16:05:55 2013
UPTIME: 00:26:04
LOAD AVERAGE: 2.20, 0.84, 0.49
TASKS: 614
NODENAME: mightymoose
RELEASE: 3.2.0-35-generic
VERSION: #55-Ubuntu SMP Wed Dec 5 17:42:16 UTC 2012
MACHINE: x86_64 (3499 Mhz)
MEMORY: 8 GB
PANIC: "[ 1561.519960] Kernel panic - not syncing: Fatal Machine check"
PID: 0
COMMAND: "swapper/5"
TASK: ffff880211251700 (1 of 8) [THREAD_INFO: ffff880211260000]
CPU: 5
STATE: TASK_RUNNING (PANIC)
logユーティリティからcrashを実行すると、ログの下部に次のように表示されます。
[ 1561.519943] [Hardware Error]: CPU 4: Machine Check Exception: 5 Bank 3: be00000000800400
[ 1561.519946] [Hardware Error]: RIP !INEXACT! 33:<00007fe99ae93e54>
[ 1561.519948] [Hardware Error]: TSC 539b174dead ADDR 3fe98d264ebd MISC 1
[ 1561.519950] [Hardware Error]: PROCESSOR 0:206a7 TIME 1357862746 SOCKET 0 APIC 1 microcode 28
[ 1561.519951] [Hardware Error]: Run the above through 'mcelog --ascii'
[ 1561.519953] [Hardware Error]: CPU 0: Machine Check Exception: 4 Bank 3: be00000000800400
[ 1561.519955] [Hardware Error]: TSC 539b174de9d ADDR 3fe98d264ebd MISC 1
[ 1561.519957] [Hardware Error]: PROCESSOR 0:206a7 TIME 1357862746 SOCKET 0 APIC 0 microcode 28
[ 1561.519958] [Hardware Error]: Run the above through 'mcelog --ascii'
[ 1561.519959] [Hardware Error]: Machine check: Processor context corrupt
[ 1561.519960] Kernel panic - not syncing: Fatal Machine check
[ 1561.519962] Pid: 0, comm: swapper/5 Tainted: P M C O 3.2.0-35-generic #55-Ubuntu
[ 1561.519963] Call Trace:
[ 1561.519964] <#MC> [<ffffffff81644340>] panic+0x91/0x1a4
[ 1561.519971] [<ffffffff8102abeb>] mce_panic.part.14+0x18b/0x1c0
[ 1561.519973] [<ffffffff8102ac80>] mce_panic+0x60/0xb0
[ 1561.519975] [<ffffffff8102aec4>] mce_reign+0x1f4/0x200
[ 1561.519977] [<ffffffff8102b175>] mce_end+0xf5/0x100
[ 1561.519979] [<ffffffff8102b92c>] do_machine_check+0x3fc/0x600
[ 1561.519982] [<ffffffff8136d48f>] ? intel_idle+0xbf/0x150
[ 1561.519984] [<ffffffff8165d78c>] machine_check+0x1c/0x30
[ 1561.519986] [<ffffffff8136d48f>] ? intel_idle+0xbf/0x150
[ 1561.519987] <<EOE>> [<ffffffff81509697>] ? menu_select+0xe7/0x2c0
[ 1561.519991] [<ffffffff815082d1>] cpuidle_idle_call+0xc1/0x280
[ 1561.519994] [<ffffffff8101322a>] cpu_idle+0xca/0x120
[ 1561.519996] [<ffffffff8163aa9a>] start_secondary+0xd9/0xdb
btはバックトレースを出力します：
PID: 0 TASK: ffff880211251700 CPU: 5 COMMAND: "swapper/5"
#0 [ffff88021ed4aba0] machine_kexec at ffffffff8103947a
#1 [ffff88021ed4ac10] crash_kexec at ffffffff810b52c8
#2 [ffff88021ed4ace0] panic at ffffffff81644347
#3 [ffff88021ed4ad60] mce_panic.part.14 at ffffffff8102abeb
#4 [ffff88021ed4adb0] mce_panic at ffffffff8102ac80
#5 [ffff88021ed4ade0] mce_reign at ffffffff8102aec4
#6 [ffff88021ed4ae40] mce_end at ffffffff8102b175
#7 [ffff88021ed4ae70] do_machine_check at ffffffff8102b92c
#8 [ffff88021ed4af50] machine_check at ffffffff8165d78c
[exception RIP: intel_idle+191]
RIP: ffffffff8136d48f RSP: ffff880211261e38 RFLAGS: 00000046
RAX: 0000000000000020 RBX: 0000000000000008 RCX: 0000000000000001
RDX: 0000000000000000 RSI: ffff880211261fd8 RDI: ffffffff81c12f00
RBP: ffff880211261e98 R8: 00000000fffffffc R9: 0000000000000f9f
R10: 0000000000001e95 R11: 0000000000000000 R12: 0000000000000003
R13: ffff88021ed5ac70 R14: 0000000000000020 R15: 12d818fb42cfe42b
ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018
--- <MCE exception stack> ---
#9 [ffff880211261e38] intel_idle at ffffffff8136d48f
#10 [ffff880211261ea0] cpuidle_idle_call at ffffffff815082d1
#11 [ffff880211261f00] cpu_idle at ffffffff8101322a
何か案は？
開始するには2つの提案があります。
最初はあなたが気に入らないでしょう。あなたのオーバークロックシステムがどれほど安定していると思っていても、それは私の最初の疑いでしょう。そして、あなたが問題を報告する開発者は同じことを言うでしょう。安定したテストワークロードは、必ずしも同じ命令を使用しているわけではなく、メモリサブシステムに多くの負荷をかけています。オーバークロックを停止します。問題がオーバークロックではないことを人々に信じてもらいたい場合は、オーバークロックしていないときにそれを実行して、クリーンなバグレポートを取得できるようにします。これは、他の人々がこの問題を解決するためにどれだけの努力を払うかで大きな違いを生むでしょう。バグのないソフトウェアを持つことは誇りのポイントですが、特に疑わしいハードウェア設定を持つ人々からのレポートは、おそらく本当のバグをまったく含まないイライラするタイムシンクです。
2つ目は、oopsデータを取得することです。気づいたように、これはあなたが言及した場所のいずれにも行きません。 X11の実行中にのみクラッシュが発生する場合は、ローカルコンソールがかなり機能していないと思います（とにかく苦痛です）。これは、シリアルコンソール、ネットワーク、またはローカルディスクに保存することで行う必要があります（これは、信頼できないカーネルがファイルシステムを破壊したくないので、それは聞こえるかもしれません。これを行うには、いくつかの方法があります。
- netdump を使用して、ネットワーク経由でサーバーに保存します。私はこれを何年も行っていないので、このソフトウェアがまだ周りにあり、最新のカーネルで動作するかどうかはわかりませんが、簡単に試してみる価値があります。
- シリアルコンソール を使用して起動します。両方のマシン（旧式のものであれUSBシリアルアダプターであれ）のシリアルポートが空いていて、ヌルモデムケーブルが必要です。他のマシンを設定して出力を保存します。
- kdump は、今日のかっこいい子供たちが使用しているもののようで、非常に柔軟に見えますが、セットアップが複雑に見えるので、私の好みではありません。つまり、何でもできる別のカーネルを起動して、以前のカーネルのメモリ内容を検査する必要がありますが、基本的にプロセス全体を構築する必要があり、そこに多くの既定のオプションはありません。 更新：実際、いくつかの素晴らしいディストリビューションがあります。 Ubuntuでは、 linux-crashdump
デバッグ情報を取得したら、アドレスをシンボル名に変換し、カーネルがどのようにクラッシュしたかを知るために使用できる ksymoops というツールがあります。そして、シンボル化されたダンプがあなたにとって何の意味もないなら、少なくともこれは、ここまたはおそらくあなたのLinuxディストリビューションのメーリングリスト/バグトラッカーで報告するのに役立つものです。
クラッシュダンプのcrashから、logおよびbtと入力して、もう少し情報を取得できます（パニックおよびスタックバックトレース中に記録されたもの）。君の Fatal Machine checkは here から来ているようですが。コードをスキミングして、プロセッサが Machine Check Exception -ハードウェアの問題を報告しました。繰り返しますが、私の最初の賭けはオーバークロックによるものでしょう。 logの出力に、より具体的なメッセージが含まれている可能性があります。
また、そのコードからは、mce=3カーネルパラメータ、クラッシュを停止します...しかし、これは診断手順として以外は、あまりお勧めしません。 Linuxカーネルがこのエラーをクラッシュする価値があると考えている場合、それはおそらく正しいでしょう。
a）カーネルメッセージがrsyslogデーモンによってファイルに記録されているかどうかを確認します
vi /etc/rsyslog.conf
そして、以下を追加します
kern.* /var/log/kernel.log
rsyslogサービスを再起動します。
/etc/initd.d/rsyslog restart
b）ロードされたモジュールをメモします
`lsmod >/your/home/dir`
c）パニックは再現できないため、発生するまで待ちます
d）パニックが発生したら、ライブCDまたは緊急CDを使用してシステムを起動します
e）影響を受けるシステム（pvs、vgs、lvsコマンドは、影響を受けるシステムでLVMを使用してLVを起動する場合に実行する）mount -t ext4 /dev/sdXN /mnt
f）/mnt/var/log/ディレクトリに移動し、kernel.logファイルを確認します。これにより、特定のモジュールまたは他の何かでパニックが発生しているかどうかを把握するのに十分な情報が得られます。
プロセッサーはオーバークロックされていますか？ BIOSのオーバークロックメニューで乗数を操作していたときに、今日も同じ問題が発生しました。 20xあたりのさまざまな乗数がこれを引き起こします。私はそれを18.5x（3.7GHz）に減らしました、そして問題は消えました;マザーボード/電源の問題だったと思います。
TSC 539b174dead ADDR 3fe98d264ebd MISC 1 [1561.519950] [ハードウェアエラー]：PROCESSOR 0：206a7 TIME 1357862746 SOCKET 0 APIC 1マイクロコード28。プロセッサー0は、カーネルがクラッシュを処理するために使用したものです。 （マルチCPUシステムの問題）およびソケット0が問題のあるプロセッサです（私は1つしかないと思いますが）。それは悪いか、またはオーバークロックされた障害の原因であることに気付きました。あなたがprime95までそれをとったと言ったのを知っていますが、私がシステムが何歳であるかについての詳細がわからないので、私はいくつかのストローをつかんでいます、あなたのサーマルペーストはどのように見えますか、そしてあなたのLGA（ CPU）よさそうですか？たぶんピンが曲がっていたり、LGAの下にペーストが貼られていると思います。ここでも根本原因です。
それでも問題が解決しない場合は、SMBIOSを使用してパニックが発生した場所を正確に見つけるための小さなトリックがあります。別の行（TSC 539b174de9d ADDR 3fe98d264ebd MISC 1）は、基本的に、クラッシュが発生した場所を示すSMBIOSデータです。マシンが起動したら、コマンドライン実行で、「TSC 539b174de9d ADDR 3fe98d264ebd MISC 1」をエコーします。出力を取得するためにSudo mcelog --ascii --dmiを実行すると、ハードウェアエラーであり、処理対象のDIMMであっても、DIMMの障害が発生するたびに障害のあるDIMMまたはバスパスを示している可能性があります。ただし、クラッシュはCPUを指します。
古いリグにmikrotikルーターをインストールしました。ファンが回転を停止し、プロセッサが熱くなりました。その後、ルーターは時々カーネルパニックを開始します。 CPUファンを交換した後、すべてがうまくいきました。
あなたのマシンをオーバークロックしているので、それは考えられる原因です。