Minicom input output error

Следующий
Предыдущий
Содержание

.

18. Разрешение
проблем

18.1 Я подключил модем, но
система его не видит

Также может выдаваться сообщение об ошибке: «Modem not
responding» («Модем не отвечает»). Возможны по крайней мере 4 причины:

1. У Вас винмодем, а подходящий для него драйвер не
   установлен.
   Или модем неисправен. Или находится в режиме передачи данных («online
   data mode»), если не отвечает. См. Винмодем
2. Ваш модем не работает (disabled), поскольку ни BIOS, ни
   Linux не смогли подключить (enable) его. У него нет адреса I/O (тут
   подразумевается последовательный порт, к которому подключен модем —
   замеч. перев.).
3. Ваш модем подключен (enabled) и у него есть адрес I/O, но
   для данного адреса не назначен номер порта ttyS (например, ttyS14).
4. Вашему модему (порту — см. замеч. перев. выше) присвоен
   номер ttyS (ttyS4, к примеру), но Вы по ошибке используете неправильный
   номер (ttyS2 вместо ttyS4, например). См. неправильный_ttySx
   и/или wvdial и/или minicom (проверка модема)

Случай 1:
Винмодем

Обычно последовательный порт винмодема (или неисправного
модема)
виден системой и без драйвера. Но при опросе по данному порту
программой wvdial (или
другой) ответа нет, так как для взаимодействия с самим
винмодемом необходим драйвер. Вы увидите сообщение, что модем не
найден. Однако, при загрузке системы карта модема, скорее всего,
определяется системой и выводится сообщение, что модем обнаружен. Т.е.,
Вам говорят, что модем найден и что модем не найден! Все это означает,
что модем не будет работать. Конечно, он может быть
неработающим не только потому, что у Вас винмодем, для
которого
нет драйвера.. См. Программные
модемы (винмодемы, линмодемы).

Случаи 2-3

Случаи 2 и 3 означают, что для Вашего модема нет
последовательного порта. См. Отсутствует
последовательный порт.

Случай 4:
Неправильный номер ttySx

Если Ваш случай — четвертый, то Вам повезло. Вам просто надо
найти, какой ttyS соответствует Вашему модему.

wvdial

В комплекте с wvdial идет программа wvdialconf, которая сама
находит
модемы, проверяя стандартные последовательные порты. Наберите
«wvdialconf <название-нового-файла>». Это создаст новый
файл
настроек wvdial, в котором будет указан порт модема (если Вы не будете
использовать wvdial, то этот файл Вам не пригодится).
См. wvdialconf.
Если модем находится в режиме передачи данных (online), то в
таком
случае wvdialconf сообщит «No modem detected» («Модем не обнаружен»).
См. minicom (проверка
модема)

minicom
(проверка модема)

Выяснить, присутствует ли на определенном порте модем, можно,
запустив minicom (только перед этим в minicom надо сделать настройки
для этого
порта. Сделав настройки, сохраните их, выйдите из minicom и запустите
его снова). Если, введя «AT», Вы не увидите в ответ «OK», то попробуйте
ввести ATQ0 V1 E1. Если и после этого Вы не получаете в ответ OK (а,
может, и вовсе не видите вводимые команды), то модема на данном порте,
судя по всему, нет. Но может быть, что он не виден по одной из
указанных выше причин — случай 1, 2 или 3.

Отсутствие отклика от модема также может объясняться тем, что
модем
остается в режиме передачи данных и не принимает никакие AT-команды
(точнее,
модем принимает команды как обычные данные —
замеч. перев.). Если во время сеанса неожиданно произошло
разъединение
(например, «убийство» процесса сигналом 9), то модем не
«сбрасывается» в командный режим, в котором с ним возможно
взаимодействие посредством AT-команд. Minicom может сообщить»You are
already online. Hangup first.» («Вы уже на линии. Сперва
отсоединитесь.») (может быть и другая причина появления такого
сообщения — см. Вы
уже на линии! Сперва отсоединитесь.)
Получается, что Вы как бы остаетесь на связи, но подсоединится к
чему-нибудь через телефонную линию Вы не можете. Wvdial в
такой
ситуации выводит «modem not responding» («модем не отвечает»).

Исправить указанную ситуацию можно перезагрузкой компьютера.
Но есть
и другой способ — послать модему последовательность +++, которая
укажет ему перейти из режима передачи в командный режим.
Последовательность +++ должна предваряться и завершаться временными
задержками длительностью около 1 секунды (в течение данных «защитных
интервалов» не должно быть никаких данных). Данный способ может
не работать, если другой процесс использует модем, поскольку
последовательность +++ может быть «разбавлена» символами от данного
процесса, или же эти символы могут оказаться на месте защитных
интервалов. По иронии, даже если через модем не передаются
никакие
данные, неожиданный ввод +++ вызовет обмен служебными пакетами
(невидимый для Вас), который нарушит требуемую задержку и,
соответственно, помешает получению желаемого (?). Обычно +++
записывается в строке, называемой «строкой отбоя» («hangup
string»), которая используется minicom’ом, если ему дать команду
отсоединиться от линии. Сделать это также можно путем завершения
работы minicom’а и его повторного запуска.

Помимо отсутствия ответа на AT-команды могут быть еще такие
проблемы в minicom:

• Много секунд занимает ожидание реакции на производимые
  действия (в
  том числе на перемещение курсора всего лишь на одну строчку вниз). См. Чрезвычайно медленно: текст появляется на
  экране медленно, после долгих задержек
• Появляются непонятные символы,
  которых не должно быть в ответе на AT-команды. Такое может
  быть
  из-за того, что модем все еще может оставаться на связи, и с другого
  конца телефонной линии могут приходить какие-то пакеты или что-то еще.

18.2 «Modem is busy» («Модем
занят»)

