Ich habe einige btrfs und ext4 Fehler. Nachdem ich mich entschlossen hatte, meinen RAM zu testen, bekam ich die folgenden Wiederholungsfehler mit memtester. Ich bekomme immer ähnliche Fehler, nachdem ich das ausgeführt habe memtester. Normalerweise in einer Stunde, aber es dauerte 4-5 Stunden auf einmal.

Der RAM meines Computers ist verlötet. Ich habe zusätzlichen leeren Steckplatz. Im BIOS gibt es keine Einstellungen zum Deaktivieren des integrierten Arbeitsspeichers.

Ich bin gelaufen:

• Memtest86 + für 8 Durchgänge (~ 8 Stunden)
• MemTest86 für 18 Pässe (~ 9 Stunden)
• memtesterund stressapptestauf Fedora 27 Standard, installiert auf einem USB-Stick (~ 10 Stunden)
• memtesterund stressapptestunter Ubuntu 17.10 Live Standard (~ 2 Stunden)
• memtesterund stressapptestunter Ubuntu 17.10 auf USB-Stick (~ 8 Stunden)
• # debsums --changed Die einzige geänderte Datei war ein Bild eines Themas.

Sie haben keine Fehler gedruckt.

Ich verwende Ubuntu 17.10 (aktualisiert von 17.04) mit Standardkernel. Kernel ist nicht verdorben. Es ist ein ASUS-Laptop mit Intel Haswell i3.

• Auch mit Linux 4.14.13 und 4.15.0-rc3, rc4, mainline getestet.
• Wird auch mit einem gelöschten Intel-Mikrocode-Paket getestet.

Der Fehler ist reproduzierbar, entweder Nouveau ist deaktiviert oder aktiviert, es werden keine nvidia-Binärtreiber geladen.

Die folgenden Module wurden mtd intel_spi_platform intel_spiauf die schwarze Liste gesetzt: Sie werden bei der Standardinstallation von Fedora 27 nicht geladen und scheinen einige Lenova-Laptops zu beschädigen. Fehler haben nicht aufgehört.

uname -aAusgabe

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

# lsmodAusgabe

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

Fedora 27's # lsmodAusgabe

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

Momentane Situation

Ich habe meine Festplatte in einen Laptop (Backup-Laptop) gesteckt, von dem ich weiß, dass er gut ist, und dort die Tests durchgeführt. Ich habe die Fehler bekommen. Jetzt bin ich mir ziemlich sicher, dass dies ein Softwareproblem ist. Ich war noch nie in der Lage, die Fehler auf meinem Laptop mit einem neuen Ubuntu oder einem Fedora auszulösen, der viele, viele Stunden lang versucht hat.

Was sollte ich tun?

Ein Beispiel für die Fehler:

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

Ein ähnlicher Fehler mit den beiden RAM-Steckplätzen ist voll:

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

Ein Fehler von 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

Ich vermute, dass Ubuntus Konfiguration in Kombination mit der Hardware meines Laptops an diesen Fehlern schuld ist. Fast jedes Mal in Achterpackungen.

Unwichtige, lose verwandte Informationen unten

Über die btrfs-Fehler; Ich habe 17.04 verwendet. Ich habe in btrfs 'irc herumgefragt. Mir wurde gesagt, dass es sich um einen Hardwarefehler oder einen Speicherverwaltungsfehler handeln könnte. Ein Teil der Metadatenseite des btrfs wurde mit Nullen gefüllt, so wie ich es jetzt erlebt habe. Ich habe memtester nur ein paar Durchgänge ausgeführt, auf ext4 umgestellt und die Schuld auf den nvidia-Binärtreiber gelegt.

Die Befehle und ihre Parameter, die ich benutze:

# stressapptest -M 10000 -s 1800

