Erreurs de mémoire avec Ubuntu mais pas avec MemTest86 +

J'ai eu quelques erreurs btrfs et ext4. Après avoir décidé de tester ma RAM, j'ai eu les erreurs de répétition suivantes avec memtester. J'obtiens toujours des erreurs similaires après un peu de fonctionnement du memtester. Habituellement en une heure, mais cela prenait 4-5 heures en une seule fois.

La RAM de mon ordinateur est soudée. J'ai un emplacement vide supplémentaire. Il n'y a aucun paramètre dans le BIOS pour désactiver la RAM intégrée.

J'ai couru:

Memtest86 + pour 8 passes (~ 8 heures)
MemTest86 pour 18 passes (~ 9 heures)
memtesteret stressapptestsur Fedora 27 par défaut, installé sur une clé USB (~ 10 heures)
memtesteret stressapptestsur Ubuntu 17.10 Live par défaut (~ 2 heures)
memtesteret stressapptestsur Ubuntu 17.10 sur clé USB (~ 8 heures)
# debsums --changed le seul fichier modifié était une image d'un thème.

Ils n'ont imprimé aucune erreur.

J'utilise Ubuntu 17.10 (mis à jour à partir de 17.04) avec le noyau par défaut. Le noyau n'est pas corrompu. C'est un ordinateur portable ASUS avec Intel Haswell i3.

Également testé avec Linux 4.14.13 et 4.15.0-rc3, rc4, mainline.
Également testé avec un package de microcode Intel purgé.

L'erreur est reproductible, Nouveau est désactivé ou activé, aucun pilote binaire nvidia n'est chargé.

Liste noire des modules suivants: mtd intel_spi_platform intel_spicar ils ne se chargent pas lors de l'installation par défaut de Fedora 27 et ils semblent bloquer certains ordinateurs portables Lenova. Les erreurs ne se sont pas arrêtées.

uname -asortie

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

# lsmodsortie

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

# lsmodSortie de Fedora 27

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

Situation actuelle

J'ai placé mon disque dur dans un ordinateur portable (ordinateur portable de secours) que je connais bien et j'ai effectué les tests là-bas. J'ai eu les erreurs. Maintenant, je suis presque sûr qu'il s'agit d'un problème logiciel. Je n'ai jamais pu déclencher les erreurs sur mon ordinateur portable avec un Ubuntu frais ni avec un Fedora essayant de nombreuses heures.

Que devrais-je faire?

Un échantillon des erreurs:

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

Une erreur similaire avec les deux emplacements RAM est pleine:

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

Une erreur de 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

Je soupçonne que la configuration d'Ubuntu combinée avec le matériel de mon ordinateur portable est à blâmer pour ces erreurs. Presque à chaque fois en paquets de huit.

Informations sans importance et vaguement liées ci-dessous

À propos des erreurs btrfs; J'utilisais le 17.04. J'ai demandé dans l'irc de btrfs. On m'a dit que cela pourrait être une erreur matérielle ou en quelque sorte une erreur de gestion de la mémoire. Une partie de la page de métadonnées des btrfs s'est remplie de zéros, comme je l'ai fait maintenant. J'ai exécuté memtester juste quelques passes, je suis passé à ext4 et j'ai mis le blâme sur le pilote binaire nvidia.

Les commandes et leurs paramètres que j'utilise:

# stressapptest -M 10000 -s 1800

10000 est la mémoire disponible que je peux tester. Je l'obtiens via free -m-s` est en secondes.

# memtester 4096

Le processeur de l'ordinateur portable a 2 cœurs, donc je démarre généralement deux instances. 4096 est la moitié de la mémoire actuellement disponible viafree -m

ram data-corruption

— Artyom
source

Je remplacerais une mauvaise RAM, mais je ne sais pas si c'est possible avec des puces de RAM soudées. L'ordinateur est-il suffisamment récent pour être remplacé dans le cadre de la garantie?

— sudodus

@sudodus Oui, sa garantie n'a pas encore expiré. Je vais le RMA si je ne trouve pas de solution. J'ai trouvé que même s'il n'y a pas de moyen officiel, les gens ont trouvé des moyens de désactiver les béliers soudés sur certains ordinateurs portables en sautant certains points de test.

— Artyom

Pour être plus sûr, essayez à memtest86+partir de n'importe quel LiveCD d'installation d'Ubuntu.

— N0rbert

@ N0rbert J'ai fait quelques tests avec memtest86 - le propitiatoire - avec des résultats négatifs. Mais ils étaient à court de -4 répétitions, je ferai un test du jour au lendemain.

— Artyom