Что может означать данное сообщение — зависит от программы,
которая
его вывела. Модем действительно может быть занят (используется
какой-нибудь программой). В дистрибутиве SuSE, как сообщалось, причиной
такого сообщения могло быть одновременное присутствие двух драйверов
последовательного порта вместо одного. Один драйвер был встроен в
ядро, а второй был в виде модуля.

kppp посылает данное сообщение при неудачной попытке
получить/задать
«stty»-параметры последовательного порта. (Наподобие «Ошибки
ввода/вывода» («Input/output error»), которую можно получить при
выполнении «stty -F /dev/ttySx»). Для получения некоторых
«stty»-параметров необходимо, чтобы драйверу был известен точный адрес
порта. Но драйвер может иметь неправильный адрес. (Узнать, что «думает»
драйвер, можно с помощью setserial.) Поэтому сообщение «модем занят»
может означать, что последовательный порт (и, соответственно, модем) не
найден.

Если у Вас pci-модем, то узнать правильный адрес и irq модема
поможет одна из команд: lspci -v, cat /proc/pci, dmesg. После этого
посмотрите, показывает ли то же самое setserial. Если нет, то Вам надо,
чтобы стартовый скрипт содержал команду setserial, которая
сообщит
драйверу правильные адрес и irq.

18.3 «You are already online!
Hang up first.» («Вы уже на линии! Сперва отсоединитесь.») (от minicom)

Присутствует сигнал CD. Это означает, что либо сеанс связи
действительно установлен (несущая обнаружена), либо настройки модема
таковы, что он постоянно выдает сигнал CD. Наберите в minicom’е команду
at&v, чтобы посмотреть, не задано ли &C или
&C0. Если
задано, то CD будет присутствовать постоянно (пока на модем подается
питание — добав. перев.:)), а Вы будете получать ошибочное по сути
сообщение, приведенное в заголовке. Чтобы исправить это, надо задать
&C1, указав в строке инициализации или сразу сохранив в модем.

18.4 На коробке модема написано
56k, а скорость к 56k не приближается

Чтобы скорость модема была близка к 56k, надо иметь линию с
очень
малым уровнем шумов. Но телефонные линии бывают настолько плохи,
что на них максимум можно получить 28.8k или даже меньше. Иногда
проблемы могут вызывать дополнительный(ые) телефон(ы), подключенный(ые)
параллельно к этой же линии. Чтобы проверить это, можно отсоединить
(если это возможно) от линии все, кроме модема, а сам модем
подсоединить как можно ближе к месту, где телефонная линия входит в
помещение. Скорость увеличилась?

18.5 Загрузка файлов либо
прерывается, либо медленная

Данная проблема может быть вызвана тем, что отсутствует
управление
потоком ПК-модем и/или модем-модем). Случай отправки
(uploading):
При высокой скорости DTE (115.2k) исходящий поток (от ПК к модему и
далее) из-за низкой пропускной способности телефонной линии не будет
проходить весь. Это приведет к возникновению большого числа ошибок и
повторной отправке пакетов. Таким образом, передача файла займет много
времени. Файлы, вообще, могут «застрять» и никуда не уйти В обратном
направлении (от модема к ПК) при высокой скорости DTE никаких проблем
вроде бы быть не должно

Случай приема (downloading): Если задана низкая скорость DTE и
отсутствует управление потоком, то в таком случае для принимаемого файла
«пробка» может возникнуть на участке от модема к ПК (думаю, скорость
порта должна быть очень низкой — перев.). Также при отсутствии
управления потоком передача может не получиться при
загрузке больших несжатых файлов и веб-страниц, если модем
использует сжатие данных (?).

18.6 Выдается сообщение: «line
NNN of inittab invalid» («строка NNN в файле inittab неправильная»)
(для случая приема звонков)

Проверьте, что Вы используете правильный синтаксис init,
соответствующий Вашей версии. Различным
версиям init соответствуют различные
синтаксисы файла /etc/inittab.
Проверьте, что Вы используете правильный синтаксис getty,
соответствующий Вашей версии.

18.7 Постоянно
получаю сообщение: «Id «S4″ respawning too fast: disabled for 5
minutes» («Процесс с id
«S4″ перезапускается слишком быстро: отключено на 5 минут»)

Id процесса не обязательно должен быть «S4» — может быть
любой
другой. В нашем случае (id «S4») посмотрите на строку в файле
/etc/inittab, которая начинается с «S4». Проблема связана с этой
строкой. Проверьте ее синтаксис и то, что устройство (в данном случае
это ttyS4) существует и доступно. Указанное сообщение об ошибке
возникает в случае, когда модем сбросил сигнал CD, а getty пытается
открыть порт. При сброшенном CD происходит уничтожение процесса getty.
Однако, после уничтожения getty сразу же перезапускается, поскольку так
задано в файле /etc/inittab (?). Но так как CD остается сброшенным, то
getty опять уничтожается, и все повторяется снова и снова (очень
быстро). Кажется, что в случае, когда от модема отсоединился кабель,
или в случае, когда задан неправильный последовательный порт, CD как бы
тоже оказывается сброшенным. Все это может произойти, когда Ваш модем
обменивается информацией с getty. Проверьте, что Ваш модем настроен
правильно. Посмотрите AT-команды E и Q.

Если Вы используете uugetty, проверьте правильность синтаксиса
файла /etc/gettydefs, выполнив:

linux# getty -c /etc/gettydefs

Рассматриваемая проблема также может возникать при неудачном
запуске uugetty. См. uugetty
по-прежнему не работает.

18.8 Прием звонков: getty не
перезапускается после завершения соединения удаленным пользователем

Причиной этого может быть то, что модем не перезагружается
правильно, когда происходит падение DTR при завершении соединения
пользователем. У большинства Hayes-совместимых модемов все проходит
нормально, если в их настройках стоит &D3.
Но в случае модемов USR Courier, SupraFax и некоторых других Вам надо
задать &D2 (и еще S13=1
в некоторых случаях). Посмотрите в руководстве к своему модему (если,
конечно, оно имеется :)), что должно быть. См. также Завершение входящего
соединения

