Отладка USB remote wakeup и suspend/resume: selective suspend, resume-сигнализация, управление питанием и пропущенные wake-события

Баги USB-управления питанием трудно диагностировать: "устройство может идеально работать, пока система активна, и ломаться только после простоя, сна, selective suspend, сна дока, закрытия крышки ноутбука или выключения монитора. Пользователи ищут «USB remote wakeup not working», «USB selective suspend disconnect», «USB device does not wake computer», «USB resume failure», «USB suspend resume bug», «HID keyboard wake from sleep not working»." Bus Scope полезен тем, что suspend и resume — события уровня шины, а не только ошибки приложения. Нужно увидеть, перевёл ли хост устройство в suspend, был ли включён remote wakeup, послало ли устройство resume-сигнал, восстановил ли хост трафик, и устройство перечислилось заново или возобновило работу.

Что значит remote wakeup

Remote wakeup позволяет уснувшему USB-устройству попросить хост возобновить коммуникацию. Частые примеры:

• Клавиатура будит спящий десктоп.
• Мышь будит ноутбук из простоя.
• Кнопка дока будит рабочую станцию.
• Сканер штрихкодов будит киоск.
• Промышленный контроллер будит панельный ПК.
• HID-датчик будит хост после внешнего события.

Remote wakeup — это не просто «у устройства есть питание». Хост должен разрешить его, устройство должно заявить поддержку, фича должна быть включена, и resume-сигнализация должна произойти в нужное время.

Типичные симптомы

Проблемы remote wakeup и suspend выглядят так:

• Устройство работает, пока ПК не уснёт.
• Устройство не будит компьютер.
• Устройство будит систему сразу после suspend.
• Устройство исчезает после resume.
• Устройство пере-нумеруется с новым адресом.
• HID-ввод пропускается после простоя.
• Serial-устройство перестаёт слать после selective suspend.
• Аудио или камера возвращаются из сна без данных.
• Прошивка восстанавливается только после переподключения.

Эти симптомы часто списывают на драйвер, но захват может показать баг power-state прошивки.

Доказательства дескрипторов и фич

Configuration descriptor может заявить поддержку remote wakeup. Хост затем может включить или отключить фичу remote wakeup. Полезная трасса USB-диагностики должна отвечать:

• Заявляет ли устройство remote wakeup?
• Послал ли хост SET_FEATURE(DEVICE_REMOTE_WAKEUP)?
• Очистил ли хост фичу позже?
• Произошёл ли suspend после простоя?
• Пыталось ли устройство подать resume-сигнал?
• Возобновил ли хост нормальные передачи?

Без этих фактов диагноз — догадки.

Selective suspend

Selective suspend позволяет ОС усыпить idle-устройство, не кладя всю систему. Это экономит энергию, но вытаскивает на свет баги прошивки.

Паттерны сбоев:

• Устройство входит в low-power, но не восстанавливает состояние конечных точек.
• Прошивка теряет ожидающее состояние interrupt IN.
• Устройство NAK-нуло бесконечно после resume.
• Хост делает reset устройства после тайм-аута.
• Приложение видит тайм-аут или удаление устройства.
• Составное устройство возобновляет работу на одном интерфейсе, но не на другом.

Ищущие часто пишут «USB selective suspend random disconnect», потому что устройство выглядит отключённым, хотя реальное событие — сбой suspend/resume.

Resume vs пере-нумерация

После сна есть два очень разных исхода:

• Resume: устройство продолжает с существующей конфигурацией.
• Пере-нумерация: хост делает reset и перечисляет устройство заново.

Пере-нумерация может быть допустима после физического отключения, но подозрительна после обычного suspend. Она может сломать приложения, держащие хэндлы, имена serial-портов, HID-пути или сессии захвата камеры.

Bus Scope должен помочь определить, содержит ли трасса нормальный resume-трафик или новую последовательность перечисления с GET_DESCRIPTOR, SET_ADDRESS и SET_CONFIGURATION.

Пропущенные wake-события

Иногда устройство видит внешнее событие, а хост не просыпается. Причины:

• Remote wakeup не заявлен.
• Remote wakeup не включён хостом.
• Устройство шлёт resume слишком рано.
• Устройство шлёт resume слишком поздно.
• Концентратор блокирует или неверно обрабатывает wake-сигнализацию.
• BIOS или ОС отключили порт по политике wake.
• Прошивка устройства входит в более глубокий сон, чем ожидалось.
• Событие происходит до завершения suspend.

Пакетные данные не заменяют ОС-политику питания, но сужают вопрос. Было ли у устройства разрешение будить хост, и пыталось ли оно это сделать?

Немедленное пробуждение после suspend

Обратная проблема тоже частая: система уходит в suspend и сразу просыпается. USB-устройства могут вызвать это из-за устаревшего ввода, шумного состояния interrupt, багов debounce или прошивки, которая трактует suspend как новое событие.

Что собрать:

• Последний interrupt-репорт до suspend.
• Включил ли хост wake.
• Тайминг между suspend и resume.
• Класс устройства и интерфейс.
• Были ли в той же конечной точке ожидающие данные.
• Повторяется ли событие при каждой попытке suspend.

Это особенно часто у клавиатур, мышей, тач-панелей, игровых контроллеров и кастомных HID-устройств.

Чек-лист отладки

Используйте такой процесс:

1. Захватите перечисление с момента подключения.
2. Подтвердите поддержку remote wakeup в дескрипторах.
3. Проверьте, включил ли хост remote wakeup.
4. Зафиксируйте период простоя до suspend.
5. Определите тайминг suspend.
6. Ищите resume-сигнализацию или resume-трафик хоста.
7. Отделите resume от полной пере-нумерации.
8. Проверьте поведение конечных точек после resume.
9. Сравните то же устройство на прямом порту и через концентратор.
10. Сохраните пакеты и до, и после suspend.

Итоговый диагноз

Баги USB remote wakeup и suspend/resume — проблемы протокола power-state. Полезные доказательства — capability дескриптора, выбор фичи хостом, тайминг suspend, resume-сигнализация, восстановление конечной точки и то, перечислил ли хост устройство заново или возобновил.

Bus Scope помогает сделать эти доказательства видимыми, чтобы «USB wake not working» стал конкретным диагнозом, а не петлёй обвинений драйвера.