web-dev-qa-db-ja.com

MemTest86 +ではなくUbuntuでのメモリエラー

いくつかのbtrfsおよびext4エラーが発生しました。 RAMをテストすることにした後、memtesterで次のエラーが繰り返し表示されます。 memtesterを少し実行した後、常に同様のエラーが発生します。通常1時間ですが、一度に4〜5時間かかりました。

コンピューターのRAMははんだ付けされています。空のスロットが追加されました。 BIOSには、オンボードRAMを無効にする設定はありません。

私は走った:

  • Memtest86 + 8パス(〜8時間)
  • 18パスのMemTest86(〜9時間)
  • memtesterおよびstressapptestは、Fedora 27のデフォルトでUSBスティックにインストールされます(最大10時間)
  • memtesterおよびstressapptest Ubuntu 17.10 Liveのデフォルト(〜2時間)
  • memtesterおよびstressapptest USBスティック上のUbuntu 17.10で(〜8時間)
  • # debsums --changed唯一の変更されたファイルはテーマの画像でした。

エラーは出力されませんでした。

デフォルトのカーネルでUbuntu 17.10(17.04からアップグレード)を使用しています。カーネルは汚染されていません。 Intel Haswell i3を搭載したASUSラップトップです。

  • Linux 4.14.13および4.15.0-rc3、rc4、メインラインでもテスト済み。
  • パージされたインテルマイクロコードパッケージでもテストされています。

エラーは再現可能です。Nouveauが無効になっているか有効になっており、nvidiaバイナリドライバはロードされていません。

以下のモジュールをブラックリストに追加しました:mtdintel_spi_platformintel_spiは、デフォルトのFedora 27インストールではロードせず、 と思われる Lenovaラップトップをレンガにしたためです。エラーは停止していません。

uname -aの出力

Linux hostname 4.13.0-19-generic #22-Ubuntu SMP Mon Dec 4 11:58:07 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

# lsmodの出力

https://paste.ubuntu.com/26222245/

Fedora 27の# lsmodの出力

https://paste.ubuntu.com/26226473/

現在の状況

私は自分のHDDをラップトップ(バックアップラップトップ)に入れました。エラーが発生しました。今、これはソフトウェアの問題だと確信しています。新しいUbuntuやFedoraで何時間も試してみても、ラップトップでエラーをトリガーすることはできませんでした。

私は何をすべきか?

エラーのサンプル:

Loop 6:
  Stuck Address       : ok         
  Random Value        : ok
  Compare XOR         : ok
  Compare SUB         : ok
  Compare MUL         : ok
  Compare DIV         : ok
  Compare OR          : ok
  Compare AND         : ok
  Sequential Increment: ok
  Solid Bits          : ok         
  Block Sequential    : ok         
  Checkerboard        : ok         
  Bit Spread          : ok         
  Bit Flip            : testing 262
FAILURE: 0x00000000 != 0xfffffffeffffffff at offset 0x0ef94000.
FAILURE: 0x00000000 != 0x100000000 at offset 0x0ef94008.
FAILURE: 0x00000000 != 0xfffffffeffffffff at offset 0x0ef94010.
FAILURE: 0x00000000 != 0x100000000 at offset 0x0ef94018.
FAILURE: 0x00000000 != 0xfffffffeffffffff at offset 0x0ef94020.
FAILURE: 0x00000000 != 0x100000000 at offset 0x0ef94028.
FAILURE: 0x00000000 != 0xfffffffeffffffff at offset 0x0ef94030.
FAILURE: 0x00000000 != 0x100000000 at offset 0x0ef94038.
  Walking Ones        : ok         
  Walking Zeroes      : ok         
  8-bit Writes        : ok
  16-bit Writes       : ok

両方のRAMスロットで同様のエラーが発生しています:

