Ports USB3 qui répondent mal

Support Debian
#3

[quote=“Algarda”][quote]Je me demande ce que sont toutes ces lignes en “xhci_hcd 0000:04:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff8801bfd38*”…
[/quote]

il s’agirais d’un bug , je n’ai trouver que cela : google.fr/search?q=xhci_hcd … Axhci_drop[/quote]

Merci pour cette réponse. En effet, j’ai fait quelques recherches là-dessus, parfois en connexion avec le nom de mon USB controller ( ASMedia Technology Inc. ASM1042 SuperSpeed USB Host Controller ) qui semble poser problème. Ce qui m’ennuie, c’est que les messages qui parlent de bug sont assez vieux, concernent des noyaux plus récents que celui de Debian Wheezy (voir le uname -a plus haut).

Ce qui m’ennuie aussi, c’est que dans toutes ces vieilles discussions sur le sujet, je n’arrive pas à trouver une solution qui fonctionne chez moi.

Pour l’instant, quand je branche un disque dur sur le port USB3, je vais faire le café, la vaisselle, les vitres, etc., et il finit par ce monter tout seul… :slightly_smiling: Et ensuite je peux l’utiliser de manière assez fiable. [edit 2 : j’ai chronométré, ça prend un tout petit peu moins de 20 minutes…]

[edit] Par contre en recherchant sur le controleur USB tout seul, je trouve des discussions plus récentes, comme par exemple forums.opensuse.org/showthread.p … alfunction Mais d’abord dans /etc/modeprob.d je n’ai pas de blacklist.conf, j’ai testé d’en créer un pour y mettre le blacklist uas et pour le udev, j’ai aussi testé, mais sans succès.

D’ailleurs, cette règle udev, ça m’a fait pensé que récemment j’ai ajouté une règle udev pour pouvoir connecter mon Geeksphone Peak sous Firefox OS sur ma Debian. Alors, j’ai supprimé cette règle pour voir, mais sans succès.

Bref, je nage un peu…

#4

Chose amusante, pendant ces 20 minutes, je ne peux pas monter d’autres périphériques sur des ports USB : “DBus error org.gtk.Private.RemoteVolumeMonitor.Failed: An operation is already pending”.

#5

bonjour.

Dans ce genre de situation, après avoir fouille sur le net, et
si rien de nouveau, je le connecte à l’arrière (ce que tu as déjà fait) et qui évite les problèmes (rares) de câble (chute de tension ou/et autres pbs divers) entre carte mère et connecteur USB,
si rien de nouveau, Je vérifie que l’alimentation du disque est correcte (échange),
si rien de nouveau, je change de cordon USB,
si rien de nouveau, je met à jour le système debian,
si rien de nouveau, je tente un essais avec une version Live ou une autre installation vite fait (1/2 heure max),
si rien de nouveau, je vérifie la version du BIOS P8H61 BIOS 4306 et Je remets à jour le système debian,
si rien de nouveau, je tente un échange de boîtier,
si rien de nouveau, j’installe un autre disque dans le boîtier pour tester le boîtier,
si rien de nouveau, je connecte le disque directement par sata (sans son boîtier, donc) pour le tester.
Après…je vais me détendre avant de continuer.

#6

Hello MiCP,

Merci pour cette procédure très détaillée qui me donne en effet des idées et des pistes ! :slightly_smiling:

#7

J’en oublie peut-être d’autres, mais c’est ce qui me viens à l’idée.
D’autres intervenants ont peut-être aussi des méthodes efficaces que je ne connais pas (et que je serai très content de découvrir)

Pour le BIOS, par contre, je ferai d’abord des recherches pour savoir ce que ça a donné chez les autres avant de mettre à jour (en ces temps d’UEFI…)

#8

Alors j’ai essayé plusieurs disques différents, avec plusieurs câbles différents, sur les deux ports USB3 qui existent à l’arrière de ma tour, toujours le même comportement : 20 minutes avant d’être montés.

