Forum Linux.noyau Déco USB aléatoire et changement d'adresse pour Onduleur

Posté par  .
Étiquettes :
1
23
août
2010
Bonjour Forum,

J'ai installé dernièrement une petite Debian Squeeze pour rôder une machine qui fera office de serveur (quand Squeeze sera stable). Je l'ai naturellement mise derrière un UPS histoire d'éviter les surtensions et de laisser le temps à la bestiole de s'arrêter proprement en cas de panne de courant.
Il s'agit d'un Eaton Ellipse 600 USBS, branché en USB.

Bref, ... j'installe le client nut (en version 2.4.3-1) et je le configure en laissant il est vrai un bon nombre d'options par défaut. Un petit "upsc Onduleur" et voilà les données de mon UPS rapatriée. Ô joie.

Oui mais... de manière apparemment aléatoire, l'adresse dévolue à l'UPS sur le bus est changée ! Je me retrouve avec (dans /var/log/messages) :

Aug 23 05:35:27 Athos kernel: [912578.246156] usb 4-1: USB disconnect, address 7
Aug 23 05:35:28 Athos kernel: [912579.224028] usb 4-1: new low speed USB device using ohci_hcd and address 8
Aug 23 05:35:29 Athos kernel: [912580.112325] usb 4-1: New USB device found, idVendor=0463, idProduct=ffff
Aug 23 05:35:29 Athos kernel: [912580.112328] usb 4-1: New USB device strings: Mfr=1, Product=2, SerialNumber=4
Aug 23 05:35:29 Athos kernel: [912580.112331] usb 4-1: Product: ELLIPSE
Aug 23 05:35:29 Athos kernel: [912580.112332] usb 4-1: Manufacturer: EATON
Aug 23 05:35:29 Athos kernel: [912580.112334] usb 4-1: SerialNumber: BD8L12045
Aug 23 05:35:29 Athos kernel: [912580.112416] usb 4-1: configuration #1 chosen from 1 choice
Aug 23 05:35:34 Athos kernel: [912584.623577] generic-usb 0003:0463:FFFF.0006: hiddev0,hidraw0: USB HID v1.00 Device [EATON ELLIPSE] on usb-0000:00:12.1-1/input0

Tandis que dans /var/log/debug :

Aug 23 05:35:27 Athos kernel: [912577.348222] usb 4-1: usbfs: USBDEVFS_CONTROL failed cmd usbhid-ups rqt 161 rq 1 len 512 ret -110
Aug 23 05:35:29 Athos usbhid-ups[10520]: libusb_get_interrupt: error submitting URB: No such device
Aug 23 05:35:29 Athos usbhid-ups[10520]: libusb_get_report: error sending control message: No such device
Aug 23 15:15:07 Athos kernel: [947358.036168] usb 4-1: usbfs: USBDEVFS_CONTROL failed cmd usbhid-ups rqt 161 rq 1 len 512 ret -110

