Configurer frequence CPU et vitesse ventilo et ACPI

[quote=“piratebab”]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 ?[/quote]

pourquoi GRUB_CMDLINE_LINUX=“acpi_enforce_resources=lax”
?
Tu tapes sur la touche “e” juste après le POST et tu complètes la ligne “linux /boot/vmlinuz…” avec acpi_enforce_resources=lax
Ctrl+X pour lancer le démarrage avec ces paramètres…

Aprés tu peux jeter un oeil dans dmesg pour voir si tu as toujours ceci :

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

:handgestures-thumbup: :obscene-drinkingcheers:

oui, c’est sur le modprobe que ça ne veux pas charger (j’ai dégager le midule asus avec un rmmod)
Je le met dans /etc/default/grub pour ne avoir à le rajouter à chaque mise à jour su kernel.
Et oui, j’ai toujours ces erreurs dans demesg, c’est pour ça que je m’intéroge sur la prise en compte du lax
J’en ai marre de rebooter, je continu demain

Au cas où ça intéresserait quelqu’un, je viens de trouver (facilement en plus) le datasheet du circuit 83627EHF
J’avais pas bien fait attention, car j’étudiais une autre version de ce circuit pour mieux connaître ses possibilités de contrôle des tensions, températures et ventilation,
mais il se trouve que c’est aussi ce même circuit qui est utilisé pour flasher la ROM BIOS.
Ça n’a pas d’incidence sur le problème actuel, mais je trouvais ça intéressant.
Même quelqu’un de non électronicien pourrait se faire une idée de ce que gère ce circuit en jetant un œil juste aux premières pages de la doc.

Ceci ne nous dit pas comment il est intégré et câblé sur la carte mère de piratebab, mais on peux quand même voir qu’il est programmable/rep-rogrammable par un bus I²C, et ce bus est sûrement accessible avec les mêmes applications Linux qui utilisent ce protocole I²C : port HDMI, VGA, DVI, EEPROM RAM, et autres circuits…
Il dispose aussi d’une seconde interface de communication (LPC) beaucoup plus rapide et qui peut utiliser les ports ISA ou PCI => 33MHz.
Le fait que ce circuit soit “busy” d’après le module ne veux pas forcement dire inaccessible. tout dépends bien sûr du programme de gestion intégré dans le BIOS, ou/et du pilote linux.

dans tes recherches, tu n’aurais pas trouvé comment fonctionne l’option “lax” ? De mon coté je n’ai encore pas trouver ce quelle apporte précisement.

[quote=“piratebab”]Je le met dans /etc/default/grub pour ne avoir à le rajouter à chaque mise à jour su kernel.
[/quote]

C’est précisément ce qu’il faut éviter de faire : paramétrer l’option de façon permanente sans savoir si ça ne va pas interagir négativement avec le Bios ACPI. Alors, oui je sais, c’est ch…t de tout retaper à chaque boot mais bon, comme tu l’as signalé plus haut, il y a un risque potentiel de dysfonctionnement.

Le bios ACPI réserve probablement des ports (I2C , SMBUS ) ce qui empêche ton pilote de les utiliser. L’option “lax” permet de libérer ces ports. C’est une hypothèse et je ne fais que relater ce que j’ai appris avec Jean D. (dev. lmsensors). Pour plus de détails, contacte le. Tu verras que c’est quelqu’un de fort sympathique en plus d’être compétent :wink: .

Je viens de repenser à quelque chose qui pourrait expliquer le fait que ajout (GRUB_CMDLINE_LINUX=“acpi_enforce_resources=lax”) soit sans effet.

Étant donné que initramfs intègre un noyau d’initialisation dans son système de fichiers en RAM, il se pourrait bien que le module asus_atk_0110 y soit déjà intégré, ce qui fait que ACPI activée ou pas par le menu setup du BIOS, ce module est quand même utilisé et monopoliserait l’accès aux fonctionnalités du 83627EHF.

Il faudrait donc, après avoir indiqué GRUB_CMDLINE_LINUX=“acpi_enforce_resources=lax” dans le menu de grub, récréer l’image initramfs avec “update-initramfs” pour que ce module ne soit plus intégré dans le noyau utilisé pour l’initialisation du système, ce qui libérait l’accès au 83627EHF.

piste intéressante. Le module asus est en effet chargé automatiquement, il faut le blacklister. Mais même aprés un rmmod de l’asus, le w8362 ne se charge pas.

J’avais zappe:

Rien trouvé encore, mais ça devrait sûrement avoir un rapport avec “laxiste” =>(dans ce contexte) tolérant.
Je pense qu’ils doivent (gestion par BIOS ACPI et gestion par Linux Soft) se débrouiller pour ne pas trop se marcher sur les pieds, mais comme ces profils de gestions n’utilisent pas forcément les mêmes méthodes de calcul, il risque fort d’y en avoir un qui dit :" bon on ventile plus" et l’autre qui aura décidé le contraire.