18.9 NO DIALTONE (нет гудка в
линии)

Данное сообщение означает, что в линии нет гудка (иногда стОит
верить написанному — перев. :)). Возможно, что кто-то занял эту же
линию через параллельно подключенный телефон. А может, что
модем просто не включен в линию (не воткнут телефонный шнур),
или
обрыв где-то в линии. Подключите вместо модема обычный телефон (через
тот же шнур). Послушайте, есть ли гудок в телефонной трубке.

Если по какой-либо причине модем не распознает гудок в линии,
то Вы
можете заставить его набирать номер и устанавливать соединение, не
дожидаясь гудка в линии. Для этого в строку инициализации надо добавить
команду X3.

18.10 NO CARRIER (нет несущей)

Такое сообщение означает, что модем не обнаруживает несущую
(аналоговая синусоида) от другого модема. Если соединение было, то это
означает, что оно потеряно. Причиной мог стать шум в линии или само по
себе плохое соединение (?). Или же другой модем мог «повесить
трубку» по какой-либо причине: Возможно, процесс идентификации (login)
не отработал нормально. Возможно, PPP не запустился нормально.
Возможно, был превышен временной лимит.

Если Вы получаете это сообщение об ошибке до установления
соединения, то это опять же значит, что несущая противоположного модема
не была найдена Вашим модемом. Так может произойти из-за того, что на
противоположном конце линии находится не модем. Например, вместо
модема Ваш звонок может принять автоответчик. Сообщение ‘NO
CARRIER’ также возникает в случае, когда модемы не могут договориться
между собой о протоколе. Это может относиться к первым модемам V.90,
которые при установке соединения сперва предлагают протокол X2 или
K56flex. Эти два протокола являются устаревшими, и сервера некоторых
провайдеров сбрасывают соединение (вешают трубку) в таком случае,
поскольку они не понимают данных протоколов и не ждут, пока вызывающий
модем перейдет на V.90.

Если Вы заставите модем сбросить соединение, сбросив сигнал
DTR, или
пошлете модему сигнал отбоя (команда ATH), то также можете получить
рассматриваемое сообщение об ошибке. Но в данном случае Вы сами (или
запущенная Вами программа) хотите завершить соединение, поэтому это не
должно быть проблемой. Да и получение сообщения ‘NO CARRIER’
предполагается в этом случае только, если были потеряны данные. Поэтому
обычно при завершении соединения посредством команды отбоя (или
посредством сброса сигнала DTR) Вы получаете только OK. Ваша программа
может даже и вовсе ничего не показать Вам при этом.

18.11 uugetty по-прежнему не
работает

В getty_ps для поиска ошибок
есть опция DEBUG (отладка). Добавьте
в файл /etc/conf.{uu}getty.ttySN
строчку DEBUG=NNN.
Здесь NNN — один из следующих кодов,
определяющих область поиска:

D_OPT 001 заданные опции (option settings)
D_DEF 002 обработка файла настроек по умолчанию (defaults file
 processing)
D_UTMP 004 обработка utmp/wtmp (?) (utmp/wtmp processing)
D_INIT 010 строка инициализации (line initialization) (INIT)
D_GTAB 020 обработка файла gettytab (gettytab file processing)
D_RUN 040 другая диагностика (other runtime diagnostics)
D_RB 100 отладка "обратного вызова" (ringback debugging)
D_LOCK 200 обработка lock-файла uugetty (uugetty lockfile
  processing)
D_SCH 400 планировщик (?) (schedule processing)
D_ALL 777 все подряд (everything)

Хорошо начать с задания DEBUG=010.

При запущенном syslogd вся
отладочная информация будет сохраняться в Ваши log-файлы. Если syslogd
не запущен, то информация будет сохраняться: в /tmp/getty:ttySN
— для getty, в /tmp/uugetty:ttySN
— для uugetty, и в /var/adm/getty.log.
Это информация поможет узнать, в чем может быть причина проблемы.
Весьма вероятно, Вам потребуется подрегулировать некоторые
параметры в файле настроек uugetty и
изменить какие-нибудь настройки у модема.

Можно также попробовать использовать mgetty.
Возможно с нею Вам повезет больше

18.12 (Оставшаяся часть данного
раздела одинакова для Serial HOWTO и для Модем HOWTO)

18.13 Последовательный порт
отсутствует

Возможны 3 варианта:

1. Ваш порт отключен, поскольку ни у BIOS, ни у Linux не
   получилось его подключить. У порта нет адреса IO.
2. Ваш
   порт подключен и у него есть адрес IO, но он у него нет номера ttyS
   (например, ttyS14), соответствующего этому адресу, поэтому порт не
   может использоваться. Назначить номер ttyS порту можно с помощью
   setserial.
3. У
   порта есть номер ttyS (например, ttyS14), но Вы не знаете, какому
   разъему (сзади корпуса Вашего ПК или внутри него) он соответствует. См.
   Serial-HOWTO: «Which Connector on the Back of my PC is ttyS1, etc.?»
   («Какой разъем сзади моего ПК называется ttyS1, ttyS2 и т.д.?») Если
   перед Вами стоит обратная задача: узнать какое название у порта, к
   которому подключен модем, то см. Я
   подключил модем, но система его не видит

Сперва проверьте сообщения BIOS при загрузке, относящиеся к
последовательным портам (заодно посмотрите меню BIOS, в котором
задаются настройки последовательного порта). Затем, если у Вас
PCI-порт, выполните команду: lspci -v. Если в ее выводе встретится «LPC
Bridge», то Ваш последовательный порт, вероятно, подключен к шине LPC,
которая не очень хорошо поддерживается Linux пока что ?? Если у Вас PnP
ISA-порт, то попробуйте выполнить «pnpdump —dumpregs» и/или посмотрите
Plug-and-Play-HOWTO. Если окажется, что порт подключен (enabled), то
попытаться
найти его адрес IO можно следующим образом:

