Re: Résolu: Résumé et tentative d'explication: Problème avec udevd

2020-01-01 Par sujet Bureau LxVx
Bonjour à tous !

@JMarc  : merci infiniment de tes explications et de ton sens pédagogique .

Meilleurs vœux 2020 au Libre et aux libristes !

Sylvie

Le 31/12/2019 à 18:29, Jean-Marc a écrit :
> Tue, 31 Dec 2019 15:39:03 +0100
> Bureau LxVx  écrivait :
>
>> Bonjour à tous !
>>
>> @JMarc
> Bonsoir Sylvie,
>
>> [...]
>>> Content d'avoir pu t'aider, Sylvie.
>> :-D
> Très sincèrement.
>
 En fait, j'avais trouvé cette soluce MAIS ...en ajoutant

 
 j'avais "oublié" l'espace qui suivait (pas tech, j'avais dit ...)
>>> Pour quelqu'un de "pas tech", c'est impressionant !
>> J’espère que ce n'est pas ironique ;-)
> Absolument pas.  Je n'oserai pas.
> Et éditer des fichiers en plus d'y repérer une erreur de syntaxe, c'est déjà 
> très "tech" !
> :-)
>
>>> Donc ... merci : mon apprentissage continue par votre aide et par mes 
>>> erreurs.
>>> Avec grand plaisir !
>>>
>>> Dernier détail : tu ne mentionnes pas si tu as copié le fichier 
>>> 97-hid2hci.rules dans le répertoire /etc/udev/rules.d/ avant de le modifier.
>> J'ai suivi tes conseils "à la lettre"...
>>>   Se faisant, tu évites qu'il ne soit remis dans sa version originale en 
>>> cas de mise à jour du paquet bluez, paquet qui contient ce fichier.
>> Compris ! et ça marche  pour l'instant.
> Super !
>
>> Deux questions :
>>
>>   * quel est le sens de cet ajout ""
> udev gère les périphériques de manière dynamique et fonctionne sur base 
> d'évènements.
> ACTION=="add" dans une règle indique qu'il ne faut suivre la règle uniquement 
> que quand l'évènement "add" survient.  Ce qui, dans le cas qui nous occupe, 
> permet d'éviter que le système ne boucle.
>
> Il faudrait aussi vérifier sur ton système que udev fait bien son boulot.
> Je m'explique.  Si la règle ne s'applique qu'en cas d'évènement de type 
> "add", je me demande si /dev est correctement maintenu et que le périphérique 
> qui causait la boucle est bien accessible.
>
> Dans le rapport de bogue, une autre suggestion proposait d'utiliser un autre 
> pilote plutôt que d'ajouter une limitation basée sur le type d'ACTION.
>
> À voir donc.
>
>>   * pour quelles raisons ne faut-il pas éditer ce fichier ? cf PJ
> La phrase qui dit qu'il ne faut pas éditer le fichier vient du fichier 
> original.
> N'en tiens pas compte.
>
>>> Et, pour info, ce bogue fait l'objet d'un suivi dans le rapport de bogue 
>>> suivant :
>>> . https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=901965
>> J'y ai ajouté quelques infos en espérant relancer les maintainers en vue
>> d'une solution définitive.
>> [...]
>> Merci : je n'aurais pas su faire.
> De rien.  J'espère que cela produira l'effet escompté.
>
>> Bon réveillon à tous !
>>
>> Bien librement,
>>
>> Sylvie
> D'excellentes fêtes à toutes et à tous !
>
> Jean-Marc 
> https://6jf.be/keys/ED863AD1.txt





Re: Résolu: Résumé et tentative d'explication: Problème avec udevd

2019-12-31 Par sujet Jean-Marc
Tue, 31 Dec 2019 15:39:03 +0100
Bureau LxVx  écrivait :

> Bonjour à tous !
> 
> @JMarc

Bonsoir Sylvie,

> [...]
> > Content d'avoir pu t'aider, Sylvie.
> :-D

Très sincèrement.

> >
> >> En fait, j'avais trouvé cette soluce MAIS ...en ajoutant
> >>
> >> 
> >> j'avais "oublié" l'espace qui suivait (pas tech, j'avais dit ...)
> > Pour quelqu'un de "pas tech", c'est impressionant !
> J’espère que ce n'est pas ironique ;-)

Absolument pas.  Je n'oserai pas.
Et éditer des fichiers en plus d'y repérer une erreur de syntaxe, c'est déjà 
très "tech" !
:-)

