Зависание драйвера порта - NPort IA5250AI

[xxxxxAXxxxxx]

Здравствуйте, данный вопрос поднимался на форуме, но решение не последовало.

 

Проблема в том же. 

OC Linux x86, NPort IA5250AI. Nport работает в режиме Real COM Mode.

Есть программа, которая:

    1. Открывает порт.

    2. Опрашивает RS-485.

    3. Закрывает порт.

Если разрывается ethernet-соединение, то программа зависает на этапе опроса, порт не закрывается.  Как решить данную проблему?

[Незнайка]

Добрый день,

я правильно понимаю, что если программа перестаёт получать данные из tty, то она зависает?

[xxxxxAXxxxxx]

Да, похоже проваливается в чтение-запись порта и не возвращается из него.

[Незнайка]

Соответственно, надо встроить обработчик ошибки. Что бы возвращалась 

[boris_r_v]

Позвольте и свои 5-коп вставить:

Есть аналогичная проблема, при разрывае линка. команда записи данных в последовательный терминал: ssize_t write(int fd, const void *buf, size_t count); from (unistd.h) проваливается на уравень ядра и не держиться там пока линк не поднимут.

Хочется спросить у господина "Незнайки" - куда встраивать обработчик ошибки если нет сообщения об ней? Или ваш ответ был сделан "просто так"?

 

 

[Незнайка]

Странно слышать вопрос о том, куда встраивать обработчик от человека, у которого в подписи "embedded arm-device coding"

Я понимаю, что с точки зрения разработчика (ПО?)  хочется взять всё готовое и использовать как своё. Но, кмк, в данном случае, требовать от драйвера ещё и проверять целостность вашей сетевой инфраструктуры - это уже несколько избыточно.  Проверяйте доступность NPort и генерируйте ошибки. Драйвер то откуда знает, что и как, может у вас спутник с задержкой в 15-20 сек (а такое у нас тоже встречается)?

[boris_r_v]

1 hour ago, Незнайка said:

Странно слышать вопрос о том, куда встраивать обработчик от человека, у которого в подписи "embedded arm-device coding"

Я понимаю, что с точки зрения разработчика (ПО?)  хочется взять всё готовое и использовать как своё. Но, кмк, в данном случае, требовать от драйвера ещё и проверять целостность вашей сетевой инфраструктуры - это уже несколько избыточно.  Проверяйте доступность NPort и генерируйте ошибки. Драйвер то откуда знает, что и как, может у вас спутник с задержкой в 15-20 сек (а такое у нас тоже встречается)?

В рантайме проверить доступность не проблемма - но как мне нить вытащить из kernelspace если она уже там и ждет завершения системного вызова. Допускаю, что я не могу все знать, но про завершения вызова на уровне ядера ( из ядерного моделя npreal2) из user space не слыхал ни разу, а именно это вы предлагаете делать. 

Тут приложение зависнет в системнов вызове ранее, чем я узнаю о пропадании пинга на nport.  

Вроде доступно олбъяснил что не получитсья решить проблемуу из приложения user space

 

[boris_r_v]

понятно, что с помошью ряда костылей и подпорок, названных, к примеру: midleware(portabl) layer. Эта задача решается, но ИМХО одидается, по—умолчанию. стандартное поведение: не получается выполнить запрос — верни ошибку и двигаемся далее. Потом пишем обработчик, на случившуюся ошибку. А тут тебе по не ошибок, ни работы—только ступор нити в системном вызове. Вот об этом речь у комрада xxxxAxxxx.

[Незнайка]

2 hours ago, boris_r_v said:

понятно, что с помошью ряда костылей и подпорок, названных, к примеру: midleware(portabl) layer. Эта задача решается, но ИМХО одидается, по—умолчанию. стандартное поведение: не получается выполнить запрос — верни ошибку и двигаемся далее. Потом пишем обработчик, на случившуюся ошибку. А тут тебе по не ошибок, ни работы—только ступор нити в системном вызове. Вот об этом речь у комрада xxxxAxxxx. 

А что мешает писать не "костыли и подпорки", а взять и исправить, как надо, под свою задачу? Драйвер в исходниках. Протокол есть. Или вы сюда "просто так" пришли, чужое поругать, да свою удаль показать? Ну так покажите

И да, я вам ничего не предлагаю. Моя мысль была несколько в другом:  есть драйвер, и у 99% пользователей он работает нормально. Но есть тот самый 1%, у  которого то сеть вечно падает, то ещё какие то внешние факторы. Всего ведь не предусмотришь. И тут придётся самим. Или под заказ.

[boris_r_v]

Прекрасно, что комрад "Незнайка" так близко к сердцу воспринимает поднятую проблему - это залог ее успешного решения. Но в этом топике идет не обсуждение скилла участников, а несоответсвие linux nport драйвера linux system calls convections. (для примера:  man syscalls, второй абзац посвящен обработке ошибок происходящих во время вызова)

Для решения данной проблемыв рамках обсуждения  поступила два предложения: 

1. Писать отдельную прослойку для работы с последовательными портами nport - плохой вариант по двум причинам: 1) неединообразно с другими устройсвами  2) нарушение инкапсуляции функций системы

2. Исправить ядерный модуль (добавить соответствие соглашению по системным вызовам) - отличный вариант, но что мешает производителю оборудования это сделать - это же его продукт и опыта у него гораздо больше в данном вопросе?

P.S.

Ну и интересна актуальность  рассматриваемой  проблемы и насколько приведенные ранее цифры в 99% точны - может на самом деле я "сгущаю краски" или, что наиболее вероятно - всех интеграторов и так все устраивает, с эксплуатацией введенных систем она редко связывыются. Или, как вариант, windows драйвер работает более корректно с системными вызовами? 

P.P.S. Очень хотелось бы услышать комментарии технического специалиста по данной тематике, должна же быть объективная причина нестандартному поведению ядерного модуля.