Сканирование/проверка стандартных (legacy) портов

В основном, данная информация касается портов, не
подключенных
к шине PCI и не поддерживающих Plug-and-Play, к коим можно отнести
и ISA-порты.

Просканировать  все подключенные к шине порты
позволяет
утилита scanport (входит в состав только Debian ??), в
результате выполнения которой можно найти
неизвестный
порт, в том числе последовательный (но проверку портов scanport не
производит). Предупреждение: Во время сканирования Ваш ПК может
подвиснуть
Можно и вручную попытаться проверить определенный адрес, по которому
— как Вы предполагаете — может находиться последовательный порт, но
когда таких адресов несколько, то это превращается в долгое и
утомительное занятие… См. Проверка.

18.14 Конфликт прерываний (в
Вашем ПК есть слоты ISA)

Если в Вашем ПК присутствует шина ISA, то возникновение
конфликта
прерываний (IRQ) может быть связано с нехваткой свободных IRQ.
Обычно BIOS содержит список зарезервированных IRQ,
зарезервированных для существующих (legacy) ISA-карт. Если
зарезервированных IRQ слишком много, то BIOS может не найти свободное и
назначить последовательному порту неправильное значение, что приведет к
конфликту. Поэтому посмотрите, все ли зарезервированные IRQ
действительно необходимы, нельзя ли освободить какое-нибудь одно, чтобы
его мог использовать последовательный порт. См.
также Plug-and-Play-HOWTO.

18.15
Чрезвычайно медленно:
текст появляется на экране медленно, после долгих задержек

Вероятно, это связано с неправильно заданными или
конфликтующими
прерываниями. Примерами рассматриваемой проблемы могут быть
такие
ситуации: Вы что-то вводите с клавиатуры, но на экране в
течение
долгого времени ничего не появляется, отобразиться
может только
последний введенный символ, которым может оказаться невидимый символ
возврата (<return>), поэтому все, что Вы заметите, будет
переход
курсора на одну строчку вниз. В другом случае вместо ожидаемого вывода
всех данных на экран отображаются только 16 символов или около
того, затем после долгого ожидания следует другая партия символов и
т.д. Также может возникнуть сообщение об ошибке «input overrun» (что-то
вроде «превышение ввода» — перев.).

Более подробно примеры и причины описаны в разделе
Serial-HOWTO,
который называется «Interrupt Problem Details» («Проблемы, связанные с
прерываниями»).

Если это касается устройств Plug-and-Play, то посмотрите также
Plug-and-Play-HOWTO.

Быстрым способом проверить, действительно ли проблема
связана с
прерыванием, является установка с помощью setserial значения IRQ на 0.
Этим Вы укажете драйверу использовать опрос (polling) вместо
конкретного номера прерывания. Если проблема «медлительности»
после этого исчезает, то причина кроется в прерывании. Конечно, можно
оставить использование опроса, но это приведет к излишнему расходу
ресурсов компьютера (которых и так всегда мало — примеч. перев.), так
что лучше разобраться с прерыванием

Определить конфликт прерываний в Linux может оказаться не
просто,
поскольку предполагается, что Linux не допускает конфликтов прерываний.
Если — по мнению Linux — Вы попытаетесь сделать что-то, что приведет
к конфликту, то получите сообщение /dev/ttyS?: Device or
resource busy (/dev/ttyS?:
Устройство или ресурсы заняты). Но конфликт может
получиться и без Вашего прямого участия, если setserial сообщит ядру
неправильную информацию. Ядро верит этой информации (оказывается
обманутым) и, следовательно, не предполагает наличия конфликта. Таким
образом, setserial не помогает выявить конфликт, скорее наоборот:
вводит в заблуждение и ядро, и Вас (надо сказать, что информация в
файле /proc/interrupts тоже взята от setserial). Вам самому надо
выяснить, что в настройках setserial неверно и исправить их так, чтобы
они соответствовали внутренним настройкам последовательного
порта.

Внутренние настройки порта устанавливаются либо перемычками
(посмотрите, как они стоят), либо «программным обеспечением PnP». В
случае PnP для получения информации о настройках выполните команду
«pnpdump —dumpregs» (если шина ISA) или «lspci» (если шина PCI). Затем
сравните полученные данные с настройками setserial. Они должны
совпадать.

18.16 Что-то медленно. Я
ожидал(а), что будет быстрее

Скорее всего, установлено очень низкое значение бодовой
скорости. Но
утверждалось также, что похожее было и в случае задания слишком большой
бодовой скорости, не поддерживаемой последовательным портом (такой как
230400).

Другой причиной может быть то, что Ваше подключенное к
последовательному порту
устройство  (модем, терминал, принтер) на самом деле работает
не
так быстро, как Вы думали. Модем 56k редко работает на скорости 56k, а
в самом Интернете не так уж редки свои заторы и пробки, которые, само
собой, приводят к замедлению передачи данных. Если на противоположном
конце соединения отсутствует цифровая линия и не используется
специальный «цифровой модем» (который не продается в любом компьютерном
магазине), то скорости выше 33,6 кбит/с не будет.

Еще одной причиной может быть устаревший
последовательный порт:
UART 8250, 16450 или один из первых 16550 (или драйвер
последовательного порта думает, что у Вас устаревший
последовательный порт). См. раздел «What are UARTS» в
Serial-HOWTO.