> > Donc ... merci : mon apprentissage continue par votre aide et par mes 
> > erreurs.
> > Avec grand plaisir !
> >
> > Dernier détail : tu ne mentionnes pas si tu as copié le fichier 
> > 97-hid2hci.rules dans le répertoire /etc/udev/rules.d/ avant de le modifier.
> J'ai suivi tes conseils "à la lettre"...
> >   Se faisant, tu évites qu'il ne soit remis dans sa version originale en 
> > cas de mise à jour du paquet bluez, paquet qui contient ce fichier.
> Compris ! et ça marche  pour l'instant.

Super !

> 
> Deux questions :
> 
>   * quel est le sens de cet ajout ""

udev gère les périphériques de manière dynamique et fonctionne sur base 
d'évènements.
ACTION=="add" dans une règle indique qu'il ne faut suivre la règle uniquement 
que quand l'évènement "add" survient.  Ce qui, dans le cas qui nous occupe, 
permet d'éviter que le système ne boucle.

Il faudrait aussi vérifier sur ton système que udev fait bien son boulot.
Je m'explique.  Si la règle ne s'applique qu'en cas d'évènement de type "add", 
je me demande si /dev est correctement maintenu et que le périphérique qui 
causait la boucle est bien accessible.

Dans le rapport de bogue, une autre suggestion proposait d'utiliser un autre 
pilote plutôt que d'ajouter une limitation basée sur le type d'ACTION.

À voir donc.

>   * pour quelles raisons ne faut-il pas éditer ce fichier ? cf PJ

La phrase qui dit qu'il ne faut pas éditer le fichier vient du fichier original.
N'en tiens pas compte.

> > Et, pour info, ce bogue fait l'objet d'un suivi dans le rapport de bogue 
> > suivant :
> > . https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=901965
> J'y ai ajouté quelques infos en espérant relancer les maintainers en vue
> d'une solution définitive.
> [...]
> Merci : je n'aurais pas su faire.

De rien.  J'espère que cela produira l'effet escompté.

> >
> Bon réveillon à tous !
> 
> Bien librement,
> 
> Sylvie

D'excellentes fêtes à toutes et à tous !

Jean-Marc 
https://6jf.be/keys/ED863AD1.txt


pgp3BRAmJQ53A.pgp
Description: PGP signature


Re: Résolu: Résumé et tentative d'explication: Problème avec udevd

2019-12-31 Par sujet Bureau LxVx
Bonjour à tous !

@JMarc

