USB адаптер после простоя: как проверить runtime suspend
Полевой шлюз хозяйства продолжает работать, но последовательный USB адаптер перестаёт отвечать после тихого периода. Причина может быть связана с runtime power management отдельного устройства. Проверяйте состояние, поддержку драйвера и возобновление обмена. Не отключайте энергосбережение глобально по одному совпадению симптома. Для приёмки важно воспроизвести переход и отличить его от исчезновения устройства, отказа самого прибора и ошибки повторного открытия порта приложением.
Подтвердить механизм простоя
Документация Linux USB Power Management отделяет runtime suspend отдельного устройства от system suspend и связывает idle поведение с драйвером. (Linux Kernel — USB Power Management) Поддержку конкретного адаптера нужно установить. Не считайте любую паузу передачи доказательством suspend. Сохраните разрешённые наблюдаемые состояния, версию драйвера и действующую политику. Если пользовательский журнал не показывает нужный уровень, ограничение доказательства должно оставаться явным, а не заменяться уверенностью по времени случайного первого отказа.
В карте укажите USB устройство, его физическую принадлежность, открывающий процесс и источник тестовых данных. Отдельно сохраните состояние основного датчика и локального интерфейса. Если адаптер имеет составные функции, сопоставьте именно используемую часть. Не меняйте несколько PM настроек и таймеров одновременно. Для первого опыта достаточно существующего режима и безопасной наблюдаемости. Рабочие подключения хозяйства сохраняют по проектному порядку; испытательный стенд должен исключать непредусмотренную передачу управляющих команд после последующего возобновления адаптера.
Сравнить до и после паузы
На стенде передайте собственную нумерованную последовательность, затем оставьте адаптер в согласованном состоянии простоя. Наблюдайте доступный PM переход и выполните предусмотренное возобновление обмена. Сверьте первый новый пакет, порядок и полноту ряда. Не принимайте ответ из кэша за подтверждение работы интерфейса после resume. Укажите, было ли устройство всё время открыто приложением: этот контекст может влиять на поведение драйвера и должен совпадать с реальным режимом эксплуатации шлюза хозяйства.
Отдельно сравните документированный альтернативный режим на стенде, изменяя только согласованный параметр. После опыта верните исходную конфигурацию и повторите проверку. Исчезновение симптома даёт основание дальнейшему разбору, но не доказывает универсальную неисправность runtime PM. Нужны повторяемость и наблюдение. Если для возврата требуется физическое переподключение или ручное действие, сохраните это ограничение. Нельзя объявлять автоматическое восстановление только потому, что инженер смог вернуть интерфейс и следующий запрос уже завершился нормально.
Принять возобновлённый обмен
В акте сохраните PM контекст, наблюдённый переход и судьбу тестового ряда. Приёмка подтверждает работу конкретного адаптера и драйвера после согласованного простоя. Для хозяйства это помогает локализовать отказ без ненужной смены радиоканала или датчика. Инженер видит, где остановилась цепочка и как она восстановилась, а энергосбережение оценивается по фактам выбранного комплекта. Глобальная настройка системы не меняется без основания, и успешный resume получает собственное доказательство нового прикладного обмена после паузы.