マシンチェックの例外によるランダムな再起動
ラップトップが1日2回ほどランダムに再起動します。再起動前の次のエラーログが表示されます。
。
残念ながら、マシンチェック例外（MCE）をデコードする方法がわかりません。 mcelog --asciiは何も出力しません。これがソフトウェアの問題である可能性はありますか？
ラップトップは、Intel Core i5-3317Uプロセッサを搭載したSamsung NP900X3Cです。 3.13.5カーネルでArch Linuxを使用しています。
この問題は、ハードウェア障害に関係しています。具体的には、バンク4のメモリ（DIMM 4-想定）が故障しているようです。 MCEファシリティ（マシンチェックイベント） についてはあまり知られていませんが、サイトに関するいくつかの質問に回答しました。
さらに、次のタイトルのこのU＆L Q＆Aで、MCEの独自のルールを記述できます： mcelogのトリガーを書き込む 。
また、MCEのFAQを参照する場合、項目＃6は、タイトルのmcelog --asciiコマンドを使用する方法を示しています： mcelog --asciiを実行するにはどうすればよいですか？ 基本的には、パニックメッセージをテキストファイルに保存し、次のようにmcelogコマンドで実行するとします。
$ mcelog --ascii < file
どうすれば修正できますか？
オプション＃1
基本的に3つのオプションがあります。最初の説明は省きます。スロット4のRAMDIMMを交換することです。
オプション＃2
2番目のオプションは、問題をさらに診断し、それが実際に障害のあるDIMMであることを確認することです。これを行うには memtest86 + を使用できます。このテストを実行すると同時に、DIMMを取り付け直してDIMMを装着し直し、マザーボードのスロットにしっかりと接触していることを確認します。これを行うのは実際には非常に簡単です。
オプション＃3
3番目のオプションは、その場所がDIMM内の特定の2つのアドレスに分離されていると想定して、その場所をブラックリストに登録することです。信じられないかもしれませんが、実際には特定のメモリアドレスをブラックリストに登録できます。このサイトでこれを行う方法についても説明しました。タイトルは次のとおりです。 MemTest86 +のエラー表示に従って、正しい不良RAMセクターをブラックリストに登録する方法 。
allソフトウェアを更新します。非公式のソフトウェア（ビデオドライバーなど）がインストールされている場合は、とりあえず削除してください。その後、再試行してください。特にnVidiaドライバーは不安定性を引き起こすことで有名であり、ndiswrapperで使用されるWindowsドライバーはほとんどが誤って機能します。
ランダムクラッシュ（出力が毎回同じでない場合）は、通常、どこか（過熱ファン、乾燥したヒートペースト、ダストバニーによって詰まった気流/詰まった気道）の過熱の結果です。 RAMまたは他のコンポーネントがしっかりと固定されていない場合にも、このような状況が発生しました。
不良RAMが原因である可能性があります memtest を実行します（ブートメニューのオプションの場合があります）。はい、これには非常に長い時間がかかります。他のハードウェアの問題は、より遠隔の可能性です。
MCEエラー（b200000000100402）は、「MCA：内部未分類エラー：402」です。したがって、それはメモリとは関係ありません、または少なくともそれを述べることはできません。以下のデコードされたエラーでわかるように、ハードウェアに関連しています。
The kernel log indicates that hardware errors were detected.
System log may have more information.
The last 20 mcelog lines of system log are:
==========================================
Mar 28 01:59:27 900x3c mcelog: Hardware event. This is not a software error.
Mar 28 01:59:27 900x3c mcelog: MCE 0
Mar 28 01:59:27 900x3c mcelog: CPU 0 BANK 4
Mar 28 01:59:27 900x3c mcelog: TIME 1395968361 Fri Mar 28 01:59:21 2014
Mar 28 01:59:27 900x3c mcelog: MCG status:
Mar 28 01:59:27 900x3c mcelog: MCi status:
Mar 28 01:59:27 900x3c mcelog: Uncorrected error
Mar 28 01:59:27 900x3c mcelog: Error enabled
Mar 28 01:59:27 900x3c mcelog: Processor context corrupt
Mar 28 01:59:27 900x3c mcelog: MCA: Internal unclassified error: 402
Mar 28 01:59:27 900x3c mcelog: STATUS b200000000100402 MCGSTATUS 0
Mar 28 01:59:27 900x3c mcelog: MCGCAP c07 APICID 0 SOCKETID 0
Mar 28 01:59:27 900x3c mcelog: CPUID Vendor Intel Family 6 Model 58
さらに、 カーネルバグ839511 では、同じエラーが発生します。マザーボードとCPUを変更することで解決しました。
これは内部CPUの問題のようです。 1つ以上のコアでチェックサムエラーをトリガーします。私のラップトップ（Samsung NP900X3C）は時々同じことをします。
Windowsがクラッシュせず、Linuxがクラッシュしない理由は、Windowsがブート時に自動的にIntelの最新のマイクロコードをCPUにロードするという事実に関係している可能性があります。マイクロコードはCPU内で実行される「ファームウェア」（存在する）であり、インテルは時々これにパッチを当て（バグ修正）、新しいマイクロコードをリリースします。これは実際にはサムスンのBIOSアップデートでアップデートされるはずですが、それは起こりそうにありません......
幸い、Windowsが行うように、起動時に新しいIntelマイクロコードをCPUにロードすることは可能ですが、これは次の再起動までしか保持されません。
さらに幸いなことに、DebianとUbuntuでは、これは次のように簡単に実行できます。
Sudo apt-get install intel-microcode
この後、Linuxは起動のたびに最新のIntelマイクロコードをCPUにロードします。試してみて、問題が解消するかどうかを確認してください。私はこれを数日前に自分のラップトップで自分で行っており、それ以来クラッシュは見られません。