Le 28/12/2019 à 16:01, Jean-Marc a écrit :
> Sat, 28 Dec 2019 11:24:15 +0100
> Bureau LxVx  écrivait :
>
>> Bonjour à tous !
> salut Sylvie,
>> Je reprends l'Inspiron ce matin et
>>
>> @JMarc : ça marche ! super !
> Content d'avoir pu t'aider, Sylvie.
:-D
>
>> En fait, j'avais trouvé cette soluce MAIS ...en ajoutant
>>
>> 
>> j'avais "oublié" l'espace qui suivait (pas tech, j'avais dit ...)
> Pour quelqu'un de "pas tech", c'est impressionant !
J’espère que ce n'est pas ironique ;-)
> Donc ... merci : mon apprentissage continue par votre aide et par mes erreurs.
> Avec grand plaisir !
>
> Dernier détail : tu ne mentionnes pas si tu as copié le fichier 
> 97-hid2hci.rules dans le répertoire /etc/udev/rules.d/ avant de le modifier.
J'ai suivi tes conseils "à la lettre"...
>   Se faisant, tu évites qu'il ne soit remis dans sa version originale en cas 
> de mise à jour du paquet bluez, paquet qui contient ce fichier.
Compris ! et ça marche  pour l'instant.


Deux questions :

  * quel est le sens de cet ajout ""
  * pour quelles raisons ne faut-il pas éditer ce fichier ? cf PJ

> Et, pour info, ce bogue fait l'objet d'un suivi dans le rapport de bogue 
> suivant :
> . https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=901965
J'y ai ajouté quelques infos en espérant relancer les maintainers en vue
d'une solution définitive.

> Can you, please, advice what is the best solution to, at least, mitigate the 
> risk of being hit by this bug ?  Specifying the ACTION like described in the 
> RH bugreport or using the driver usbhid like in the Тут Root's proposed patch.
>
> And about further investigations, unfortunately, I cannot reproduce the bug 
> and, then, I am not able to investigate further to know if it is really a 
> driver or kernel bug.
Merci : je n'aurais pas su faire.

>> Librement,
>>
>> Sylvie
> Bonne fin de journée.
>
> Jean-Marc 
> https://6jf.be/keys/ED863AD1.txt
Bon réveillon à tous !

Bien librement,

Sylvie
sylinfo84@debian-inspiron:~$ cd /etc/udev/
sylinfo84@debian-inspiron:/etc/udev$ ls
hwdb.d  rules.d  udev.conf
sylinfo84@debian-inspiron:/etc/udev$ cd rules.d/
sylinfo84@debian-inspiron:/etc/udev/rules.d$ ls
59-smfp_samsung.rules  97-hid2hci.rules
sylinfo84@debian-inspiron:/etc/udev/rules.d$ nano 97-hid2hci.rules 
sylinfo84@debian-inspiron:/etc/udev/rules.d$ 

Le résultat (j'ai bien du l'éditer !): 


# do not edit this file, it will be overwritten on update

ACTION=="remove", GOTO="hid2hci_end"
SUBSYSTEM!="usb*", GOTO="hid2hci_end"

# Variety of Dell Bluetooth devices - match on a mouse device that is
# self powered and where a HID report needs to be sent to switch modes
# Known supported devices: 413c:8154, 413c:8158, 413c:8162

ACTION=="add", ATTR{bInterfaceClass}=="03", ATTR{bInterfaceSubClass}=="01", ATT$
  ATTRS{bDeviceClass}=="00", ATTRS{idVendor}=="413c", ATTRS{bmAttributes}=="e0"$
  RUN+="hid2hci --method=dell --devpath=%p", ENV{HID2HCI_SWITCH}="1"

# Logitech devices
KERNEL=="hiddev*", ATTRS{idVendor}=="046d", ATTRS{idProduct}=="c70[345abce]|c71$
  RUN+="hid2hci --method=logitech-hid --devpath=%p"
# Logitech, Inc. diNovo Edge Keyboard
KERNEL=="hidraw*", ATTRS{idVendor}=="046d", ATTRS{idProduct}=="c714", \
  RUN+="hid2hci --method=logitech-hid --devpath=%p"

ENV{DEVTYPE}!="usb_device", GOTO="hid2hci_end"

# When a Dell device recovers from S3, the mouse child needs to be repoked
# Unfortunately the only event seen is the BT device disappearing, so the mouse
# device needs to be chased down on the USB bus.
ATTR{bDeviceClass}=="e0", ATTR{bDeviceSubClass}=="01", ATTR{bDeviceProtocol}=="$
  ENV{REMOVE_CMD}="/sbin/udevadm trigger --action=change --subsystem-match=usb $

# CSR devices
ATTR{idVendor}=="0a12|0458|05ac", ATTR{idProduct}=="1000", RUN+="hid2hci --meth$

LABEL="hid2hci_end"


Résolu: Résumé et tentative d'explication: Problème avec udevd

2019-12-28 Par sujet Jean-Marc
Sat, 28 Dec 2019 11:24:15 +0100
Bureau LxVx  écrivait :

> Bonjour à tous !

salut Sylvie,

> Je reprends l'Inspiron ce matin et
> 
> @JMarc : ça marche ! super !

Content d'avoir pu t'aider, Sylvie.

> En fait, j'avais trouvé cette soluce MAIS ...en ajoutant
> 
> 
> j'avais "oublié" l'espace qui suivait (pas tech, j'avais dit ...)

Pour quelqu'un de "pas tech", c'est impressionant !

> Donc ... merci : mon apprentissage continue par votre aide et par mes erreurs.

Avec grand plaisir !

Dernier détail : tu ne mentionnes pas si tu as copié le fichier 
97-hid2hci.rules dans le répertoire /etc/udev/rules.d/ avant de le modifier.  
Se faisant, tu évites qu'il ne soit remis dans sa version originale en cas de 
mise à jour du paquet bluez, paquet qui contient ce fichier.

Et, pour info, ce bogue fait l'objet d'un suivi dans le rapport de bogue 
suivant :
. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=901965

J'y ai ajouté quelques infos en espérant relancer les maintainers en vue d'une 
solution définitive.

> Librement,
> 
> Sylvie

Bonne fin de journée.

Jean-Marc 
https://6jf.be/keys/ED863AD1.txt


pgp5J5kjVWLk5.pgp
Description: PGP signature


Re: Résumé et tentative d'explication: Problème avec udevd

2019-12-21 Par sujet Bureau LxVx

Le 21/12/2019 à 15:42, Jean-Marc a écrit :
> 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  devant la ligne qui 
> contient 
> 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 
> 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  é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 > 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/pci:00/: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 
>> 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.
Bonsoir Jean-Marc et merci infiniment du résumé et de toutes tes
explications très claires : belle pédagogie.

> 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.
En effet, j'avais bien compris ET ne savais (ou n'osais) faire sans l'aide de 
plus 
compétent que moi d'où mon appel à cette liste.

> Ce qui, pour faire bref, risque de rendre le système inopérant en cas 
> d'ajout/retrait de certains périphériques amovibles.
Bien évidemment. Toutefois, aucun périph amovible n'est branché sur ce pc. Je 
penche pour 
"un vieillissement matériel" de la machine ancienne et de petite config (plutôt 
"bac à sable" 
d'où sans crainte de manip irréversible)

> [1] sur un de mes anciens Dell, il est possible d'éteindre le WiFi et le 
> Bluetooth avec un petit switch.
Je connais : j'ai 2 dell pro avec ce switch que cet inspiron n'a pas.

Je ne suis pas actuellement sur cette machine et je remonterai les résultats 
rapidement.

Merci encore, bon 

Re: Résumé et tentative d'explication: Problème avec udevd

2019-12-21 Par sujet Jean-Marc
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  devant la ligne qui 
contient 
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 
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  é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  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/pci:00/: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 
> 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.


pgpTxNyCGNq1_.pgp
Description: PGP signature


Résumé et tentative d'explication: Problème avec udevd

2019-12-21 Par sujet Jean-Marc
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  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/pci:00/: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 
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.


pgpsPjp0oaVib.pgp
Description: PGP signature


Re: Problème avec udevd

2019-12-21 Par sujet Bureau LxVx
Bonjour Jean-Marc,

> une manière aussi de voir s'il y a un soucis avec un processus, c'est la 
> commande suivante :
>
> journalctl /lib/systemd/systemd-udevd
dernière ligne :

déc. 21 11:50:31 debian-inspiron systemd-udevd[253]: *Process 'hid2hci
--method=dell
--devpath=/devices/pci:00/:00:1a.0/usb2/2-1/2-1.2/2-1.2:1.0'
failed with exit code 1.*

@plus merci

Sylvie


Le 20/12/2019 à 16:43, Jean-Marc a écrit :
> Fri, 20 Dec 2019 15:32:01 +0100
> Bureau LxVx  écrivait :
>
>> Bonjour à tous,
>>
>> Je ne suis pas très "tech" ... et j'ai besoin de votre aide.
>>
>> Depuis mon install de Buster, j'ai le problème ci-dessous qui fait
>> chauffer mon pc.
>> Quel est la raison ppour laquelle cette commande
>> "/lib/systemd/systemd-udevd reste
>> à 99% du temps aux alentours des 100% des coeurs ?
> une manière aussi de voir s'il y a un soucis avec un processus, c'est la 
> commande suivante :
>
> journalctl /lib/systemd/systemd-udevd
>
>> Merci de votre aide,
>>
>> Sylvie
>
> Jean-Marc 
> https://6jf.be/keys/ED863AD1.txt



Re: Problème avec udevd

2019-12-21 Par sujet Bureau LxVx
Bonjour,

Le 20/12/2019 à 21:22, Dethegeek a écrit :
> Bonjour
>
> Ça vaudrait le coup de voir si le système se comporte mieux sans le
> périphérique concerné ?
>
> Il me semble que la commande
>
> lsusb -t
Résultat - il semble que cela se produise sur Dell - j'ai un vieil
inspiron ...) :
> /:  Bus 08.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M
> /:  Bus 07.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M
> /:  Bus 06.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M
> |__ Port 2: Dev 2, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M
> /:  Bus 05.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M
> /:  Bus 04.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M
> /:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/6p, 480M
> /:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M
> |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/3p, 12M
> |__ Port 1: Dev 3, If 0, Class=Human Interface Device, Driver=usbhid, 
> 12M
> |__ Port 2: Dev 4, If 0, Class=Human Interface Device, Driver=, 12M
> |__ Port 3: Dev 5, If 2, Class=Vendor Specific Class, Driver=, 12M
> |__ Port 3: Dev 5, If 0, Class=Wireless, Driver=btusb, 12M
> |__ Port 3: Dev 5, If 3, Class=Application Specific Interface, 
> Driver=, 12M
> |__ Port 3: Dev 5, If 1, Class=Wireless, Driver=btusb, 12M
> /:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/6p, 480M
> |__ Port 6: Dev 4, If 0, Class=Video, Driver=uvcvideo, 480M
> |__ Port 6: Dev 4, If 1, Class=Video, Driver=uvcvideo, 480M


>
> devrait aider à trouver ce qui correspond à 2-1.2
>
> En espérant que ce ne soit pas un périphérique interne à un PC
> portable, car c'est tout de suite un peu plus compliqué à débrancher :)
>
>
>
> Le 20 décembre 2019 18:00:28 GMT+01:00, Bureau LxVx
>  a écrit :
>
> J'ai mis "résolu". Comme j'ai redémarré, le pb se représente. et
> j'ai suivi ce lien d'aide :
> 
> https://ikalay.blogspot.com/2018/09/systemd-udevd-too-much-cpu-using-solving.html
>
> si vous voulez aller plus loin :
>
> udevadm monitor
>
>
>
> Trop "tech" pour moi ; il apparaîtrait bien un pb kernel
> ...désolée ...
>
> Merci à tous.
>
> Sylvie
>
>
> Le 20/12/2019 à 16:49, ajh-valmer a écrit :
>> On Friday 20 December 2019 15:32:01 Bureau LxVx wrote:
>>> Je ne suis pas très "tech" ... et j'ai besoin de votre aide.
>>> Depuis mon install de Buster, j'ai le problème ci-dessous qui fait
>>> chauffer mon pc.
>>> Quel est la raison pour laquelle cette commande
>>> "/lib/systemd/systemd-udevd reste
>>> à 99% du temps aux alentours des 100% des coeurs ?
>> Quelle est cette commande  "/lib/systemd/systemd-udevd" ?
>>
>> Merci.
>>
>
>
> -- 
> Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez
> excuser ma brièveté. 



Re: Problème avec udevd

2019-12-21 Par sujet Bureau LxVx
Bonjour Bernard,

Comme je l'ai dit précédemment, je ne suis pas "tech" et ce n'est pas
facile de suivre même si je lis la plupart de vos échanges.
Copie "history" de mon terminal et de "ce que j'ai fait" (mal peut-être) :

en root  "sudo -s" , entrée après chaque commande.
>
>    19  cat >/etc/init.d/systemd-udevd-solv.sh <    20  #!/bin/sh
>    21  systemctl stop systemd-udevd systemd-udevd-kernel.socket
> systemd-udevd-control.socket
>    22  sleep 5
>    23  systemctl start systemd-udevd systemd-udevd-kernel.socket
> systemd-udevd-control.socket
>    24  EOF
>    25  chmod a+x /etc/init.d/systemd-udevd-solv.sh
Si c'est ok : pas de changement au redémarrage.
Si j'ai mal compris et fait des erreurs : merci de m'éclairer (l'erreur
est la preuve d'être en cours d'apprentissage)

Merci.

Sylvie

N.B : j'essaie d'appliquer un conseil à la fois ;-)