Loop 1:
  Stuck Address       : ok         
  Random Value        : ok
  Compare XOR         : ok
  Compare SUB         : ok
  Compare MUL         : ok
  Compare DIV         : ok
  Compare OR          : ok
  Compare AND         : ok
  Sequential Increment: ok
  Solid Bits          : ok         
  Block Sequential    : ok         
  Checkerboard        : ok         
  Bit Spread          : testing   4
FAILURE: 0x00000000 != 0x00000050 at offset 0x7da80000.
FAILURE: 0x00000000 != 0xffffffffffffffaf at offset 0x7da80008.
FAILURE: 0x00000000 != 0x00000050 at offset 0x7da80010.
FAILURE: 0x00000000 != 0xffffffffffffffaf at offset 0x7da80018.
FAILURE: 0x00000000 != 0x00000050 at offset 0x7da80020.
FAILURE: 0x00000000 != 0xffffffffffffffaf at offset 0x7da80028.
FAILURE: 0x00000000 != 0x00000050 at offset 0x7da80030.
FAILURE: 0x00000000 != 0xffffffffffffffaf at offset 0x7da80038.
  Bit Flip            : setting 141

stressapptestのエラー:

Report Error: miscompare : DIMM Unknown : 1 : 157s
Hardware Error: miscompare on CPU 2(0x2) at 0x7fcc0726e000(0xb0d18:DIMM Unknown): read:0x0000000000000000, reread:0x0000000000000000 expected:0x4a4a4a4a4a4a4a4a
Report Error: miscompare : DIMM Unknown : 1 : 157s
Hardware Error: miscompare on CPU 2(0x2) at 0x7fcc0726e008(0xb0d18:DIMM Unknown): read:0x0000000000000000, reread:0x0000000000000000 expected:0x4a4a4a4a4a4a4a4a
Report Error: miscompare : DIMM Unknown : 1 : 157s
Hardware Error: miscompare on CPU 2(0x2) at 0x7fcc0726e010(0xb0d18:DIMM Unknown): read:0x0000000000000000, reread:0x0000000000000000 expected:0x4a4a4a4a4a4a4a4a
Report Error: miscompare : DIMM Unknown : 1 : 157s
Hardware Error: miscompare on CPU 2(0x2) at 0x7fcc0726e018(0xb0d18:DIMM Unknown): read:0x0000000000000000, reread:0x0000000000000000 expected:0x4a4a4a4a4a4a4a4a
Report Error: miscompare : DIMM Unknown : 1 : 157s
Hardware Error: miscompare on CPU 2(0x2) at 0x7fcc0726e020(0xb0d18:DIMM Unknown): read:0x0000000000000000, reread:0x0000000000000000 expected:0x4a4a4a4a4a4a4a4a
Report Error: miscompare : DIMM Unknown : 1 : 157s
Hardware Error: miscompare on CPU 2(0x2) at 0x7fcc0726e028(0xb0d18:DIMM Unknown): read:0x0000000000000000, reread:0x0000000000000000 expected:0x4a4a4a4a4a4a4a4a
Report Error: miscompare : DIMM Unknown : 1 : 157s
Hardware Error: miscompare on CPU 2(0x2) at 0x7fcc0726e030(0xb0d18:DIMM Unknown): read:0x0000000000000000, reread:0x0000000000000000 expected:0x4a4a4a4a4a4a4a4a
Report Error: miscompare : DIMM Unknown : 1 : 157s
Hardware Error: miscompare on CPU 2(0x2) at 0x7fcc0726e038(0xb0d18:DIMM Unknown): read:0x0000000000000000, reread:0x0000000000000000 expected:0x4a4a4a4a4a4a4a4a

私のラップトップのハードウェアと組み合わせたUbuntuの構成が、これらのエラーのせいだと思われます。ほぼ8パック入り。

重要ではない、大まかに関連する以下の情報

Btrfsエラーについて。 17.04を使用していました。私はbtrfsのircで尋ねました。ハードウェアエラーかメモリ管理エラーの可能性があると言われました。私が今経験しているように、btrfsのメタデータページの一部はゼロで埋められました。私はほんの数回パスを実行し、ext4に切り替えて、nvidiaバイナリドライバーに責任を負わせました。

