Bonjour, j'ai depuis quelques jours le message suivant : 'Temperature above threshold, cpu clock throttled'.
Bizarrement, il apparaît touiours deux fois, à 10 minutes PILE POIL de décalage, comme ce matin :
 
[extrait de /var/log/messages]

Sauriez-vous me dire comment repérer ce qui cause ce pic de température ? Le contenu de /var/log/messages ne m'apprend rien.
 
Ma config :
Mandriva Spring 2007
Linux localhost 2.6.17-13mdv #1 SMP Fri Mar 23 15:18:36 EDT 2007 x86_64               Intel(R) Pentium(R) 4 CPU 3.40GHz GNU/Linux
 
* carte mère ASUS P5LD2 Deluxe
* Processeur INTEL Pentium 4 650 LGA775 2 Mo (3.4 Ghz)
* 4 Go DDR2 PC6400 800 Mhz
* Disque dur Western Digital 36 Go SATA 10,000t
* Carte graphique NVIDIA 6200TC 64/256Mo PCI-E
 
 
Merci !
 
 

regarde dans ta tour si le ventilo tourne correctement.
nettoyer le rad du processeur et les pales du ventilo.

Mettre des glaçons autour du CPU, ça ira mieux
 
Regardes le contenu de /proc/acpi/thermal_zone/TZ00/temperature aussi

> memaster62 : déjà fait, je n'ai rien vu de spécial
 
Ce qui m'étonne est que la surchauffe intervienne à chaque fois à 10 minutes pétantes : quel programme peut bien se lancer ainsi et faire chauffer mes 2 procs ?

> WedgeAnt : mon répertoire /proc/acpi/thermal_zone existe mais il est vide. Je ne sais pas pourquoi.

Alors /sys/class/hwmon/hwmon0/device/temp1_input ?

Tu peux aussi faire voir le résultat des commandes "lsmod" et "dmesg | grep -i acpi"

> WedgeAnt : /sys/class/hwmon existe mais est vide. [Désolé pour le boulet que je suis mais vous me faites faire des choses auxquelles je ne connais rien...]

tu fais un top pendant 10min et tu regardes quel process fait tourner tes proc au moment de la surchauffe

 
J'essaye de voir les différents fichiers systèmes qui contiennent l'information sur la température du processeur

lsmod :
 

Ok, donc le support cpufreq est activé, ainsi que la gestion des sondes température (s'il y en a ...)

> memaster62 : pour regarder via 'top' les applis qui produisent le pic il faudrait que j'y passe la journée car la surchauffe se produit une ou deux fois par 24 heures (mais deux fois de suite, à 10 minutes d'intervalle). Connais-tu un moyen de conserver les résultats de top dans un fichier pendant 24 heures ?

man top

heureusement, sinon cramage de proc inside sans le vouloir : en plus c'est un p4 : ça chauffe pas mal ces bestiots la

> WedgeAnt : ok, je regarde man top. Dès que j'ai identifié ce qui cause la surchauffe, je vous fais signe.
 
Et merci à vous deux ainsi qu'à ceux qui m'ont lu : ça fait du bien...

Sauf que ça m'explique pas pourquoi le thermal_zone est vide ...

saurais tu regardé dans le cron (lancement auto de procedures à intervalles programmées),
si tu ne trouves pas l'appli/processus qui fait chauffer ton proc.
sinon pour top, je n'ai jamais pratiqué l'archivage de datas : regarde dans le man si c'est possible.

pour archiver le contenu de top :  top -b > top.txt
 
Et top.txt est un fichier txt est un fichier lisible en clair. En gros, toutes les 3 secondes une nouvelle list est ajoutée à la fin du fichier. Par contre celui-ci grossit rapidement.

je suis d'avis d'avoir cpufreq partout pour l'économie d'énergie et le gain en température. noyau maison ou de distrib ?
 
t'as un cacti ou un truc comme ça pour faire des graphs voir ce qui se passe ?
 
ouais enfin bon, y a problème, si toutes les 12H t'as un machin qui se met à manger un peu de CPU et que direct tu passes un seuil, c'est dangereux.

> Taz : mon noyeau est celui de la Mandriva 2007 Spring ( Linux localhost 2.6.17-13mdv #1 SMP Fri Mar 23 15:18:36 EDT 2007 x86_64               Intel(R) Pentium(R) 4 CPU 3.40GHz GNU/Linux  ).
 
Je me renseigne sur cacti.

je savais pas que le p4 3.4 était en 64bits

> memaster62 : on m'aurait menti ??? (  )

C'est p'tet pas un p4 classique, mais il est sans doute répertorié comme p4 par le kernel

c'te question?
quelqu'un pour éluder c't' histoire

edit : ah non chuis con, il existe bel et bien des double proc de p4 sur une meme galette : peut etre 2x32?

Depuis quand 2x32 bits ça fait 64 bits ?  

si on "paralellise" les bus de datas, ça fait un bien 64 nan?
au lieu de stacker sur un reg de 32 tu stack sur 2 reg. de 32 d'où le 64 obtenu.  
 
en outre je ne suis pas spécialiste de l'archi des derniers proc.

bah non, ça fait pas 64
ça fait 2x32 ...
 
tu n'arriveras jamais à stocker des données 64bits dans un bus 2x32, même parallélisées et même en tassant bien fort  

pas le bus mais dans les registres respectifs  
eax du proc1 + eax du proc2 = 64  
 
bon : tu as sans doute raison, je n'ai encore jamais fait de prog. paralellisante

> memaster62 : tu es sérieux quand tu décris deux procs 32 bits comme équivalent pour le kernel à un proc 64 bits ? Si c'est le cas, j'aimerais avoir confirmation. Il y a longtemps je faisais joujou avec l'assembleur x86 et je n'aurais JAMAIS cru qu'un truc aussi monstrueux soit possible.

nan en fait c'est plus que ça : t'as 2 x 8 registres 32 bits => 512bits. Si tu overclocks à une fréquence multiple de PI, ça équivaut à 1,5 bit quantique

j'espere que non , mais en theorie c'est possible de stocker une valeur 64bits sur 2 registres 32bits de même nature.
sinon je vois pas trop à quoi servent certains algorythmes paralellisants.
dans le temps on mettait bien une floppée de proc 16bits sur une même CM, alors je conçois 2 possibilités :
- on threadifie et on distribue des calculs n'ayant rien à voir sur 2 proc distincts
- on paralellise vraiment : on empile les registres de 16 - 32 - 64... pour en avoir des plus grands.