Asegúrese de estar usando la sintaxis correcta para su versión de
init
. Las diferentes versiones de init
que hay por ahí usan
sintaxis diferentes en el fichero /etc/inittab
. Asegúrese de
estar usando la sintaxis correcta para su versión de getty
.
Este problema puede surgir cuando DCD o DTR no están activados
correctamente. DCD sólo debe activarse cuando haya una conexión en curso
(ej: alguien ha llamado a este sistema), no cuando getty
esté
vigilando el puerto. Compruebe el módem para asegurarse de que está
configurado para activar DCD sólo cuando haya una conexión. DTR debe estar
activo siempre que alguien esté usando, o vigilando la línea, como
getty
, kermit
, o algún otro programa de comunicaciones.
Otra causa común de los errores de ``device busy'' (dispositivo ocupado), es que haya configurado el puerto serie con una interrupción que ya esté siendo usada. Cuando cada dispositivo se inicializa, le pide permiso a Linux para usar las interrupciones hardware. Linux sigue la pista de a quién se le ha asignado cada interrupción, y si la interrupción ya está siendo usada será imposible que el dispositivo se inicialice correctamente. El dispositivo realmente no tiene muchas formas de avisarle de que esto está ocurriendo, excepto que cuando intente usarlo, dará un mensaje de error ``device busy''. Compruebe las interrupciones de todas las placas (serie, ethernet, SCSI, etc). Busque conflictos de IRQ.
E
y Q
.Esto puede ocurrir cuando el módem está negociando con getty
.Asegúrese de estar llamando correctamente a getty
desde/etc/inittab
. Si usa una sintaxis o nombre de dispositivoincorrectos puede causar graves problemas. Esto también puede ocurrir cuando esté fallando la inicialización deuugetty
.
Probablemente tenga un conflicto de IRQ. Asegúrese de que no se están
compartiendo IRQs. Compruebe todas las placas (serie, ethernet, SCSI,
etc). Asegúrese de que los puentes, y los parámetros de setserial
son
los correctos en todos los dispositivos serie. Revise también
/proc/ioports
y /proc/interrupts
por si hubiera
conflictos.
uugetty
no se reinicia.
Esto puede ocurrir cuando no se reinicia el módem al desactivar el DTR. He
visto que los LEDs RD y SD de mi módem se vuelven locos cuando esto
ocurre. Debe tener el módem reiniciado. Muchos módems compatible Hayes
hacen esto con &D3
, pero en mi USR Courier, he tenido que poner
&D2
y S13=1
. Mire en el manual de su módem.
getty
: Probablemente no tendrá puesto
CLOCAL
en ninguna línea de /etc/gettydefs
para el terminal,
y probablemente no está usando un cable completo de módem nulo. Necesita
CLOCAL
, el cual le dice a Linux que ignore las señales del control
del módem. Debería parecerse a esto:
# 38400 bps, entrada para un Terminal no inteligente
DT38400# B38400 CS8 CLOCAL # B38400 SANE -ISTRIP CLOCAL #@S @L login: #DT38400
# 19200 bps, entrada para un Terminal no inteligente
DT19200# B19200 CS8 CLOCAL # B19200 SANE -ISTRIP CLOCAL #@S @L login: #DT19200
# 9600 bps, entrada para un Terminal no inteligente
DT9600# B9600 CS8 CLOCAL # B9600 SANE -ISTRIP CLOCAL #@S @L login: #DT9600
Después, elimine el proceso getty
con el comando kill
y se
generará un proceso nuevo con la nueva entrada.
agetty
: Añada el parámetro -L
a la línea
de agetty
en /etc/inittab
. Esto hará que ignore las señales
de control del módem. Después ejecute de nuevo init
escribiendo
init q
. La línea debería ser como esta:
s1:345:respawn:/sbin/agetty -L 9600 ttyS1 vt100
Si está intentando usar el módem a más de 38400 bps, y no tiene una UART 16550A, debe conseguirla. Vea la sección ¿Qué son las UARTs? para saber más sobre las UARTs.
Esto es verdad. Linux no realiza ninguna detección de IRQ al arrancar, sólo hace la detección de los dispositivos serie. Así que no haga caso de lo que diga sobre las IRQs, ya que asume que son las IRQs estándar. Esto se hace porque la detección de IRQs no es fiable, y puede ser falsa.
Así, aún cuando tengo mi ttyS2
en la IRQ5, me sale
Jan 23 22:25:28 misfits vmunix: tty02 at 0x03e8 (irq = 4) is a 16550A
cuando Linux arranca.
Tiene que usar setserial
para decirle a Linux la IRQ que está usando.
Después de que Linux arranque, puede mirar en el fichero
/proc/interrupts
para ver que IRQs se han configurado realmente.
rz
y/o sz
no funcionan cuando llamo a mi máquina linuxcon un módemSi Linux busca /dev/modem
cuando intenta enviar un fichero, mire
en /etc/profile
, y /etc/csh.cshrc
. Algunas
distribuciones definen ahí muchos alias, sobre todo Slackware. Estos alias
echan a perder los programas zmodem. Elimínelos o corríjalos.
Esto ocurre en las consolas virtuales cuando envía datos binarios a la
pantalla, o a veces en conexiones serie. La forma de arreglar esto es
escribiendo echo ^v^[c
. Para los que son incapaces de identificar
los caracteres de control, es:
linux% echo <ctrl>v<esc>c
getty
o uugetty
no funciona todaviaExiste la opción DEBUG
que viene con getty_ps
. Edite el fichero
de configuración /etc/conf.{uu}getty.ttyS
N y añada
DEBUG=
NNN. Donde NNN es una de las combinaciones numéricas
siguiente, dependiendo de lo que quiera depurar:
D_OPT 001 activacion de las opciones
D_DEF 002 procesamiento del fichero de opciones por defecto
D_UTMP 004 procesamiento de utmp/wtmp
D_INIT 010 inicializacion de la linea (INIT)
D_GTAB 020 procesamiento del fichero gettytab
D_RUN 040 otros diagnosticos de ejecucion
D_RB 100 depuracion de rellamada
D_LOCK 200 procesamiento de bloqueo de uugetty
D_SCH 400 procesamiento de tareas
D_ALL 777 todo lo anterior
Poniendo DEBUG=010
es una buena forma de empezar.
Si está ejecutando syslogd
, la información de depuración aparecerá en
los ficheros log. Si no está usando syslogd
la información aparecerá
en /tmp/getty:tyyS
N si depura getty
y
/tmp/uugetty:ttyS
N si usa uugetty
, y en
/var/adm/getty.log
. Mire la información de depuración y vea que
está ocurriendo. Probablemente necesitará ajustar algunos parámetros del
fichero de configuración, y reconfigurar el módem.
También lo puede intentar con mgetty
. Algunas personas tienen mejores
resultados con él.