Forum Linux.général input overrun sur port série

Posté par  (site web personnel) .
Étiquettes :
1
2
mar.
2012

Salut !

Je viens poser une question sur le port série de ma machine de dev.

J'utilise screen pour afficher les traces du matos que je programme en ce moment (une STB), et j'ai très souvent des "ttyS0: 11 input overrun(s)" qui arrivent dans le syslog.
Du coup, dans les traces qui arrivent de la STB, je perds aléatoirement des caractères, ce qui rend les traces illisibles.

Je vais préciser mon setup, parce que je pense que ça vient de là:

  • j'utilise la commande screen -R -d -t "Serial" /dev/ttyS0 115200 pour me connecter au port série (je fais partie du groupe dialout)
  • c'est sous Fedora 16 3.2.6-3.fc16.x86_64 (important, car sur ma Fedora 15 je n'avais pas le souci!)
  • dans mes traces, j'aime bien mettre de la couleur et des bold, du coup je me demande si c'est ça qui fait que?

En réalité, je penche surtout sur 2 pistes:

  • le kernel et les pilotes ont changé depuis ma Fedora 15 (c'était du 2.6.xxx )
  • j'ai moins souvent de problèmes (mais y en a quand même) quand j'utilise xterm au lieu de gnome-terminal

Petit exemple de dmesg:

[359121.944194] ttyS0: 2 input overrun(s)
[359123.473361] ttyS0: 1 input overrun(s)
[359135.016933] ttyS0: 1 input overrun(s)
[359136.043309] ttyS0: 10 input overrun(s)
[359162.011197] ttyS0: 4 input overrun(s)
[359164.466220] ttyS0: 2 input overrun(s)
[359202.914947] ttyS0: 3 input overrun(s)
[359204.610023] ttyS0: 4 input overrun(s)
[359267.952069] ttyS0: 3 input overrun(s)

J'ai l'impression que ça se produit quand j'ai des bursts de traces.

Vous avez déjà eu le même problème?

  • # Non,

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

    Jamais eu ce problême :)

  • # Des pistes

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

    Il semblerait que tu reçoives des datas plus vite que ton système n'arrive à les dépiler.
    As tu essayé de diminuer la vitesse ? Vérifié le Flow Contol ?

    • [^] # Re: Des pistes

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

      J'ai essayé de diminuer la vitesse, oui, mais de l'autre côté (STB) ça envoie à 115k, donc trop vite (je reçois des caractères pourris) et comme je suis pas le seul à utiliser le bouzin, je peux pas changer la vitesse d'émission sans raison vraiment valable (mon problème est isolé).

      Par contre, c'est quoi le Flow Control? Je peux éventuellement tester, si je sais comment… :)

      • [^] # Re: Des pistes

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

        Perso, je commencerais par essayer avec minicom à la place de screen. Dans le paramétrage tu as une option "Hardware Flow Control", essayes en le désactivant.

        • [^] # Re: Des pistes

          Posté par  . Évalué à 2.

          Euh, Moi dans des cas comme ça, j'aurai plutôt envie de l'activer. Même si aujourd'hui, j'imagine qu'il doit être complètement fake, entre le câble qui court-circuite des pins pour économiser des fils de cuivre et les périphs qui ne l'implémentent même pas, sans parler des périphs qui le désactivent par défaut… Il faut que le périph et le câble supportent le flow control avant de vouloir l'utiliser.

          S'il était activé sur le PC et que ça passait, je vois pas en quoi le désactiver améliorera quelque chose.

          Sinon, à défaut de flow control hard, essaye voir si ton périph ne supporte pas le XON/XOFF (flow control 'soft')

          Sinon, je me souviens que le noyau avait implémenté un mécanisme pour éviter qu'un port série plante une machine si jamais le port série débitait tellement que le noyau ne pouvais jamais redonner la main aux applis. J'ai pas regardé depuis, mais à l'époque, j'étais obligé de patcher mon noyau si je voulais bourriner avec une vielle machine, même en 9600 baud. Si ta machine est trop chargée et que t'a pas de flow control, c'est normal que ça merde.

          Mais bon, la vraie solution reste quand même d'utiliser un vrai protocole de transfert avec gestion des erreurs.

  • # Des news ?

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

    Tu t'en sors ?

    • [^] # Re: Des news ?

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

      Nope, j'ai posé ma question sur StackExchange mais c'est pas mieux.
      Je fais avec pour le moment.

      • [^] # Re: Des news ?

        Posté par  . Évalué à 2.

        si tu faisais differemment, sous linux tout est fichier

        screen -RdS serial
        pour pas perdre la main en cas de deconnexion

        puis dans ce terminal, tu fais
        tail -f /dev/ttyS0
        pour suivre ce qui rentre sur /dev/ttyS0

        • [^] # Re: Des news ?

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

          Certes, mais j'ai besoin d'intéragir avec la boite aussi, du coup un tail ne suffit pas.

          • [^] # Re: Des news ?

            Posté par  . Évalué à 3.

            je ne sais pas comment tu fais avec screen, mais je n'arrive pas au resultat que tu decris

            screen -R -d -t "Serial" /dev/ttyS0 115200

            me connecte sur un screen qui existe deja sur la machine ou je l'execute.

            et si je colle les options comme j'ai l'habitude de le faire

            screen -Rdt "Serial" /dev/ttyS0 115200

            ca me dit que 115200 n'est pas une commande valide.

            je penses que la solution d'un minicom (logiciel prevu pour interagir sur un port serie)
            eventuellement lancé dans un screen pour ne pas perdre la main si le PC est telepiloté par le reseau.

Suivre le flux des commentaires

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