@sudodus, je crois que memtest86 + peut tester sa propre mémoire, cela ne devrait cependant pas être un gros problème. Oui, j'ai réparé ma partition ext4 à plusieurs reprises car elle s'est cassée probablement en raison d'erreurs liées à la mémoire. Malheureusement, je n'ai pas pu réparer ma partition btrfs car les métadonnées ont été corrompues avant d'être écrites sur le disque et ma partition btrfs l'a probablement propagée avec scrub btrfs et en a corrompu une partie.

— Artyom

Réponses:

La réponse supprimée était proche

Une réponse a été supprimée sur cette Q&R:

Avez-vous déjà essayé de réinstaller Ubuntu car cela ressemble à un échec de gestion de la mémoire au niveau du système d'exploitation

Ma réponse est similaire car elle implique une gestion de la mémoire de très bas niveau; KASLR au niveau du noyau.

Que fait KASLR

KASLR signifie K Ernel A ddress S rythme L ayout R andomization. Je ne l'ai jamais entendu à voix haute mais dans mon esprit je le prononce "Casler". Pensez à un fantôme amical dans la machine. KASLR est une mesure de sécurité pour randomiser quels emplacements de mémoire les modules du noyau résident. La théorie est que le noyau est plus difficile à pirater lorsque vous ne pouvez pas compter sur le même bit de code toujours au même endroit de la mémoire.

L'opération KASLR pourrait être considérée comme l'opposé des testeurs de mémoire qui lisent et écrivent de manière répétée aux mêmes emplacements de mémoire sans attendre de CHANGEMENTS. Ces opposés, cela m'a attiré (idiome remarqué), pour faire une recherche google sur KASLR et les erreurs de mémoire. Un en particulier apparemment sans rapport mérite peut-être un message sur le lien github vers ce Q&R. La raison en est qu'ils pensent qu'ils sont les seuls à être affectés par le décalage des adresses mémoire (si je lis correctement leur fil). Les trois premiers hits proviennent de RedHat que je répugne à lier parce que leurs sites Web sont des publications partielles à obtenir sur les robots de recherche Google, puis ils vous font payer pour lire.

Il y a des problèmes connus lorsque KASLR charge des "trucs" du noyau au milieu de la carte mémoire, ce qu'il n'est pas censé faire. Malheureusement, je ne me souviens pas du lien que j'ai trouvé la semaine dernière à inclure dans la réponse de ce soir. Le lien avait un correctif / solution de contournement pour demander à KASLR de ne pas utiliser d'emplacements de mémoire spécifiques.

Après avoir confirmé les problèmes connus avec KASLR et les emplacements de mémoire, j'ai commenté sous la question pour le désactiver KASLR et relancer les tests de mémoire. Une réponse a indiqué qu'elle semble réussir, donc je poste cette réponse.

Comment désactiver KASLR

Bien que j'utilise l'option de ligne de commande du noyau grub "kaslr" depuis quelques années maintenant, c'est devenu la valeur par défaut du noyau depuis au moins la version 4.12 . Pour empêcher KASLR de se charger, éditez /etc/default/grubet modifiez cette ligne:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash nokaslr"

Vous pourriez avoir d'autres options en plus de "silencieux" et "splash". L'étape importante consiste à ajouter "nokaslr" et à laisser les autres options en place.

Enregistrez ensuite le fichier et exécutez:

sudo update-grub

Bien sûr, une autre façon de désactiver KASLR est d'utiliser simplement un noyau plus ancien comme 4.4.0 sous Ubuntu 16.04.1 lorsque KASLR n'était pas automatiquement inclus.

— WinEunuuchs2Unix
source

Le problème ressemble beaucoup à une corruption aléatoire de la RAM. D'après mon expérience, MemTest86 est un test "trop facile" pour le matériel. Il trouvera une très mauvaise mémoire mais de légers problèmes passeront souvent inaperçus.

Si vous voulez savoir si votre mémoire est bonne, essayez d'exécuter Prime95 en mode auto-test / torture configuré pour utiliser autant de RAM que possible.

Un autre bon test consiste à exécuter un test de marteau à double face pendant quelques heures.

Je crois que si Prime95 et un marteau à double face ne peuvent pas trouver de problèmes avec votre mémoire, cela fonctionne probablement correctement. Cependant, simplement exécuter MemTest86, compiler des programmes, installer le système d'exploitation, jouer à des jeux peut sembler fonctionner même si votre mémoire est légèrement mauvaise (vous y êtes allé, faites cela - et vous avez obtenu des données corrompues à long terme).

— Mikko Rantalainen
source