USB после system suspend: проверить persistence и прикладной контекст

Запросить

После выхода шлюза хозяйства из system suspend USB прибор снова виден ядру, но сборщик продолжает ожидать старый обмен. Сохранение устройства и готовность приложения имеют разные этапы. Проверяйте поддерживаемую persistence модель, идентичность и повторную инициализацию протокола. Методика относится к шлюзу, где system suspend предусмотрен проектом. Она не предлагает переводить рабочую систему в сон ради диагностики и не приравнивает такой сценарий к runtime suspend одного адаптера.

Возврат USB и прикладного обмена. Выход из system suspend; USB-устройство вернулось; Сборщик восстановил контекст; Новый обмен подтверждён. Сохранение привязки; Проверка экземпляра и параметров после возобновления.
Возврат устройства и восстановление прикладного обмена подтверждают отдельно.

Подтвердить охват восстановления

Документация Linux USB persistence описывает условия сохранения устройства при system suspend. (Linux Kernel — USB persistence) Это не гарантия прикладного состояния всех программ. Подтвердите поддержку конкретного оборудования, драйвера и конфигурации. Нельзя считать повторно появившийся путь достаточным доказательством непрерывного протокольного сеанса. Сохраните, какие сведения ядро использует для восстановления и что доступно приложению. Внешнее совпадение имени не подтверждает, что датчик сохранил внутренний измерительный контекст и что незавершённый запрос допускается продолжить после возобновления шлюза.

В карте разделите физическое устройство, его представление системе, открытый контекст процесса и состояние протокола. Укажите незавершённые операции перед паузой и проектную политику после неё. Не пересылайте автоматически старую команду исполнительному устройству без подтверждения допустимости повтора. Для испытания используйте безопасный имитатор и собственную последовательность измерений. Если метод идентификации не позволяет уверенно установить принадлежность возвратившегося прибора, оставьте это ограничение открытым вместо молчаливого продолжения архива под именем прежнего источника хозяйства.

Сверить состояние до и после

На выделенном стенде выполните штатный тестовый обмен, согласованный suspend и предусмотренный resume. Сохраните системные события, фактическую идентичность и первое новое сообщение приложения. Сопоставьте его с известным источником. Успешное чтение старого буфера не считается новым циклом. Не меняйте одновременно драйвер и политику suspend: опыт должен иметь понятное основание. Условия сохранения питания прибора тоже фиксируют по стендовому паспорту, поскольку от них может зависеть его внутреннее состояние после паузы.

Отдельно проверьте предусмотренный отказ восстановления на изолированной схеме. Сборщик должен показать ограничение и пройти документированный путь повторного открытия или инициализации, если он поддерживается. Не объявляйте persistence способом восстановления любого отключения. После возврата проверьте порядок и полноту тестовой последовательности, а также качество оставшихся данных. Если часть интервала не наблюдалась, архив должен сохранить пробел. Программная непрерывная линия не доказывает, что физический прибор всё время измерял и что все результаты действительно были получены после сна.

Принять подтверждённый resume

В акте сохраните поддержку, состояния и результаты прикладного восстановления. Приёмка относится к конкретному комплекту и согласованному system suspend сценарию. Для хозяйства это делает энергосберегающий режим предсказуемым без ложного вывода по одному системному имени устройства. Инженер различает сохранённое USB представление, новый протокольный контекст и восстановленный сбор, а неподтверждённый участок остаётся видимым. Последующее обслуживание может повторить тот же опыт и проверить, как изменение драйвера или приложения повлияло на фактическую готовность данных после resume шлюза.

Все разборы