Re: Questions driver serial

[Eric Lassauge <lassauge@mail.dotcom.fr>]

Eric Huiban wrote:
> 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. 
> ;-)

	C'est un Oxford 0X16PCI954, le driver serial le reconnait comme un 
"16950/954":

% setserial /dev/ttyS11
/dev/ttyS11, UART: 16950/954, Port: 0xb418, IRQ: 10



> 
> 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.
> 


	Y'a plus qu'à ....


> 
>>>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.
> 
> 

	Actuellement j'ai (4 et 3) 10 et 12:
STANDARD:
/dev/ttyS0 uart 16550A port 0x03f8 irq 4 baud_base 115200 spd_normal 
skip_test
/dev/ttyS1 uart 16550A port 0x02f8 irq 3 baud_base 115200 spd_normal 
skip_test
PCI 1:
/dev/ttyS4 uart 16950/954 port 0xa400 irq 12 baud_base 115200 spd_normal 
skip_test
/dev/ttyS5 uart 16950/954 port 0xa408 irq 12 baud_base 115200 spd_normal 
skip_test
/dev/ttyS6 uart 16950/954 port 0xa410 irq 12 baud_base 115200 spd_normal 
skip_test
/dev/ttyS7 uart 16950/954 port 0xa418 irq 12 baud_base 115200 spd_normal 
skip_test
PCI 2:
/dev/ttyS8 uart 16950/954 port 0xb400 irq 10 baud_base 115200 spd_normal 
skip_test
/dev/ttyS9 uart 16950/954 port 0xb408 irq 10 baud_base 115200 spd_normal 
skip_test
/dev/ttyS10 uart 16950/954 port 0xb410 irq 10 baud_base 115200 
spd_normal skip_test
/dev/ttyS11 uart 16950/954 port 0xb418 irq 10 baud_base 115200 
spd_normal skip_test



>>>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/>
> 

	Merci pour les infos. Je regarde également pour modifier la
gestion de la line discipline (n_tty.c) afin d'augmenter la taille
des buffers.


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