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-marc@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-marc@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-marc@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:
pgpiLRJa8Dwbg.pgp
Description: PGP signature