Le 20/12/2019 à 20:55, Bernard Schoenacker a écrit :
> - Mail original - 
>
>> De: "Bureau LxVx" 
>> À: debian-user-french@lists.debian.org
>> Envoyé: Vendredi 20 Décembre 2019 16:46:06
>> Objet: Re: Problème avec udevd
>> Bonjour Bernard et merci de ton aide précieuse.
>> Pour partager ma soluce, je suis allée via ton lien conseillé sur :
>> https://ikalay.blogspot.com/2018/09/systemd-udevd-too-much-cpu-using-solving.html
>> et la bonne commande est :
>> sudo systemctl stop systemd-udevd systemd-udevd-control.socket
>> systemd-udevd-kernel.socket
>> C'est ok. A relancer à chaque démarrage.
>> @pluX
>> Sylvie
> bonjour Sylvie,
>
> pourrais tu simplement relire la doc que je t'ai indiqué (?)
> afin de simplement créer un fichier exécutable qui arrête le 
> processus au démarrage ?
>
> dans le terminal (copier coller) :
>
> sudo -s
>
> cat >/etc/init.d/systemd-udevd-solv.sh <
> #!/bin/sh
>
> systemctl stop systemd-udevd systemd-udevd-kernel.socket 
> systemd-udevd-control.socket
>
> sleep 5
>
> systemctl start systemd-udevd systemd-udevd-kernel.socket 
> systemd-udevd-control.socket
>
> EOF
>  
> chmod a+x /etc/init.d/systemd-udevd-solv.sh
>
> merci pour ton aimable
>
> attention
>
> bien à toi
> bernard
>




