Re: instabilit matrielle
Nicolas wrote: A l'origine, j'ai rencontré une erreur de segmentation lors de la compilation d'un noyau. Ceci m'a ammené à effectuer le test suivant : dd if=/dev/urandom of=/dev/null bs=1M count=10 Des fois ça marche, sinon j'ai des comportements variés : X plante, une appli plante, le système se fige, dd segfault... Pour info pour ceux qui ont suivi, je me suis décidé à racheter de la RAM, et bien sûr, j'ai reproduit les plantages avec la nouvelle barrette, donc la ram est dédouanée. Je penses racheter un CPU, mais j'ai peur de finir par racheter tout le PC à ce rythme là :( -- Nicolas
RE: instabilit matrielle
Je penses qu'il s'agit soit de la RAM (dans ce cas les 2 barrettes sont nazes), soit de la carte mère. J'avais des problèmes de compilation de noyeau et cela venait du processeur. On m'avait indiqué cette page. http://www.bitwizard.nl/sig11/ Le meilleur test pour ton materiel semble la compilation de noyeau. Mickaël
RE: instabilit matrielle
Mickael Vera wrote: Le meilleur test pour ton materiel semble la compilation de noyeau. c'est une compilation de noyau qui m'a laissé soupçonner un problème matériel. J'avais déjà lu cette page web, mais il n'y a pas de recette pour dédouaner la RAM ou le CPU. La seule solution qui me reste est de tester des composants à la place des miens pour trouver le fautif.
Re: instabilit matrielle
Tony Schonfeld wrote: j'ai eu des problemes similaires et comme propose plusieurs fois dans la liste il faut serieusement penser a la ram, oui mais dans mon cas l'astuce est que la ram doit etre testee pendant plusieurs heures ( au moins 4 ou 5 ) et la le verdict sera credible. plus de 12 heures et 27 passes plus tard, 0 erreurs avec memtest86+ ! D'autres idées ?
Re: instabilit matrielle
franky wrote: Tous mes problèmes ont été résolus le jour où j'ai mis à jour le BIOS de ma carte mère. Ce n'est peut-être pas ton problème, mais c'est une piste à ne pas négliger à mon avis. j'ai la dernière mise à jour. Ca pourrait donc bien être un problème de carte mère. Un orage est passé par là il y a deux semaines, c'est peut être l'effet d'une surtension.
Re: instabilit matrielle
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Le samedi 22 Mai 2004 09:49, Nicolas a écrit : Tony Schonfeld wrote: j'ai eu des problemes similaires et comme propose plusieurs fois dans la liste il faut serieusement penser a la ram, oui mais dans mon cas l'astuce est que la ram doit etre testee pendant plusieurs heures ( au moins 4 ou 5 ) et la le verdict sera credible. plus de 12 heures et 27 passes plus tard, 0 erreurs avec memtest86+ ! D'autres idées ? Ton processeur est-il overclocké ? Il y a eu dans cette liste (il me semble) quelqu'un qui avait un problème de compilation du noyau, et après de multiples recherche, il s'est avéré que son processeur overclocké était en cause. Sinon, peut-tu installer les sensors pour vérifier la température de ton uc et de ton cpu. Une surchauffe peut-être à l'origine d'un problème tel que celui-ci. Si tu ne peut pas installer les sensors, réitère le test quand ton pc est froid, lorsque tu vient juste de l'allumer et que tu n'a pas fait tourné de grosses applications. Au pire des cas, tu peut ouvrir le pc et toucher le radiateur du cpu quand ton pc est en marche depuis quelques heures. Mais attention : certains pc sont fait pour avoir un refroidissement optimal lorsqu'ils sont FERMÉS, il font donc bien connaître son pc avant de faire cela (j'ai faillit griller un 486 comme ça). Florent -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFArzMjM+Ix3/RCm3gRApPRAJ9p55eadNNkCaCYJzO/zbJyWVVqSQCgm4ZX F0SYzJchpLkr/b6WOBAHgGM= =H3Ho -END PGP SIGNATURE-
Re: instabilit matrielle
Florent Bayle wrote: Ton processeur est-il overclocké ? Il y a eu dans cette liste (il me semble) quelqu'un qui avait un problème de compilation du noyau, et après de multiples recherche, il s'est avéré que son processeur overclocké était en cause. Du tout, XP 1900+ en utilisation normale. J'utilisais athcool, j'ai cru un moment que le problème venait de là, mais même sans le problème persiste. Sinon, peut-tu installer les sensors pour vérifier la température de ton uc et de ton cpu. Une surchauffe peut-être à l'origine d'un problème tel que celui-ci. Si tu ne peut pas installer les sensors, réitère le test quand ton pc est froid, lorsque tu vient juste de l'allumer et que tu n'a pas fait tourné de grosses applications. Le problème apparait à chaud ou à froid. J'ai un ventillo de proc réglable, un ventillo de tour réglable, j'ai bien tenté de les pousser à fond (cpu = 30°, systeme = 28°), ça n'y fait rien. J'ai posé la main dessus pour être sûr, y'a pas à dire, c'est froid. Encore tout à l'heure j'ai vu mon gkrellm disparaitre alors que j'encodais du ogg, chose qui m'était déjà arrivée avec l'exemple du dd. Je penses qu'il s'agit soit de la RAM (dans ce cas les 2 barrettes sont nazes), soit de la carte mère. -- Nicolas
instabilit matrielle
Bonjour, je penses avoir un problème d'ordre matériel, étant donné que j'ai reproduit ce problème sur la debian testing, et sur différents cd live (knoppix et dinebolix) : A l'origine, j'ai rencontré une erreur de segmentation lors de la compilation d'un noyau. Ceci m'a ammené à effectuer le test suivant : dd if=/dev/urandom of=/dev/null bs=1M count=10 Des fois ça marche, sinon j'ai des comportements variés : X plante, une appli plante, le système se fige, dd segfault... Je pensais à un problème de barrette de RAM (2 x 256Mo PC2100), j'ai donc reitéré le test en ne gardant qu'une barrette, puis l'autre : tout marche. J'ai remis les barrettes en changeant l'ordre, ça marche aussi. Malheureusement, le problème est réaparu la semaine suivante. Et là, les différentes combinaisons mènent toutes à un echec. J'ai testé les barrettes avec mentest+ pendant une bonne heure, aucun problème de relevé. La question : ce problème peut il venir d'ailleurs : CPU (palomino), carte mère (epox KHA+)... et comment diagnostiquer ? (avant d'acheter un composant de rechange). Pour info la même commande utilisant /dev/zero en entrée fonctionne correctement. -- Nicolas
Re: instabilit matrielle
Nicolas a écrit : [...] Des fois ça marche, sinon j'ai des comportements variés : X plante, une appli plante, le système se fige, dd segfault... Je pensais à un problème de barrette de RAM (2 x 256Mo PC2100), j'ai donc reitéré le test en ne gardant qu'une barrette, puis l'autre : tout marche. J'ai remis les barrettes en changeant l'ordre, ça marche aussi. As-tu fait le test avec les 2 barrettes ensemble ? Et, pour memtest, je ne suis pas certain qu'une heure soit suffisante pour se faire une idéee... Surtout s'il n'est pas lancé d'une disquette (mais là, c'est memtest86) = en général, je laisse tourner la machine une nuit entière. Claude
Re: instabilit matrielle
Nicolas wrote: Bonjour, je penses avoir un problème d'ordre matériel, étant donné que j'ai reproduit ce problème sur la debian testing, et sur différents cd live (knoppix et dinebolix) : A l'origine, j'ai rencontré une erreur de segmentation lors de la compilation d'un noyau. Ceci m'a ammené à effectuer le test suivant : dd if=/dev/urandom of=/dev/null bs=1M count=10 Des fois ça marche, sinon j'ai des comportements variés : X plante, une appli plante, le système se fige, dd segfault... Je pensais à un problème de barrette de RAM (2 x 256Mo PC2100), j'ai donc reitéré le test en ne gardant qu'une barrette, puis l'autre : tout marche. J'ai remis les barrettes en changeant l'ordre, ça marche aussi. Malheureusement, le problème est réaparu la semaine suivante. Et là, les différentes combinaisons mènent toutes à un echec. J'ai testé les barrettes avec mentest+ pendant une bonne heure, aucun problème de relevé. La question : ce problème peut il venir d'ailleurs : CPU (palomino), carte mère (epox KHA+)... et comment diagnostiquer ? (avant d'acheter un composant de rechange). Pour info la même commande utilisant /dev/zero en entrée fonctionne correctement. Nicolas, j'ai eu des problemes similaires et comme propose plusieurs fois dans la liste il faut serieusement penser a la ram, oui mais dans mon cas l'astuce est que la ram doit etre testee pendant plusieurs heures ( au moins 4 ou 5 ) et la le verdict sera credible. Bonne chance
Re: instabilit matrielle
Tony Schonfeld wrote: j'ai eu des problemes similaires et comme propose plusieurs fois dans la liste il faut serieusement penser a la ram, oui mais dans mon cas l'astuce est que la ram doit etre testee pendant plusieurs heures ( au moins 4 ou 5 ) et la le verdict sera credible. OK j'essaye cette nuit et je poste le résultat, merci. -- Nicolas
Re: instabilit matrielle
claude wrote: As-tu fait le test avec les 2 barrettes ensemble ? oui, j'ai fait toutes les combinaisons. Si j'ai un problème de RAM, je l'ai sur les deux barrettes. Et, pour memtest, je ne suis pas certain qu'une heure soit suffisante pour se faire une idéee... Surtout s'il n'est pas lancé d'une disquette (mais là, c'est memtest86) = en général, je laisse tourner la machine une nuit entière. je boote dessus via grub, je vais tenter de le faire tourner cette nuit. -- Nicolas
Re: instabilit matrielle
Le vendredi 21 Mai 2004 04:15, Nicolas a écrit : Bonjour, je penses avoir un problème d'ordre matériel, étant donné que j'ai reproduit ce problème sur la debian testing, et sur différents cd live (knoppix et dinebolix) : A l'origine, j'ai rencontré une erreur de segmentation lors de la compilation d'un noyau. Ceci m'a ammené à effectuer le test suivant : dd if=/dev/urandom of=/dev/null bs=1M count=10 Des fois ça marche, sinon j'ai des comportements variés : X plante, une appli plante, le système se fige, dd segfault... Je pensais à un problème de barrette de RAM (2 x 256Mo PC2100), j'ai donc reitéré le test en ne gardant qu'une barrette, puis l'autre : tout marche. J'ai remis les barrettes en changeant l'ordre, ça marche aussi. Malheureusement, le problème est réaparu la semaine suivante. Et là, les différentes combinaisons mènent toutes à un echec. J'ai testé les barrettes avec mentest+ pendant une bonne heure, aucun problème de relevé. La question : ce problème peut il venir d'ailleurs : CPU (palomino), carte mère (epox KHA+)... et comment diagnostiquer ? (avant d'acheter un composant de rechange). Pour info la même commande utilisant /dev/zero en entrée fonctionne correctement. -- Nicolas Bonsoir, J'ai longtemps eu des problèmes de stabilité avec ma Debian, se traduisant notamment par plantages intempestifs de Mozilla. Lorsque j'ai voulu installer une Gentoo sur une autre partition, impossible de terminer la compilation sans que ça se termine par un crash de gcc ! Memtest86 n'a jamais détecté aucun problème (24 heures de test non stop). Tous mes problèmes ont été résolus le jour où j'ai mis à jour le BIOS de ma carte mère. Ce n'est peut-être pas ton problème, mais c'est une piste à ne pas négliger à mon avis. A+ -- Franky