J’ai essayé ces mêmes disques sur des ports USB3 d’une autre machine, qui est sous Debian Wheezy, mais Xfce, aussi à jour que l’est mon desktop, avec le même contrôleur USB3, et aucun problème, le disque est tout de suite visible dans le gestionnaire de fichier et se monte en un clic.

J’ai démarré ma tour sur une Live USB Debian Wheezy, branché un disque externe sur l’un des deux fameux ports USB3, aucun problème non plus, le disque se monte automatiquement et nautilus s’ouvre en affichant le contenu du disque. Bon, c’est pas immédiat, mais c’est d’une rapidité tout à fait correcte, d’autant que c’est une session Live et un disque bien rempli.

Hypothèse : c’est donc mon installation qui pose problème ? Mais alors quoi ? :question:

[edit] Je dispose sur cette machine d’un dualboot, une tango studio basée sur Debian Wheezy. J’ai redémarré dessus, branché mon disque sur le port USB3, disque monté tout seul tout à fait rapidement…

#9

Bon, voilà que désormais, pour n’importe quel périphérique USB, sur n’importe quel port, y compris les ports USB2, c’est le même comportement : 20 minutes avant que ce soit monté, et pas moyen, avant de le voir avec blkid ou fdisk…

Ça commence à devenir légèrement pénible. :slightly_smiling:

[edit] : je fatigue, c’était une erreur de ma part, je veux dire les 3 lignes ci-dessus…

#10

Effectivement, le matériel (disque + câble + ports USB) sont bien hors de cause. => Déjà un doute en moins.
Reste à trouver pourquoi ce système réagit aussi mal.

Ne serait-ce pas un problème dû à [mono]gnome-volume-manager[/mono], étant donné que les ports, et le disque fonctionnent très bien ?

Mais j’utilise Xfce, et jamais de mountage automatique.

#11

Ben apparemment c’est pas gnome-volume-manager, parce qu’il est pas installé sur Wheezy, et il est même pas dans les dépôts : packages.debian.org/search?keyw … &suite=all

Va donc falloir que je trouve qui fait le job à la place.

#12

regarde si jamais nautilus ne te monterait pas ton disque , je dis cela par rapport a que sous kde dolphin tu sa cette possibilité et qu’en plus il te donne le message d’erreur du pourquoi du comment

#13

Dans mon post précédent, j’avais confondu ce fil avec un autre dans lequel il était question de sid.

=====

=====

[quote=“iGor”]… Je me demande ce que sont toutes ces lignes en “xhci_hcd 0000:04:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff8801bfd38*”… …[/quote]Ce sont des messages générés par le module [mono]xhci_hcd[/mono] (USB 3.0)

=====
Il pourrait être intéressant de connaître les versions de noyaux qui ont fait fonctionner correctement l’USB3, pour les comparer avec la version qui pose problème

#14

J’ai fait un test de plus, sur une autre machine chez moi, aussi sous Debian Wheezy, même noyau, même contrôleur USB3, même comportement… Pour mémoire, il s’agit du 3.2.0-4-amd64 #1 SMP Debian 3.2.60-1+deb7u3 x86_64 GNU/Linux

Les noyaux sur lesquels les disques se montent normalement :
Debian Wheezy sous Xfce (autre machine, même contrôleur USB3) : 3.2.0-4-amd64 #1 SMP Debian 3.2.57-3+deb7u2 x86_64 GNU/Linux
Tango Studio (même machine) : 3.2.0-4-realtime-amd64 #1 SMP PREEMPT RT Debian 3.2.54-2+tstudio.1 x86_64 GNU/Linux
Debian Wheezy en Live USB (même machine) : 3.2.0-4-amd64 #1 SMP Debian 3.2.54-2 x86_64 GNU/Linux

#15

Bonjour,

Finalement :