Re: Problème avec udevd

2019-12-20 Par sujet Dethegeek
Bonjour

Ça vaudrait le coup de voir si le système se comporte mieux sans le 
périphérique concerné ?

Il me semble que la commande

lsusb -t

devrait aider à trouver ce qui correspond à 2-1.2

En espérant que ce ne soit pas un périphérique interne à un PC portable, car 
c'est tout de suite un peu plus compliqué à débrancher :)



Le 20 décembre 2019 18:00:28 GMT+01:00, Bureau LxVx 
 a écrit :
>J'ai mis "résolu". Comme j'ai redémarré, le pb se représente. et j'ai
>suivi ce lien d'aide :
>https://ikalay.blogspot.com/2018/09/systemd-udevd-too-much-cpu-using-solving.html
>
>si vous voulez aller plus loin :
>
>udevadm monitor
>
>
>
>Trop "tech" pour moi ; il apparaîtrait bien un pb kernel ...désolée ...
>
>Merci à tous.
>
>Sylvie
>
>
>Le 20/12/2019 à 16:49, ajh-valmer a écrit :
>> On Friday 20 December 2019 15:32:01 Bureau LxVx wrote:
>>> Je ne suis pas très "tech" ... et j'ai besoin de votre aide.
>>> Depuis mon install de Buster, j'ai le problème ci-dessous qui fait
>>> chauffer mon pc.
>>> Quel est la raison pour laquelle cette commande
>>> "/lib/systemd/systemd-udevd reste
>>> à 99% du temps aux alentours des 100% des coeurs ?
>> Quelle est cette commande  "/lib/systemd/systemd-udevd" ?
>>
>> Merci.
>>

