Configurer frequence CPU et vitesse ventilo et ACPI

Support Debian
#1

Bonjour,
mon ventilo n’est pas du tout régulé, et le CPU est toujours à fond (debian testing).
Je m’attaque donc au problème, mais je bloque

cpufreq-info cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009 Veuillez rapportez les erreurs et les bogues à cpufreq@vger.kernel.org, s'il vous plait. analyse du CPU 0 : pilote : acpi-cpufreq CPUs which run at the same hardware frequency: 0 CPUs which need to have their frequency coordinated by software: 0 maximum transition latency: 10.0 us. limitation matérielle : 1.60 GHz - 2.67 GHz plage de fréquence : 2.67 GHz, 2.67 GHz, 2.53 GHz, 2.40 GHz, 2.27 GHz, 2.13 GHz, 2.00 GHz, 1.87 GHz, 1.73 GHz, 1.60 GHz régulateurs disponibles : powersave, conservative, userspace, ondemand, performance tactique actuelle : la fréquence doit être comprise entre 2.67 GHz et 2.67 GHz. Le régulateur "performance" est libre de choisir la vitesse dans cette plage de fréquences. la fréquence actuelle de ce CPU est 2.67 GHz (vérifié par un appel direct du matériel). des statistique concernant cpufreq:2.67 GHz:99,93%, 2.67 GHz:0,00%, 2.53 GHz:0,00%, 2.40 GHz:0,00%, 2.27 GHz:0,01%, 2.13 GHz:0,00%, 2.00 GHz:0,01%, 1.87 GHz:0,04%, 1.73 GHz:0,00%, 1.60 GHz:0,00% (32)

Comme vous le voyez, c’est pas brillant. je peux réguler entre 2.67 et 2.67 GHz!
cpufreq est installé.
J’ai visiblement un problème de driver ACPI (extrait de dmesg)

[quote]ACPI Warning: 0x0000000000000295-0x0000000000000296 SystemIO conflicts with Region _SB_.PCI0.SBRG.SIOR.HWRE 1 (20130328/utaddress-251)
[ 1506.391907] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver
[/quote]
qui apparait plusieurs fois.

Comment trouver ce driver alternatif ?

Serai ce le driver ci dessous recomendé par lm-sensors mais qui ne veut pas se charger ?

ERROR: could not insert 'w83627ehf': Device or resource busy
J’ai bien vu une solution

mais c’est déconseillé (voir hansdegoede.livejournal.com/7932.html)

je suis tombé sur un vieux bug de 2009, mais qui est répité étre résolu: bugzilla.kernel.org/show_bug.cgi?id=13571

Si vous pouvez me donner quelques pistes …

#2

Et si tu bascule sur ondemand?

Performance sert justement a utiliser ton cpu au max, donc effectivement il ne ne propose que les plages les plus hautes.

#3

j’ai effectivement forcè on demand, ça baisse un peu la fréquence CPU, je regarderai comment mettre ça en dur (kpowersave ne me propose plus l’option).
Le plus critique c’est la gestion du ventilo et le chargement du module w83627ehf.
J’ai trouvé pas mal de rapport de bug concernant la gestion de l’ACPI (dont un pour redhat très bien documenté), mais la conclusion n’est pas très claire. Le dev kernel dis que le problème est résolu (ce qui est certainement vrai à son niveau), mais les utilisateurs continuent à se plaindre que ça ne fonctionne pas et réouvre le bug (que le dev referme …). C’est un peu un dialogue de sourd.
Je vais finir par tester l’option de boot acpi_enforce_resources=lax, mais c’est risqué (risque de modification incontrôlée de la tension d’alim CPU …)
J’ai testé hier un autre module, mais il me semble que j’ai mal configuré lmsensor.
Je reteste ce soir.

[quote]
sensors-detect detects w83627ehf and enters it into /etc/conf.d/lm_sensors, but this module cannot be loaded due to conflict with ACPI. asus_atk0110 module should be used instead (on asus boards) per link posted here, replacing w83627ehf with asus_atk0110 in /etc/conf.d/lm_sensors fixed the problem.[/quote]

Pour ceus qui sont concerné, l’origine du problème est la suivante:

[quote] With previous kernels hwmon drivers used to drive IO ranges which were potentially used by the ACPI code in your BIOS (which is active not only during but also after boot), we now explicitly check for this and if the ACPI code claims the IO-ports used by the hwmon chip, we no longer allow the hwmon driver to load.

