私はUbuntu 12.04派生バージョン（amd64）を実行していますが、最近非常に奇妙な問題に直面しました。予期せずXがしばらく（1〜3分？）完全に停止した後、システムは再起動します。システムはオーバークロックされていますが、Windowsでは非常に安定していることが確認されました。これにより、カーネルパニックが発生したり、モジュールの1つに問題が発生したと考えられます。 Linuxでも高いCPU負荷にもかかわらず、競合なしにLINPACKを実行できます。コンピュータがアイドル状態であってもクラッシュがランダムに発生するようです。
システムクラッシュの原因をどのようにデバッグできますか？
これが独自のNVIDIAドライバであるかもしれないという予感を持ち、そのドライバの安定版（バージョン304）に戻りましたが、それでもクラッシュが発生しました。
クラッシュ後に正しいデバッグ手順を案内できる人はいますか？私はサムドライブを起動し、すべてのクラッシュ後に設定ファイルを公開したいのですが、それが何であるかわかりません。システムクラッシュの原因が何であるかをどのように知ることができますか？
通常、犯人となるログの束です。
.xsession - エラー:http://pastebin.com/EEDtVkVm
/var/log/Xorg.0.log:http://pastebin.com/ftsG5VAn
/var/log/kern.log:http://pastebin.com/Hsy7jcHZ
/var/log/システムログ:http://pastebin.com/9Fkp3FMz
事故記録すら全く見つかりません。
衝突を引き起こすのはそれほど簡単ではなく、GPUが同時に複数のアイテムを描画しようとしたときに発生するようです。 YouTube 動画をフルスクリーンで再生し、しばらく繰り返すか、複数の GIF をスクロールして Skype 通知ポップアップが表示されるとクラッシュすることがあります。私はこれについて完全に混乱しています。
CPUは4.8GHzにオーバークロックされていますが、完全に安定しており、昨日のLINPACK実行と9時間のPrime95テスト中にクラッシュは発生しませんでした。
修正する
私のカーネルバージョン3.2.0-35のカーネルデバッグシンボルと、、、およびをkdumpインストールcrashしました。競合が発生したカーネルファイルを実行してから競合ダンプを実行するlinux-crashdumpと、次の結果が表示されます。apport-unpackcrashVmCore
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
どんなアイデアがありますか？
ベストアンサー1
始めるには2つの提案があります。
あなたは最初のものが好きではありません。オーバークロックされたシステムがどんなに安定していると考えても、これが最初の疑いです。問題を報告する開発者なら誰でも同じことを言います。安定したテストワークロードは必ずしも同じコマンドを使用するわけではないので、とにかくメモリサブシステムに同じ量のストレスを加えます。オーバークロックを中止してください。人々が問題がオーバークロックに起因していないと信じるようにするには、オーバークロックが発生していないときに発生するようにして、クリーンなエラーレポートを取得できるようにします。これは、他の人が問題を解決するためにどれだけの努力をしているかに大きな影響を与えます。バグのないソフトウェアを持っていることは誇りに思っていますが、特にハードウェアの設定に問題がある人のレポートは残念で時間の無駄になる可能性があり、実際のバグとまったく関係がない可能性があります。
2番目は、あなたが言及した場所に移動しない申し訳ありませんデータを取得することです。実行中にのみ競合が発生した場合は、信頼できないカーネルがファイルシステムを破損させたくないので、考えよりも優れています。以下はいくつかの方法です。
- 使用ネットワークダンプネットワーク経由でサーバーに保存します。私は何年もこれをやったことがないので、このソフトウェアがまだ存在し、最新のカーネルで動作するかどうかはわかりませんが、簡単で試してみる価値があります。
- シリアルコンソールの使用を開始します（アーカイブバージョン、現在のバージョン）、両方のコンピュータ（以前のコンピュータまたはUSBシリアルアダプタ）で動作するシリアルポートが必要で、出力を保存するように別のコンピュータを設定できるヌルモデムケーブルが必要です。
- ダンプファイル最近は素敵な子どもたちが使っているようで、かなり柔軟に見えますが、設定が複雑に見えるので、私の好みではありません。簡単に言えば、何でもできる他のカーネルを起動し、以前のカーネルのメモリ内容を確認することが含まれますが、基本的にプロセス全体を構築する必要があり、固定されたオプションはあまり見られません。 修正する:実際、Ubuntuにはlinux-crashdumpという良いディストリビューションがあります。アーカイブバージョン、現在のバージョン）。
デバッグ情報がある場合は ksymoops(アーカイブバージョン、現在のバージョン（広告を含む））これを使用すると、アドレスをシンボル名に変換し、カーネルがどのように競合するかを理解できます。シンボリックダンプが何も意味がない場合は、少なくともここまたはLinuxディストリビューションのメーリングリスト/バグトラッカーに報告するのが役立ちます。
crashクラッシュダンプから入力を試み、log追加bt情報（パニックおよびスタックトレース中に記録された情報）を取得できます。あなたのFatal Machine check出身だと思います。ここ、しかし。コードに移動すると、プロセッサが報告します。機械検査例外- ハードウェアの問題。繰り返しますが、私の最初の賭けはオーバークロックによるものです。log詳細を知らせるより具体的なメッセージが出力にある可能性があります。
また、そのコードからmce=3カーネルパラメータで起動すると、競合が停止します。ただし、診断ステップを除いてはお勧めできません。 Linuxカーネルがこのバグがクラッシュする価値があると思うなら、おそらく正しいでしょう。