-- 
Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma 
brièveté.

Re: Problème avec udevd

2019-12-20 Par sujet Bernard Schoenacker


- Mail original - 

> De: "Bureau LxVx" 
> À: debian-user-french@lists.debian.org
> Envoyé: Vendredi 20 Décembre 2019 16:46:06
> Objet: Re: Problème avec udevd

> Bonjour Bernard et merci de ton aide précieuse.

> Pour partager ma soluce, je suis allée via ton lien conseillé sur :
> https://ikalay.blogspot.com/2018/09/systemd-udevd-too-much-cpu-using-solving.html

> et la bonne commande est :
> sudo systemctl stop systemd-udevd systemd-udevd-control.socket
> systemd-udevd-kernel.socket

> C'est ok. A relancer à chaque démarrage.

> @pluX

> Sylvie

bonjour Sylvie,

pourrais tu simplement relire la doc que je t'ai indiqué (?)
afin de simplement créer un fichier exécutable qui arrête le 
processus au démarrage ?

dans le terminal (copier coller) :

sudo -s

cat >/etc/init.d/systemd-udevd-solv.sh <

Re: Problème avec udevd

2019-12-20 Par sujet Jean-Marc
Fri, 20 Dec 2019 15:32:01 +0100
Bureau LxVx  écrivait :

> Bonjour à tous,

salut Sylvie,

> Je ne suis pas très "tech" ... et j'ai besoin de votre aide.
> 
> Depuis mon install de Buster, j'ai le problème ci-dessous qui fait
> chauffer mon pc.
> Quel est la raison ppour laquelle cette commande
> "/lib/systemd/systemd-udevd reste
> à 99% du temps aux alentours des 100% des coeurs ?

