Linux: Unklarheiten in USB-Spezifikation führen zu Verbindungsabbrüchen

Der im Linux-Kernel enthaltene XHCI-Treiber gibt USB-Geräten nicht genug Zeit, um aus den zur Laufzeit nutzbaren Schlafzuständen aufzuwachen; das kann bei USB-3-Controllern zu Verbindungsabbrüchen führen.

In Pocket speichern vorlesen Druckansicht 3 Kommentare lesen
Lesezeit: 2 Min.
Von
  • Thorsten Leemhuis

Der im Linux-Kernel enthaltene XHCI-Treiber gibt USB-Geräten nicht genug Zeit, um aus den zur Laufzeit nutzbaren Schlafzuständen aufzuwachen; das kann zu Verbindungsabbrüchen zwischen USB-3-Controllern und Geräten führen, die der Kernel bei Nichtverwendung mit Hilfe von "auto-suspend" schlafen legt.

Sharps Google+-Post.

Die Problematik ist die Folge einer unklaren Beschreibung in der USB-Spezifikation, wie Sarah Sharp in einem Google+-Beitrag schreibt. Dort zitiert die seit langem an der USB-Unterstützung von Linux arbeitende Intel-Entwicklerin einen Abschnitt aus der USB-Spezifikation, laut der ein Treiber 10 ms warten muss, bevor er auf USB-Geräte zugreift, die an einem reaktivieren USB-Segment hängen. An diese Zeitvorgabe habe sich der Kernel-Treiber auch gehalten. Allerdings erläutert eine Tabelle an anderer Stelle der USB-Spezifikation, diese 10 ms seien ein Mindestwert; ein Maximalwert ist nicht spezifiziert.

Wie Text und Tabelle zusammenpassen und auszulegen sind, ist umstritten, wie Kommentare zum Google+-Post und einem Reddit-Beitrag zur Problematik zeigen. Klar ist allerdings, dass sich manche Geräte mehr als 10 ms Zeit lassen, bevor sie nach dem Aufwachen wieder reagieren – bei Messungen Sharps waren es acht Prozent der getesteten Geräte. Sharp und andere Kernel-Entwickler diskutieren daher über Kernel-Änderungen, um Verbindungsabbrüche mit solchen Geräten zu vermeiden.

Der erwähnte Teil der USB-Spezifikation bezieht sich auf das für USB 3.0 zuständigen XHCI. Das bei USB 2.0 verwendete EHCI soll nicht betroffen sein, wie eine Mailinglistenbeitrag und eine Update in Sharp Google+-Beitrag erklären. Anwender, die unter Linux Probleme mit Auto Suspend bei USB 2.0 hätten, sollten sich daher wie bisher an die Kernel-Entwickler wenden, damit der Kernel angepasst wenden kann, um solche Geräte besser zu handhaben. (thl)