10000 ist der verfügbare Speicher, den ich testen kann. Ich bekomme es über free -m-s` ist Sekunden.

# memtester 4096

Die CPU des Laptops hat 2 Kerne, daher starte ich normalerweise zwei Instanzen. 4096 ist die Hälfte des aktuell verfügbaren Speichers überfree -m

Gelöschte Antwort war knapp

Eine Antwort auf diese Fragen und Antworten wurde gelöscht:

Haben Sie bereits versucht, Ubuntu neu zu installieren, da dies wie ein Speicherverwaltungsfehler auf Betriebssystemebene klingt?

Meine Antwort ist ähnlich, da es sich um eine sehr niedrige Speicherverwaltung handelt. KASLR auf Kernel-Ebene.

Was KASLR macht

KASLR steht für K ernel A ddress S Pace L ayout R andomization. Ich habe es noch nie laut gesprochen, aber in meinen Gedanken spreche ich es "Casler" aus. Denken Sie an freundliche Geister in der Maschine. KASLR ist eine Sicherheitsmaßnahme, um zufällig zu bestimmen, an welchen Speicherorten sich Kernelmodule befinden. Die Theorie besagt, dass der Kernel schwerer zu hacken ist, wenn Sie sich nicht darauf verlassen können, dass sich immer derselbe Code an derselben Speicherstelle befindet.

Die KASLR-Operation kann als Gegenteil von Speichertestern angesehen werden, die wiederholt in dieselben Speicherstellen lesen und schreiben, ohne Änderungen zu erwarten. Da es sich um Gegensätze handelt, hat es mich angezogen (Redewendung bemerkt), eine Google-Suche nach KASLR und Speicherfehlern durchzuführen. Eine Person, die anscheinend nichts damit zu tun hat , könnte eine Nachricht über Github verdienen, die mit diesen Fragen und Antworten verknüpft ist. Der Grund dafür ist, dass sie denken, dass sie die einzigen sind, die durch das Verschieben von Speicheradressen beeinflusst werden (wenn ich ihren Thread richtig lese). Die ersten drei Treffer stammen von RedHat, auf die ich nur ungern verlinken möchte, da ihre Websites Teilbeiträge sind, um auf Google-Suchroboter zuzugreifen, und Sie dann für das Lesen bezahlen müssen.

Es sind Probleme bekannt, wenn KASLR Kernel-Inhalte in die Mitte der Speicherzuordnung lädt, was nicht vorgesehen ist. Leider kann ich mich nicht an den Link erinnern, den ich letzte Woche gefunden habe, um ihn in die heutige Antwort aufzunehmen. Der Link hatte einen Patch / eine Problemumgehung, um KASLR anzuweisen, keine bestimmten Speicherorte zu verwenden.

Nachdem ich bekannte Probleme mit KASLR und Speicherorten bestätigt hatte, kommentierte ich unter der Frage, ob KASLR deaktiviert und Speichertests erneut ausgeführt werden sollen. In einer Antwort wurde angegeben, dass dies erfolgreich zu sein scheint, daher poste ich diese Antwort.

So deaktivieren Sie KASLR

Obwohl ich seit einigen Jahren die Grub-Kernel-Befehlszeilenoption "kaslr" verwende, wurde sie seit mindestens Version 4.12 zum Kernel-Standard . Um KASLR vom Laden auszuschließen, bearbeiten /etc/default/grubund ändern Sie diese Zeile:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash nokaslr"

Möglicherweise haben Sie neben "leise" und "Spritzen" noch andere Optionen. Der wichtige Schritt besteht darin, "nokaslr" hinzuzufügen und die anderen Optionen beizubehalten.

Speichern Sie dann die Datei und führen Sie Folgendes aus:

sudo update-grub

Eine andere Möglichkeit, KASLR zu deaktivieren, besteht darin, einfach einen älteren Kernel wie 4.4.0 unter Ubuntu 16.04.1 zu verwenden, wenn KASLR nicht automatisch enthalten war.

Das Problem klingt sehr nach einer zufälligen Bitbeschädigung des RAM. Nach meiner Erfahrung ist MemTest86 ein "zu einfacher" Test für die Hardware. Es wird wirklich schlechtes Gedächtnis finden, aber leichte Probleme bleiben oft unbemerkt.

Wenn Sie wissen möchten, ob Ihr Speicher gut ist, führen Sie Prime95 im Selbsttest- / Foltermodus aus, der so konfiguriert ist, dass so viel RAM wie möglich verwendet wird.

Ein weiterer guter Test besteht darin, einige Stunden lang einen doppelseitigen Rowhammer-Test durchzuführen.

Ich glaube, wenn Prime95 und der doppelseitige Ruderhammer keine Probleme mit Ihrem Gedächtnis finden, funktioniert es wahrscheinlich richtig. Das einfache Ausführen von MemTest86, das Kompilieren von Programmen, das Installieren des Betriebssystems und das Spielen von Spielen scheint jedoch auch dann zu funktionieren, wenn Ihr Speicher etwas schlecht ist (war dort, hat das getan - und hat auf lange Sicht beschädigte Daten erhalten).