Forum Linux.redhat Couper l'alimentation des ports USB

Posté par  .
Étiquettes :
3
15
juil.
2010
Bonsoir à tous,

J'ai deux problèmes en un :

Je travaille avec Fedora 13 x86_64 sur une carte-mère ASUS P5E3, et avec un noyau 2.6.34 compilé par mes soins.

J'utilise également un palonnier USB Saitek ( http://www.saitek.com/uk/images/product/rudder.jpg ) qui fonctionne bien mais qui est rarement reconnu par le système à l'allumage de ma machine. Il faut en général que je débranche et rebranche son câble USB. En faisant un petit tour dans le dmesg, j'obtiens respectivement ceci :

[ 28.469024] usb 2-2: new full speed USB device using uhci_hcd and address 6
[ 28.493040] usb 2-2: device descriptor read/8, error -32
[ 28.613045] usb 2-2: device descriptor read/8, error -32
[ 28.816012] usb 2-2: new full speed USB device using uhci_hcd and address 7
[ 28.839058] usb 2-2: device descriptor read/8, error -32
[ 28.959065] usb 2-2: device descriptor read/8, error -32
[ 29.162023] usb 2-2: new full speed USB device using uhci_hcd and address 8
[ 29.272022] usb 2-2: device descriptor read/64, error -32
[ 29.483022] usb 2-2: device descriptor read/64, error -32
[ 29.686022] usb 2-2: new full speed USB device using uhci_hcd and address 9
[ 29.796022] usb 2-2: device descriptor read/64, error -32
[ 30.007022] usb 2-2: device descriptor read/64, error -32
[ 30.108036] hub 2-0:1.0: unable to enumerate USB device on port 2


et ceci (quand ça marche) :

[ 3116.253259] usb 2-2: new full speed USB device using uhci_hcd and address 10
[ 3116.326036] usb 2-2: New USB device found, idVendor=06a3, idProduct=0763
[ 3116.326039] usb 2-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 3116.326042] usb 2-2: Product: Saitek Pro Flight Rudder Pedals
[ 3116.326044] usb 2-2: Manufacturer: Saitek
[ 3116.333089] input: Saitek Saitek Pro Flight Rudder Pedals as /devices/pci0000:00/0000:00:1a.1/usb2/2-2/2-2:1.0/input/input6
[ 3116.333188] generic-usb 0003:06A3:0763.0003: input,hidraw2: USB HID v1.11 Joystick [Saitek Saitek Pro Flight Rudder Pedals] on usb-0000:00:1a.1-2/input0


Après plusieurs tests, il semblerait que mon palonnier se déclare correctement lorsqu'il est mis sous tension et qu'il ne soit plus capable de le faire lors des énumérations suivantes. Or, il se trouve que ma machine semble être capable de couper l'alimentation des ports USB sur demande mais que le système ne le fait pas à l'extinction totale de ma machine. D'instinct, j'ai tendance à dire que cela doit venir de la configuration de l'ACPI (état S5) mais mes compétences s'arrêtent là.

Le palonnier est équipé d'une LED qui s'éteint − parfois − lorsque que je mets le système en veille, mais ce n'est pas systématique. Il arrive aussi qu'elle s'éteigne pendant la phase d'arrêt de ma machine et qu'elle se rallume une fois le PC complètement éteint. J'ai essayé aussi de passer l'option old_scheme_first=Y au module usbcore, via modprobe.conf. L'option est bien prise en compte mais cela semble ne rien changer.

D'où mes questions :Est-ce que le problème d'énumération du palonnier est connu et y a-t-il un remède ? Sinon, y a-t-il un moyen simple de couper temporairement l'alimentation des ports hôtes USB de la carte mère (il fut un temps où retirer le module avec rmmod suffisait à le faire sur certaines machines) et, enfin, est-il possible de demander au système de couper entièrement l'alimentation des périphériques USB à l'extinction de la machine ?

Merci à tous.
  • # bios

    Posté par  . Évalué à 3.

    Hello,

    En réponse à

    "Or, il se trouve que ma machine semble être capable de couper l'alimentation des ports USB sur demande mais que le système ne le fait pas à l'extinction totale de ma machine"

    Tu peux également aller regarder du coté du bios,
    il y a des options type "wake on", pour des évènements USB.
    (à désactiver ?)

    A+

    Nicolas
    • [^] # Re: bios

      Posté par  . Évalué à 2.

      Oui, j'aurais dû le préciser, mais j'ai bien sûr commencé par là. Sans succès, malheureusement…

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.