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にオーバークロックされますが、完全に安定しており、昨日1回クラッシュすることなく、巨大なLINPACKの実行と9時間のPrime95に耐えました。

更新

私がインストールされてきた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番目は、おっとデータを取得することです。お気づきのとおり、これはあなたが言及したどの場所にも行きません。クラッシュがX11の実行中にのみ発生する場合、ローカルコンソールはほとんど機能していない（とにかく痛みです）ので、シリアルコンソールを介して、ネットワーク経由で、またはローカルディスクに保存することでこれを行う必要があります（これは、信頼できないカーネルがファイルシステムを破壊したくないために聞こえます）。これを行ういくつかの方法を次に示します。

• netdumpを使用して、ネットワーク経由でサーバーに保存します。私はこれを何年もやっていないので、このソフトウェアがまだ存在し、最新のカーネルで動作するかどうかはわかりませんが、一見の価値があるほど簡単です。
• シリアルコンソールを使用して起動します。両方のマシンに無料のシリアルポート（旧式のものでもUSBシリアルアダプターでも）とヌルモデムケーブルが必要です。出力を保存するように他のマシンを構成します。
• kdumpは、最近クールな子供たちが使用しているもののようで、非常に柔軟に見えますが、設定が複雑に見えるため、私の好みではありません。要するに、何でもできる前のカーネルのメモリ内容を検査できる別のカーネルを起動することを伴いますが、本質的にプロセス全体を構築する必要があり、そこに多くの缶詰のオプションはありません。更新：実際にはいくつかの素晴らしいディストリビューションがあります。Ubuntuの場合、linux-crashdump

デバッグ情報を取得したら、ksymoopsと呼ばれるツールを使用して、アドレスをシンボル名に変換し、カーネルがどのようにクラッシュしたかを把握することができます。そして、シンボル化されたダンプがあなたにとって何の意味も持たないなら、少なくともこれはここで、あるいはおそらくあなたのLinuxディストリビューションのメーリングリスト/バグトラッカーで報告するのに役立つものです。

crashクラッシュダンプから入力logしbtて、もう少し情報（パニックとスタックバックトレース中に記録されたもの）を取得できます。あなたFatal Machine checkはここから来ているようですが。コードのスキミングから、プロセッサがマシンチェック例外 -ハードウェアの問題を報告しました。繰り返しますが、私の最初の賭けはオーバークロックによるものです。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を使用してシステムを起動します

および/家庭別々のファイル・システムでない場合は/ var e）のファイルシステムをマウントします（通常は/影響を受けるシステムの）十分です（pvs、vgs、lvsコマンドはLVを持ち出すためにあなたが影響を受けるシステム上のLVMを使用している場合に実行する必要があります） mount -t ext4 /dev/sdXN /mnt

f）/mnt/var/log/ディレクトリに移動し、kernel.logファイルを確認します。これにより、特定のモジュールなどでパニックが発生しているかどうかを判断するのに十分な情報が得られます。

プロセッサーはオーバークロックされていますか？BIOSのオーバークロックメニューで乗数を使用して遊んでいたときに、今日同じ問題が発生しました。20倍前後のさまざまな乗数により、これが起こります。私はそれを18.5x（3.7GHz）に減らし、問題はなくなりました。マザーボード/電源の問題だと思います。

間違いなくプロセッサの問題です。TSC539b174dead ADDR 3fe98d264ebd MISC 1 [1561.519950] [ハードウェアエラー]：PROCESSOR 0：206a7 TIME 1357862746 SOCKET 0 APIC 1マイクロコード28。プロセッサ0はクラッシュを処理するために使用される行です（マルチCPUシステムの問題）およびソケット0が問題のプロセッサです（ただし、1つしかないと仮定します）。不良であるか、または障害の原因がオーバークロックされていることに注意してください。あなたはprime95を介してそれを取りましたが、システムの古さに関する詳細情報がないので、私はいくつかのストローをつかんでいます、あなたのサーマルペーストはどのように見えますか？ 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ファンを変更した後、すべてがうまくいきました。

マシンをオーバークロックしているので、原因の可能性があります。