usblp in den Griff bekommen

Version vom 06.02.2009

Drucker druckt mit gelegentlichen Aussetzern

Vorwort

Quell allen Übels war der Austausch eines alten Servers. Er verfügte über 4 Netzwerkkarten, 2 serielle Anschlüssel, 2 parallele Anschlüsse und natürlich USB. Um den Technikpark etwas zu minimieren beschlossen wir, die alte 200 MHz-Kiste gegen ein ITX-Board auszutauschen. Das Problem: Die moderne Technik nutzt USB, wo immer es geht und da der neue Server nur einen PCI-Steckplatz hat, hängen am USB nun 2 Drucker (USB-Parallel-Adapter), 1 Modem (USB-Seriell-Adapter), zwei Netzwerkadapter und eine Webcam. Die Besichtigung des Kabelsalats wäre Eintritt wert.
Kurz: Die 4 USB-Ports reichen nicht, was zur weiteren Anschaffung eines USB-HUBs führte. Nun funktionierten alle Geräte, außer der beiden Drucker.

Fehlermeldungen

Normalerweise sollte im Kernel die Option
CONFIG_USB_DEBUG=y
gesetzt sein, um vernünftige Fehlermeldungen zu erhalten. In unserem Fall, war das jedoch gar nicht notwendig. Das Anschließen des Druckers klappte problemlos, doch beim Druckern zeigte sich dann folgender Fehler (gekürzt):
Server:/# cp /tmp/Printjob /dev/usb/lp0
drivers/usb/class/usblp.c: usblp0: nonzero read/write bulk status received: -71
usb 5-2: clear tt 1 (8550) error -71
drivers/usb/class/usblp.c: usblp0: error -71 reading printer status
hub 5-2:1.0: hub_port_status failed (err = -71)
Bei neueren Kernels heißt es:
usblp0: nonzero write bulk status received: -71
Zu diesem Zeitpunkt befand sich der Drucker hinter einem USB-Hub. Dies war leider notwendig, da er ohne diesen überhaupt nicht erkannt wurde (wahrscheinlich auf Grund der Kabellänge).

Kernelupdate

Da zu diesem Zeitpunkt noch nicht klar war, ob es ein Hardware- oder Softwarefehler ist, kompilierten wir erstmal einen neuen Kernel (2.6.28-3) ohne dabei die Konfiguration zu verändern. Das Ergebnis war ein Teilerfolg: Die Meldungen erschienen in abgewandelter Form weiterhin, aber das Druckprozess stürzte nicht mehr unkontrolliert ab, sondern terminierte mit einem Fehler.

Dann setzten wir im Kernel die Option

CONFIG_USB_EHCI_TT_NEWSCHED=y
und voila: Zumindest die Fehler, die offentsichtlich der Hub einschleuste verschwanden. Der Drucker druckte nun zumindest die jeweils erste Seite fehlerfrei - leider auch nur diese. Allerdings herrschte nun relative Sicherheit darüber, dass der Hub keine Probleme (mehr) machen würde.

Treibergeschichten - Teil 1

Der Tatsache geschuldet, dass der Drucker die erste Seite problemlos druckte, überlegten wir, dass der USB-Parallel-Adapter wohl zu schnell zu viele Information bekäme und der Treiber scheinbar buggy sei. /usr/src/linux/drivers/usb/class/usblp.c heißt die dafür verantwortliche Datei. Nach etlichem Debuggen stellten wir fest, dass der Fehler während des Aufrufs des Schedulers auftritt und damit folglich von höherer Gewalt als dem usblp-Treiber sein musste. Auch die Anpassung der Puffergröße führte zu keinem Ergebnis, sondern beinflusste (logischerweise) nur die Häufigkeit der Fehlermeldungen.

EHCI deaktivieren (der Vollständigkeit halber)

Der Verzweiflung wegen, probierten wir eine andere Lösung, die das Internet ausspuckte: den ehci-Treiber rauswerfen. Praktikabel ist diese Lösung nicht, da an unserem Server auch Netzwerkkarten hängen, die mit USB-1.1 gar nicht funktionieren würden.
Trotzdem probierten wir es:
Server:/# rmmod ehci_hcd
Der Fehler bestand weiterhin - aber vielleicht ist es ja für den ein oder anderen trotzdem eine Lösung!

USB Autosuspend deaktivieren

In Zusammenhang mit Fehler (-71) ließt man häufig, dass es helfen könnte, den USB Autosuspend zu deaktivieren. Dies lässt sich kurzfristig mit
Server:/# rmmod usbcore; modprobe usbcore autosuspend=-1
realisieren oder fest im Kernel einkompilieren. Wir entschieden uns für letzteres - ob das tatsächlich etwas bringt ist eine andere Frage, zumindest erfreut sich die Webcam schnelleren Zugriffszeiten...

Ohne USB-Hub

Peinlich ist, dass wir darauf nicht früher gekommen sind, denn ohne USB-Hub funktioniert der Drucker was problemlos (jedenfalls solange genug Papier im Schacht liegt). Der Hub war notwendig, weil der Drucker relativ weit vom Server entfernt steht und das Kabel zu lang war. Doch den inneren Schweinehund zu überwinden alles umzubauen hat sich gelohnt: Der Drucker druckt und es kommen keine (!) Fehlermeldungen mehr.
Am Hub hängen nun die Webcam und der USB-Seriell-Adapter, die scheinbar besser damit klar kommen.

Treibergeschichten - Teil 2

Trotzdem war es nicht verkehrt den Treiber zu studieren: In unserem Fall scheint die Kommunikation zwischen Adapter und Drucker nicht fehlerfrei zu laufen. Ist kein Papier mehr vorhanden, meldet der Adapter, der Drucker sei abgeschaltet, was zu einem Fehler führt.
        if (~status & LP_PERRORP)
                newerr = 3;
        if (status & LP_POUTPA)
                newerr = 1;
        if (~status & LP_PSELECD)
                newerr = 1; /* newerr = 2; */
in der Funktion usblp_check_status geändert - unsaubere Lösung, aber alles läuft super!

Schlusswort

Einige mögen jetzt denken: "Wir bescheuert, lag es doch am Hub und dafür so einen langen Text." Mag sein, dass das Problem hätte schneller behoben werden können, doch viele scheinen sich mit diesem (Fehler -71) oder einem ähnlichen Problem zu quälen und dann sind die hier geschilderten Ansätze (aktuellen Kernel verwenden, ehci-Scheduler verwenden, Treiber debuggen/patchen, autosuspend deaktivieren) sicherlich nicht fehl am Platze. Wir hoffen jedenfalls, dass wir jemandem helfen konnten!
Mit Windows haben wir es übrigens nie probiert, denn es ist irrelevant! Schließlich soll die Kiste unter Linux laufen und die Erkenntnis, dass es unter Windows geht, hilft da auch nicht sonderlich weiter - zumal Windows mit hilfreichen Fehlermeldungen doch viel sparsamer umgeht als Linux!

In meinen Augen ist USB der letzte Dreck - der Aufbau ist gut durchdacht und die Spezifikationen nahezu lückenlos, doch was bringt es mir, wenn kaum ein Hardwarehersteller diese zu 100% umsetzen? Eine Webcam oder Festplatte ohne Neustart anschließen zu können ist toll, aber gerade bei seriellen und parallelen Verbindungen ist das keine Weltneuheit. Schade, dass die Computerhersteller an altbewährten Anschlüssen sparen um die Benutzer von USB-Kaffeewärmern zu befriedigen.


Kommentare

Neue Kommentare sind aus Spamgründen leider nicht möglich.