Je pense que tu pourrais commencer par essayer de trouver si udev reçoit des 
events qui pourrait expliquer ce phénomène.

Ouvre un terminal et tape la commande suivante :
udevadm monitor

Cela devrait te permettre de voir l'activité de udev.  CTRL+C permet d'arrêter 
la commande.

Une autre piste est de regarder dans les fichiers de logs si tu n'as pas 
d'erreurs.

Dans un terminal,
1/ change le répertoire de travail :
cd /var/log

2/ regarde les fichiers modifiés récemment :
ls -ltr

Pour lire les fichiers, utilise la commande .

Ou fais une recherche du terme "error" dans les fichier avec la commande :
grep -i error nom-de-fichier

> Merci de votre aide,

Bonne chance.

> Sylvie

Jean-Marc 
https://6jf.be/keys/ED863AD1.txt


pgpwnxGY5KVnW.pgp
Description: PGP signature


Re: Problème avec udevd

2019-12-20 Par sujet Bureau LxVx
J'ai mis "résolu". Comme j'ai redémarré, le pb se représente. et j'ai
suivi ce lien d'aide :
https://ikalay.blogspot.com/2018/09/systemd-udevd-too-much-cpu-using-solving.html

si vous voulez aller plus loin :

udevadm monitor



Trop "tech" pour moi ; il apparaîtrait bien un pb kernel ...désolée ...

Merci à tous.

Sylvie


Le 20/12/2019 à 16:49, ajh-valmer a écrit :
> On Friday 20 December 2019 15:32:01 Bureau LxVx wrote:
>> Je ne suis pas très "tech" ... et j'ai besoin de votre aide.
>> Depuis mon install de Buster, j'ai le problème ci-dessous qui fait
>> chauffer mon pc.
>> Quel est la raison pour laquelle cette commande
>> "/lib/systemd/systemd-udevd reste
>> à 99% du temps aux alentours des 100% des coeurs ?
> Quelle est cette commande  "/lib/systemd/systemd-udevd" ?
>
> Merci.
>



Re: Problème avec udevd

2019-12-20 Par sujet Jean-Marc
Fri, 20 Dec 2019 15:32:01 +0100
Bureau LxVx  écrivait :

> Bonjour à tous,
> 
> Je ne suis pas très "tech" ... et j'ai besoin de votre aide.
> 
> Depuis mon install de Buster, j'ai le problème ci-dessous qui fait
> chauffer mon pc.
> Quel est la raison ppour laquelle cette commande
> "/lib/systemd/systemd-udevd reste
> à 99% du temps aux alentours des 100% des coeurs ?

une manière aussi de voir s'il y a un soucis avec un processus, c'est la 
commande suivante :

journalctl /lib/systemd/systemd-udevd

> Merci de votre aide,
> 
> Sylvie


Jean-Marc 
https://6jf.be/keys/ED863AD1.txt


pgpuiRKrQ4cSI.pgp
Description: PGP signature


Re: Problème avec udevd - RESOLU

2019-12-20 Par sujet Bureau LxVx
Peut-être me suis-je mal exprimée (pas tech...)

Le 20/12/2019 à 16:49, ajh-valmer a écrit :
> On Friday 20 December 2019 15:32:01 Bureau LxVx wrote:
>> Je ne suis pas très "tech" ... et j'ai besoin de votre aide.
>> Depuis mon install de Buster, j'ai le problème ci-dessous qui fait
>> chauffer mon pc.
>> Quel est la raison pour laquelle cette commande
>> "/lib/systemd/systemd-udevd reste
>> à 99% du temps aux alentours des 100% des coeurs ?
> Quelle est cette commande  "/lib/systemd/systemd-udevd" ?
Dans cette capture, htop, dernière colonne "command" :


Après la "fameuse commande :


> Merci.
Merci aussi.


Sylvie


Re: Problème avec udevd

2019-12-20 Par sujet ajh-valmer
On Friday 20 December 2019 15:32:01 Bureau LxVx wrote:
> Je ne suis pas très "tech" ... et j'ai besoin de votre aide.
> Depuis mon install de Buster, j'ai le problème ci-dessous qui fait
> chauffer mon pc.
> Quel est la raison pour laquelle cette commande
> "/lib/systemd/systemd-udevd reste
> à 99% du temps aux alentours des 100% des coeurs ?

