/dev/ulpt0: Device busy

P

PatrickBaer

Well-Known Member
Und schon das naechste *grrrrrrrrrrrrrrrrrrrrrrr*

Hi!

Laserjet 1018 auf FreeBSD 6.1, foo2zjs, Cups, folgendes passiert:

Ich starte Rechner und Drucker, versuche eine Testseite ueber Cups zu drucken und erhalte diese Fehlermeldung "/dev/ulpt0: Device busy".

Ich ziehe den Drucker ab und haenge ihn an meinen eigenen Rechner an, genau dieselbe Fehlermeldung.

Ich boote Windows 2000 und drucke eine Testseite mit dem HP-Druckertreiber. Der REchner friert komplett ein und laesst sich nur noch resetten.

Ich druecke auf Reset und beim Booten (egal welches OS) faengt der Drucker an die Testseite (von Windows) zu drucken.

Ich boote FreeBSD und drucke. Geht einwandfrei. Keine Fehlermeldung.

Ich bin auch schon alles durchgegangen, von saemtlichen Anleitungen bezueglich foo2zjs, Cups, FreeBSD, HP. In einer Mailinglist habe ich eine Meldung von 2005 gefunden das das Problem geloest ist. Hm, irgendwie ist es dafuer aber auf meiner Kiste sehr praesent! Es muesste doch eigentlich ein FreeBSD Problem sein wenn nicht mal ein cat in das Device ( cat /etc/rc.conf >/dev/ulpt0 ) irgendetwas tut oder? Zumindestens blinken muesste er!

Hat jemand nen Tip uebrig?

Patrick
 
Benedikt schrieb:
Aber heißt das nicht, dass es eher nicht vom OS abhängt?
Zum Vergrößern anklicken....

Hi, Du bist schnell :)

Also laut foo2zjs muss bei diesem Drucker nach dem Powerup jedesmal die Firmware neu geladen werden. Bei FreeBSD geht das ja nicht: Device busy. Also ist es wahrscheinlich doch irgendetwas mit dem ulpt Treiber. Es gibt sogar einen Patch fuer das Problem, aber der loest es leider auch nicht, nur die Fehlermeldung ist jetzt "offline", weil es keinen timeout mehr gibt... Windows friert wahrscheinlich ein weil es eben ewig auf die Rueckmeldung wartet, die aber nie kommt (und deswegen unter FreeBSD den Timeout ausloest). In der printers.conf kann man das loesen indem man usb:/dev/ulpt0 auf file:/dev/ulpt aendert damit der Status nicht mehr abgefragt wird. Aber sowohl cat als auch cp oder lpr beissen sich die Zaehne aus :(
 
Ich komm nicht ganz mit. Wo ist der Drucker angeschlossen? Auf dem Rechner von dem du den Druckauftrag erstellst oder an einem Fremdrechner?

Hast du mal ne andere USB-Schnittstelle probiert?
 
Es ist ganz egal wo er angeschlossen ist, an meinem Rechner oder dem anderen, an allen acht Ports die ich habe dasselbe Ergebnis: Erst nach dem Windows Crash kann ich drucken, egal unter welchem OS und auf welchem Rechner. Aber nachdem Einschalten des Druckers muss ich einmal Windows abstuerzen lassen :)

War das verstaendlicher?

Patrick
 
Du kannst einmal probieren in der Datei:
Code: 
/usr/local/etc/cups/printers.conf

Folgenden code zu ersetzen:
Code: 
DeviceURI usb:/dev/ulpt0

durch:
Code: 
DeviceURI file:/dev/ulpt0
Dann druckt er wieder :)

Seit dem stuertzt Cups bei mir aber reproduzierbar ab. Sobald ein Druckauftrag gesendet wird und der Drucker nicht eingeschaltet ist.:rolleyes:


Falls du einen besseren Workaround finden solltest...sag bescheid!
 
Hi, auf dem Status war ich schon gestern ;)

Wie gesagt, er druckt ja einwandfrei, aber eben erst nach diesem einen Mal Windows booten!

Es liegt anscheinend wirklich daran das der Drucker ein einziges Mal den richtigen Codesalat in den Port bekommt, dann macht er auf. Und dann geht auch alles. Aber bis dahin: Device busy.

