Forum général.général Linux gère t-il la mémoire défectueuse sans problème ?

Posté par  .
Étiquettes :
3
26
mar.
2009
Suite à une série d'incidents suspects, j'ai utilisé memtest86+ qui
vient de détecter des problèmes mémoire.

Je suis sous Debian 5.0 (Lenny).

Apparemment, d'après une première recherche sur la toile, Linux sait gérer
les zones mémoires défectueuses.
memtest86+ (lancé à partir d'une disquette bootable auto-suffisante) affiche
les adresses problématiques mais je n'ai pas vu d'option pour les sauvegarder
dans un fichier. Il y en a déjà trop pour que je puisse les passer en argument
au noyau (badram=...)

Mes questions :

Quelqu'un a t-il déjà mis en oeuvre cette procédure, ou bien suis-je en train
de perdre mon temps ?
J'ai pu installer Dedian Lenny sans problème, si je pouvais indiquer au noyau
après coup "n'utilise pas ces adresses", sans tout réinstaller, ça serait l'idéal.
J'ai noté un paquet "patch noyau pour mémoire défectueuse" mais ne sais comment
l'appliquer.

Avez-vous déjà rencontré un tutoriel expliquant en détail tout ça ?
D'avance merci.

  • # Plop!

    Posté par  (site web personnel) . Évalué à 3.

    Salut,

    Il y a quelques années, j'avais eu un problème similaire au tiens et je m'étais posé exactement la même question. Finalement, je n'ai pas eu à me prendre la tête puisque je me suis rendu compte qu'à chaque "passage" de memtest86+ les adresses des blocks défectueux changeaient tout le temps.

    Autrement dit : RAM == poubelle !

    Avant de perdre ton temps, fais le test et regardes si les adresses indiquées sont identiques (ou pas) à chaque passage.

    • [^] # Re: Plop!

      Posté par  . Évalué à 1.

      Je partage cet avis : ram défectueuse => poubelle^Wdéchetterie !
      Je les teste systématiquement toutes avant install et ensuite en gros tous les six mois...
      Car un seul bit de travers et c'est tout un filesystem qui peut être corrompu (avec un risque de ne pas pouvoir le corriger avec fsck si on s'en rend compte...).
      Et je suis passé à l'ECC, même sur les desktops (par contre, je ne sais pas comment le hardware remonte l'erreur, mais bon, il vaut mieux un kernel panic que de continuer à bosser sur du hardware foireux...).

      • [^] # Re: Plop!

        Posté par  (site web personnel) . Évalué à 2.

        Vérifier les connections de la RAM parfois, c'est simplement un mauvais branchement.

        "La première sécurité est la liberté"

  • # RE

    Posté par  . Évalué à 1.

    Merci pour vos réponses.

    Dans ma malchance j'ai peut-être de la chance. J'ai relancé memtest86+ et
    il semble détecter les mêmes adresses (je dis il semble parce que je ne les ai
    pas toutes mémorisées). Mais ça semble vrai.

    Plusieurs possibilités :

    1) Soit il y a un moyen de sauvegarder sur disquette la liste et de l'indiquer
    avant ou après l'installation. Je ne vois pas comment.
    J'exclus toujours le passage "badram=..." à l'installation, c'est impraticable.

    3) Soit j'installe Linux et j'indique après coup manuellement (mais où ?) la liste
    en les ayant notées grâce à un appareil photo... Merci de ne pas rigoler au fond ;)
    Je crois que ça va être cette solution.

    Je ferai régulièrement des tests.

    De toute façon ma question reste intéressante d'une façon générale, même sur du
    matériel récent.

    • [^] # Re: RE

      Posté par  (site web personnel) . Évalué à 3.

      Perso vu le prix de la ram, j'ai l'impression que tu es un peu masochiste :)

      Moi ma solution est bcp plus simple, direction le magasin, nouvelle ram et rouler un spin.

  • # RE

    Posté par  . Évalué à 1.

    Après approndissement il doit tout simplement être possible de passer des arguments au noyau via /boot/grub/menu.lst. J'espère qu'il n'y a pas de limitation de taille parce que ça fait pas mal d'adresses à passer. L'énorme avantage est que l'on peut sauver la liste des adresse sur un disquette, pour installation ultérieure.

    Je teste tout ça, si ça marche je le dirai, des personnes peuvent être concernées par le même problème.

    • [^] # Re: RE

      Posté par  (site web personnel) . Évalué à 2.

      Bon je vais prendre le contrepied d'un peu tout ce qui a été écrit plus haut. Jeter de la RAM, même défectueuse, est une connerie. Le seul cas où c'est une solution potable, c'est si elle est vraiment flinguée de chez flinguée, et que même badram n'y peut rien.

      Ayant déjà acheté de la RAM en brocante, j'ai eu l'occasion de tester badram pour recycler une vieille machine. Plusieurs remarques : une barette qui peut faire plein d'erreurs peut très bien fonctionner normalement dans une autre machine qui a un FSB tournant à une vitesse inférieure. J'ai eu le cas d'une 128 Mo de SDRAM PC100 qui ne tournait bien qu'underclockée à 66MHz.

      Ensuite, même si les adresses erronées changent, on s'en fout : les erreurs viennent en général d'un ou plusieurs module mémoire. memtest te fournit les erreurs dans un format spécial pour badram, qui est une suite "adresse,masque". Les bits à 1 du masque t'indiquent les adresses valides, les bits à 0 les adresses invalides.

      Il est possible s'il y en a vraiment trop que que le noyau te les refuse, et dans ce cas, effectivement tu ne peux pas grand chose (c'est pour ça que je l'ai testée dans une autre machine moins rapide, et ça fonctionnait nickel : 0 erreurs).
      http://blog.freeside.fr/post/2007/01/10/Recycling-and-the-ar(...)

      Donc lance un memtest, configure le format de sortie pour l'avoir au format badram, laisse le tourner quelques heures, et ajoute ça en paramètres dans ton menu.lst.

      On est déjà dans une société ultra-consumériste, si du matos est récupérable, c'est idiot de le jeter... En plus ce truc là est un des avantages sympa de Linux vs Windows (à moins qu'il n'y ait un équivalent à badram sous Windows dont je n'aurais pas entendu parler ?).

    • [^] # Re: RE

      Posté par  . Évalué à 1.

      Si les adresses sont toutes dans la même plage, pourquoi ne pas perdre un peu plus de mémoire en déclarant toute une plage ?
      Tu peux peut-être aussi aller voir par là :
      http://rick.vanrein.org/linux/badram/

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.