Quelle est cette commande  "/lib/systemd/systemd-udevd" ?

Merci.



Re: Problème avec udevd

2019-12-20 Par sujet Bureau LxVx
Bonjour Bernard et merci de ton aide précieuse.

Pour partager ma soluce, je suis allée via ton lien conseillé sur :
https://ikalay.blogspot.com/2018/09/systemd-udevd-too-much-cpu-using-solving.html

et la bonne commande est :
sudo systemctl stop systemd-udevd systemd-udevd-control.socket
systemd-udevd-kernel.socket

C'est ok. A relancer à chaque démarrage.

@pluX

Sylvie

Le 20/12/2019 à 16:06, G2PC a écrit :
> Le 20/12/2019 à 15:32, Bureau LxVx a écrit :
>> Depuis mon install de Buster, j'ai le problème ci-dessous qui fait
>> chauffer mon pc.
>> Quel est la raison ppour laquelle cette commande
>> "/lib/systemd/systemd-udevd reste
>> à 99% du temps aux alentours des 100% des coeurs ?
>>
>>
>>
>> Merci de votre aide,
>>
>> Sylvie
>
> Sur Ubuntu, il est question de mettre le Kernel à jour, en tout cas,
> c'est un problème connu.
> Tu peux voir si tu trouves des informations ici, en traduisant cette page.
>
> https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1759836
>



Re: Problème avec udevd

2019-12-20 Par sujet fab

salut,

un peu au pif. Vire ton bleuetooth si tu n'en a pas besoin ?

https://unix.stackexchange.com/questions/433393/systemd-udevd-high-cpu-usage

f.


Le 20/12/2019 à 15:32, Bureau LxVx a écrit :

Bonjour à tous,

Je ne suis pas très "tech" ... et j'ai besoin de votre aide.

Depuis mon install de Buster, j'ai le problème ci-dessous qui fait 
chauffer mon pc.
Quel est la raison ppour laquelle cette commande 
"/lib/systemd/systemd-udevd reste

à 99% du temps aux alentours des 100% des coeurs ?



Merci de votre aide,

Sylvie





Re: Problème avec udevd

2019-12-20 Par sujet G2PC
Le 20/12/2019 à 15:32, Bureau LxVx a écrit :
> Depuis mon install de Buster, j'ai le problème ci-dessous qui fait
> chauffer mon pc.
> Quel est la raison ppour laquelle cette commande
> "/lib/systemd/systemd-udevd reste
> à 99% du temps aux alentours des 100% des coeurs ?
>
>
>
> Merci de votre aide,
>
> Sylvie

Sur Ubuntu, il est question de mettre le Kernel à jour, en tout cas,
c'est un problème connu.
Tu peux voir si tu trouves des informations ici, en traduisant cette page.

https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1759836



Re: Problème avec udevd

2019-12-20 Par sujet Bernard Schoenacker

- Mail original - 

> De: "Bureau LxVx" 
> À: "Debian user french" 
> Envoyé: Vendredi 20 Décembre 2019 15:32:01
> Objet: Problème avec udevd

> Bonjour à tous,

> Je ne suis pas très "tech" ... et j'ai besoin de votre aide.

> Depuis mon install de Buster, j'ai le problème ci-dessous qui fait
> chauffer mon pc.
> Quel est la raison ppour laquelle cette commande
> "/lib/systemd/systemd-udevd reste
> à 99% du temps aux alentours des 100% des coeurs ?

> Merci de votre aide,

> Sylvie

bonjour,

voici un début de piste :

https://askubuntu.com/questions/1017571/what-nasty-systemd-udevd-overloading-my-cpu

merci

@+
bernard

Problème avec udevd

2019-12-20 Par sujet Bureau LxVx
Bonjour à tous,

Je ne suis pas très "tech" ... et j'ai besoin de votre aide.

Depuis mon install de Buster, j'ai le problème ci-dessous qui fait
chauffer mon pc.
Quel est la raison ppour laquelle cette commande
"/lib/systemd/systemd-udevd reste
à 99% du temps aux alentours des 100% des coeurs ?



Merci de votre aide,

Sylvie