Чтобы узнать о своих последовательных портах, а точнее о том,
что о
них думает драйвер, выполните команду «setserial -g /dev/ttyS*». Если в
выводе этой команды тип UART отличается от 16550A, то проблема может
заключаться в этом. Но если Вы считаете, что setserial (и,
следовательно, драйвер) ошибается, то задайте ей нужные значения. См.
раздел Setserial.
Только учтите, что если у Вас действительно устаревший порт, то,
обманув setserial, Вы сделаете только хуже.

18.17 Во время загрузки
показываются неправильные значения IRQ для последовательных портов

Для не-PnP портов Linux вообще не выполняет никакой
проверки при загрузке. Поиск последовательных устройств
производится при загрузке модуля драйвера последовательного порта. Но
не стоит обращать внимание на показываемые при этом значения IRQ,
поскольку предполагается, что они являются стандартными. Считается, что
процедура определения IRQ является ненадежной, поэтому проще показать
стандартные значения (?) Но затем из одного из стартовых скриптов
запускается setserial, который изменяет значение IRQ и отображает это
новое (будем надеяться, что правильное :)) значение на экране. Если
значение IRQ не изменилось и осталось неправильным, то порт работать не
будет.

Так, хотя у моего ttyS2 IRQ
равно 5, в начале загрузки Linux мне показывается

ttyS02 at 0x03e8 (irq = 4) is a 16550A

(У более старых ядер «ttyS02» может обозначаться как «tty02»).
Используемое значение IRQ указывается Linux (драйверу) с помощью все
той же setserial.

18.18 «Cannot open /dev/ttyS?:
Device or resource busy» («Не могу открыть /dev/ttyS?: Устройство или
ресурсы заняты») 

См. /dev/tty? Устройство
или ресурсы заняты

18.19 «Cannot open /dev/ttyS?:
Permission denied» («Не могу открыть /dev/ttyS?: Доступ запрещен»)

Проверьте права доступа к файлу последовательного
порта,
выполнив команду: «ls -l /dev/ttyS?». Если Вы являетесь владельцем
файла /dev/ttyS? (обычно им является root — прим. перев.), то
необходимо, чтобы строка, описывающая права, начиналась с «crw», здесь
латинская буква «с» в начале означает символьное устройство (Character
device). Если же Вы не являетесь владельцем файла /dev/ttyS? (см. прим.
выше — перев.), то для работы с портом надо, чтобы на 8-й и
9-й
позиции строки, описывающей права, были символы «rw», означающие право
чтения и записи для любого пользователя. Изменение прав доступа
осуществляется командой «chmod». Есть и другие (более надежные) способы
получить доступ к файлу последовательного порта, например включение
пользователя в группу, имеющую соответствующие права. Некоторые
программы сами изменяют права доступа во время своего выполнения и
восстанавливают их при своем нормальном завершении. Но тут есть
опасность: в случае аварийного завершения (например, при
незапланированном отключении питания ПК) правильного
восстановления прав не произойдет…

18.20 «Cannot open /dev/ttyS?»
(«Не могу открыть /dev/ttyS?»)

Если stty не было выставлено clocal, то для открытия
последовательного порта может потребоваться, чтобы был сигнал
CD. Если к последовательному порту ничего не подключено, или на
устройство, которое подключено к последовательному порту (например,
внешний модем), не подано питание, то сигнала CD, естественно, не
будет. Возникнет сообщение «Не могу открыть…».
Либо выставите clocal,
либо подключите к последовательному порту устройство и подайте
на него
питание.

Но даже если к последовательному порту подключено устройство и
на
него подано питание, последовательный порт все равно может не
открываться. Так может быть из-за того, что у самого устройства
оказывается сброшенным сигнал CD, на одноименном выводе (CD)
последовательного порта напряжение отрицательно, сигнал CD
отсутствует.

18.21 «Operation not supported by
device» («Операция не поддерживается устройством») (относится к ttyS?)

Появление данного сообщения означает, что операция,
запрашиваемая
setserial, stty или др. программой, не может быть выполнена, потому что
ядро не поддерживает ее выполнение. Раньше такое часто происходило по
причине того, что не был загружен модуль драйвера
последовательного порта. Но после появления PnP такое сообщение чаще
стало появляться по причине несовпадения действительного адреса модема
или другого последовательного устройства (который назначается PnP) с
адресом,
указанным в настройках драйвера (setserial). Очевидно, что команды (на
выполнение операции), отправленные по адресу драйвера, не дойдут до
модема (поскольку у него другой адрес) и не будут исполнены. См. Какие адрес IO и IRQ
«зашиты» в мой последовательный порт?

Если Вы получили сообщение об ошибке, что модуль драйвера
последовательного порта не загружен, но «lsmod» показывает, что все как
раз наоборот (т.е. что он загружен), то, скорее всего, модуль
загрузился позже. Обычно загрузка модуля происходит
автоматически по мере необходимости (если, конечно, его можно найти).
Чтобы так происходило, модуль прописывается в файле /etc/modules.conf
или /etc/modules. Сам модуль должен находиться в
/lib/modules/…/misc/serial.o.

18.22 «Cannot create lockfile.
Sorry» («Не могу создать lock-файл. Извините»)

Иногда вместо указанного сообщения при невозможности создать
lock-файл (файл блокировки) может выдаваться другое сообщение: «…
Device or resource busy» («… Устройство или ресурсы заняты»). Когда
порт открывается какой-нибудь программой, в каталоге /var/lock
(lock-каталог) создается lock-файл. Если для lock-каталога заданы
права, не позволяющие производить в него запись, то в нем нельзя будет
создать lock-файл. Чтобы посмотреть права доступа к данному каталогу,
выполните команду: «ls -ld /var/lock». Владелец каталога, коим является
root, и группа, которой он принадлежит, для нормальной
работы должны
иметь все права (rwx), при этом в группу должны быть включены
пользователи, которым требуется доступ к порту. Для остальных (третья
тройка прав) должны стоять права на чтение и выполнение (r-x). Но стоит
отметить, что такая схема не обеспечивает полной безопасности Для
изменения прав используйте команду «chmod», для изменения групп —
«chgrp». Само собой разумеется, что при отсутствии lock-каталога в нем
также невозможно будет создать lock-файл. Более подробная информация о
lock-файлах есть в подразделе «What Are Lock Files», содержащемся в
Serial-HOWTO.