Mais AMHA, le “bug” (j’ai du mal à appeler un bug une histoire d’incompatibilité avec un brevet) du noyau semble résolu avec la version 3.2, ça vaudrait le coup de tester le comportement de l’ACPI BIOS avec une version 3.2 Live ou une installation temporaire. Bien sûr, une mise à jour du BIOS ne fera pas de mal, et pourrait même peut-être (si Murphy est occupé ailleurs…) régler le problème de conflit d’accès au circuit 83627ehf.
L’utilisation de l’option “lax” et les risques de problèmes d’interprétation et de conflit de profil de gestion par le soft risquent d’êtres très pénibles à résoudre.

Le bios est à jour, et j’ai un kernel 3.10
Tout ce que je trouve date de 2010. Le driver IT87 pose le même problème. et toujours la même solution proposée: lax
En fouillant les options du kernel, j’ai trouvé

[quote]acpi_enforce_resources= [ACPI]
{ strict | lax | no }
Check for resource conflicts between native drivers
and ACPI OperationRegions (SystemIO and SystemMemory
only). IO ports and memory declared in ACPI might be
used by the ACPI subsystem in arbitrary AML code and
can interfere with legacy drivers.
strict (default): access to resources claimed by ACPI
is denied; legacy drivers trying to access reserved
resources will fail to bind to device using them.
lax: access to resources claimed by ACPI is allowed;
legacy drivers trying to access reserved resources
will bind successfully but a warning message is logged.
no: ACPI OperationRegions are not marked as reserved,
no further checks are performed.[/quote]

en fait ce n’est pas si dramatique que ça.
Je vais chercher le fameux warning message dans les log pour voir si c’est bien activé

l’option lax n’est pas passée

cat /proc/cmdline BOOT_IMAGE=/boot/vmlinuz-3.10-2-amd64 root=UUID=d8a091e1-53e3-4238-9855-a2a8a7a01af2 ro quiet

j’ai du merder quelque part

[quote=“piratebab”]… l’option lax n’est pas passée …[/quote]Finalement, la proposition de milediou serait un possibilité plus directe

[quote=“milediou”]… Tu tapes sur la touche “e” juste après le POST et tu complètes la ligne “linux /boot/vmlinuz…” avec acpi_enforce_resources=lax
Ctrl+X pour lancer le démarrage avec ces paramètres…[/quote]C’est d’ailleurs la méthode que j’utilise pour indiquer “desktop=xfce” à chaque nouvelle installations plutôt que de me perdre dans les menus de l’installateur.
J’ai aussi pendant un temps dû ajouter “noacpi” et d’autres options, mais depuis la version 3.2 du kernel, je n’ai plus besoin de ça.

pas eu le temps de tester. Ce qui est pénible, c’est qu’il faut rebooter en permanence, j’ai perdu cette habitude depuis que j’ai quitté le mondes de fenetres.

Plaisanterie hors sujet donc supprimée

pas compris.
Quelle copine ?

EDIT:
Bon j’efface tout ça, ça n’a rien à faire ici.

là je ne comprends plus rien

cat /proc/cmdline BOOT_IMAGE=/boot/vmlinuz-3.10-2-amd64 root=UUID=d8a091e1-53e3-4238-9855-a2a8a7a01af2 ro quiet acpi_enforce_ressources=lax
ça , c’est bon

modprobe w83627ehf ERROR: could not insert 'w83627ehf': Device or resource busy
ça, c’est pas bon.

[quote=“piratebab”]là je ne comprends plus rien

cat /proc/cmdline BOOT_IMAGE=/boot/vmlinuz-3.10-2-amd64 root=UUID=d8a091e1-53e3-4238-9855-a2a8a7a01af2 ro quiet acpi_enforce_ressources=lax
ça , c’est bon[/quote]

Non, pas bon ! C’est resources et non “ressources”

oui j’ai vu et corrigé. Au boot, le module asus s’en offusque! (pas encore blacklisté, mais de toute façon, ne se charge pas.

modprobe w83627ehf
passe comme une lettre à la poste (lorsqu’ils ne sont pas en grève …)
pwmconfig détecte bien 3 sorties pwm, mais aucune ne fait varier la vitesse du ventilo (comme avec qfan). Je vais revérifier le câblage et la config du BIOS

Bios et hardware OK, mais toujours pas de variation de vitesse du ventilo.
la carte comporte 4 sorties PWM (CPU, power, CAS1, CHAS2). Mais pwm config n’en trouve que 3 …