module w83627.ehf qui a disparu du kernel ?

[piratebab]

Voici mon problème: j'ai une erreur de chargement du module w83627.ehf
Je cherche dans debian package search, et il me trouve ce module dans le kernel 4.11, mais j'ai le 4.13 d'installé.
Je vais donc à la recherche des changelog des kernel 4.12 et 4.13. Mais sur kernel.org, je ne trouve que le changelog du 4.14.
Comment connaître l'historique des changelog du kernel lorsqu'on est face a un tel problème ?

[PascalHambourg]

Tu veux dire le module w83627ehf (sans point) ?
Il est toujours présent dans les sources amont du noyau 4.14 et dans le noyau Debian 4.13.

Peux-tu en dire plus sur cette erreur de chargement ? Elle peut provenir non pas de l'absence du module mais d'une erreur lors de l'initialisation de celui-ci, par exemple si le matériel géré n'est pas détecté.

[piratebab]

Salut pascal,
merci de te pencher sur mon probléme
l'erreur est vue via journalctl -b

Failed to insert 'w83627ehf': Device or resource busy

le chip est reconnu

kernel: w83627ehf: Found W83667HG chip at 0x290

c'est en cherchant ce module dans les linux-image via debian package chip que je ne l'ai trouvé que dans le kernel 4.11.
C'était donc une fausse piste
il n'est pas chargé, car rien en sortie de

Code : Tout sélectionner

lsmod | grep w83627

je ne sais pas trop ou chercher pour trouver la cause de ce non chargement

[MicP]

Bonjour

…Failed to insert 'w83627ehf': Device or resource busy…


À moins que "Device or resource" ne concerne le support disque du fichier pilote w83627ehf
il s'agit peut-être du composant w83627ehf lui même dont l'accès est bloqué.

Mais il est plus probable que certaines routines d'accès au composant W83667HG
ne soient pas tout à fait les mêmes que celles prévues pour le composant w83627ehf.

=======
Certains des registres mémoire de ce composant électronique sont souvent bloqués en lecture seule
de manière logicielle par l'exécution du programme du BIOS ou/et l'UEFI.

Par exemple, j'avais remarqué que l'accès en écriture aux registres mémoire de ce type de composant
qui permettraient par exemple de programmer les vitesses de rotation des ventilateurs et les limites de température associés
sont bloqués en lecture seule par l'exécution d'une routine du BIOS des cartes mères ASUS
qui implémentaient la fonctionnalité Q-FAN.

=======
Peut-être que les spécificités de ce composant électronique
seront prises en charge dans une future version du kernel.

=======
Quelques liens concernant ce composant,
avec peut-être ce qu'il faut pour créer le pilote pour ce composant :

https://github.com/rockchip-linux/coreb ... w83667hg-a

https://www.coreboot.org/Superiotool

https://review.coreboot.org/#/q/status% ... 3Acoreboot

[PascalHambourg]

La description du module w83627ehf mentionne explicitement qu'il supporte le W83627HG.

config SENSORS_W83627EHF
tristate "Winbond W83627EHF/EHG/DHG/UHG, W83667HG, NCT6775F, NCT6776F"
depends on !PPC
select HWMON_VID
help
If you say yes here you get support for the hardware
monitoring functionality of the Winbond W83627EHF Super-I/O chip.

This driver also supports the W83627EHG, which is the lead-free
version of the W83627EHF, and the W83627DHG, which is a similar
chip suited for specific Intel processors that use PECI such as
the Core 2 Duo. And also the W83627UHG, which is a stripped down
version of the W83627DHG (as far as hardware monitoring goes.)

This driver also supports Nuvoton W83667HG, W83667HG-B, NCT6775F
(also known as W83667HG-I), and NCT6776F.

This driver can also be built as a module. If so, the module
will be called w83627ehf.

Y a-t-il d'autres messages relatifs à w83627ehf dans les logs du noyau ?
D'ailleurs, est-ce que ce module est-il chargé automatiquement ou bien est-ce toi qui essaies de le charger ?
Une raison qui peut provoquer l'échec du chargement d'un module est si un autre pilote prend déjà en charge le même matériel. Or il y a un autre module qui remplace w83627ehf pour certains composants.

