Sous-cadencement du processeur (à cause de la température?)

Hello (Debian-fr) world!

(Ceci est le 17.000ème sujet de la section support, j’ai gagné quoi?)

Description du problème: mon PC portable (sous Debian testing et quelques paquets d’unstable) est devenu anormalement lent depuis quelques jours (moins d’une semaine), à cause d’un sous-cadencement du CPU.

Il est équipé d’un processeur Pentium-M à 2GHz, mais celui-ci s’obstine à tourner à 600MHz, ce qui effondre les performances et rend atrocement lent son usage.

Or je suis en train de travailler sur un site avec Joomla, ce qui implique IceWeasel (FireFox), Apache, MySQL, PHP, Joomla et ses modules en parallèle, donc nécessite la pleine puissance du CPU. Ce problème m’a déjà fait perdre deux jours de boulot la semaine dernière… (autrement dit il n’est pas anodin pour moi!)

Je précise qu’était installé depuis plusieurs mois powersaved et que ce dernier gérait correctement le cadencement du CPU, il descendait à 600MHz quand il n’avait rien à faire, mais remontait à 2GHz quand la charge le nécessitait.

Pour l’anecdote, avec juste un IceDove/Thunderbird et un IceWeasel/FireFox ouvert avec 5 onglets sur des pages statiques sans animations, le CPU (à 600Mhz donc) est à 100% et la charge processeur est à environ 2,5!

Je ne sais pas trop ce qui a pu changer au cours de la semaine écoulée, j’ai pensé à deux hypothèses:
[] une mise à jour logicielle (aptitude update; aptitude safe-upgrade…) installant une version boguée de powersaved ou autre composant de la chaîne de gestion du cadencement du CPU, de la température et des batteries…
[
] la chaleur ambiante (environ 25 degrés dans le bâtiment) qui ferait dépasser un seuil thermique et déclencherait la réduction du cadencement CPU…
ou une combinaison des deux! (Murphy, quand tu nous tiens…)

Je précise que depuis j’ai désinstallé powersaved et installé à la place cpufreqd, ce qui n’a rien changé, pas plus que l’installation de cpudyn d’ailleurs (les trois étant incompatibles). J’ai une préférence pour powersaved qui fournit la commande powersave

En particulier, ce qui m’intrigue est la chose suivante:

tuxo:~# cpufreq-info cpufrequtils 005: cpufreq-info (C) Dominik Brodowski 2004-2006 Veuillez rapportez les erreurs et les bogues à cpufreq@vger.kernel.org, s'il vous plait. analyse du CPU 0 : pilote : acpi-cpufreq CPUs qui doivent changer de fréquences en même temps : 0 limitation matérielle : 600 MHz - 2.00 GHz plage de fréquence : 2.00 GHz, 1.80 GHz, 1.60 GHz, 1.40 GHz, 1.20 GHz, 1000 MHz, 800 MHz, 600 MHz régulateurs disponibles : powersave, userspace, conservative, ondemand, performance tactique actuelle : la fréquence doit être comprise entre 600 MHz et 600 MHz. Le régulateur "performance" est libre de choisir la vitesse dans cette plage de fréquences. la fréquence actuelle de ce CPU est 600 MHz (vérifié par un appel direct du matériel). des statistique concernant cpufreq:2.00 GHz:1,28%, 1.80 GHz:0,00%, 1.60 GHz:0,76%, 1.40 GHz:0,00%, 1.20 GHz:0,00%, 1000 MHz:0,00%, 800 MHz:0,00%, 600 MHz:97,95% (14)
Commentaires: le PC portable étant branché sur le secteur, la gestion d’énergie est en mode “performance” (plutôt que “powersave” quand il est sur batterie). Jusque là tout va bien.
Par contre ce qui est bizarre, c’est que la “plage” de fréquence est restreinte à la plus basse possible, sans que je sache pourquoi ni ne comprenne quel logiciel la fixe (on dirait que c’est indépendant du gestionnaire cpufreqd ou powersaved). J’ai pensé un moment à la couche de gestion ACPI (acpid), mais rien dans les fichiers de config ne me permet d’en savoir plus.

