23.08.2013, 14:52
Niejeden użytkownik Linuksa klął na producentów przeróżnych urządzeń peryferyjnych podłączanych przez USB, w przekonaniu, że problemy z ich częstym rozłączaniem wynikają bądź to z kiepskiej jakości sterowników, bądź nędznej elektroniki. Dało się to odczuć przy wielu pendrive'ach, które na Linuksie działały znacznie gorzej niż na Windows, ale też i takich urządzeniach jak skanery, które potrafiły w trakcie skanowania nagle się rozłączyć. Ale w wielu wypadkach to nie producenci są winni. To w podsystemie USB linuksowego jądra tkwił błąd, który powodował niewłaściwe działanie sprzętu.
Problem zauważyła dopiero Sarah Sharp z Intela, pełnoetatowa opiekunka sterownika xHCI, pracująca też nad obsługą USB 3.0. We wpisie na Google+ przedstawia szczegóły swojego odkrycia. Otóż najwyraźniej Linux obsługiwał USB 2.0 niezgodnie ze standardem, zgodnie z którym oprogramowanie systemowe odpowiadające za obsługę interfejsu szeregowego powinno zagwarantować urządzeniu 10 ms na wznowienie czasu odzyskiwania (resume recovery time, TRSMRCY), podczas którego nie powinno się wysyłać żadnych sygnałów na dany odcinek magistrali.
![[Obrazek: g_-_550x412_-_s_45933x20130823122801_0.png]](http://gallery2.dpcdn.pl/imgc/News/45933/g_-_550x412_-_s_45933x20130823122801_0.png)
Sharp uważa, że programiści systemu zapewne rozumieli to jako przyzwolenie na próbę dostępu do urządzenia po odczekaniu 10 ms. Sęk w tym jednak, że w specyfikacji wartości zmiennych w tabeli załączonej do dokumentacji USB, 10 ms to dla TRSMRCY wartość minimalna. Oznacza to, że wiele portów może być w stanie wznowienia dłużej niż przez 10 ms, a jeśli w tym czasie jądro systemu będzie próbowało coś z podłączonym urządzeniem robić przez demona khubd, to albo się ono rozłączy, albo zgłosi błędy transmisji.
Według przeprowadzonych przez programistkę Intela testów, z 227 zdarzeń wychodzenia ze stanu uśpienia inicjowanych przez mysz i klawiaturę USB, 163 zajęły mniej niż jedną mikrosekundę, 47 zmieściło się w czasie poniżej 10 ms, ale 17 zajęło ponad 10 ms (a najdłuższe odnotowane opóźnienie wyniosło 17 ms). Tak więc w 8% wypadków zbyt mała wartość zmiennej określającej czas oczekiwania doprowadzała do rozłączeń z urządzeniami. Problem ten daje się najwyraźniej odczuć na chromebookach – Chrome OS bardzo agresywnie zarządza oszczędzaniem energii na USB, a rozłączenia z urządzeniami powodują zauważalne dla użytkownika migotanie interfejsu.
Problem tymczasowo rozwiązano, podnosząc po prostu wartość parametru TRSMRCY do 20. Jednak za wcześniej jeszcze, by odtrąbić sukces, gdyż rozwiązanie tego problemu ujawniło inne. pani Sharp zasugerowała właśnie, że odkryty przez nią błąd dotyczy wyłącznie kontrolera hosta xHCI, i nie jest przyczyną rozłączeń w starszym kontrolerze EHCI.
Więcej informacji można znaleźć na liście dyskusyjnej linux-usb. Przygotowana przez panią Sharp łatka powinna znaleźć się w wersji 3.11 jądra, której wydanie nastąpi najpewniej już we wrześniu tego roku.
Problem zauważyła dopiero Sarah Sharp z Intela, pełnoetatowa opiekunka sterownika xHCI, pracująca też nad obsługą USB 3.0. We wpisie na Google+ przedstawia szczegóły swojego odkrycia. Otóż najwyraźniej Linux obsługiwał USB 2.0 niezgodnie ze standardem, zgodnie z którym oprogramowanie systemowe odpowiadające za obsługę interfejsu szeregowego powinno zagwarantować urządzeniu 10 ms na wznowienie czasu odzyskiwania (resume recovery time, TRSMRCY), podczas którego nie powinno się wysyłać żadnych sygnałów na dany odcinek magistrali.
Sharp uważa, że programiści systemu zapewne rozumieli to jako przyzwolenie na próbę dostępu do urządzenia po odczekaniu 10 ms. Sęk w tym jednak, że w specyfikacji wartości zmiennych w tabeli załączonej do dokumentacji USB, 10 ms to dla TRSMRCY wartość minimalna. Oznacza to, że wiele portów może być w stanie wznowienia dłużej niż przez 10 ms, a jeśli w tym czasie jądro systemu będzie próbowało coś z podłączonym urządzeniem robić przez demona khubd, to albo się ono rozłączy, albo zgłosi błędy transmisji.
Według przeprowadzonych przez programistkę Intela testów, z 227 zdarzeń wychodzenia ze stanu uśpienia inicjowanych przez mysz i klawiaturę USB, 163 zajęły mniej niż jedną mikrosekundę, 47 zmieściło się w czasie poniżej 10 ms, ale 17 zajęło ponad 10 ms (a najdłuższe odnotowane opóźnienie wyniosło 17 ms). Tak więc w 8% wypadków zbyt mała wartość zmiennej określającej czas oczekiwania doprowadzała do rozłączeń z urządzeniami. Problem ten daje się najwyraźniej odczuć na chromebookach – Chrome OS bardzo agresywnie zarządza oszczędzaniem energii na USB, a rozłączenia z urządzeniami powodują zauważalne dla użytkownika migotanie interfejsu.
Problem tymczasowo rozwiązano, podnosząc po prostu wartość parametru TRSMRCY do 20. Jednak za wcześniej jeszcze, by odtrąbić sukces, gdyż rozwiązanie tego problemu ujawniło inne. pani Sharp zasugerowała właśnie, że odkryty przez nią błąd dotyczy wyłącznie kontrolera hosta xHCI, i nie jest przyczyną rozłączeń w starszym kontrolerze EHCI.
Więcej informacji można znaleźć na liście dyskusyjnej linux-usb. Przygotowana przez panią Sharp łatka powinna znaleźć się w wersji 3.11 jądra, której wydanie nastąpi najpewniej już we wrześniu tego roku.
Za: dobreprogramy.pl