私が使用するコマンドとそのパラメーター:

# stressapptest -M 10000 -s 1800

10000は、テストできる使用可能なメモリです。 free -m- s`で取得するのは秒です。

# memtester 4096

ラップトップのCPUには2つのコアがあるため、通常は2つのインスタンスを起動します。 4096は、free -mを介して現在使用可能なメモリの半分です

8
Artyom

削除された回答は近かった

このQ&Aで回答が削除されました。

OSレベルのメモリ管理エラーのように聞こえるので、すでにubuntuの再インストールを試みましたか

私の答えは非常に低レベルのメモリ管理を伴うため、同様です。 KASLRカーネルレベルで。

KASLRが行うこと

KASLRはKernelAddressSpaceLayoutRandomization。私はそれが大声で話されるのを聞いたことがありませんが、私の心ではそれを「Casler」と発音します。マシンに優しいゴーストを思い浮かべてください。 KASLRは、カーネルモジュールが存在するメモリの場所をランダム化するセキュリティ対策です。常に同じメモリスポットにある同じコードビットに依存できない場合、カーネルはハッキングするのが難しいという理論です。

KASLR操作は、変更がないことを期待して同じメモリ位置に繰り返し読み書きするメモリテスターの反対と見なすことができます。これらは正反対であり、KASLRおよびメモリエラーでGoogle検索を行うことは私を魅了しました(イディオムに気づいた)。特に一見無関係に見えるものは、このQ&Aにリンクする github に関するメッセージに値するかもしれません。メモリアドレスをシフトすることによって影響を受けるのは彼らだけだと考えるからです(スレッドを正しく読み取っている場合)。最初の3つのヒットは、RedHatからのものです。彼らのウェブサイトはGoogle検索ロボットに乗る部分的な投稿であり、あなたを作ります読んで支払う。

KASLRがカーネルの「もの」をメモリマップの中央にロードする際に、想定されていない既知の問題があります。残念ながら、先週見つけたリンクを今夜の回答に含めることはできません。リンクには、特定のメモリロケーションを使用しないようにKASLRに指示するためのパッチ/回避策がありました。

KASLRとメモリの場所に関する既知の問題を確認した後、質問の下でコメントしてKASLRを無効にし、メモリテストを再実行しました。返信には成功したように見えるので、この回答を掲載しています。

KASLRを無効にする方法

数年前からgrubカーネルコマンドラインオプション「kaslr」を使用していましたが、少なくともバージョン4.12以降、カーネルのデフォルトになりました。 KASLRの読み込みを回避するには、edit /etc/default/grubを使用して、次の行を変更します。

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash nokaslr"

「静か」と「スプラッシュ」以外のオプションがあります。重要なステップは、「nokaslr」を追加し、他のオプションをそのままにしておくことです。

次に、ファイルを保存して実行します:

Sudo update-grub

もちろん、KASLRを無効にする別の方法は、KASLRが自動的に含まれていなかったUbuntu 16.04.1の下で4.4.0のような古いカーネルを単に使用することです。

1

この問題は、RAMのランダムなビット破損のように聞こえます。私の経験では、MemTest86はハードウェアの「簡単すぎる」テストです。それは本当に悪いメモリを見つけますが、わずかな問題はしばしば見過ごされます。

メモリが良好かどうかを知りたい場合は、できるだけ多くのRAMを使用するように設定されたセルフテスト/拷問モードで Prime95 を実行してみてください。

もう1つの優れたテストは、両面ローハンマーテストを数時間実行することです。

Prime95と両面ローハンマーがあなたの記憶に問題を見つけることができなければ、おそらく正しく動作することを信じています。ただし、MemTest86の実行、プログラムのコンパイル、OSのインストール、ゲームのプレイは、メモリがわずかに悪い場合でも動作しているように見える場合があります(そこに、それを実行し、長期的に破損したデータを取得しました)。

0