Et si j’essaye ce qui suit:

[code]tuxo:~# cpufreq-set --max 2Ghz
tuxo:~# cpufreq-set --min 2Ghz
En ajustant les nouveaux paramètres, une erreur est apparue. Les sources
d’erreur typique sont :

  • droit d’administration insuffisant (êtes-vous root ?) ;
  • le régulateur choisi n’est pas disponible, ou bien n’est pas disponible en
    tant que module noyau ;
  • la tactique n’est pas disponible ;
  • vous voulez utiliser l’option -f/–freq, mais le régulateur « userspace »
    n’est pas disponible, par exemple parce que le matériel ne le supporte
    pas, ou bien n’est tout simplement pas chargé.[/code]
    alors cpufreq-info rend le même résultat que ci-dessus.

Commentaires: il est étonnant qu’après avoir fixé la valeur max de la plage de fréquence à 2Ghz, celle-ci apparaisse à nouveau à 600Mhz.
Mais ce qui est encore plus étrange, c’est qu’il n’est même pas possible de fixer la valeur min!

Quelqu’un peut m’expliquer ce qui se passe?

tuxo:~# dpkg -l acpi-support acpi-support-base cpufreqd cpufrequtils hal linux-image-2.6.30-1-686 Souhait=inconnU/Installé/suppRimé/Purgé/H=à garder | État=Non/Installé/fichier-Config/dépaqUeté/échec-conFig/H=semi-installé/W=attend-traitement-déclenchements |/ Err?=(aucune)/H=à garder/besoin Réinstallation/X=les deux (État,Err: majuscule=mauvais) ||/ Nom Version Description +++-=========================================-=========================================-================================================================================================== ii acpi-support 0.123-1 scripts for handling many ACPI events ii acpi-support-base 0.123-1 scripts for handling base ACPI events such as the power button ii cpufreqd 2.3.3-4 fully configurable daemon for dynamic frequency and voltage scaling ii cpufrequtils 005-1 utilities to deal with the cpufreq Linux kernel feature ii hal 0.5.12~git20090406.46dc48-2 Hardware Abstraction Layer ii linux-image-2.6.30-1-686 2.6.30-1 Linux 2.6.30 image on PPro/Celeron/PII/PIII/P4 tuxo:~# uname -a Linux tuxo 2.6.30-1-686 #1 SMP Sun Jun 14 16:11:32 UTC 2009 i686 GNU/Linux

Une idée :bulb: : tu as un noyau 2.6.30. Les softs de gestion d’énergie que tu utilises sont ils compatibles avec cette version ?

Effectivement, ça pourrait être une idée pertinente: cette nuit après avoir posté mon message j’ai réinstallé linux-image-2.6.26-2-686 et redémarré dessus, et pfuit! plus de problème (mais par contre le CPU était presque tout le temps à 2Ghz, même quand il n’avait rien à faire, alors que j’avais mis la limite basse à 1GHz…)

Par contre ce matin, une fois redémarré sur le noyau 2.6.26-2-686, le problème est à nouveau présent! C’est à n’y rien comprendre…

Cependant je viens d’observer (car cela vient de se passer) un phénomène curieux: juste après le démarrage, la fréquence du CPU variait normalement entre 0,6Hz et 2Ghz (plus particulièrement entre 1,4GHz et 2GHz car anacron a lancé des tâches), mais à partir du moment où le ventilateur s’est mis à tourner, la fréquence est à nouveau scotchée à 600MHz… Argh!

Anyone?

tuxo:~# dpkg -l linux-image-2.6.26-2-686 Souhait=inconnU/Installé/suppRimé/Purgé/H=à garder | État=Non/Installé/fichier-Config/dépaqUeté/échec-conFig/H=semi-installé/W=attend-traitement-déclenchements |/ Err?=(aucune)/H=à garder/besoin Réinstallation/X=les deux (État,Err: majuscule=mauvais) ||/ Nom Version Description +++-=========================================-=========================================-================================================================================================== ii linux-image-2.6.26-2-686 2.6.26-17 Linux 2.6.26 image on PPro/Celeron/PII/PIII/P4 tuxo:~# uname -a Linux tuxo 2.6.26-2-686 #1 SMP Sun Jun 21 04:57:38 UTC 2009 i686 GNU/Linux

