CPU Frequency Scaling capricieux

[zoken4]

Voila, le CPU Frequency Scaling de mon portable fait des siennes sous Debian. Il reste bloqué sur 800mHz et il est impossible de changer cela via l'applet Gnome, je suis obligé de changer ça (lorsque je veux augmenter la fréquence par exemple) via la commande 'echo 1810000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq'. De plus, malgré la commande 'echo ondemand > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor ' et le fait qu'il l'indique dans l'applet Gnome, le gouverneur 'ondemand' ne semble pas fonctionner, la fréquence ne varie pas, même en sollicitant le cpu.

Voici les modules cpufreq chargés (copié de lsmod) :

cpufreq_powersave 1856 0

cpufreq_ondemand 8428 1

cpufreq_userspace 3812 0

acpi_cpufreq 9484 2

freq_table 4512 2 cpufreq_ondemand,acpi_cpufreq

[Amour]

Même avec un kernel à jour cela ne change rien ? Quelle version actuelle ?

[zoken4]

Je suis sous Debian Sid, j'ai un kernel 2.6.25.

Hier j'ai essayé de compiler le dernier snapshot de la 2.6.26 mais j'ai réussi à obtenir un kernel panic lorsque j'essayais de booter dessus. xD

Je réessaierai peut-être avec la rc8 (que j'imagine plus stable que la git)

[Pi3rr3]

J'ai eu un problème semblable avec la lignée des 2.6.24, il y avait un patch pour le corriger qui a été intégré a quelques versions puis retiré (j'ai pas compris pourquoi), j'ai changé de noyau hier (2.6.25) et j'ai a nouveau le problème, il ne me reste plus qu'à retrouve le patch.

Par contre, la recompilation du noyau est inévitable

[zoken4]

Aïe :(

Tu me tiens au courant quand tu aura retrouvé ce patch?

Merci

[zoken4]

J'ai compris le problème.

Un petit cpufreq-info m'a fait comprendre que le gouverneur ondemand était inopérant à cause d'une limite dans la fréquence fixée (je ne sais pourquoi) à 800mhz :

cpufrequtils 002: cpufreq-info © Dominik Brodowski 2004-2006

Veuillez rapportez les erreurs et les bogues à linux@brodo.de, s'il vous plait.

analyse du CPU 0 :

pilote : acpi-cpufreq

CPUs qui doivent changer de fréquences en même temps : 0 1

limitation matérielle : 800 MHz - 1.80 GHz

plage de fréquence : 1.80 GHz, 1.80 GHz, 1.20 GHz, 800 MHz

régulateurs disponibles : powersave, ondemand, userspace, performance

tactique actuelle : la fréquence doit être comprise entre 800 MHz et 800 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 800 MHz (vérifié par un appel direct du matériel).

analyse du CPU 1 :

pilote : acpi-cpufreq

CPUs qui doivent changer de fréquences en même temps : 0 1

limitation matérielle : 800 MHz - 1.80 GHz

plage de fréquence : 1.80 GHz, 1.80 GHz, 1.20 GHz, 800 MHz

régulateurs disponibles : powersave, ondemand, userspace, performance

tactique actuelle : la fréquence doit être comprise entre 800 MHz et 800 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 800 MHz (vérifié par un appel direct du matériel).

Comme je l'ai dit plus tôt, la commande 'echo 1800000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq' est fonctionnelle, et celle configurant visiblement la fréquence maximale, il me suffit de la mettre dans le rc.local pour régler le problème.

Je suis vraiment étonné de la connerie du problème (et de la mienne également pour ne pas avoir compris plus tôt alors que j'utilisais déjà la commande résolvant le problème). 0_°

[Pi3rr3]

C'est du bricolage

Au fait, c'est quoi ton portable ?

[zoken4]

Clairement, oui . J'aime quand même pas mettre des commandes comme ça au démarrage du système, je vais quand même chercher pourquoi il se met par défaut en 800mHz.

C'est un Vaio CR11Z/R, plutôt pas mal (=excellent) sous Linux.

[ebrsc]

J'ai compris le problème.

Un petit cpufreq-info m'a fait comprendre que le gouverneur ondemand était inopérant à cause d'une limite dans la fréquence fixée (je ne sais pourquoi) à 800mhz :

cpufrequtils 002: cpufreq-info © Dominik Brodowski 2004-2006

Veuillez rapportez les erreurs et les bogues à linux@brodo.de, s'il vous plait.

analyse du CPU 0 :

pilote : acpi-cpufreq

CPUs qui doivent changer de fréquences en même temps : 0 1

limitation matérielle : 800 MHz - 1.80 GHz

plage de fréquence : 1.80 GHz, 1.80 GHz, 1.20 GHz, 800 MHz

régulateurs disponibles : powersave, ondemand, userspace, performance

tactique actuelle : la fréquence doit être comprise entre 800 MHz et 800 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 800 MHz (vérifié par un appel direct du matériel).

analyse du CPU 1 :

pilote : acpi-cpufreq

CPUs qui doivent changer de fréquences en même temps : 0 1

limitation matérielle : 800 MHz - 1.80 GHz

plage de fréquence : 1.80 GHz, 1.80 GHz, 1.20 GHz, 800 MHz

régulateurs disponibles : powersave, ondemand, userspace, performance

tactique actuelle : la fréquence doit être comprise entre 800 MHz et 800 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 800 MHz (vérifié par un appel direct du matériel).

Comme je l'ai dit plus tôt, la commande 'echo 1800000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq' est fonctionnelle, et celle configurant visiblement la fréquence maximale, il me suffit de la mettre dans le rc.local pour régler le problème.

Je suis vraiment étonné de la connerie du problème (et de la mienne également pour ne pas avoir compris plus tôt alors que j'utilisais déjà la commande résolvant le problème). 0_°

mais si utiliser rc.local est viable, ce parametre devrait etre renseigne dans /etc/conf.d/cpufreq

Jette y un coup d'oeil si tu l'as pas deja fait...

[zoken4]

Je n'ai pas de dossier dossier /etc/conf.d :/

[Pi3rr3]

Je viens de retrouver le patch en ouvrant opera (c'est dire la fréquence à laquelle je le fais ^^).

J'espère que ca fonctionnera pour toi aussi :)

http://bugzilla.kernel.org/attachment.cgi?...amp;action=view

[zoken4]

Merci mais je vais m'abstenir de recompiler le noyau, je suis trop fainéant pour ça

J'ai un nouveau problème après une mise à jour du noyau en 2.6.25-2, le système ne semble plus prendre en compte les paramètres du rc.local. Je suis obligé de tout lancer à la main. :/

C'est à dire :

# Economie énergie carte son

echo 10 > /sys/module/snd_hda_intel/parameters/power_save

# Undervolting & CPU frequency scaling

echo "10:18 9:15 6:1 136:0" > /sys/devices/system/cpu/cpu0/cpufreq/phc_controls

echo 1810000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq

echo ondemand > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

# Désactivation bluetooth

echo disable > /proc/acpi/ibm/bluetooth

# Economie énergie carte wifi

echo 7 > /sys/bus/pci/drivers/iwl3945/0000:02:00.0/power_level

# Economie énergie SCSI

echo min_power > /sys/class/scsi_host/host0/link_power_management_policy

echo min_power > /sys/class/scsi_host/host1/link_power_management_policy

# Suspension USB

for i in /sys/bus/usb/devices/%s/power/autosuspend; do echo 1 > $i; done

exit 0

Quelqu'un aurait-il une idée pour résourdre ce problème? Ou au pire un contournement?