Удостоверьтесь, что вы используете правильный для вашей версии init синтаксис.
Различные init используют различный синтаксис в файле /etc/inittab. Удостоверьтесь, что вы используете правильный синтаксис для вашей версии getty.
Эта проблема может возникать, когда DCD или DTR неправильно установлены. DCD должен быть установлен только когда имеется фактическое соединение (то есть кто-то позвонил), а не когда getty наблюдает за состоянием порта. Проверьте, что ваш модем сконфигурирован так, чтобы DCD устанавливался только когда имеется соединение. DTR должен быть установлен всякий раз, когда кто-то использует или наблюдает за линией, вроде getty, kermit или любой другой программы связи.
Другая общая причина ошибки ``device busy", - что вы настроили ваш последовательный порт на уже кем-то занятое прерывание.
Когда каждое устройство инициализируется, оно запрашивает Linux о своих правах использования аппаратных прерываний. Linux смотрит, какое прерывание назначено усройству, и если это прерывание уже занято, то устройство не сможет корректно проинициализироваться. Устройство не имеет другого способа сообщить вам о своей неправильной инициализации, кроме выдачи сообщения "device busy", когда вы попытаетесь воспользоваться этим устройством. Проверьте прерывания на всех ваших платах (последовательных, ethernet SCSI и т.д.). Поищите конфликты IRQ.
Удостоверьтесь, что ваш модем сконфигурирован правильно. Проверьте регистры Е и Q. Это может происходить, когда ваш модем общается с getty.
Удостоверьтесь, что в вашем /etc/inittab getty вызывается правильно.
Неправильный синтаксис или имена устройств могут вызвать серьезные проблемы.
Проверите правильность синтаксиса вашего /etc/gettydefs, делая следующее:
linux# getty -c /etc/gettydefs
Также такое может случиться при неудачной инициализации uugetty . См. раздел ``getty или uugetty все еще не работает".
Вероятно у вас конфликт IRQ. Удостоверьтесь, что это не так. Проверьте все ваши платы (последовательные, ethernet, SCSI и т.д ...). Проверьте установки перемычек и параметры setserial для всех ваших последовательных устройств. Также попытайтесь обнаружить конфликты в /proc/ioports и /proc/interrupts .
Это может случиться, когда ваш модем не сбрасывается при отсутствии DTR. Я видел как светодиоды RD и SD сходили с ума, когда это случалось. Вы должны сбросить ваш модем. В большинстве Hayes-совместимых модемов это делается командой &D3, но на моем USR Courier, я должен был установить &D2 и S13=1. Проверьте ваше руководство по модему.
# 38400 bps Dumb Terminal entry
DT38400# B38400 CS8 CLOCAL # B38400 SANE -ISTRIP CLOCAL #@S @L login: #DT38400
# 19200 bps Dumb Terminal entry
DT19200# B19200 CS8 CLOCAL # B19200 SANE -ISTRIP CLOCAL #@S @L login: #DT19200
# 9600 bps Dumb Terminal entry
DT9600# B9600 CS8 CLOCAL # B9600 SANE -ISTRIP CLOCAL #@S @L login: #DT9600
Затем перезапустите init, напечатав init q. Запись должна выглядеть следующим образом:
s1:345:respawn:/sbin/agetty -L 9600 ttyS1 vt100
Если вы попробуете заставить работать ваш модем быстрее, чем на 38400 бит\сек, и у вас нет UART 16550A, то вы должны обновить вашу технику. О UART написано в разделе ``Что такое UART?".
Это не совсем так. Linux не пытается обнаружить IRQ при запуске, он делает только обнаружение последовательных устройств. Таким образом неважно, что он говорит о IRQ, потому что он принимает только стандартные IRQS.
Но когда при загрузке setserial изменяет IRQ, вы должны увидеть это на экране.
Так, например, при том, что я устанавливаю ttyS2 на IRQ 5, я вижу
Jan 23 22:25:28 misfits vmunix: tty02 at 0x03e8 (irq = 4) is a 16550A
вначале загрузки Linux. Вы должны использовать setserial, чтобы сообщить Linux IRQ, который вы используете.
Если Linux ищет /dev/modem, когда вы пытаетесь передавать файлы, посмотрите файлы /etc/profile или /etc/csh.cshrc. Возможно, что в этих файлах определены несколько псевдонимов, как это случается в некоторых дистрибутивах, особенно в Slackware. Эти псевдонимы запутывают программы zmodem. Уберите их или исправьте.
Это случается на виртуальных консолях, когда вы посылаете двоичные данные на ваш экран, или иногда при последовательных соединениях. Способ устранить это состоит в том, чтобы напечатать echo ^v^[c. Делается это так:
linux% echo <ctrl>v<esc>c
Есть опция DEBUG, которая приходит с getty_ps. Отредактируйте ваш настроечный файл /etc/conf.{uu}getty.ttySN и добавьте DEBUG=NNN. Где NNN - одна из следующих комбинаций чисел в зависимости от того, что вы собираетесь отлаживать:
D_OPT 001 установки опций
D_DEF 002 обработка файлов по умолчанию
D_UTMP 004 обработка utmp/wtmp
D_INIT 010 инициализация линии (INIT)
D_GTAB 020 обработка файла gettytab
D_RUN 040 другая диагностика времени выполнения
D_RB 100 отладка ringback
D_LOCK 200 обработка файла блокировки uugetty
D_SCH 400 обработка schedule
D_ALL 777 все вместе
Для первой отладки отлично подходит DEBUG=010.
Если у вас запущен syslogd, отладочная информация появится в ваших log-файлах. Если syslogd не запущен, то информация появится в /tmp/getty:ttySN для отлаживаемого getty и /tmp/uugetty:ttySN для uugetty, и в log-файле /var/adm/getty.log . Посмотрите в отладочной информации, что происходит. Наиболее вероятно, что вам придется настроить некоторые из параметров в вашем файле конфигурации, и перенастроить ваш модем.
Вы могли бы также попробовать mgetty. Для некоторых он проще.