config SENSORS_NCT6775
tristate "Nuvoton NCT6775F and compatibles"
depends on !PPC
select HWMON_VID
help
If you say yes here you get support for the hardware monitoring
functionality of the Nuvoton NCT6106D, NCT6775F, NCT6776F, NCT6779D,
NCT6791D, NCT6792D, NCT6793D, and compatible Super-I/O chips. This
driver replaces the w83627ehf driver for NCT6775F and NCT6776F.

This driver can also be built as a module. If so, the module
will be called nct6775.

Certes le W83667HG n'est pas mentionné, mais dans la description du module w83627ehf il est écrit que le NCT6775F est aussi connu comme W83667HG-I, qui sonne très proche.
Le module nct6775 est-il chargé ?

[piratebab]

Alors, dans l'ordre:
la CN est une ASUS P6T (c'est pas jeune, pas dUEFI ) je n'ai pas vu de Q-fan dans la doc.
L'insatllation de ce module est suite à une recommandation de lm-sensors, déjà ancienne (sensors-detect de 2013). J'ai ajouté w83262ehf dans /etc/modules

un sensors-detect me trouve bien:

Found `Winbond W83667HG Super IO Sensors' Success!
(address 0x290, driver `w83627ehf'

Le module nct6775 n'est pas chargé, et le module w83627ehf' non plus

[PascalHambourg]

Et concernant la présence d'autres messages du noyau ?

Tu peux aussi regarder dans /proc/ioports pour voir s'il y a une indication concernant ce port 290.

Tu as essayé de charger le module nct6775 au cas où ?

[piratebab]

une tentative de chargement manuel donne la même erreur

modprobe: ERROR: could not insert 'w83627ehf': Device or resource busy

Dans les messages kernel, seullement

[ 3.638564] w83627ehf: Found W83667HG chip at 0x290
[87021.961758] w83627ehf: Found W83667HG chip at 0x290

Je ne sais pas comment interpréter

cat /proc/ioports | grep 290
0290-029f : pnp 00:03

[PascalHambourg]

Je parlais de charger le module nct6775 au cas où ce serait lui qui gère ce périphérique.

D'après ce que j'ai compris, la mention "pnp" dans ioports veut juste dire que ce port est référencé par le BIOS PnP, mais ne semble pas actuellement utilisé par un "vrai" pilote du noyau.

[piratebab]

pas mieux

modprobe: ERROR: could not insert 'nct6775': No such devic

je vais continuer à fouiller

[piratebab]

Aprés un modprobe w83627efh
l'erreur est

[179851.621628] w83627ehf: Found W83667HG chip at 0x290
[179851.621656] ACPI Warning: SystemIO range 0x0000000000000295-0x0000000000000296 conflicts with OpRegion 0x0000000000000290-0x0000000000000299 (\_SB.PCI0.SBRG.SIOR.HWRE) (20170531/utaddress-247)
[179851.621662] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver

J'ai trouvé plusieurs cas sur le net, mais pas encore la solution

[piratebab]

La route va étre longue

ls -l /usr/lib/modules/$(uname -r)/kernel/drivers/acpi
ls: impossible d'accéder à '/usr/lib/modules/4.13.0-1-amd64/kernel/drivers/acpi': Aucun fichier ou dossier de ce type

[PascalHambourg]

Les modules du noyau sont dans /lib, pas dans /usr/lib. Qu'est-ce que tu y cherches ?
Quant au message d'avertissement ACPI, je ne sais pas l'interpréter.

[MicP]

…ASUS P6T …pas vu de Q-fan dans la doc.…

Sur ASUS P6T, l'équivalent à Q-FAN est nommé Fan Xpert

Un extrait du code source du pilote w83627ehf.c

Code : Tout sélectionner

…
	err = acpi_check_resource_conflict(&res);
	if (err)
		goto exit_device_put;
…

Il y a effectivement un conflit d'accès aux ports IO par l'ACPI et à ce composant
mais de toutes façons, il ne sera pas possible d'accéder aux réglages des ventilateurs.

On pourra juste lire les registres du composant (température, vitesse, seuils, etc.)
mais pas accéder en écriture aux registres car le BIOS de la carte mère (avec Fan Xpert)
gère lui même (et le fait très bien) le réglage de la vitesse des ventilateurs.

Ce conflit d'accès pourrait peut-être être réglé en utilisant le pilote linux pour ASUS ATK0110
mais je ne sais pas pourquoi le programme d'installation ne l'a pas installé.

Ceci dit, ce n'est peut-être pas un problème qui rendra le système Linux instable.

[piratebab]

je cherchais ça

-rw-r--r-- 1 root root 2808 Aug 29 23:58 ac.ko.gz
-rw-r--r-- 1 root root 3021 Aug 29 23:58 acpi_ipmi.ko.gz
-rw-r--r-- 1 root root 3354 Aug 29 23:58 acpi_memhotplug.ko.gz
-rw-r--r-- 1 root root 4628 Aug 29 23:58 acpi_pad.ko.gz
drwxr-xr-x 2 root root 4096 Aug 29 23:59 apei
-rw-r--r-- 1 root root 7120 Aug 29 23:58 battery.ko.gz
-rw-r--r-- 1 root root 3700 Aug 29 23:58 button.ko.gz
-rw-r--r-- 1 root root 2181 Aug 29 23:58 container.ko.gz
-rw-r--r-- 1 root root 1525 Aug 29 23:58 custom_method.ko.gz
-rw-r--r-- 1 root root 1909 Aug 29 23:58 ec_sys.ko.gz
-rw-r--r-- 1 root root 2001 Aug 29 23:58 fan.ko.gz
-rw-r--r-- 1 root root 1532 Aug 29 23:58 hed.ko.gz
-rw-r--r-- 1 root root 3241 Aug 29 23:58 pci_slot.ko.gz
-rw-r--r-- 1 root root 17742 Aug 29 23:58 processor.ko.gz
-rw-r--r-- 1 root root 3073 Aug 29 23:58 sbshc.ko.gz
-rw-r--r-- 1 root root 7098 Aug 29 23:58 sbs.ko.gz
-rw-r--r-- 1 root root 6311 Aug 29 23:58 thermal.ko.gz
-rw-r--r-- 1 root root 8891 Aug 29 23:58 video.ko.gz

ça c'est après avoir installé acpid, je n'ai pas regardé avant.
Je cherche à minima à avoir accès aux infos. La régul du ventilo CPU est fait par la CM, pour les autres , j'ai un rhéobus avec plusieurs sondes réparties dans le boitier.
Et j'aimerai ne pas avoir de message d'erreur dans les logs. C'est en essayant de les éliminer qu'on apprends!
La prochaine étape sera l'optimisation des ressources, et en particulier le temps de boot.
Ca me servira pour le HTPC que je suis en train de refaire, c'est pour améliorer son WAF.

[MicP]

Ceci dit, concernant le conflit d'adresse IO,
il ne s'agit quand même que d'un message d'avertissement (warning)
et pas un message d'erreur.
Donc, du moment où la machine fonctionne sans problème…

Le message d'erreur ne s'affiche uniquement que quand on cherche à forcer l'installation d'un module
qui ne peut être installé justement à cause de ce conflit d'adresse IO entre l'ACPI et le composant piloté par ce module.

D'autre part, il est possible que le module concernant ce composant
soit déjà intégré au noyau => intégré dans les sources du kernel et donc pas chargé comme un module externe

[piratebab]

Ce module est effectivement dans les sources du kernel, mais il doit étre chargé explicitement.
Je continu à chercher comment accéder aux infos fournies par ce chip via l'ACPI, sinon au prochain reboot, je regarde comment le libérer via le BIOS.

[PascalHambourg]

Ne pas confondre être dans les sources du noyau et être compilé en dur dans le noyau (au lieu de module).
Je peux me tromper, mais même si l'adresse était utilisée par un autre pilote compilé en dur, il y aurait le nom de ce pilote au lieu de "pnp" dans /proc/ioports. En tout cas c'est ce que je constate sur mon PC.
A la réflexion, l'hypothèse selon laquelle ce composant est utilisé par l'ACPI me semble plausible.

[franb]

As tu regardé ce que te disait lspci -vv pour voir si ta ressource était prise par autre chose?

[piratebab]

lspci -vv ne me sort rien en rapport avec w83627efh