18.23 «Device /dev/ttyS? is
locked.» («Устройство /dev/ttyS? заблокировано.»)

Такое сообщение означает, что какой-то другой процесс, судя по
всему,  уже занял последовательный порт. Есть несколько
способов
выяснить, какой процесс мешает нам воспользоваться нашим портом Один
из них — посмотреть lock-файл (/var/lock/LCK…). В нем
должен
содержаться идентификатор процесса (process id). Если process id равен,
скажем, 100, то для того, чтобы узнать об этом процессе, наберите: «ps
100». Если решите, что этот процесс больше не нужен, то Вы
можете «убить» его командой «kill 100». Если он будет
сопротивляться, то примените команду «kill -9 100», которая не оставит
ему шансов Но lock-файл в этом случае удален не будет, и Вам надо
будет самому его удалить. Если процесс с таким id (равным 100) вообще
отсутствует, то Вы просто удаляете этот lock-файл, хотя, как правило,
lock-файлы, содержащие id несуществующих процессов, должны удаляться
автоматически.

18.24 «/dev/tty? Device or
resource busy» («/dev/tty? Устройство или ресурсы заняты»)

Данное сообщение предположительно говорит о том, что
устройство, к
которому Вы пытаетесь получить доступ (или которым собираетесь
воспользоваться), занято (используется), или же о том, что ресурсы,
необходимые для этого устройства (например IRQ), уже используются
другим устройством и не могут быть разделены. Не очень понятно, правда?
Если с устройством, которое занято, еще
можно разобраться, то вот с ресурсами,
которые «уже используются»… Еще более запутывает эту ситуацию тот
факт, что в некоторых случаях ни устройство, ни требуемые ресурсы на
самом деле не являются «занятыми»…

Раньше при выключении компьютера путем простого отключения
питания
(простого нажатия на выключатель) в системе могли оставаться ненужные
lock-файлы, что  впоследствии приводило к появлению
рассматриваемого сообщения и не позволяло открыть последовательный
порт. В настоящее время предполагается, что система должна сама
автоматически удалять такие lock-файлы, но по состоянию на 2006-й год
оставалась проблема с wvdial, связанная с lock-файлами: если
wvdial
не может создать lock-файл, потому что не имеет права на запись в
каталог /var/lock/, то Вы видите такое же сообщение. См. Не могу создать lock-файл. Извините

Следующий пример описывает ситуацию, когда прерывания не могут
быть
разделены (во всяком случае, одно из прерываний на шине ISA). Слова
«ресурсы заняты» в сообщении часто означают (ttyS2
взят в качестве примера): «Вы не можете работать с ttyS2,
поскольку другое устройство использует прерывание ttyS2«.
Вероятный
конфликт прерываний получается из-за некорректных настроек setserial.
Более правильным сообщением об ошибке в данном случае было бы такое:
«Нельзя использовать ttyS2,
поскольку, как следует из
настроек setserial (и ядра, соответственно), ему задано прерывание,
которое уже используется другим устройством». Если у двух устройств
одинаковое IRQ, но работает только одно из них, то все нормально, т.к.
конфликта еще нет. Но как только Вы попытаетесь «запустить» второе
устройство (без отключения первого), то тут же получите сообщение об
ошибке: «… ресурсы заняты». Так получается из-за того, что ядро
отслеживает IRQ только тех устройств, которые используются в данный
момент, и не следит за IRQ незадействованных (еще не открытых)
устройств. Для адресов ввода-вывода в случае конфликта ситуация схожа.

Рассматриваемая ошибка также может возникать из-за наличия в
системе
одновременно двух драйверов последовательного порта: одного в виде
модуля и другого, встроенного в ядро. Оба драйвера пытаются
использовать одни и те же ресурсы, и для одного из них они оказываются
«занятыми».

Появление рассматриваемого сообщения возможно в двух случаях:

1. В системе (в самих устройствах) действительно имеется
   конфликт ресурсов (скрытый?).
2. setserial имеет неправильные настройки, из-за которых
   возникает
   конфликт, которого на самом деле нет, тем не менее порт нельзя
   использовать (сам до конца не понимаю — прим. перев. :)).

Вам надо узнать, какое прерывание по мнению setserial
используется ttyS2 (на месте ttyS2
может быть любой другой последовательный порт — напом. перев.). Для
этого загляните по адресу /proc/tty/driver/serial. Также это можно
выяснить, выполнив саму команду «setserial» для ttyS2.

Ошибка в предыдущих версиях: до 2001 года существовала ошибка,
которая не позволяла узнавать настройки с помощью самой
setserial: setserial выдавала такое же сообщение,
что, мол,
«… ресурсы заняты».

Попытайтесь перезагрузиться (reboot) или просто выйти (exit),
или
просто убить (kill) все процессы, которые могут вызывать конфликт. При
перезагрузке: 1. Посмотрите, что (какие значения) показывается в
сообщениях для последовательных портов при повторной загрузке. 2.
Остается надежда, что файл, запускающий setserial во время загрузки
(один из стартовых скриптов), не создаст (сам) тот же самый конфликт
снова. (Т.е. подразумевается, что в строках, запускающих
setserial
для каждого порта, прописаны правильные значения их настроек.)

