je suis sous FreeBSD 4.8 que j'utilise actuellement en tant que desktop
(très stable). ma machine freeze parfois sous x sans raison apparente, et
je n'arrive pas à trouver la cause de ces plantages : je n'étais pas devant
la machine la dernière fois que cela s'est produit, et j'ai retrouvé mon
écran gelé avec mon screensaver. il n'y a rien qui signale un quelconque
plantage dans /var/log/messages ou bien dans XFree86.0.log...
quelqu'un peut m'aider ? où trouver des infos sur le plantage à part
/var/log ?
merci d'avance
ps : un indice important : ça arrive pendant que je rippe un dvd avec
gmencoder
On Tue, 24 Aug 2004 19:16:26 +0200 ferdydurke disait:
bonjour,
après vérifications du hardware monitor de mon bios : (athlon xp 2000+ en charge maxi, dvdrip, routage internet, surf, musique)
- température processeur = 56° C (redescend à 50 environ après rip, en été donc... 47° C en hiver)
- température carte mère = 33° C
bref des valeurs loin d'être scandaleuses d'après quelques recherches sur le web, et qui invalide la thèse de la chauffe CPU lors d'un ripping avec gmencoder ?
Ca l'invalide assez oui ... Maintenant il faudrait regarder la carte vidéo, même si elle bosse pas plus que ca, ca se peut qu'elle surchauffe. Apres il faut regarder la RAM... avec un coup de memtest86 par exemple ...
merci pour la réponse,
je pense que vous avez trouvé la cause de ma panne : j'avais complètement oublié, mais j'ai enlevé le ventilateur de ma radeon cet hiver, afin que ma machine soit plus silencieuse... cqfd donc une surchauffe de carte graphique peut freezer un système BSD sous x sans aucun fichier de log ? je vais quand même tester ma RAM avec ce fameux memtest86.
Martin wrote:
On Tue, 24 Aug 2004 19:16:26 +0200
ferdydurke <ferdy@ferdy.com> disait:
bonjour,
après vérifications du hardware monitor de mon bios :
(athlon xp 2000+ en charge maxi, dvdrip, routage internet, surf,
musique)
- température processeur = 56° C (redescend à 50 environ après rip, en
été donc... 47° C en hiver)
- température carte mère = 33° C
bref des valeurs loin d'être scandaleuses d'après quelques recherches
sur le web, et qui invalide la thèse de la chauffe CPU lors d'un
ripping avec gmencoder ?
Ca l'invalide assez oui ...
Maintenant il faudrait regarder la carte vidéo, même si elle bosse pas
plus que ca, ca se peut qu'elle surchauffe. Apres il faut regarder la
RAM... avec un coup de memtest86 par exemple ...
merci pour la réponse,
je pense que vous avez trouvé la cause de ma panne : j'avais complètement
oublié, mais j'ai enlevé le ventilateur de ma radeon cet hiver, afin que ma
machine soit plus silencieuse... cqfd
donc une surchauffe de carte graphique peut freezer un système BSD sous x
sans aucun fichier de log ?
je vais quand même tester ma RAM avec ce fameux memtest86.
On Tue, 24 Aug 2004 19:16:26 +0200 ferdydurke disait:
bonjour,
après vérifications du hardware monitor de mon bios : (athlon xp 2000+ en charge maxi, dvdrip, routage internet, surf, musique)
- température processeur = 56° C (redescend à 50 environ après rip, en été donc... 47° C en hiver)
- température carte mère = 33° C
bref des valeurs loin d'être scandaleuses d'après quelques recherches sur le web, et qui invalide la thèse de la chauffe CPU lors d'un ripping avec gmencoder ?
Ca l'invalide assez oui ... Maintenant il faudrait regarder la carte vidéo, même si elle bosse pas plus que ca, ca se peut qu'elle surchauffe. Apres il faut regarder la RAM... avec un coup de memtest86 par exemple ...
merci pour la réponse,
je pense que vous avez trouvé la cause de ma panne : j'avais complètement oublié, mais j'ai enlevé le ventilateur de ma radeon cet hiver, afin que ma machine soit plus silencieuse... cqfd donc une surchauffe de carte graphique peut freezer un système BSD sous x sans aucun fichier de log ? je vais quand même tester ma RAM avec ce fameux memtest86.
Miod Vallat
donc une surchauffe de carte graphique peut freezer un système BSD sous x sans aucun fichier de log ?
Évidemment. N'importe quel système électronique peut mal se comporter sans que cela déclenche la moindre alarme.
Surtout si lesdites alarmes sont électroniques et partie prenante du système...
Ceci dit, personne n'a voulu me croire le jour où j'ai fait planter un 68020 - après tout, il n'y avait que 65 C en surface de la céramique...
[En fait, je pense que personne de nos jours ne sait faire chauffer autant un 68020]
donc une surchauffe de carte graphique peut freezer un système BSD sous x
sans aucun fichier de log ?
Évidemment. N'importe quel système électronique peut mal se comporter
sans que cela déclenche la moindre alarme.
Surtout si lesdites alarmes sont électroniques et partie prenante du
système...
Ceci dit, personne n'a voulu me croire le jour où j'ai fait planter un
68020 - après tout, il n'y avait que 65 C en surface de la céramique...
[En fait, je pense que personne de nos jours ne sait faire chauffer
autant un 68020]
donc une surchauffe de carte graphique peut freezer un système BSD sous x sans aucun fichier de log ?
Évidemment. N'importe quel système électronique peut mal se comporter sans que cela déclenche la moindre alarme.
Surtout si lesdites alarmes sont électroniques et partie prenante du système...
Ceci dit, personne n'a voulu me croire le jour où j'ai fait planter un 68020 - après tout, il n'y avait que 65 C en surface de la céramique...
[En fait, je pense que personne de nos jours ne sait faire chauffer autant un 68020]
Paul Gaborit
À (at) Thu, 26 Aug 2004 23:25:37 +0200, ferdydurke écrivait (wrote):
je vais quand même tester ma RAM avec ce fameux memtest86.
Par expérience, un bon 'make -j 4 buildworld' ou 'make buildkernel' est souvent plus rapide et plus efficace que memtest86 pour détecter des erreurs mémoires. Par contre, ça ne vous indique pas la barette défectueuse.
-- Paul Gaborit - <http://www.enstimac.fr/~gaborit/>
À (at) Thu, 26 Aug 2004 23:25:37 +0200,
ferdydurke <ferdy@ferdy.com> écrivait (wrote):
je vais quand même tester ma RAM avec ce fameux memtest86.
Par expérience, un bon 'make -j 4 buildworld' ou 'make buildkernel' est
souvent plus rapide et plus efficace que memtest86 pour détecter des erreurs
mémoires. Par contre, ça ne vous indique pas la barette défectueuse.
--
Paul Gaborit - <http://www.enstimac.fr/~gaborit/>
À (at) Thu, 26 Aug 2004 23:25:37 +0200, ferdydurke écrivait (wrote):
je vais quand même tester ma RAM avec ce fameux memtest86.
Par expérience, un bon 'make -j 4 buildworld' ou 'make buildkernel' est souvent plus rapide et plus efficace que memtest86 pour détecter des erreurs mémoires. Par contre, ça ne vous indique pas la barette défectueuse.
-- Paul Gaborit - <http://www.enstimac.fr/~gaborit/>
Arnaud Launay
Le Fri, 27 Aug 2004 11:40:37 +0200, Paul Gaborit écrivit:
Par expérience, un bon 'make -j 4 buildworld' ou 'make buildkernel' est souvent plus rapide et plus efficace que memtest86 pour détecter des erreurs mémoires. Par contre, ça ne vous indique pas la barette défectueuse.
Le Fri, 27 Aug 2004 11:40:37 +0200, Paul Gaborit écrivit:
Par expérience, un bon 'make -j 4 buildworld' ou 'make buildkernel' est
souvent plus rapide et plus efficace que memtest86 pour détecter des erreurs
mémoires. Par contre, ça ne vous indique pas la barette défectueuse.
Le Fri, 27 Aug 2004 11:40:37 +0200, Paul Gaborit écrivit:
Par expérience, un bon 'make -j 4 buildworld' ou 'make buildkernel' est souvent plus rapide et plus efficace que memtest86 pour détecter des erreurs mémoires. Par contre, ça ne vous indique pas la barette défectueuse.