Salut,

Logique :

Si le ventilateur se met à tourner, c’est que çà chauffe et si çà chauffe il est temps de freiner la fréquence CPU.

Essayes d’améliorer la ventilation : nettoyage du ventilo, adjonction d’une tablette, mettre la bête sur des pieds permettant de le décoller du sol …

Logique: dans le principe, oui. Mais le réglage du sous-cadencement est trop violent, là le CPU est à peine à 43 degrés C, ce qui n’est pas du tout excessif (en général il est plutôt vers 46-48 degrés C), mais le PC est quasi-inutilisable. :frowning:

J’essayerai en dernier recours, mais là le problème me paraît plus clairement logiciel.

D’ailleurs est-ce que quelqu’un(e) sait quel processus fixe la plage de fréquences du CPU? (Je n’arrive pas à trouver l’info. :confused: )

Que te donne

[code]# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors

cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies

grep “=” /etc/init.d/cpufrequtils | grep “^[A-Z]”[/code]

Les deux premières commandes me donnent la même chose que la sortie de la commande cpufreq-info citée dans mon premier message, mais la dernière donne une réponse intéressante concernant les paramètres MAX_SPEED et MIN_SPEED…

tuxo:~# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors ondemand powersave userspace conservative performance tuxo:~# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies 2000000 1800000 1600000 1400000 1200000 1000000 800000 600000 tuxo:~# grep "=" /etc/init.d/cpufrequtils | grep "^[A-Z]" DESC="CPUFreq Utilities" PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin CPUFREQ_SET=/usr/bin/cpufreq-set CPUFREQ_INFO=/usr/bin/cpufreq-info CPUFREQ_OPTIONS="" ENABLE="true" GOVERNOR="ondemand" MAX_SPEED="0" MIN_SPEED="0" CPUS=$(cat /proc/stat|sed -ne 's/^cpu\([[:digit:]]\+\).*/\1/p') RETVAL=0
Q: ça change quelque chose que les params MAX/MIN_SPEED soient à la valeur “0” plutôt que 0 (sans les guillemets…)?

Dans le fichier /etc/init.d/cpufrequtils au-dessus de la série de paramètres CPUFREQ_* se trouve le commentaire suivant:

[code]# Which governor to use. Must be one of the governors listed in:

cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors

and which limits to set. Both MIN_SPEED and MAX_SPEED must be values

listed in:

cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies

a value of 0 for any of the two variables will disabling the use of

that limit variable.

WARNING: the correct kernel module must already be loaded or compiled in.

Set ENABLE to “true” to let the script run at boot time.

eg: ENABLE=“true”

GOVERNOR=“ondemand”

MAX_SPEED=1000

MIN_SPEED=500[/code]