On sait maintenant que le problème n’est pas un problème de disque, de son boîtier, de son câble, du PC et de ses port USB 3.0,
Il n’y a donc aucun problème du côté matériel.

Vu les messages d’erreurs xhci, j’écarte aussi l’idée d’un problème logiciel d’auto-mountage.

Il ne reste donc “plus qu’à” (célèbre expression de la famille des “yaka”, “taka”, et “yfokon” :slightly_smiling: ) trouver une solution “noyau + module xhci” qui résoudra le problème.

Malheureusement, en cherchant sur le web avec [mono]xHCI xhci_drop_endpoint called with disabled ep[/mono], j’ai trouvé pas mal de posts, mais aucune solution applicable.

Je continue à fouiller, et je te tiendrai au courant (si je trouve).

#16

Merci beaucoup pour ton aide ! Je cherche également de mon côté… :slightly_smiling:

#17

Bonjour,

je ne suis pas sûr que mon intervention soit une aide, sinon pour moi-même…

J’ai eu un problème analogue: j’ai essayé hier une clé USB3 toute neuve, avec un problème qui ressemble fort à celui de iGor.
Cette clé fonctionne en USB2 (=sur une prise USB2), mais reste inerte sur une prise USB3 ( la lumière de la clé ne s’allume pas, gnome n’affiche pas son icône, elle n’est pas montée )

Par contre, sa présence (inerte) dans la prise USB3 ne semble pas perturber le comportement des USB2.

uname -a:frowning: Squeeze mis à jour )

Linux php75 2.6.32-5-amd64 #1 SMP Sat Jul 12 16:47:57 UTC 2014 x86_64 GNU/Linux
lsusb me donne:

Bus 009 Device 003: ID 04e8:3301 Samsung Electronics Co., Ltd Bus 009 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 008 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 005 Device 002: ID 09da:032b A4 Tech Co., Ltd Wireless Mouse (Battery Free) Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 002: ID 04a9:1909 Canon, Inc. CanoScan LiDE 110 Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 002: ID 05dc:a833 Lexar Media, Inc. Bus 001 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
qui me confirme que la clé “Lexar Media” est bien identifiée sur le Bus 001 “3.0 root hub”

et lsusb -t

/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M</code> qui affiche aussi le Driver xhci_hcd
dmesg | egrep -i ‘usb|xhci_hcd’ affiche ces lignes:

[    2.189699] xhci_hcd 0000:0e:00.0: PCI INT A -> GSI 29 (level, low) -> IRQ 29
[    2.189723] xhci_hcd 0000:0e:00.0: setting latency timer to 64
[    2.189725] xhci_hcd 0000:0e:00.0: xHCI Host Controller
[    2.189741] xhci_hcd 0000:0e:00.0: new USB bus registered, assigned bus number 1
[    2.189848] xhci_hcd 0000:0e:00.0: irq 29, io mem 0xfbdfe000
---
[ 1541.554917] xhci_hcd 0000:0e:00.0: WARN: short transfer on control ep
[ 1541.556039] xhci_hcd 0000:0e:00.0: WARN: Stalled endpoint
[/code](et beaucoup d'autres)

[i]blkid[/i]:
[code]/dev/sdg1: LABEL="Lexar" UUID="6F6B-483D" TYPE="vfat"

:041 Youpiii ! elle est «mountable»

Je suppose qu’il y est question de configuration de GNOME ou de règles UDEV, auxquelles je ne connaîs presque rien.

La surprise du jour: hier elle n’apparaissait pas dans l’utilitaire de disque de gnome, et aujourd’hui, (après umount, bien entendu ) elle y apparaît [size=90](le test affiche une vitesse d’accès en lecture de 107 Mo/s au lieu de 35 Mo/s [/size])
Différences avec hier soir:

  • 1 clé branchée avant de démarrer.
  • 2 mise à jour de Squeeze après quelques jours de négligence.
  • 3 je suis reposé.

Paquets mis à jour:
[size=85]libgssapi-krb5-2 libgssrpc4 libk5crypto3 libkadm5clnt-mit7 libkadm5srv-mit7 libkdb5-4 libkrb5-3 libkrb5support0
libpython2.6 python2.6 python2.6-dev python2.6-minima[/size]l

à bientôt

#18

Suite…

Encore plus surprenant:
Je viens de redémarrer, puis brancher une clef (USB2) sur la prise USB3 = même comportement que décrit ci-dessus

Je branche une deuxième clef, et celle-ci apparaît sur le bureau Gnome ( USB2 aussi bien qu’ USB3 )

L’expérience est symétrique ( la première prise branchée peut être aussi bien l’une que l’autre )

Si cela peut aider quelqu’un à comprendre… voire à donner une solution 8)