Und genau da liegt eben das Problem, ich koennt echt kotzen.
 
Blöde Idee, aber kann es vielleicht an Ghostscript liegen? Oder kommt das nicht zum Einsatz? Wäre nurmal ins Blaue geschossen...

Was passiert wenn du unter Windows über die Eingabeaufforderung was druckst?
 
Das gleiche Problem hatte ich mit einem HP LaserJet 1000W. Das ist ein GDI-Drucker, auf den vor dem Drucken das Firmwareimage geladen werden muß. Ich habe das weder mit Free-, noch Open- oder NetBSD zum Laufen bekommen, denn ich konnte das USB-Device nicht "beschreiben". Falls Ihr also ein Lösung finden solltet - ich habe auch sehr großes Interesse dran :-)
 
Versuch einmal in deiner Kernelconfig folgende Zeile auszukommentieren:

device ulpt

Sobald du deinen Kernel neu kompiliert hast, erkennt FreeBSD den Drucker nicht mehr als 'ulpt' sondern als 'ugen'. Du solltest aber nicht direkt 'ugen[0-9]' verwenden sondern 'ugen[0-9].[1/2]'.

Danach konnte ich in meiner 'printers.conf' auch wieder das 'file:' durch ein 'usb:' ersetzen ohne den 'busy'-Fehler zu erhalten. Vielleicht ermoeglicht dies dir auch deine Firmware auf deinen Drucker zu verfrachten.
 
kmh schrieb:
Sobald du deinen Kernel neu kompiliert hast, erkennt FreeBSD den Drucker nicht mehr als 'ulpt' sondern als 'ugen'. Du solltest aber nicht direkt 'ugen[0-9]' verwenden sondern 'ugen[0-9].[1/2]'.
Zum Vergrößern anklicken....
Welcher der beiden Dvices ist denn vorzuziehen? ugenX.1 oder ugenX.2? Wenn man ulpt im Kernel hat, dann bekommt man ja auch ulpt und unlpt als Devices für den Drucker? Entspricht nun .1 oder .2 ulpt?
 
Also bei mir geht nur ugen[X].1, der andere device liefert den alt bekannten "device busy...30 sec...." Fehler.

Ich glaube nicht das man ugenX.X mit unlpt bzw. ulpt gleichsetzen kann:

device ugen. # Generic. device
device ulpt. # Printer
Zum Vergrößern anklicken....

Daher ist ugen als generelles usb device anzusehen und ulpt besagt das ein Drucker hinter dem device-file steckt.
 
Bei mir funktioniert weder ugenX.1 noch ugenX.2 besser als ulpt. (Soll heißen funktionieren auch nicht mit cups)

Ich denke schon, daß ulpt im wesentlichen ein Mapping macht.

Ugen ist ja der Kerneltreber für generische USB-Geräte, also Geräte für die der Kernel keinen besser passenden Treiber hat. Bei meinem Drucker stellt dieser Treiber dann ugenX als Hauptgerät mit den Untergeräten ugenX.1 und ugenX.2 zur Verfügung.

Ist der ulpt Treiber im Kernel, so schreit dieser: Mit dieser HW kann ich was anfangen, ugen laß die Finger davon! Anschließend stellt ulpt die Devices ulptX und unlptX zur Verfügung. Das Hauptgerät läßt er weg, weil er weiß, daß der Nutzer sonst nichts damit anfangen kann.

Ich glaube nicht, daß ulpt wesentlich mehr macht als ein solches mapping.
 
Welche CUPS-Version verwendest du?

Ich verwende CUPS 1.2.8.

Wie gesagt, ich weiss nicht genau worin der Unterschied liegt zwischen ulpt und ugen. Falls jemand genauer informiert ist, kann er sich ja hier mal zu Wort melden und uns aufklaeren ;)
 
Hier ist es auch CUPS 1.2.8.

Das Seltsame:
Code: 
$CUPS stop
cat $PSFILE > /dev/ultp # alternativ /dev/ugenX.1
$CUPS start
Und CUPS funktioniert.......
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben