Один из разработчиков ядра Linux Сара Шарп из компании Intel посыпает голову пеплом: за восемь лет работы над стеком Linux USB они неоднократно сталкивались с ситуацией, когда USB-устройство внезапно отключалось после выхода из режима ожидания при включенной функции auto-suspend. Все это время проблему списывали на китайских производителей дешевых флэшек, мышек и клавиатур. Обсуждалась даже идея внедрить «черный список» моделей таких устройств прямо в ядро, чтобы для них не активировался режим энергосбережения. От идеи отказались только когда стало ясно, что список будет слишком большим: так много было USB-устройств, которые вели себя некорректно.
Сейчас выяснилось, что сбои не всегда были аппаратными.
В коде хост-контроллера Intel xHCI (drivers/usb/core/hub.c) есть строчка с лаконичным комментарием «TRSMRCY = 10 msec». В соответствии с пунктом 7.1.7.7 спецификаций USB 2.0, система USB System Software должна обеспечить время в 10 миллисекунд для восстановления работы устройства, в течение которых не отправлять на него никаких запросов. В ядро Linux просто вставили таймаут 10 мс. Но специалисты по аппаратному обеспечению сейчас обратили внимание разработчиков ядра Linux, что в таблице 7-14 спецификаций USB 2.0 указано, что таймаут должен быть минимум 10 миллисекунд, а не максимум. Это означает, что устройство может восстанавливаться дольше, чем сейчас установлено в строке TRSMRCY в Linux USB. В таких случаях при попытке обратиться к нему может возникнуть ошибка передачи данных — тогда операционная система считает устройство отключенным.
Тесты показали, что выход устройства из спящего режима никогда не занимает больше 17 мс, но в 8% случаев превышает 10 мс. Для исправления бага достаточно увеличить значение таймаута с 10 до 20 мс, после чего все USB-устройства начнут нормально работать. Сара Шарп уже подготовила патч.
Разработчики говорят, что больше всего от бага страдают пользователи ChromeOS, потому что эта система очень агрессивно использует режим энергосбережения для USB, активируя auto-suspend для всех внутренних USB-устройств, включая WiFi и Bluetooth.
(c) x
UDP: Посоны, расходимся
I guess the xHCI hardware engineers just assumed software would always wait for the interrupt from the port status change event, rather than using a simple 10 ms timer. I bet they didn't even realize that that the transition took longer than 10ms, because Windows waited for the port status change event.
(c) src
