Подтвердить что ты не робот

Функция open() зависает (никогда не возвращается) при попытке открыть последовательный порт в Mac OS X

У меня возникла проблема, когда функция open никогда не возвращается, когда я пытаюсь открыть последовательный порт. Это не происходит постоянно, и проблема исчезает некоторое время, если я отсоединяю свой USB-адаптер от последовательного адаптера и подключаю его обратно. Мой код выглядит следующим образом:

fileDescriptor = open(bsdPath, O_RDWR | O_NOCTTY);

где bsdPath -/dev/cu.KeySerial1. Я попытался добавить параметр O_NONBLOCK в команду open, но он все еще зависает.

Конечно, я хотел бы понять, почему это происходит. Я убежден, что независимо от проблемы с указанным O_NONBLOCK, open должен возвращаться независимо от того, даже если он не смог открыть порт. Если он не может открыть порт, fileDescriptor должен быть равен -1, а errno должен быть установлен (я проверяю это сразу после вызова для открытия). Конечно, этого не происходит. Неправильно ли мое предположение? Есть ли какая-то известная причина, по которой open() никогда не возвращается даже с O_NONBLOCK, указанным при возникновении ошибки?

Используя последнюю версию драйвера Prolific PL-2303 с USB-последовательным адаптером на основе PL-2303 на 10.7.2, я снова смог воспроизвести эту проблему сегодня. Несколько примечаний:

  • При входе в вызов open() процесс не прерывается с помощью команды-. (Control-C).
  • Запуск ps -avx показывает код состояния процесса U для процесса. Я не уверен, что означает этот код. Он не отображается в man-страницах для ps, найденных Googling. На странице управления для ps на моей машине нет списка кодов состояния процесса. Возможно, это специфично для Mac (10.4+?) Версии ps?
  • Я отметил, что при запуске сразу перед первым появлением этой проблемы мой вызов ioctl() to reset параметров на порту возвращается к их состоянию до того, как я их изменил для использования в моей программе. Мне пришлось убить программу (через отладчик Xcode). Сразу после этого, при следующем запуске программы, open() повис...
4b9b3361

Ответ 1

В драйвере устройства может возникнуть проблема. Вы правильно относитесь к тому, как должен вести себя O_NONBLOCK, но это правильно для правильного внедрения драйвера. Было бы полезно узнать, какая версия OS X и какой USB для последовательного устройства используется.

Стандартные процедуры состоят в том, чтобы убедиться, что устройство подключено непосредственно к USB-портам CPU (а не к концентратору), проверяет кабели и проверяет наличие обновленных драйверов.

Кроме того, когда open() блокируется, процесс прерывается с помощью control-c? Если вы посмотрите на процесс с "ps -aux", когда он заблокирован, что говорит поле "STAT"?