Absence d'interruptions sur ports série (select==timeout)

Recherche :

Dernière réponse
Sujet : Absence d'interruptions sur ports série (select==timeout)
kzimir	Bon, dernière partie de mon monologue :o En fait, si je fais cat /proc/interrupts pendant le fonctionnement de mon appli, je vois bien l'IT. Me voilà bien maitenant avec mon select qui ne marche pas et mes IT qui sont OK :o

Votre réponse

Nom d'utilisateur

Pour poster, vous devez être inscrit sur ce forum .... si ce n'est pas le cas, cliquez ici !

Le ton de votre message

Votre réponse

Smilies

Liste des smilies perso
Wiki smilies
Chercher un smiley

Options

Activer votre signature
Désactiver les smilies
Activer la notification par email du sujet

Aperçu

Vous avez perdu votre mot de passe ?

Vue Rapide de la discussion

kzimir

Bon, dernière partie de mon monologue :o

En fait, si je fais cat /proc/interrupts *pendant* le fonctionnement de mon appli, je vois bien l'IT. Me voilà bien maitenant avec mon select qui ne marche pas et mes IT qui sont OK :o

kzimir

Un dernier up avant de partir du travail. D'après mes recherches google, c'est un problème assez fréquent, mais autant j'arrive à trouver des gens qui ont ce problème, autant je n'arrive pas à trouver de gens qui ont une réponse.

Est-ce qu'un conflit pourrait se manifester comme ça ? J'imagine que je verrais trop de monde sur l'IRQ4 plutôt que personne. Je précise au passage que mon port 3F8 est bien attribué à ttyS0(=tts/0) (de toute façon, j'arrive à lire/écrire dessus, mais pas à "selecter"...)

Dernière précision, les droits de ttyS0 sont r-x et ceux de ttS/0 sont rw-, il me semble que c'est normal.

Toute idée est bonne à prendre :)

kzimir

J'ajoute que setserial /dev/ttyS0 irq 4 ne change rien :/

Edit : je ne sais pas si ça veut dire quelque chose, mais si je fais cat /dev/ttyS0, le cat affiche quelques-unes des infos reçues puis quitte (retour à l'invite bash). Si je refais la manip, ça retourne immédiatement.

kzimir

Bonjour,

Je développe une application qui contrôle divers hardware sous MDK 9.2 et j'ai depuis peu des problèmes sur mes ports série (ttyS0 et ttyUSB0, port série adapté sur un USB).

Jusqu'à ce que je fasse je ne sais quoi (enfin, il n'y a que moi qui touche à ce PC, je dois être dans le coup), je pouvais faire des "select" en lecture sur ces ports (en C), fonction qui -en gros- demande au driver de réveiller le processus lorsqu'une interruption intéressante est soulevée.

Bref, tout fonctionnait pour le mieux, mais tout d'un coup, mes select font des timeout et je n'arrive pas à en déterminer la cause. L'ouverture des ports est OK.

cat /proc/interrupts me donne :

Code :

CPU0
0: 75127 IO-APIC-edge timer
1: 2779 IO-APIC-edge keyboard
2: 0 XT-PIC cascade
5: 0 IO-APIC-level usb-ohci, ehci_hcd
8: 1 IO-APIC-edge rtc
9: 490 IO-APIC-level usb-ohci, SiS SI7012, can_drv
11: 5213 IO-APIC-level usb-ohci, Texas Instruments PCI1410 PC card Cardbus Controller, orinoco_cs
12: 30081 IO-APIC-edge PS/2 Mouse
14: 9837 IO-APIC-edge ide0
NMI: 0
LOC: 75081
ERR: 0
MIS: 0

Si j'ai bien compris, cat /proc/interrupts me donne les périphériques sur lesquels des IT ont été soulevées depuis le démarrage. Donc, là, rien sur l'irq4 (ttyS0).

cat /proc/tty/driver/serial me donne

Code :

serinfo:1.0 driver:5.05c revision:2001-07-08
0: uart:16550A port:3F8 irq:4 tx:0 rx:0
1: uart:16550A port:2F8 irq:3 tx:0 rx:0

A priori, tout est là (les tx et rx sont normaux, c'est juste après reboot), mais faut-il vraiment s'y fier ? En polling et en read/write direct, ça marche, mais niveau fiabilité, c'est nul. Enfin, je précise que tout est OK dans le bios.

Si vous pouviez me mettre sur une piste, vous me tireriez une sacrée épine du pied.

Merci !