La valeur 0 (mais peut-être pas “0” pour les MAX/MIN_SPEED ne devrait donc pas être handicapante.

À tout hasard j’ai édité le fichier (ce que je n’avais jamais fait auparavant, je ne touche jamais aux fichiers de /etc/init.d) en mettant

[code]MAX_SPEED=2000000
MIN_SPEED=600000[code]
puis

sans aucun effet. :frowning:
Je vais redémarrer au cas où les paramètres ne soient fixables qu’au démarrage (?!?).

Essaye de changer la ligne
GOVERNOR="ondemand"
en
GOVERNOR=“performance”

Je pense que tu as mis le doigt sur le problème.
La baisse de cadence n’est pas due à une sous charge, mais à une surchauffe (en tout cas vue du soft qui gére la température)
Tu dois avoir quelque part un fichier de paramètre qui détermine à quelle température la frequ CPU doit baisser, en plus de la mise en route du ventilo.
J’avais déjà remarqué dans ton 1er post que ton proc avait fonctionné pendant un petit moment à 2 Ghz, probablement le temps de montée en température.

Regarde aussi dans le BIOS si il ne prendrait pas la main sur ce point.

[quote=“fran.b”]Essaye de changer la ligne
GOVERNOR="ondemand"
en
GOVERNOR=“performance”[/quote]
C’est fait, je relance le script, ça n’a pas d’effet… (Tu noteras que j’ai déjà essayé tous les gestionnaires/governors possibles, sans aucun effet, car c’est la plage de fréquence qui est trop limitée).

[quote=“piratebab”]Je pense que tu as mis le doigt sur le problème.
La baisse de cadence n’est pas due à une sous charge, mais à une surchauffe (en tout cas vue du soft qui gére la température)[/quote]
C’est aussi ce que je crois.

Oui, je suppose, mais où à votre avis?
Rien dans la config de powersaved ou acpid

Yep.

Je vais regarder mais sans conviction car c’est le troisième été que j’ai ce PC (Dell Latitude D800) et je n’ai jamais eu ce problème (d’habitude le clavier devient brûlant mais le CPU tient la charge!)
Édit: rien dans le BIOS ne parle de température, il n’y a qu’une option de désactivation d’Intel SpeedStep (le CPU étant alors cadencé à 600MHz, non merci!)

À tout hasard je vais désactiver le i8kmon (dédié à la gestion des ventilos des Dell Inspiron & Latitude), mais cela fait des mois qu’il est installé, sans problème (et il a déjà fait chaud ici au cours du printemps).

PS: bonne nouvelle, après un redémarrage, le changement dynamique de fréquence refonctionne!

Y compris après avoir remis 0 (et non “0”) comme valeur des params MAX/MIN_SPEED de /etc/init.d/cpufrequtils et redémarré avec le noyau 2.6.30…

phil@tuxo:~$ uname -r 2.6.30-1-686 phil@tuxo:~$ cpufreq-info cpufrequtils 005: cpufreq-info (C) Dominik Brodowski 2004-2006 Veuillez rapportez les erreurs et les bogues à cpufreq@vger.kernel.org, s'il vous plait. analyse du CPU 0 : pilote : acpi-cpufreq CPUs qui doivent changer de fréquences en même temps : 0 limitation matérielle : 600 MHz - 2.00 GHz plage de fréquence : 2.00 GHz, 1.80 GHz, 1.60 GHz, 1.40 GHz, 1.20 GHz, 1000 MHz, 800 MHz, 600 MHz régulateurs disponibles : powersave, userspace, conservative, ondemand, performance tactique actuelle : la fréquence doit être comprise entre 600 MHz et 2.00 GHz. Le régulateur "userspace" est libre de choisir la vitesse dans cette plage de fréquences. la fréquence actuelle de ce CPU est 1000 MHz. des statistique concernant cpufreq:2.00 GHz:67,96%, 1.80 GHz:7,17%, 1.60 GHz:5,88%, 1.40 GHz:5,01%, 1.20 GHz:3,64%, 1000 MHz:2,66%, 800 MHz:1,57%, 600 MHz:6,12% (336)
Déduction: puisque le dysfonctionnement ne dépend pas du BIOS, ni de la version du noyau, ni de powersaved, ni des paramètres du fichier cpufrequtils, c’est donc que le coupable doit être i8kmon

Je m’en vais vérifier de suite en le réactivant: je remets ENABLED=1 dans /etc/default/i8kmon, puis je lance:

tuxo:~# /etc/init.d/i8kmon restart Stopping Dell Inspiron fan/cpu-temperature monitor: i8kmon. Starting Dell Inspiron fan/cpu-temperature monitor: i8kmon.
Et là… eh bien ça fonctionne toujours!?!

À tout hasard je redémarre pour vérifier si le problème réapparaît… non!

Le système est revenu dans le même état que quand ça dysfonctionnait, sauf que là ça fonctionne!

À part peut-être la température extérieure, rien n’a donc changé, le ventilo tourne à fond, le CPU est à 53 degrés. Je force le ventilo en vitesse réduite…

phil@tuxo:~$ i8kfan 0 1 0 1
la température monte entre 60 et 70 degrés C, mais le CPU n’a pas l’air de s’en porter mal, et fonctionne normalement, bref je n’y comprends plus rien et j’en perds mon latin!

L’un(e) d’entre vous a-t’il/elle sacrifié une batterie aux dieux de l’informatique pour moi???

En tout cas merci à piratebab, fran.b et ggoodluck47 pour vos contributions.

PS: dois-je indiquer que mon problème est résolu?
Il semble que ce soit le cas, mais rien ne me le prouve, étant donné que la cause du problème n’a pas été isolée!

Update: ça y est, c’est retombé, le CPU est à nouveau scotché à 600Mhz…

Vous connaissez un bon marabout?

Essaie de virer i8kmon, il semble avoir un problème d’initialisation!
Ou alors il reçoit une mauvaise température.

Salut
Concernant la temperature, tu peux augmenter les seuils aussi, juste pour voir, j’utilisais ce script de temps en temps (ca coupe le ventilo si le support “fan” existe )
#!/bin/sh
echo -n “30” > /proc/acpi/thermal_zone/TZ1/polling_frequency
echo -n “100:0:90:65:68” > /proc/acpi/thermal_zone/TZ1/trip_points
echo -n “3” > /proc/acpi/fan/C202/state
echo -n “3” > /proc/acpi/fan/C203/state
echo -n “3” > /proc/acpi/fan/C204/state
echo -n “3” > /proc/acpi/fan/C205/state

Sinon, les modules noyaux sont bien chargés? Sur mon portable (intel), le module générique ne marchait pas.
J’utilise pas non plus powersaved.

Après, ca peut être des problèmes plus compliqués d’acpi…

Etudie le syslog et /var/log/messages, tu auras des explications je pense.

Hello, toujours la même panne intermittente…

[quote=“piratebab”]Essaie de virer i8kmon, il semble avoir un problème d’initialisation!
Ou alors il reçoit une mauvaise température.[/quote]
J’ai désactivé son démarrage (comme indiqué plus haut).

Je ne suis pas sûr que ça ait un rapport avec la température…

Oui:

tuxo:~# lsmod | grep cpufreq acpi_cpufreq 7640 0 cpufreq_powersave 1292 0 cpufreq_userspace 2756 0 cpufreq_stats 3520 0 cpufreq_conservative 6256 1 processor 34448 2 acpi_cpufreq

Effectivement j’en viens à penser qu’il y a un bug dans les modules du noyau…

Et comment détermine-t’on si c’est le cas?

J’ai bien regardé, et non, rien d’intéressant à première vue.

Ce qui continue de m’intriguer est la chose suivante:

tuxo:/sys/devices/system/cpu/cpu0/cpufreq# cpufreq-info cpufrequtils 005: cpufreq-info (C) Dominik Brodowski 2004-2006 Veuillez rapportez les erreurs et les bogues à cpufreq@vger.kernel.org, s'il vous plait. analyse du CPU 0 : pilote : acpi-cpufreq CPUs qui doivent changer de fréquences en même temps : 0 limitation matérielle : 600 MHz - 2.00 GHz plage de fréquence : 2.00 GHz, 1.80 GHz, 1.60 GHz, 1.40 GHz, 1.20 GHz, 1000 MHz, 800 MHz, 600 MHz régulateurs disponibles : powersave, userspace, conservative, ondemand, performance tactique actuelle : la fréquence doit être comprise entre 600 MHz et 600 MHz. Le régulateur "ondemand" est libre de choisir la vitesse dans cette plage de fréquences. la fréquence actuelle de ce CPU est 600 MHz (vérifié par un appel direct du matériel). des statistique concernant cpufreq:2.00 GHz:0,38%, 1.80 GHz:0,14%, 1.60 GHz:0,09%, 1.40 GHz:0,09%, 1.20 GHz:0,08%, 1000 MHz:0,06%, 800 MHz:0,05%, 600 MHz:99,12% (151) tuxo:/sys/devices/system/cpu/cpu0/cpufreq# cat scaling_governor ondemand tuxo:/sys/devices/system/cpu/cpu0/cpufreq# echo conservative > scaling_governor tuxo:/sys/devices/system/cpu/cpu0/cpufreq# cat scaling_governor conservative tuxo:/sys/devices/system/cpu/cpu0/cpufreq# cat cpuinfo_max_freq 2000000 tuxo:/sys/devices/system/cpu/cpu0/cpufreq# cat scaling_max_freq 600000 tuxo:/sys/devices/system/cpu/cpu0/cpufreq# cat cpuinfo_max_freq > scaling_max_freq tuxo:/sys/devices/system/cpu/cpu0/cpufreq# echo $? 0 tuxo:/sys/devices/system/cpu/cpu0/cpufreq# cat scaling_max_freq 600000
Je ne comprends pas pourquoi il n’est pas possible de changer la « scaling_max_freq »!
Ça ressemble bien à un bug des modules, non?

À moins qu’il y ait un système de protection thermique, dans ce cas vous auriez une idée de ce que ça pourrait être?

[quote=“Philibre”]
À moins qu’il y ait un système de protection thermique, dans ce cas vous auriez une idée de ce que ça pourrait être?[/quote]
Essaye ca:
echo -n “30” > /proc/acpi/thermal_zone/TZ1/polling_frequency
echo -n “100:0:90:65:68” > /proc/acpi/thermal_zone/TZ1/trip_points
echo -n “3” > /proc/acpi/fan/C202/state
echo -n “3” > /proc/acpi/fan/C203/state
echo -n “3” > /proc/acpi/fan/C204/state
echo -n “3” > /proc/acpi/fan/C205/state

J’ai déjà essayé…
Pour commencer, le bon répertoire sur ma machine est /proc/acpi/thermal_zone/THM et non TZ1. Ensuite:

Je ne vois pas l’intérêt de passer de 2s à 30s, ça me paraît limite dangereux (risque de griller le CPU plus grand, non?)

Ça ne fonctionne pas:

tuxo:/proc/acpi/thermal_zone/THM# chmod u+w trip_points tuxo:/proc/acpi/thermal_zone/THM# ls -l total 0 -rw-r--r-- 1 root root 0 Jul 13 22:45 cooling_mode -rw-r--r-- 1 root root 0 Jul 13 22:45 polling_frequency -r--r--r-- 1 root root 0 Jul 13 22:45 state -r--r--r-- 1 root root 0 Jul 13 22:45 temperature -rw-r--r-- 1 root root 0 Jul 13 22:45 trip_points tuxo:/proc/acpi/thermal_zone/THM# cat trip_points critical (S5): 90 C tuxo:/proc/acpi/thermal_zone/THM# echo -n "100:0:90:65:68" > trip_points -su: echo: write error: Erreur d'entrée/sortie
Et pour le reste, le répertoire /proc/acpi/fan est tout simplement vide!

PS: merci néanmoins pour ta suggestion.

Non, c’est remis au valeur par defaut au bout de … 30s. C’est pour avoir le temps d’entendre le ventilo s’arreter…

Aie, moi aussi sur mon portable, c’est pas géré par l’acpi.
modprobe fan
?

A court d’idée…

il y a une solution qui n’est pas proposer, recompiler le kernel en forcent le mode. (je me souviens plus des option mai c est assez parlant)
De ce fait les soft aurai plus le choix (fran.b tu m’arrete si je dit une c****)

perso comme moi je re-compile mon kernel le choix est assez vite fait, pour ce qui est des ventilo j’ai plus ce problème je suis en w.c c’est gérer a la mano)

mai passer 68c° sa commence a pas être bon pour le cpu même si théoriquement on peux taper jusqu’à 80C° car si le cpu est a 68C° l’arrière de la cm conduit la chaleur sur le reste des éléments!