Sylvie,

Une solution possible pour ton problème est, comme décrit dans le rapport de 
bogue (cf. [1]), de modifier les règles udev qui posent problème.

Pour faire cela, il faut copier les règles et les modifier.

Voici les commandes :
1/ copier les règles fournies avec le système dans le répertoire des règles 
personnalisées :
sudo cp /lib/udev/rules.d/97-hid2hci.rules /etc/udev/rules.d/

2/ éditer le fichier perso en ajoutant <ACTION=="add", > devant la ligne qui 
contient <ATTR.bInterfaceClass>
sudo sed -i 's/^ATTR.bInterfaceClass/ACTION=="add", &/' 
/etc/udev/rules.d/97-hid2hci.rules

3/ vérifier que la modif est okay et correspond au rapport de bogue (optionnel)
less /etc/udev/rules.d/97-hid2hci.rules


Quand c'est fait, il faut redémarrer l'ordi et le problème devrait être réglé.

Dans le cas ou cela ne fonctionne pas, efface le fichier avec les règles 
modifiées comme ceci :
sudo rm /etc/udev/rules.d/97-hid2hci.rules

Bien à toi,

Jean-Marc <jean-m...@6jf.be>
https://6jf.be/keys/ED863AD1.txt

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1563554

Sat, 21 Dec 2019 15:14:42 +0100
Jean-Marc <jean-m...@6jf.be> écrivait :

> Bonjour à toutes et à tous,
> 
> Je me permets ce mail pour essayer d'y voir plus clair dans ce problème.
> 
> Donc, Sylvie nous dit que son système chauffe parce qu'un processus prend 
> 100% du ou d'un CPU.
> 
> Il s'agit de /lib/systemd/systemd-udevd.
> 
> Pour info, ce processus gère la création/suppression des fichiers 
> "périphérique" de manière dynamique en se basant sur les règles udev, 
> fichiers qu'on retrouve dans le répertoire /dev.
> 
> En deux mots, quand on allume son bluetooth, quand on insère une clé USB ou 
> un disque externe, le système va détecter cet évènement et 
> /lib/systemd/systemd-udevd va ajouter le nécessaire dans le répertoire /dev 
> pour que le reste du système puisse utiliser le nouveau périphérique.
> 
> Désolé Sylvie.  Mais, même si tu n'es pas "tech", tu dois savoir un peu de 
> quoi il retourne avant de faire certaines choses.  Comme, par exemple, 
> arrêter ce processus.  Ce qui, pour faire bref, risque de rendre le système 
> inopérant en cas d'ajout/retrait de certains périphériques amovibles.
> 
> Ceci posé, dans les infos que tu as communiquées comme la sortie de <udevadm 
> monitor> qui montre que le système fait un bind/unbind continuellement sur le 
> même périphérique et la sortie de la commande journalctl qui rapporte une 
> erreur :
> 
> > journalctl /lib/systemd/systemd-udevd
> 
> déc. 21 11:50:31 debian-inspiron systemd-udevd[253]: Process 'hid2hci 
> --method=dell 
> --devpath=/devices/pci0000:00/0000:00:1a.0/usb2/2-1/2-1.2/2-1.2:1.0' failed 
> with exit code 1.
> 
> Ces infos permettent de retrouver ce lien vers un rapport de bogue :
> https://bugzilla.redhat.com/show_bug.cgi?id=1563554
> 
> Ce rapport décrit un phénomène qui ressemble fort à ce qui se passe sur ton 
> système.
> 
> Apparemment, il y a un soucis dans les règles udev, les règles qui gèrent la 
> créations/suppression des fichiers dans le répertorie /dev dont je parle plus 
> haut, ce qui cause le phénomène auquel Sylvie est confrontée.
> 
> Pour confirmer qu'il s'agit bien du même soucis, Sylvie, si tu as la 
> possibilité d'éteindre le bluetooth via un interrupteur ([1]), fais-le et 
> regarde si le processus /lib/systemd/systemd-udevd arrête de prendre tout le 
> CPU.
> 
> Une solution est de modifier lesdites règles udev.
> 
> Je vais encore voir dans les bogues Debian si le même bogue est rapporté et 
> s'il y est mentionné une solution.
> 
> Bonne après-midi.
> 
> Jean-Marc <jean-m...@6jf.be>
> https://6jf.be/keys/ED863AD1.txt
> 
> [1] sur un de mes anciens Dell, il est possible d'éteindre le WiFi et le 
> Bluetooth avec un petit switch.

Attachment: pgpTxNyCGNq1_.pgp
Description: PGP signature

Répondre à