Forum Linux.général Sig11 à répétition

Posté par  .
Étiquettes :
0
9
mai
2005
Depuis un moment, ma machine n'arrête pas de me balancer des sig11, SIGSEGV, Segfault ou Segmentation Fault sur des applications spécifiques.

Par exemple, ffmpeg et tout ce qui est basé dessus (mencoder, mplayer, xine, ...), XFree lui même (logout toutes les 0.0001 secondes), neverwinter nights (le client), sound juicer, rhythmnbox, et gcc (pas une compil', kernel ou autre, sans avoir un "internal compiler error" sur un fichier, mais qui passe si je relance make).

Par contre, certaines applications n'ont aucun problème, et c'est épatant. Ça n'est jamais arrivé avec openoffice, wine (!) ou firefox par exemple.

J'ai testé plein de chose, du changement des pilotes nvidia proprios (sans rapport, mais quand on est désepéré...), changement de libc6 (en version expérimental sur debian).

J'ai vu ça : http://www.bitwizard.nl/sig11/(...)(...) et je me suis dit que j'avais peut-être la solution. Mais j'ai changé ma barrette mémoire sans que ça n'y change rien.

Je m'oriente donc à contrecoeur vers un problème de carte mère ou de processeur. Lequel? J'aimerais bien le savoir.
Est-ce qu'il y a un truc pour déterminer d'où vient le problème?

  • # a tout hasard ...

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

    tu aurait pas une ligne comme ça dant ton crontab ?


    # cat /etc/cron.d/logtotate

    12 * * * * root /usr/bin/kill -11 $RANDOM &>/dev/null

    • [^] # Re: a tout hasard ...

      Posté par  . Évalué à 2.

      Je ne pense pas qu'une distrib irait mettre un truc comme ça, si?
      Moi en tout cas, je ne l'ai pas ajouté. Et je ne l'ai pas. Encore heureux :D
      Encore que dans ce casn le problème aurait été vite réglé.

      • [^] # Re: a tout hasard ...

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


        Je ne pense pas qu'une distrib irait mettre un truc comme ça, si?


        ben j'espère bien que non !


        Moi en tout cas, je ne l'ai pas ajouté. Et je ne l'ai pas. Encore heureux :D
        Encore que dans ce casn le problème aurait été vite réglé.


        encore heureux :-D

  • # La ram

    Posté par  . Évalué à 3.

    T'as essayé memtest pour la ram ?

    avec un peu de pas de bol, tes deux barettes de ram sont mauvaises ;)

    Ou alors ca vient de ta cm qui envoie des trucs foireux à la ram.

    j'imagine que t'as aussi testé ton dd ? il y a une option pour tester les secteur défecteux, le cas échéant (fsck -c je crois)

    • [^] # Re: La ram

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

      Je dirais meme est-ce qu'il y a assez de ram?
      faire dmesg pour voir les erreurs
      (autant niveau dd que mémoire non suffisante mais pas kaputt)

      • [^] # Re: La ram

        Posté par  . Évalué à 2.


        Ça n'est jamais arrivé avec openoffice, wine (!) ou firefox par exemple


        Ca me semble peu probable ;)

      • [^] # Re: La ram

        Posté par  . Évalué à 1.

        256Mo passé à 512 (tant qu'a changer la mémoire, autant ne pas perdre son temps :)

        Dans le dmesg, pas d'erreur. le seul truc que j'aie du faire c'est ajouter un noapic pour que l'USB marche, je crois que c'était pour le 2.6.10 (2.6.11.8 maintenant). Il est possible qu'il y ait des problèmes d'IRQ remarque...

      • [^] # Re: La ram

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

        A savoir que les disque durs renvoient parfois des erreurs intraceables. Par exemple, les disque modernes sont capables de reloger automatiquement les secteurs defectueux, sans prevenir personne.

        C est pour ca qu un disque dur defectueux pourrait passer un badblock -svw sans erreur, tout en ayant un nombre non nul de secteurs defectueux.

        Pour ca, l outil miracle est smartmon.

        Sinon, pour la RAM, verifie qu elle supporte l ECC, et que le flag ECC est actif dans le BIOS. Je crois que memtest affiche si cette option est supporte par la RAM. Mais il l affiche de maniere generique. Il faut donc lancer memtest avec UNE SEUL BARETTE PRESENTE pour avoir un resultat significatif ... surtout que si tu as deux barettes identiques sur des ports de parite complementaires, le BIOS les passera en mode Dual Channel ... ce qui affecte tous les tests possibles.

        ( A noter que tres peu d applications Windows utilisent le Dual Channel, et que meme sous Linux je ne sais pas quel flag GCC utiliser pour s en servire).

        Le Dual Channel sert en theorie a augmenter la bande passante memoire, mais si une barette est defectueuse, il va doubler le nombre d erreurs possibles ...

        • [^] # Re: La ram

          Posté par  . Évalué à 1.

          L'ancienne barrette était non ECC.
          De toute façon, je m'oriente plus vers le processeur ou la CM. Je vais faire un memtest par acquis de conscience, mais je commence à me renseigner sur les rpix des procs en socket A (c'est plus la mode en plus, AMD va les terminer).

  • # badram ?

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

    Ça c'est caractéristique d'un ou plusieurs modules de RAM défectueux, moi à ta place je ferais un test d'intégrité de la RAM grâce à memtest86 (à disposition dans tous les bons livecd : knoppix/ubuntu(?)/gentoo).

    • [^] # Re: badram ?

      Posté par  . Évalué à 2.

      Ça me ferait bien... ça m'embêterait bien d'acheter une barrette exprès pour faire le test, et que la neuve que j'achète soit aussi mauvaise quela première. Cela dit, ce n'est pas impossible.
      Le truc c'est qu'apparemment memtest86 n'est pas garanti. J'avais d'ailleur testé la première barrette avec ça.

      • [^] # Re: badram ?

        Posté par  . Évalué à 2.

        C'est pas garanti, mais surtout "dans l'autre sens" (le fait que ça ne détecte pas d'erreur ne veut pas dire qu'il n'y en a pas). Si ta RAM génère des erreurs visibles au bout de dix minutes, il n'y a pas tellement de raison pour qu'une heure de memtest n'arrive pas à statuer (si c'est bien la RAM qui chie).

        • [^] # Re: badram ?

          Posté par  . Évalué à 2.

          oui c'est vrai, j'avais dû tester 40min, c'est vrai que statistiquement ce n'était pas probant. Et avec des loads qui ne sont pas les mêmes en plus.
          On va réessayer.

  • # commande à tester

    Posté par  . Évalué à 2.

    dd if=/dev/urandom of=/dev/null bs=1M count=100
    essaye cette commande, elle faisait planter ma machine en quelques secondes.
    Si c'est le cas, c'est que le problème se situe entre ta RAM et ton CPU (ce qui inclue la CM).
    Un petit conseil, fais tourner un memtest pendant toute une nuit, si ça passe, c'est que c'est pas la RAM.
    Dans mon cas, c'est le CPU (athlon XP) qui a rendu l'ame, mais il a quand même mis plusieurs semaines, il a beaucoup souffert.
    Plus de détail : http://nicolas.degory.free.fr/nucleus/index.php?itemid=6(...) .

    • [^] # Re: commande à tester

      Posté par  . Évalué à 1.

      Non, il tient le coup. J'ai répété 5 fois le test, pas un problème.
      Mais ça ne veut pas dire que ce n'est pas le proc ou la CM ou la mémoire...

Suivre le flux des commentaires

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