(Courriels de diversion: <retraiteraient@confus-retarderait.com> <negligions@sasser-demi-cercles.com> <fumiers@insonoriseras-frissonnement.com> <mousses@barmaid-sursauter.com> <gouape@suprematie-escaladerions.com> <magnolia@parlerez-vogua.com> <moyenne@veulerie-defraîchisses.com> <disparaissiez@seyaient-liane.com> <perturberiez@douer-lino.com> <prepares@delimitait-ehonte.com> )


On Monday 3 March 2003 13:10, Eric Lassauge wrote:
> Huiban, Eric wrote:
> >>j'ai qq problemes/questions avec la gestion des lignes series.
> >>Mon contexte:
> >>- RedHat 6.2 depouillee de X11
> >>- noyau 2.2.22 (base sur le 2.2.22-6.2.3 de la Redhat, mais avec le
> >>driver serial en module)
> >>- module serial en 5.05 recompile "a la mimine".
> >>
> >>J'ai une appli fortement consommatrice d'E/S sur lignes series,
> >> elle contient 2 process fils l'un fait les lectures sur les lignes
> >> series avec un select l'autre discute avec le premier via un pipe.
> >> Quand on bourrine sur une ligne serie en entree (depuis un autre
> >> PC) il apparait que des lignes entieres sont perdues a
> >>intervalles reguliers.
> >
> > Plusieures causes possibles :
> >
> > 1- manque protocole de controle (RTS/CTS, DSR/DTR)
>
> 	Impossible d'utiliser les lignes de controle car la machine Linux
> s'insère dans un "vieux" système à base de dos/windows sans refonte
> de cablage prévue

gzzzeuh ? cablage 3 fils (TX,RX,GND) seulement ? Ca va etre chaud à 
haut débit. Pour les machines dos/win a interfacer, un "fossil" aide 
enormement (remplace toute forme de driver serie avec une efficacité 
redoutable). Si par chance tu as un cablage 5 fils, certains UARTs 
modernes disposent d'un sequenceur CTS/RTS hardware calé sur le taux de 
remplissage de la fifo et là ca roxe. :-)

> > 2- fifo hardware trop petites (si le systeme est mou du driver ou
> > du bus)
>
> 	D'où ma question sur la gestion des buffers dans le driver série. La
> aussi dans ce driver on est passé d'un 16550A à un 16950/954
> (initialement mal détécté)
*
C'est bien un 16950 qui est dessus ? gros doute d'apres la formulation. 
;-)

Si les buffers hardware ne suivent pas... modifier les buffers soft 
risque de ne pas aller plus loin qu'une rustine validable daans un ou 
deux cas.

>
> > 3- mauvais reglage du seuil de declenchement d'irq en fonction du
> > niveau de remplissage la fifo
>
> 	Même question sur l'endroit où on peut modifier ca dans le driver
> .

Il te faut "te trouver" l'equivalent du parametre "rx_trigger" mais 
pour n'importe quel type d'UART et pas seulement pour l'ESP.

Ca doit trainer par là (résultat de gros grep bien bourrin et rapide 
d'après souvenirs périmés, et sans datasheet pour appuyer le tir) :

 /* Set up FIFO's */
        if (uart_config[info->state->type].flags & UART_USE_FIFO) {
                if ((info->state->baud_base / quot) < 2400)
                        fcr = UART_FCR_ENABLE_FIFO | UART_FCR_TRIGGER_1;
#ifdef CONFIG_SERIAL_RSA
                else if (info->state->type == PORT_RSA)
                        fcr = UART_FCR_ENABLE_FIFO | 
UART_FCR_TRIGGER_14;
#endif
                else
                        fcr = UART_FCR_ENABLE_FIFO | UART_FCR_TRIGGER_8;
        }

dans serial.c... avec tout autre bout de code ressemblant.

Plus tu reduis la valeur de trigger, plus tu charge le cpu et le 
gestionnaire d'irq mais plus tu as du rab' de buffer pour recuperer les 
data qui arrivent pendant ton temps de latence. Réglage à la mimine 
pour chaque appli et chaque plateforme.

> > 3- les irqs n'ont pas ete reorganisees pour donner la priorite aux
> > UARTS.
>
> 	Les E/S séries sont sur des cartes 4ports PCI. Donc si je ne me
> trompe pas, pas moyen de changer la priorité (j'ai déjà regardé
> l'outil irqtune)

Ou sinon il te faut placer ca sur les irq 9 a 11 pour garder le schema 
PC classique.

> > 4- systeme de disque IDE monopolisant les irq (mode block enabled
> > --> disabled).
>
> 	Je suppose que ca se configure avec hdparm ?

BIOS + hdparm, oui. De facon a caser une irq IDE par secteur tout en 
s'autorisant l'insertion d'irq etrangeres entre l'acces a deux secteurs.

> > 5- low-latency patch a appliquer sur le kernel.
>
> 	Je regarde ca... Et l'option low_latency de setserial ?

Ca peut aider.

a+

--------------------------------------------------------------------
Les listes de diffusion occultes: <URL:http://www.CULTe.org/listes/>