(D'ailleurs, là-aussi de manière apparemment aléatoire, mon /var/log/debug est rempli de ligne similaire à la dernière "USBDEVFS_CONTROL failed")

Hors, comme il est obligatoire que /dev/bus/usb/004/00n appartienne à root:nut (puisque c'est nut qui dans mon cas interroge), et bien dès que l'adresse change (de 00n à 00(n+1)) ça ne marche forcément plus jusqu'à ce que je fasse un chown root:nut (avec en bonus le risque d'une panne de courant dans l'intervalle).

La seule chose que j'ai essayée après avoir arpenté les forums/listes de diffusion et l'augmentation du paramètre MAXAGE de 15 à 60, ce qui a réduit le nombre de "USBDEVFS_CONTROL failed" sans l'annuler pour autant.

Je précise que j'ai déjà le même UPS branché en USB sur une Debian Lenny (nut en version 2.2.2-6.5) et, bien que j'ai également des "USBDEVFS_CONTROL failed" (à une fréquence faible), je n'ai jamais eu de changement d'adresse. (paramètre MAXAGE ici à 25).

Après cet exposé laborieux verrais-tu, ô forum, une raison qui expliquerait le changement impromptu d'adresse sur le bus ? En dernier recours je pourrais toujours faire un
chown root:nut /dev/bus/usb/004 & chmod 2770 /dev/bus/usb/004 mais c'est loin d'être satisfaisant.

  • # Peut être ?

    Posté par  (site web personnel) . Évalué à 2.

    Je sais pas si tu as regardé ca sur le net :
    http://ovanhoof.developpez.com/upsusb/
    ( surtout le mknod et la directive port dans ups.conf )

    Fuse : j'en Use et Abuse !

    • [^] # Re: Peut être ?

      Posté par  . Évalué à 1.

      Oui effectivement je l 'avais croisé et elle m'avait semblé dater un peu... En effet, on peut voir directement dans la doc de nut 2.2.0 (http://www.networkupstools.org/doc/2.2.0/) que pour les UPS branchés en USB, il est conseillé de laisser port à "auto".

      Pour le mknod j'avoue rester dubitatif... on dirait que l'auteur utilise là une méthode utilisée pour le branchement par port série (ou alors je n'ai strictement rien compris !).

  • # Udev

    Posté par  (site web personnel) . Évalué à 2.

    Je ne peut guère t'aider sur le pourquoi de la déconnection régulière de ton onduleur, les possibilitées sont nombreuses: défaut de l'onduleur, défaut de la carte mêre (ou mauvaise gestion par le pilote linux), utilisation d'un HUB usb instable peut-être ...

    Par contre la solution n'est pas de faire "chown root:nut /dev/bus/usb/004 & chmod 2770 /dev/bus/usb/004" qui en plus d'être très très moche ne sera pas forcement très fonctionnel.

    Il faut que tu ajoute une rêgle udev pour ton materiel, quelque chose dans le genre:
    SUBSYSTEM=="usb", ATTRS{idVendor}=="0463", MODE="0660", GROUP="nut"

    Voir: http://www.reactivated.net/writing_udev_rules.html

    • [^] # Re: Udev

      Posté par  . Évalué à 1.

      Je n'avais pas osé me lancer dans udev pour régler mon problème d'autorisation .... (d'ailleurs je me demandais même si ça pouvait marcher avec autre chose que des périphériques de stockage ^^)

      Merci du tuyau ! En farfouillant dans /var/log/debug, j'ai d'ailleurs vu un warning concernant une règle udev ajoutée par nut (obsolescence de l'attribut "bus") qui me laisse croire que nut essaye lui-même de faire de la sorte...

      Reste à savoir pourquoi il n'a pas marché pour l'instant ! J'ai relancé nut pour voir....

      (d'ailleurs, toujours pour ce problème d'autorisation, je me demandais également si l'affectation de l'utilisateur nut au groupe plugdev ne pouvait pas également constituer une rustine... certes bien moins propre qu'une règle udev)

  • # Pour l'usb

    Posté par  . Évalué à 0.

    Le permier message

    Aug 23 05:35:27 Athos kernel: [912577.348222] usb 4-1: usbfs: USBDEVFS_CONTROL failed cmd usbhid-ups rqt 161 rq 1 len 512 ret -110

    Indique un timeout de communication entre le PC et l'onduleur.
    Cela peut provenir de driver de ton chipset USB (version du kernel ?) ou de l'onduleur lui même qui refuse la transaction usb (trop de transaction si on l'interroge trop souvent?).

    Bref le pb est bas niveau USB, le reste est simplement la recupération de l'erreur et la ré-initialisation du périphérique apres que le usb-host ait envoyé un token bus-reset sur le bus usb.

    Tu peut essayer dans les sources de ton kernel de changer la valeur

    http://www.cs.fsu.edu/~baker/devices/lxr/http/source/linux/i(...)

    Et le recompiler pour essayer vu que dans les commentaire le dev indique que les "MGE Ellipse UPSes" sont un peut au choux sur l'usb (comprendre près des limites et parfois les dépassant)

    • [^] # Re: Pour l'usb

      Posté par  . Évalué à 0.

      Je suis pas encore réveillé
      la valeur à changer est USB_CTRL_GET_TIMEOUT et/ou USB_CTRL_SET_TIMEOUT

    • [^] # Re: Pour l'usb

      Posté par  . Évalué à 2.

      Effectivement sur la mailing-list de nut j'avais déjà vu conseillé, pour pareils problèmes de USBDEVFS_CONTROL failed, d'augmenter la valeur de ups.driver.pollfreq directement dans l'onduleur. Apparemment une fréquence d'interrogation trop élevée couplée à un temps de réponse limite peut poser ce genre de problème (cf. http://www.mail-archive.com/nut-upsuser@lists.alioth.debian.(...) et la suite de la discussion).

      Malheureusement mon (petit) ups ne me donne pas accès à ce paramètre !

      Donc merci d'une part de me confirmer que c'est bien un problème de gestion USB (et pas de configuration de nut ou je-ne-sais-quoi....), et d'autre part de m'avoir montrer comment y "remédier" via la gestion des timeout noyaux. Encore une bonne raison de compiler son noyau soi-même...va falloir que je m'y mette ! ;-)

Suivre le flux des commentaires

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