Vous n'êtes pas identifié(e).
Pages : 1
call
Voici quelques maneuvres effectuées durant mes recherches.
examen de apt history
Start-Date: 2020-12-28 22:11:06
Commandline: apt upgrade
Requested-By: polo (1001)
Upgrade: libservlet3.1-java:i386 (8.5.54-0+deb9u4, 8.5.54-0+deb9u5), linux-libc-
dev:i386 (4.9.240-2, 4.9.246-2), libcurl3:i386 (7.52.1-5+deb9u12, 7.52.1-5+deb9u
13), openjdk-8-jdk:i386 (8u272-b10-0+deb9u1, 8u275-b01-1~deb9u1), openjdk-8-jre:
i386 (8u272-b10-0+deb9u1, 8u275-b01-1~deb9u1), openssl:i386 (1.1.0l-1~deb9u1, 1.
1.0l-1~deb9u2), libsqlite3-0:i386 (3.16.2-5+deb9u2, 3.16.2-5+deb9u3), python-lxm
l:i386 (3.7.1-1+deb9u1, 3.7.1-1+deb9u3), openjdk-8-jdk-headless:i386 (8u272-b10-
0+deb9u1, 8u275-b01-1~deb9u1), linux-image-4.9.0-14-686-pae:i386 (4.9.240-2, 4.9
.246-2), libopenexr22:i386 (2.2.0-11+deb9u1, 2.2.0-11+deb9u2), openjdk-8-jre-hea
dless:i386 (8u272-b10-0+deb9u1, 8u275-b01-1~deb9u1), libssl1.1:i386 (1.1.0l-1~de
b9u1, 1.1.0l-1~deb9u2), libcurl3-gnutls:i386 (7.52.1-5+deb9u12, 7.52.1-5+deb9u13
), firefox-esr:i386 (78.5.0esr-1~deb9u1, 78.6.0esr-1~deb9u1), libssl1.0.2:i386 (
1.0.2u-1~deb9u2, 1.0.2u-1~deb9u3), openjdk-8-doc:i386 (8u272-b10-0+deb9u1, 8u275
-b01-1~deb9u1)
End-Date: 2020-12-28 22:14:46
On y voit une mise à jour du noyaux.
lorsque je lance avec le noyau qui fonctionne linux-image-4.9.0-13-686-pae
lorsque je lance avec le noyau qui ne fonctionne pas linux-image-4.9.0-14-686-pae
Dans un premier temps j'ai pensé que charger les modules manquant avec modprobe suffirait!
Que neni point de souris en vue!
j'ai donc comparé les dmesg
avec le noyau qui fonctionne linux-image-4.9.0-13-686-pae
là la ligne new low-speed USB device number 2 using ohci-pci semble intéressante
avec le noyau qui ne fonctionne pas linux-image-4.9.0-14-686-pae
aucune trace de la souris
si on regarde les lsmod fait plus haut, on trouve un module ohci_pci qui ressemble furieusement au ohci-pci trouvé avec le
dmseg | grep usb de la version qui fonctionne.
De plus on peut voir qu'il est une dépendance de usbcore.
je tente
et maintenant la souris est détectée
et journalisée
Bon c'est bien joli mais pas très propre, je pense que le problème vient de la mise à jour au moment de la construction
de l'initrd image.
Si quelqu'un à une idée !:D
Hors ligne
-->les cahiers du debutant<-- WikiDF-->Découvrir les principales commandes Linux<--
L' expérience, c'est le nom que chacun donne à ses erreurs. Oscar Wilde
En ligne
j'ai pensé que charger les modules manquant avec modprobe suffirait!
Ne pas inverser les causes et les conséquences.
Les modules "manquants" sont les pilotes de périphériques HID (claviers, souris USB...). Ils ne sont pas chargés parce que la souris n'est pas détectée, comme on peut le voir avec lsusb.
aucune trace de la souris
Pas d'autres messages liés à l'USB ?
un module ohci_pci qui ressemble furieusement au ohci-pci
Le tiret et l'underscore sont équivalents et interchangeables dans les noms de modules/pilotes du noyau.
et maintenant la souris est détectée
et journalisée
C'est le log obtenu avec le noyau 4.9.0-13 que tu as remis.
Il n'y aurait pas une histoire de "hand off" (ou approchant) entre l'USB 2 (ehci) et l'USB 1 (ohci/uhci) ?
Il vaut mieux montrer que raconter.
Hors ligne
Petite précision qui a son importance, la manœuvre expliquée avec modprobe ne marche pas pour mon système sur disque USB.
Là, je suis obligé d'effectuer la commande au boot en provoquant un arrêt par paramètre break=top passé au noyau(dans cette phase on n’a pas besoin du disque).
raleur , peux-tu préciser ce que tu entends par "hand off" (ou approchant) entre l'USB 2 (ehci) et l'USB 1 (ohci/uhci)?
Merci !
Hors ligne
la manœuvre expliquée avec modprobe ne marche pas pour mon système sur disque USB.
Pourquoi ? Le noyau refuse de décharger le module parce qu'il est utilisé pour accéder au disque USB, donc tu ne peux le faire que tôt pendant l'exécution de l'initramfs, avant que la racine soit montée ?
peux-tu préciser ce que tu entends par "hand off" (ou approchant) entre l'USB 2 (ehci) et l'USB 1 (ohci/uhci)?
Je faisais référence à l'EHCI hand-off. Pour un même port USB il y a deux contrôleurs et pilotes selon le type de périphérique, ohci pour USB 1.1 ou ehci pour USB 2.0. D'après ce que j'ai compris, l'EHCI hand-off est le mécanisme pour router un périphérique vers l'un ou l'autre, géré par le BIOS ou les pilotes de l'OS.
Il peut y avoir une option de ce type dans les réglages du BIOS. Le module ohci-hcd a un paramètre "no_handshake" qui pourrait être lié. Mais c'est juste une idée, ça n'a peut-être rien à voir.
J'ai regardé les changelogs du noyau 4.9.0-14 de stretch et j'y ai trouvé ceci :
usb: ohci: Default to per-port over-current protection
Idem dans les changelogs du dernier noyau 4.19.0-13 de buster. Quel est la version du noyau sur ton disque USB ? As-tu encore le noyau précédent 4.19.0-12 pour comparer ?
Le module ohci-hcd a un paramètre "distrust_firmware" pour ne pas faire confiance aux réglages power/over-current du BIOS, peut-être que ça peut aider.
Dernière modification par raleur (05-01-2021 23:54:30)
Il vaut mieux montrer que raconter.
Hors ligne
sur Stretch
vermagic: 4.9.0-13-686-pae SMP mod_unload modversions 686
parm: distrust_firmware:true to distrust firmware power/overcurrent setup (bool)
parm: no_handshake:true (not default) disables BIOS handshake (bool)
vermagic: 4.9.0-14-686-pae SMP mod_unload modversions 686
parm: distrust_firmware:true to distrust firmware power/overcurrent setup (bool)
parm: no_handshake:true (not default) disables BIOS handshake (bool)
Buster USB
name: ohci_hcd
vermagic: 4.19.0-13-686-pae SMP mod_unload modversions 686
signat: PKCS#7
signer:
sig_key:
sig_hashalgo: md4
parm: distrust_firmware:true to distrust firmware power/overcurrent setup (bool)
parm: no_handshake:true (not default) disables BIOS handshake (bool)
vermagic: 4.19.0-8-686-pae SMP mod_unload modversions 686
signat: PKCS#7
signer:
sig_key:
sig_hashalgo: md4
parm: distrust_firmware:true to distrust firmware power/overcurrent setup (bool)
parm: no_handshake:true (not default) disables BIOS handshake (bool)
Je ne vois aucune différence mais bon! Je continue à chercher.
Hors ligne
voici les noyaux encore disponibles sur mon disque usb
vmlinuz-4.19.0-13-686-pae
vmlinuz-4.19.0-8-686-pae
vmlinuz-4.19.0-6-686-pae
Est-ce que le problème se produit aussi avec le -8 ?
Et tu n'as pas répondu à toutes mes questions précédentes.
un exemple de la commande utilisée:
Il y a un peu plus court :
Je ne vois aucune différence
Les paramètres sont les mêmes, mais il faut peut-être jouer sur leur valeur (via la ligne de commande du noyau au démarrage) pour tenter de contourner le problème.
Dernière modification par raleur (06-01-2021 17:35:30)
Il vaut mieux montrer que raconter.
Hors ligne
J'ai essayé de le mettre plus tôt dans le boot mais, alors ça ne marche pas.
voici le script :
puis en me créant une version initramfs dans un répertoire à part
Pour le boot (dans GRUB) il suffit d'éditer la ligne de l'initrd et de modifier le chemin.
De cette manière je n'oublierais pas que quelque chose ne tourne pas rond.
J'ai aussi tenté quelques essais sur la ligne de commande du kernel sans succès.
Mais il faudra que j'y retravaille pour documenter un peu mieux avant de présenter ça ici.
Hors ligne
J'ai le même problème avec une carte arduino uno.
USB 1 ou 2 ?
Par contre aucun souci avec les clés usb.
Qui sont USB 2.
j'ai trouvé une solution acceptable pour mon cas en créant un script dans /etc/initramfs-tools/scripts/init-premount/
Je pense qu'il aurait été possible de le faire avec une directive "install" de modprobe. Les fichiers /etc/modprobe.d/*.conf sont automatiquement inclus dans l'initramfs.
J'ai aussi tenté quelques essais sur la ligne de commande du kernel sans succès.
Mais il faudra que j'y retravaille pour documenter un peu mieux avant de présenter ça ici.
Oui, merci, ça m'intéresse.
Il vaut mieux montrer que raconter.
Hors ligne
raleur demande :
USB 1 ou 2 ?
ohci_pci dépend de hoci_hcd et donc je présume que ces modules gère l'usb 1.1 et pas le 2.0
Maintenant voici ce qui intéresse raleur et avec raisons :
Ajout de
sur la ligne du noyau au boot et vérification une fois connecté.
Et la souris fonctionne.
De ça je crée un fichier
contenant:
puis
Beaucoup plus simple que ce que je fais plus haut
Petites questions :
Cette correction n'aurait-elle pas dû être introduite dans la mise à jour ?
Si oui, il s'agit d'un bug qui doit peut-être être rapporté.
Si non le changelog dont raleur parle plus haut doit être pris en considération par les utilisateurs et il est à supposer que certaines machines ne supportent pas ce changement de paramètre.
Merci à raleur
Hors ligne
ohci_pci dépend de ohci_hcd et donc je présume que ces modules gère l'usb 1.1 et pas le 2.0
Oui, OHCI est un type d'interface pour les contrôleurs hôtes USB 1.1 mais ma question portait sur le type d'USB de l'Arduino, le périphérique.
ohci_hcd.distrust_firmware=0
Cela m'a surpris car j'aurais plutôt pensé que 0 était déjà la valeur par défaut, mais il s'avère que c'est le contraire, du moins pour cette version du noyau (voir plus bas). Mais impossible de vérifier simplement en chargeant le module car celui-ci n'exporte pas ses paramètres dans /sys/module/ohci_hcd.
De ça je crée un fichier /etc/modprobe.d/ohci_distrust_firmware.conf
Tu aurais pu te contenter d'ajouter le paramètre dans la ligne de commande du noyau de façon permanente via /etc/default/grub et update-grub. Il me semble que c'est un peu plus souple pour le supprimer en direct au démarrage via le chargeur d'amorçage.
Cette correction n'aurait-elle pas dû être introduite dans la mise à jour ?
Très bonne question. Le patch "usb: ohci: Default to per-port over-current protection" a été introduit initialement dans le noyau amont 5.10 puis rétroporté dans les versions "longterm" amont comme 4.9.x et 4.19.x sur lesquelles les noyaux Debian de stretch et buster sont basés respectivement. Or un autre patch du même auteur a été introduit en même temps dans la version 5.10 :
Mais ce second patch n'a pas été rétroporté dans les versions longterm 4.9 et 4.19. Cela peut se comprendre : d'une part il modifie un réglage par défaut, ce qui va à l'encontre d'une version stable, d'autre part a priori il ne s'agit pas d'une correction de bug et il n'est pas directement lié au patch précédent.
https://git.kernel.org/pub/scm/linux/ke … .c?h=v5.10
https://git.kernel.org/pub/scm/linux/ke … h=v4.9.246
https://git.kernel.org/pub/scm/linux/ke … =v4.19.160
Si oui, il s'agit d'un bug qui doit peut-être être rapporté.
Tu peux envoyer un rapport de bug à Debian en demandant l'inclusion du second patch. De mon côté quand j'aurais le temps j'ai bien envie de tester sur quelques vieilles machines avec des chipset USB OHCI pour voir si le problème est spécifique à ton PC ou plus général. Il ne faudrait pas que le changement de valeur par défaut cause plus de problèmes qu'il n'en résoud.
Il vaut mieux montrer que raconter.
Hors ligne
souris (partie de dmesg)
Le même module ohci-pci.
Et pour être complet une partie de
Arduino
la souris
Il est vrai que la machine à un âge plus que respectable (2006 si mes souvenirs sont bons, sous Debian depuis quelque temps aussi.
Preuve que , non, Linux ne grille pas le matériel).
Ceci dit , je ne vais pas considérer qu'il s'agit d'un bug car le dique usb fonctionne avec ou sans la correction sur d'autres machines.
Merci encore, je trouve le site vraiment intéressant !
Et il me reste encore beaucoup à y apprendre.
Hors ligne
Le même module ohci-pci.
Oui, donc c'est un périphérique USB 1.1 comme la souris, alors que le disque est USB 2.0 géré par ehci.
la machine a un âge plus que respectable (2006 si mes souvenirs sont bons
Quel est son chipset USB ?
J'ai testé sur des machines utilisant l'interface OHCI (deux Athlon 64 avec chipset Nvidia MCP61, un Core 2 Duo avec chipset Nvidia MCP73 et un Athlon XP avec chipset Nvidia nForce 2 et un Sempron 32 bits avec chipset VIA VT8235) et les deux noyaux linux-image-4.9.0-14-686-pae et linux-image-4.19.0-13-686-pae, impossible de reproduire le bug.
Edit : le chipset VIA utilise l'interface UHCI donc n'est pas concerné.
Ceci dit , je ne vais pas considérer qu'il s'agit d'un bug
C'est indubitablement un bug, mais la question est de savoir quelle est sa fréquence : s'il affecte une proportion non négligeable de chipsets USB OHCI, le chipset particulier de ta carte mère ou spécifiquement ton modèle de carte mère.
car le disque usb fonctionne avec ou sans la correction sur d'autres machines.
Tu veux dire que le système installé sur ce disque voit bien les périphériques USB 1.1 lorsqu'il tourne sur d'autres machines ?
Est-ce que les autres machines ont aussi un chipset USB 1.1 OHCI ?
Dernière modification par raleur (20-01-2021 09:39:34)
Il vaut mieux montrer que raconter.
Hors ligne
J'epère que tu as suffisament d'infos pour comparer par rapport à tes propres tests !
( pour ce qui nous concerne "Silicon Integrated Systems" )
Pour l'autre machine tu as raison en réalité elle utilise ehci et non ohci pour la souris.
Au temps pour moi !
J'ai suivi ton conseil et placé mon paramètre dans la ligne de boot, et il suffit de passer ohci-hcd.distrust_firmware=1 valeur par défaut
pour provoquer le bug.
Hors ligne
Hors ligne
J'epère que tu as suffisament d'infos pour comparer par rapport à tes propres tests !
( pour ce qui nous concerne "Silicon Integrated Systems" )
SiS n'était pas le fabricant de chipsets le plus réputé, que ce soit pour les cartes mères ou les cartes graphiques.
J'ai cherché dans mon stock de vieilles cartes mères, mais je n'en ai aucune avec un chipset SiS. Je n'ai que des cartes mères à chipset UHCI (Intel et VIA) non concernés ou à chipset OHCI Nvidia (du nForce 2 pour Athlon 32 au MCP73 pour Core 2 Duo) avec lesquels je n'ai pas constaté le problème. Pas de chipset ATI, ALi ou autre qui utilise l'interface OHCI.
Pour l'autre machine tu as raison en réalité elle utilise ehci et non ohci pour la souris.
Tu es sûr ? Ce n'est pas plutôt UHCI ou xHCI ? L'interface EHCI est pour les contrôleurs et périphériques USB 2.0. J'ai lu qu'il existait des chipset intégrant un pont USB 1.1-USB 2.0 pour que les périphériques USB 1.1 puissent être gérés par le contrôleur EHCI, mais je n'en ai jamais vu.
ok j'ai rapporté le bug !
Quel numéro ?
Il vaut mieux montrer que raconter.
Hors ligne
Hors ligne
Il vaut mieux montrer que raconter.
Hors ligne
Il vaut mieux montrer que raconter.
Hors ligne
Pages : 1