Vérifier que la syntaxe utilisée pour init est correcte.
Les multiples init disponibles utilisent des formats de ligne
/etc/inittab différents. Vérifier également que l'utilisation
de getty est syntaxiquement correcte.
Ce problème peut survenir lorsque les lignes DCD ou DTR sont incorrectement
paramétrées. DCD doit être positionnée lorsqu'il y a effectivment
connexion, pas pendant que getty surveille le port.
Vérifier donc que le modem est configuré de manière à ce que la ligne DCD
ne soit positionnée que pendant les connexions. DTR ne doit
être active que quand un process utilise ou surveille la ligne, comme
getty, kermit ou un autre programme de communication.
Autre cause possible du problème~: le port série est affecté à un IRQ déjà utilisé. Lors de l'initialisation, chacun des périphériques demande à Linux l'autorisation d'utiliser son IRQ. Linux conserve une carte de l'utilisation des IRQ, et si l'IRQ demandé est déjà utilisé, l'initialisation du périphérique ne peut se dérouler correctement. Le périphérique n'a pas vraiment les moyens de prévenir l'utilisateur de ce qui s'est passé, sinon en signalant une erreur "device-busy" (périphérique non disponible) à chaque tentative d'utilisation. Vérifier les niveaux d'interruption utilisés par chacune des cartes (série, ethernet, etc.). Chercher les conflits d'IRQ.
Vérifier la configuration du modem, notamment les registres E et Q.
Cela peut arriver lorsque le modem essaie de communiquer avec getty.
Vérifier que la syntaxe de getty dans /etc/inittab est
correcte. Une mauvaise syntaxe, ou un périphérique mal nommé peuvent
être la cause de problèmes sévères.
Cela peut aussi arriver du fait d'une erreur d'initialisation de uugetty.
Voyez la question ``getty ou uugetty ne fonctionne toujours pas''.
Vous avez probablement un conflit d'IRQ. Assurez-vous qu'aucune IRQ n'est
partagée. Vérifiez toutes vos cartes (séries, ethernet, SCSI, etc...).
Vérifiez que les switchs sont bien positionnés, et que les paramètres
de setserial sont corrects pour chacun de vos périphériques série.
uugetty ne se relance pas. Cela peut arriver si votre modem ne se réinitialise pas lorsque DTR tombe.
Lorsque cela m'est arrivé, mes diodes RD et SD sont devenues folles.
Il faut que votre modem se réinitialise. Sur la plupart des compatibles
Hayes, la commande &D3 fait l'affaire, mais sur mon USR Courier,
il a fallu utiliser &D2 et S13=1. Lisez le manuel de votre
modem.
Il n'y a probablement pas de CLOCAL dans la ligne de
/etc/gettydefs relative au terminal~; il est également possible
que le câble utilisé ne soit pas un vrai null modem.
CLOCAL est indispensable, il indique à Linux d'ignorer les
signaux de contrôle du modem.
Voici à quoi cela doit ressembler~:
#Ligne pour une terminal passif a 38400 baud
DT38400# B38400 CS8 CLOCAL # B38400 SANE -ISTRIP CLOCAL #@S @L login: #DT38400
#Ligne pour une terminal passif a 19200 baud
DT19200# B19200 CS8 CLOCAL # B19200 SANE -ISTRIP CLOCAL #@S @L login: #DT19200
#Ligne pour une terminal passif a 9600 baud
DT9600# B9600 CS8 CLOCAL # B9600 SANE -ISTRIP CLOCAL #@S @L login: #DT9600
Puis, kill le processus getty, afin qu'un autre
soit lancé, avec les nouveaux paramètres.
Pour utiliser un modem à > 19200 bps, il faut un UART 16550A. Voir la section Que sont les UART~? .
Absolument. Linux ne fait pas la détection des IRQ au démarrage, seulement celle des périphériques série. Ne tenez pas compte de ce qui est affiché au sujet des IRQ, le système ne fait que supposer qu'ils sont standard. Linux procède de la sorte parce que la détection d'IRQ est peu fiable, et sujette à erreurs.
Donc, bien que mon ttyS2 utilise l'IRQ 5, Linux m'affiche~:
Jan 23 22:25:28 misfits vmunix: tty02 at 0x03e8 (irq = 4) is a 16550A
Il faut utiliser setserial pour indiquer à Linux les IRQ que
l'on souhaite utiliser.
rz et/ou sz ne marchent pas lorsque j'appelle le modem de ma machine Linux.Si Linux recherche /dev/modem pour les transferts de
fichiers, regarder dans /etc/profile, et /etc/csh.cshrc.
Certaines des distributions, et notoirement la Slackware, définissent
une foultitude d'alias dans ces fichiers~; certains d'entre eux
empêchent le fonctionnement des programmes zmodem. Il faut les
effacer, ou les corriger.
Cela arrive quand on envoie des données binaires à l'écran ou sur les
connexions série.
La commande qui marche à tous les coups est echo ˆvˆ[c,
soit pour les non-ASCIIsants, echo <ctrl>v<esc>c.
getty ou uugetty ne marche toujours pas.getty_ps possède une option de DEBUG. Ajouter dans
/etc/conf.{uu}getty.ttySN la ligne DEBUG=NNN.
NNN est une combinaison des nombres suivants, selon ce que
vous voulez déboguer~:
D_OPT 001 options de configuration
D_DEF 002 traitement des valeurs par defaut
D_UTMP 004 traitement de utmp/wtmp
D_INIT 010 initialisation de la ligne (INIT)
D_GTAB 020 traitement fu fichier gettytab
D_RUN 040 autres diagnostics
D_RB 100 debogage du rappel de securite
D_LOCK 200 fichiers verrou de uugetty
D_SCH 400 appels preprogrammes
D_ALL 777 toutes les options ci-dessus
Je vous recommande DEBUG=010 pour commencer.
Si syslogd est actif, les informations de débogage seront
dirigées sur vos fichiers de log. Sinon, elles seront dirigées
sur /tmp/getty:ttySN pour getty, ou sur
/tmp/uugetty:ttySN pour uugetty ainsi que
dans /var/adm/getty.log.
Les informations de débogage devraient vous indiquer la voie. Dans
la plupart des cas, il suffit de modifier un paramètre du fichier
de configuration, ou de reconfigurer le modem.
Vous pouvez aussi essayer mgetty. Certains s'en trouvent mieux.
Chapitre suivant, Chapitre Précédent
Table des matières de ce chapitre, Table des matières générale
Début du document, Début de ce chapitre