Если Вы знаете, какой IRQ сейчас используется последовательным
портом, тем же ttyS2
:), то тогда можете посмотреть в /proc/interrupts, что еще (кроме
другого последовательного порта — одно прерывание приходится на два
порта (?) ) использует это же IRQ. Также можно проверить, все ли
значения IRQ, приведенные там, и значения, выдаваемые setserial,
являются правильными (т.е. соответствуют тем значениям, что «прописаны»
в самих портах). Способом выяснить, действительно
ли рассматриваемая проблема вызвана возможным конфликтом
прерываний, является установка значения IRQ на 0 с помощью setserial
(при котором драйвером используется опрос прерываний). Если сообщение о
«занятости ресурсов» исчезает, то проблема, скорее
всего, была связана с конфликтом прерываний. Оставлять IRQ,
равным
0, не рекомендуется, поскольку это приводит к дополнительной нагрузке
на ЦП.

18.25 «Input/output error»
(«Ошибка ввода/вывода»), получаемая от setserial, stty, pppd и т.д.

Такое сообщение говорит о том, что связь с последовательным
портом работает не так, как должна. Возможно, что по адресу
ввода-вывода, который был задан для setserial, нет никакого
последовательного порта. Возможно, что имеет место конфликт прерываний
(или конфликт адресов ввода-вывода). Возможно, что последовательный
порт уже чем-то используется (занят или открыт), и поэтому попытка
получить/задать параметры с помощью setserial или stty приводит к
появлению данного сообщения. Еще одной причиной возникновения этой
ошибки может быть опечатка в названии последовательного порта, например
вместо «ttyS» было набрано «ttys» (обращайте внимание на регистр).

18.26 «LSR safety check engaged»

LSR — это название аппаратного регистра. Обычно появление
данного сообщения означает, что драйверу задан неправильный адрес
последовательного порта. Надо изменить настройки либо у драйвера, либо
у самого порта. См. Настройка
последовательного порта: адрес IO, IRQ и/или setserial

18.27 Ошибки переполнения
(overrun) последовательного порта

Переполнение происходит в аппаратном буфере FIFO, увеличить
размер которого Вы, к сожалению, не можете. В 2002 году году сообщалось
о следующей особенности: из-за ошибки в некоторых версиях ядра 2.4 в
сообщениях о переполнении не указывался номер порта — просто «ttyS».
Но при использовании devfs эта ошибка не проявлялась, порт
указывался в ее нотации, например «tts/2». См. раздел «Higher Serial
Thruput» («Более высокая пропускная способность последовательного
порта») в Serial-HOWTO.

18.28 Модем не принимает входящие
звонки

Это касается только случая, когда модем используется и для
совершения звонков, и для их приема. Если модем будет выдавать сигнал
DCD (=CD), то некоторые программы (но не mgetty) будут думать, что он
занят. Это приведет к возникновению проблемы при установке связи. Модем
должен выставлять сигнал DCD только во время соединения, а не тогда,
когда getty прослушивает порт.
Проверьте, что Ваш модем выдает DCD только при наличии соединения
(&C1). Также и сигнал DTR должен устанавливаться программами,
такими как getty, kermit
и др., только на время, когда модем ими используется или когда
прослушивается линия.

18.29 Данные на порт приходят
нерегулярно, спорадически 

Порт может использоваться другой программой. Выполните команду
«top» (предварительно задав, чтобы она отображала номер порта) или
команду «ps -alxw». Из результатов их выполнения можно узнать, какая
еще программа может использовать порт. Последовательный порт часто
бывает занят программой gpm (терминальная программа для мышки).

18.30 Полезные программы

Здесь представлен список некоторых из программ, которые могут
пригодиться при поиске и устранении проблем:

• Команда «lsof /dev/ttyS*» отобразит список последовательных
  портов, открытых в данный момент.
• «setserial» — отображает и устанавливает настройки
  (низкоуровневые) последовательного порта, которые используются
  драйвером. См. setserial.
• «stty» — еще одна программа, служащая для настройки порта (в дополнении к setserial). См. раздел «Stty» в Serial-HOWTO.
• «modemstat» или «statserial» или «watch head
  /proc/tty/driver/serial» отобразят текущее состояние сигнальных линий
  модема, а точнее его регистров (DTR, CTS и т.д.). Также в
  /proc отображается количество переданных
  данных (байтовый поток) и ошибок (?).
• С помощью «irqtune» прерываниям последовательного порта можно
  задать более высокий приоритет (?), чтобы улучшить производительность.
• «hdparm» служит для настройки параметров жесткого диска, которая может чем-то помочь.
• Команда «lspci» отображает список устройств, подключенных к шине PCI, вместе с их актуальными параметрами (IRQ и т.д.).
• Команда «pnpdump —dumpregs» отображает актуальные параметры (IRQ и т.д.) PnP-устройств на шине ISA.
• Некоторый «файлы», расположенные внутри /proc (например ioports,
  interrupts и tty/driver/serial).

Следующий
Предыдущий
Содержание

I use arduino ide on arch linux with arduino uno connected via USB.
I am sure that I choosed right port and board in ide menu.

when I run ls -l /dev/ttyACM* I get:

crw-rw---- 1 root uucp 166, 0 14. dub 12.44 /dev/ttyACM0
crw-rw-rw- 1 root uucp 166, 1 14. dub 12.54 /dev/ttyACM1

but when I click upload I get this error:

Sketch uses 440 bytes (1%) of program storage space. Maximum is 32256 bytes.
Global variables use 9 bytes (0%) of dynamic memory, leaving 2039 bytes for local variables. Maximum is 2048 bytes.

avrdude: Version 6.3, compiled on Jul  7 2020 at 19:38:43
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
         Copyright (c) 2007-2014 Joerg Wunsch

         System wide configuration file is "//etc/avrdude.conf"
         User configuration file is "/home/john/.avrduderc"
         User configuration file does not exist or is not a regular file, skipping

         Using Port                    : /dev/ttyACM1
         Using Programmer              : arduino
         Overriding Baud Rate          : 115200
avrdude: ser_open(): can't open device "/dev/ttyACM1": Input/output error