Banging IO-ports of a chip from 2 different drivers, the Linux hwmon driver and the ACPI code is a really bad idea and can cause all sort of issues (including things like changing CPU / RAM voltage or clock speed). So the old behaviour was a really bad idea.

So even though this change in behaviour makes some people unhappy as to old behaviour happened to work without problems in their case (by sheer luck really), this change is really for the best!

If you have an Asus motherboard, chances are good there is an ACPI interface to read your sensors, which is safe, and no more sensors.conf tweaking needed for conversion formulas! Make sure you have the asus_atk0110 driver enabled in your kernel configuration to use this. You will also need lm-sensors version 3.1.0 or later.

If you want to restore the old behaviour (which might be dangerous) add: “acpi_enforce_resources=lax” to the kernel cmdline when booting (or add it in grub.conf to make this permanent).

Notes:

  1. This change actually first appeared in the mainline 2.6.30 kernel, but due to a bug in 2.6.30, it didn’t take effect until 2.6.31, see: bugzilla.kernel.org/show_bug.cgi?id=13967 [/quote]

[quote]
This is the same problem as above. The ACPI resource check was accidentally dropped in kernel 2.6.39. It was reintroduced in kernel 3.3, and the fix was then backported to stable kernels 3.2.2 and 3.0.18. [/quote]

nota: j’ai un kernel 3.10

#4

avec le module asus_atk0110, c’est mieux, j’ai les températures:

[quote] sensors
atk0110-acpi-0
Adapter: ACPI interface
Vcore Voltage: +0.93 V (min = +0.80 V, max = +1.60 V)
+3.3 Voltage: +3.31 V (min = +2.97 V, max = +3.63 V)
+5 Voltage: +5.17 V (min = +4.50 V, max = +5.50 V)
+12 Voltage: +12.31 V (min = +10.20 V, max = +13.80 V)
CPU FAN Speed: 1757 RPM (min = 600 RPM, max = 7200 RPM)
CHASSIS1 FAN Speed: 0 RPM (min = 600 RPM, max = 7200 RPM)
CHASSIS2 FAN Speed: 0 RPM (min = 600 RPM, max = 7200 RPM)
POWER FAN Speed: 0 RPM (min = 0 RPM, max = 7200 RPM)
CPU Temperature: +51.5°C (high = +60.0°C, crit = +75.0°C)
MB Temperature: +47.0°C (high = +45.0°C, crit = +75.0°C)

coretemp-isa-0000
Adapter: ISA adapter
Core 0: +61.0°C (high = +80.0°C, crit = +100.0°C)
Core 1: +56.0°C (high = +80.0°C, crit = +100.0°C)
Core 2: +59.0°C (high = +80.0°C, crit = +100.0°C)
Core 3: +58.0°C (high = +80.0°C, crit = +100.0°C)[/quote]

mais pwmconfig ne trouve pas les sorties pour réguler le ventilo

#5

Salut,

tu devrais poser la question à Jean Delvare ( khali@linux-fr.org ). Il en connait un rayon sur l’ACPI et devrait te répondre, bien content de faire du support en français. Ca va le changer :wink:
Il m’avait dépanné lorsque j’avais cherché à extraire les infos SPD de mes barrettes sur un portable Asus. J’avais ouvert un sujet ici >> debian-fr.org/lecture-des-in … 42855.html

Tiens nous au courant.

#6

merci du conseil.
Mais je crois que c’est pas gagné mon affaire.
Les cartes ASUS P6T ont semble t il un problème pour réguler les ventilos. J’ai essayé de réguler via le BIOS, et ça marche pas non plus. J’ai trouvé pleins de cas sur le net avec cette carte.
Je vais faire une mise à jour du BIOS avant toute autre chose (via linux, ça va étre coton …)

#7

Ca devrait se faire sans souci avec flashrom

flashrom.org/Supported_hardware
flashrom.org/pipermail/flash … 02500.html

#8

OK merci.
Il y a aussi un utilistaire ASUS, mais je n’arrive pas à lui faire lire une clef USB (car evidement, il ne veux lire que sur un disque dur en fat).
C’est vraiment pas gagné, car dans les changemog du BIOS, je ne vois rien concernant la gestion des ventilos.

#9

J’ai fini par retrouver le lien que je cherchais : forum.ubuntu-fr.org/viewtopic.ph … 1#p3671821

Le fait qu’ATK0110 corresponde à une abstraction logicielle (non documentée) au niveau du bios des cartes Asus est sûrement la cause de ces problèmes d’incompatibilité.
Le circuit w83627ehf, par contre est très bien documenté depuis longtemps.

Pour conclure, je dirais qu’il faut donc faire un choix entre :
utiliser les fonctionnalités QFan et compagnie de l’ATK0110 => gestion par le BIOS,
ou bien désactiver les fonctionnalités ATK0110 depuis le setup du BIOS, et laisser le système Linux gérer directement le w83627ehf.

Ceci dit, le lien que je transmets datant de 2010, il faudrait peut-être reposer la question aux développeurs de lmsensor.
Leur réponse m’intéressera beaucoup…

EDIT: Un EeePC voulait pas que je le flashe, je l’ai eu en créant une clef USB qui est pasée pour une disquette 1.44 avec msDOS 622
J’ai mounté l’image 622C.IMG avec un “mount -o loop” pour y ajouter le fichier ROM par un simple “cp” après avoir fait un peu de place sur l’image de la disquette, et l’utilitaire DOS d’ASUS pour flasher le BIOS. ensuite j’ai copié tout ça sur une clef USB avec “dd” (1.44 Mo c’est très très rapide à copier…)
Pour toi, il suffit apparemment que le fichier ROM soit présent sur un support accessible, donc ça devrait aller.
L’utilitaire de flashage d’ASUS permet de sauvegarder l’ancien contenu ROM-BIOS avant flashage.

#10

oui, j’ai vu tout ça dans mes recherches. J’ai une P6T, pas une P7 comme dans le post.
voila ou j’en suis:

  • avec le driver atk0110, j’ai les températures, mais le BIOS ne gére pas le ventilo (même avec Q FAN d’activé))
  • sans q Fan, impossible de charger le driver w83627ehf (celui recommendé par lmsensors).
    La prochaine étape c’est la mise à jour du BIOS, puis si ça suffit pas, d’activer l’option lax au boot(avec w83627ehf). Mais vu les risques écris partout, j’hésite encore.
#11

Alors là !, ça me fait bizarre étant donné qu’il communique par un bus I²C normalement accessible, je pensais, au contraire, qu’activer QFAN bloquerait l’accès à ce port I²C,
mais les mystères des BIOS sont impénétrables (enfin presque…).
Je te souhaite un bon flashage (avec l’édit de mon précédent post, ça devrait aller)

#12

ce problème de driver qui ne se charge pas à fait l’objet de nombreux post en 2010, mais pas de solution autre que

Je ferais la manip du BIOs dans la soirée

#13

Oui, rien ne dit que la mise à jour va te permettre d’aller plus loin.
Pour le flashage, même si flashrom semble être à la hauteur de cette tâche, je te recommande d’utiliser plutôt un utilitaire bas niveau tel qu’EZ Flash2 accessible depuis le setup -> menu tools. Le nouveau Bios sera copié sur une clé USB formatée en FAT32.

[quote]ce problème de driver qui ne se charge pas à fait l’objet de nombreux post en 2010, mais pas de solution autre que
Code:
GRUB_CMDLINE_LINUX="acpi_enforces_resources=lax[/quote]

Contente toi de passer l’option au noyau lors du démarrage pour test, plutôt que de modifier les options de façon permanente.

#14

la méthode que j’ai proposé dans l’“EDIT” de mon post a été utilisée justement car aucune autre méthode classique n’a pu fonctionner:
Ni depuis le BIOS (“EZ Flash 2”), ni par “Asus Update Utility”, ni par “ASUS Update” (ça fait un peu “chevaliers qui disent NI!” (Sacré Graal) tout ça :slightly_smiling: ).
Il ne me restait donc plus que la méthode “AFUDOS” sur une “disquette” USB MSDOS 6.22
D’où le “… Un EeePC voulait pas que je le flashe …”

Maintenant, si une des autres méthode classique fonctionne, tant mieux: sur 10 machines et cartes mères flashées, c’était la seule machine (Eee PC 1011PX) qui a nécessité cette méthode.
Toutes les autres machines et cartes mères ont été flashées grâce à une simple clef USB avec une seule partition FAT 32 bits de quelques MiB.

Ah, si! j’ai failli oublier : le nom du fichier image du BIOS téléchargé doit être modifié pour être au format MSDOS => 8.3 => 8 lettres pour le nom + un point + 3 lettres pour l’extension.
Et ce pour toutes les méthodes (par le setup du BIOS ou autre)
Aucune importance pour le nom de fichier, la version du bios téléchargé sera reconnue par le programme de flashage.

#15

milediou, le risque avec l’option lax, c’est de ne plus plus maitriser les tensions d’alim( CPU, RAM, …).
Donc même en provisoire, ça ne pardonne pas!

#16

[quote=“MicP”]la méthode que j’ai proposé dans l’“EDIT” de mon post a été utilisée justement car aucune autre méthode classique n’a pu fonctionner:
Ni depuis le BIOS (“EZ Flash 2”), ni par “Asus Update Utility”, ni par “ASUS Update” (ça fait un peu “chevaliers qui disent NI!” (Sacré Graal) tout ça :slightly_smiling: ).
Il ne me restait donc plus que la méthode “AFUDOS” sur une “disquette” USB MSDOS 6.22
D’où le “… Un EeePC voulait pas que je le flashe …”[/quote]

hello MicP,

je constate que l’on est voisin et que l’on partage quelques centres d’intérêt autour du matériel Asus :wink:
J’ignore pour quelle raison ton netbook refusait le flashage (downgrade ?) mais dans le cas général, l’usage d’une clé USB avec EZ flash (alt+F2 au démarrage) permet de réaliser cette opération dans de bonnes conditions. Pour les notebooks Asus, le principe est le même avec un utilitaire nommé EasyFlash présent dans le Bios. J’ai réalisé un tuto à ce sujet ici >> forum-des-portables-asus.fr/ … asus.5696/ sans toutefois aborder le cas des netbooks.
Cela ne concerne pas piratebab qui doit ici flasher une carte mère Asus Desktop et avant d’explorer d’autres pistes, il devrait tester la méthode usuelle qui donne la plupart du temps de bons résultats.

Attention, le flashage n’est jamais une opération anodine et comporte quelques risques…

#17

[quote=“piratebab”]milediou, le risque avec l’option lax, c’est de ne plus plus maitriser les tensions d’alim( CPU, RAM, …).
Donc même en provisoire, ça ne pardonne pas![/quote]

Je ne pense pas mais je me trompe peut-être. Les réglages au niveau du setupBios restent maîtres et souverains sur tout le reste. Pour moi le risque se situerait plutôt au niveau de la gestion du refroidissement faute d’accès par le système à certaines sondes.

Tu as des retours de ce genre de mauvaise expérience ?

#18

non,plusieurs posts mettent en garde, mais peu indiquent qu’ils l’ont activé.
Voila ou j’en suis:

  • BIOS mis à jour: pa smieux
  • j’ai désactivé qfan, ACPI2, APIC, activé control plug nd play: w83627ehf ne se charge toujours pas (rssource busy …)

Je tente le lax

#19

le module w83627ehf ne se charge toujours pas.
Comment savoir si la ligne

GRUB_CMDLINE_LINUX="acpi_enforce_resources=lax"
est bien prise en compte ?

#20

[quote=“milediou”]…je constate que l’on est voisin et que l’on partage quelques centres d’intérêt autour du matériel Asus…[/quote]Il semblerait bien que ce soit le cas pour ces deux constatations. On finira sûrement par se retrouver devant une bonne petite mousse un jour, pour parler de debian, Asus et I²C, G53, et d’autre choses aussi, mais pas en avant que je ne me sois débarrassé de ce dernier cadeau de mon fils: un rhume qu’il a ramené du nord… (j’ai la tête en feu…).

[quote=“piratebab”]… w83627ehf ne se charge toujours pas (rssource busy …) …
… Comment savoir si la ligne … est bien prise en compte ? …[/quote]Même manuellement (modprobe), pas moyen de charger le module ?
Ce “ressources busy” me fait comme une espèce de fussoir… :slightly_smiling: , j’irai bien explorer les buses I²C pour savoir ce qui se passe, mais le module le fait sûrement mieux que moi, et je n’ai pas la doc complète du w83627ehf, je n’ai que des modèles plus anciens.
Sur ma machine, un “lsmod” m’informe que le module "atk0110 est bien chargé. Mais demain, si ce rhume s’est un peu dissipé (pas ce soir : j’ai mal à la tête… :slightly_smiling: ), je testerais la désactivation de Qfan et compagnie dans le BIOS et je rajouterai manuellement lors du boot, depuis le menu de grub, “acpi_enforce_resources=lax” à la ligne de commande.
Je te tiendrais au courant.