#19

@ josephtux
[strike]Là[/strike] Dans ton post du 20 Aoû 2014 14:29, tu nous montre que ton [mono]hub[/mono] interne (Class=root_hub) est bien en USB 3.0, mais ce n’est pas l’interface (boîtier) USB <-> disque dont il s’agit,
bien que ce soit déjà un des maillons de la chaîne qui est bien reconnu.

=======
La référence [mono]constructeur:produit[/mono] de ton interface Boîtier USB <-> disque (ou ta clef “Lexar Media”) est : [mono]05dc:a833[/mono]
Entre la commande:lsusb -v -d 05dc:a833 | grep bcdUSBqui te retournera, s’il s’agit bien d’une interface (boîtier) disque reconnue et accessible en USB 3.0 :
[mono]bcdUSB 3.00[/mono]
Ou bien, s’il s’agit bien d’une interface (boîtier) disque reconnue et accessible en USB 2.0 :
[mono]bcdUSB 2.00[/mono]

ou bien, si tu préfère en plus bavard:

========
Refais tes commandes en connectant une clef ou disque USB 2.0 sur le hub USB 3.0, et regarde ce que ça donne, tu comprendra.

EDIT: je vois que tu viens de faire un essais avec une clef USB 2.0 pendant que je rédigeais ce post. Impec :slightly_smiling:

#20

Merci MicP

Je reviens sur ce que j’ai dit précédemment:

Il y a un comportement aléatoire, y compris avec les prises USB2, qui semble varier en fonction.

  • de la prise physique
  • de la cle elle-même ( par exemple, la clé A sur la prise 1 ne se monte pas seule, même si je la retire puis la remet, alors que la clé B se monte seule et apparaît sur le bureau.)

Autre caractère aléatoire: redémarrage de l’imprimante ( USB ) lorsque je branche une clé, reconnue, mais pas à chaque fois.

J’essaie de trouver une règle à cet aspect apparemment aléatoire, et si je trouve, je vous la donne.

#21

@ josephtux
Le contexte n’est plus le même: ton noyau est en version [mono]2.6.32-5[/mono], et le message d’erreur n’est pas tout-à fait le même que celui de iGor.

Toutefois, une recherche sur le web m’a permis de trouver ce message qui m’a permis de trouver l’extrait suivant:

[quote=“Dans http://ftp.lpclinux.com/?p=linux-2.6-lpc.git;a=commitdiff_plain;h=435a5aebf609624bdf7c5a9a7705c260d0076195, Linus Torvalds”]
…
xhci: Don’t let the USB core disable SuperSpeed ports.
xhci: Setup array of USB 2.0 and USB 3.0 ports.
xhci: Fix reset-device and configure-endpoint commands
…
[/quote]Il semblerait donc qu’à partir de la version 2.6.37-rc5, tes problèmes avec USB 3.0 soient résolu.

#22

@ iGor : Rien de nouveau si ce n’est ce fil dans lequel on retrouve ce même message d’erreur: [mono]xHCI xhci_drop_endpoint called with disabled ep[/mono]