avrdude done.  Thank you.

the selected serial port 
 does not exist or your board is not connected

Error remains on newest linux kernel and LTS.

My device is Lenovo thinkpad X390: Linux 5.11.14-arch1-1

When I plug arduino to usb and then run sudo dmesg I get this messages:

[ 1605.378324] usb 1-4: new full-speed USB device number 14 using xhci_hcd
[ 1605.520509] usb 1-4: New USB device found, idVendor=2341, idProduct=0043, bcdDevice= 0.01
[ 1605.520517] usb 1-4: New USB device strings: Mfr=1, Product=2, SerialNumber=220
[ 1605.520521] usb 1-4: Manufacturer: Arduino (www.arduino.cc)
[ 1605.520523] usb 1-4: SerialNumber: 7583434383935150E152
[ 1605.523881] cdc_acm 1-4:1.0: ttyACM1: USB ACM device
[ 1630.618749] usb 1-9: reset full-speed USB device number 10 using xhci_hcd
[ 1630.792727] audit: type=1130 audit(1618567069.016:82): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=fprintd comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
[ 1632.601215] audit: type=1100 audit(1618567070.822:83): pid=29714 uid=1000 auid=1000 ses=1 msg='op=PAM:authentication grantors=? acct="john" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/1 res=failed'
[ 1635.720577] audit: type=1100 audit(1618567073.942:84): pid=29714 uid=1000 auid=1000 ses=1 msg='op=PAM:authentication grantors=pam_faillock,pam_permit,pam_faillock acct="john" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/1 res=success'
[ 1635.721507] audit: type=1101 audit(1618567073.942:85): pid=29714 uid=1000 auid=1000 ses=1 msg='op=PAM:accounting grantors=pam_unix,pam_permit,pam_time acct="john" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/1 res=success'
[ 1635.722751] audit: type=1110 audit(1618567073.946:86): pid=29714 uid=1000 auid=1000 ses=1 msg='op=PAM:setcred grantors=pam_faillock,pam_permit,pam_faillock acct="root" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/1 res=success'
[ 1635.727018] audit: type=1105 audit(1618567073.949:87): pid=29714 uid=1000 auid=1000 ses=1 msg='op=PAM:session_open grantors=pam_limits,pam_unix,pam_permit acct="root" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/1 res=success'

How can I fix this ?
Thank you for help

PS: If you need any more information, comment below and I will add it soon as possible.

Страницы: [1]   Вниз

0 Пользователей и 1 Гость просматривают эту тему.

Страницы: [1]   Вверх

• This is a bug report
• This is a feature request
• I searched existing issues before opening this one

Expected behavior

Mounting a pts device with --device should make it accessible within the container.

Actual behavior

The device appears, but I get EIO when trying to access it.

Steps to reproduce the behavior

I am using socat to bring a remote serial port to my server over the LAN. socat creates pts devices.

On the physical machine:

root@server:~# ls -l /dev/pts/1
crw--w---- 1 root tty 136, 1 Aug  3 20:54 /dev/pts/1
root@server:~# cat /dev/pts/1
[...output from remote serial device...]

Start a container:

docker run -ti --device=/dev/pts/1:/dev/hostpts ubuntu:17.04 /bin/bash

Now, inside the container:

root@689d0696b167:/# ls -l /dev/hostpts
crw--w---- 1 root tty 136, 1 Aug  3 20:02 /dev/hostpts
root@689d0696b167:/# cat /dev/hostpts
cat: /dev/hostpts: Input/output error

Trying with /dev/null instead of a pts appears to work fine:

root@server:~# docker run -ti --device=/dev/null:/dev/hostnull ubuntu:17.04 /bin/bash
root@2b75680ed7a9:/# ls -l /dev/hostnull
crw-rw-rw- 1 root root 1, 3 Aug  3 20:03 /dev/hostnull
root@2b75680ed7a9:/# cat /dev/hostnull
root@2b75680ed7a9:/#

Output of docker version:

Client:
 Version:      17.06.0-ce
 API version:  1.30
 Go version:   go1.8.3
 Git commit:   02c1d87
 Built:        Fri Jun 23 21:18:10 2017
 OS/Arch:      linux/amd64

Server:
 Version:      17.06.0-ce
 API version:  1.30 (minimum version 1.12)
 Go version:   go1.8.3
 Git commit:   02c1d87
 Built:        Fri Jun 23 21:17:03 2017
 OS/Arch:      linux/amd64
 Experimental: false

Output of docker info:

Containers: 21
 Running: 3
 Paused: 0
 Stopped: 18
Images: 56
Server Version: 17.06.0-ce
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 78
 Dirperm1 Supported: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: bridge host macvlan null overlay
 Log: awslogs fluentd gcplogs gelf journald json-file logentries splunk syslog
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: cfb82a876ecc11b5ca0977d1733adbe58599088a
runc version: 2d41c047c83e09a6d61d464906feb2a2f3c52aa4
init version: 949e6fa
Security Options:
 apparmor
 seccomp
  Profile: default
Kernel Version: 4.10.0-26-generic
Operating System: Ubuntu 17.04
OSType: linux
Architecture: x86_64
CPUs: 4
Total Memory: 15.55GiB
Name: server
ID: MME7:KAO3:HFB7:RCTP:4P45:FWLV:TI46:YLYQ:3INW:7MLD:LZ2Y:BJK3
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Username: codeaholics
Registry: https://index.docker.io/v1/
Experimental: false
Insecure Registries:
 127.0.0.0/8
Live Restore Enabled: false

WARNING: No swap limit support

Additional environment details (AWS, VirtualBox, physical, etc.)

root@server:~# lsb_release -a
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 17.04
Release:	17.04
Codename:	zesty
root@server:~# uname -a
Linux server 4.10.0-26-generic #30-Ubuntu SMP Tue Jun 27 09:30:12 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux