hplip macht mich wahnisnng!
Hallo, ich habe sowohl zu Hause (Business Inkejet 2250TN) als auch im Office (Business Inkejet 2230) einen HP Drucker via Netzwerk an einem 11.3er Server hängen und via hplip angebunden. Und was soll ich sagen: Das ist alles andere als ausgereift. Mal druckt er, mal nicht. Nach einer längeren Zeit der Nichtbenutzung (insbesonders wenn der Drucker ausgeschaltet war) muss ich JEDESMAL diesen blöden Drucker in cups wieder starten. Regelmässig fehlern Jobs aus (cups backend failed) und lassen sich nicht mehr anschieben. Einfach unbrauchbar. Ich habe jetzt zu Hause wieder auf "normale" PPDs ohne HPLIP umgestellt; das funktioniert problemlos. Da ich (anderer Thread) aber wohl bald ein Kombigerät haben werden und hp sich ja eigentlich rühmt, mit hplip Linux zu unterstützen würde ich das gerne klären Hier mal ein aktueller error-Log Auszug für den Versuch, ein PDF aus firefox auf den BIJ 2200 zu drucken: --- cut here --- D [20/Oct/2010:09:33:39 +0200] [Job 289] prnt/hpcups/HPCupsFilter.cpp 361: DEBUG: Bad PPD - hpPrinterLanguage not found D [20/Oct/2010:09:33:39 +0200] [Job 289] prnt/backend/hp.c 839: ERROR: null print job total=0 D [20/Oct/2010:09:33:39 +0200] [Job 289] cups_print_chunked: xflip = 0, yflip = 0, height = 6639 D [20/Oct/2010:09:33:39 +0200] PID 21910 (/usr/lib/cups/filter/hpcups) stopped with status 1! D [20/Oct/2010:09:33:39 +0200] PID 21911 (/usr/lib/cups/backend/hp) exited with no errors. D [20/Oct/2010:09:33:39 +0200] PID 21908 (/usr/lib/cups/filter/pstops) did not catch or ignore signal 13. D [20/Oct/2010:09:33:39 +0200] PID 21909 (/usr/lib/cups/filter/pstoraster) did not catch or ignore signal 13. D [20/Oct/2010:09:33:39 +0200] Discarding unused job-state-changed event... E [20/Oct/2010:09:33:39 +0200] [Job 289] Job stopped due to filter errors; please consult the error_log file for details. --- cut here --- Genau der gleiche Druck via "recommended" Treiber (Foomatic/chp2200) in cups geht einwandfrei. Geht dieses hplip Zeugs überhaupt irgendwo vernünftig? Andreas -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Am 20.10.2010 09:51, schrieb Kyek, Andreas, VF-DE:
Hallo,
ich habe sowohl zu Hause (Business Inkejet 2250TN) als auch im Office (Business Inkejet 2230) einen HP Drucker via Netzwerk an einem 11.3er Server hängen und via hplip angebunden.
Und was soll ich sagen: Das ist alles andere als ausgereift.
Mal druckt er, mal nicht. Nach einer längeren Zeit der Nichtbenutzung (insbesonders wenn der Drucker ausgeschaltet war) muss ich JEDESMAL diesen blöden Drucker in cups wieder starten. Regelmässig fehlern Jobs aus (cups backend failed) und lassen sich nicht mehr anschieben. Einfach unbrauchbar.
Ich habe jetzt zu Hause wieder auf "normale" PPDs ohne HPLIP umgestellt; das funktioniert problemlos.
Da ich (anderer Thread) aber wohl bald ein Kombigerät haben werden und hp sich ja eigentlich rühmt, mit hplip Linux zu unterstützen würde ich das gerne klären
Hier mal ein aktueller error-Log Auszug für den Versuch, ein PDF aus firefox auf den BIJ 2200 zu drucken:
--- cut here --- D [20/Oct/2010:09:33:39 +0200] [Job 289] prnt/hpcups/HPCupsFilter.cpp 361: DEBUG: Bad PPD - hpPrinterLanguage not found D [20/Oct/2010:09:33:39 +0200] [Job 289] prnt/backend/hp.c 839: ERROR: null print job total=0 D [20/Oct/2010:09:33:39 +0200] [Job 289] cups_print_chunked: xflip = 0, yflip = 0, height = 6639 D [20/Oct/2010:09:33:39 +0200] PID 21910 (/usr/lib/cups/filter/hpcups) stopped with status 1! D [20/Oct/2010:09:33:39 +0200] PID 21911 (/usr/lib/cups/backend/hp) exited with no errors. D [20/Oct/2010:09:33:39 +0200] PID 21908 (/usr/lib/cups/filter/pstops) did not catch or ignore signal 13. D [20/Oct/2010:09:33:39 +0200] PID 21909 (/usr/lib/cups/filter/pstoraster) did not catch or ignore signal 13. D [20/Oct/2010:09:33:39 +0200] Discarding unused job-state-changed event... E [20/Oct/2010:09:33:39 +0200] [Job 289] Job stopped due to filter errors; please consult the error_log file for details. --- cut here ---
Genau der gleiche Druck via "recommended" Treiber (Foomatic/chp2200) in cups geht einwandfrei.
Geht dieses hplip Zeugs überhaupt irgendwo vernünftig?
Andreas
Hi, also, ich habe es privat am Laufen (11.1) mit einem HP CLJ 2605 und kann überhaupt keine Fehler melden. Lief von Anfang an, ohne jeden manuellen Eingriff. Keine Ahnung, ob das 11.3er Zeugs buggy ist... Deinem Log entnehme ich, dass die ppd nicht gefunden wird (erste Zeile), ist die da und wenn ja, am richtigen Ort? Kann es sein, dass hplip eine falsche ppd eingestellt hat? Dass der Drucker dann immer inaktiv ist, ist Standard bei cups, wenn Aufträge nicht gedruckt werden können. Kannst Du aber in der Fehlerbehandlung für cups ändern... Zugegebenermaßen nehme ich im Job hplip auch nicht, allerdings geht das meiste bei uns über unser Datenbanksystem vorformatiert per raw raus... cu jth -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Joerg Thuemmler wrote:
Am 20.10.2010 09:51, schrieb Kyek, Andreas, VF-DE:
Hallo,
[...]
Hier mal ein aktueller error-Log Auszug für den Versuch, ein PDF aus firefox auf den BIJ 2200 zu drucken:
--- cut here --- D [20/Oct/2010:09:33:39 +0200] [Job 289]
prnt/hpcups/HPCupsFilter.cpp 361: DEBUG: Bad PPD - hpPrinterLanguage not found
D [20/Oct/2010:09:33:39 +0200] [Job 289] prnt/backend/hp.c 839: ERROR: null print job total=0 D [20/Oct/2010:09:33:39 +0200] [Job 289] cups_print_chunked: xflip = 0, yflip = 0, height = 6639 D [20/Oct/2010:09:33:39 +0200] PID 21910 (/usr/lib/cups/filter/hpcups) stopped with status 1! D [20/Oct/2010:09:33:39 +0200] PID 21911 (/usr/lib/cups/backend/hp) exited with no errors. D [20/Oct/2010:09:33:39 +0200] PID 21908 (/usr/lib/cups/filter/pstops) did not catch or ignore signal 13. D [20/Oct/2010:09:33:39 +0200] PID 21909 (/usr/lib/cups/filter/pstoraster) did not catch or ignore signal 13. D [20/Oct/2010:09:33:39 +0200] Discarding unused job-state-changed event... E [20/Oct/2010:09:33:39 +0200] [Job 289] Job stopped due to filter errors; please consult the error_log file for details. --- cut here ---
Genau der gleiche Druck via "recommended" Treiber (Foomatic/chp2200) in cups geht einwandfrei.
[...]
Deinem Log entnehme ich, dass die ppd nicht gefunden wird (erste Zeile), ist die da und wenn ja, am richtigen Ort? Kann es sein, dass hplip eine falsche ppd eingestellt hat?
keine Ahnung! Was ich wohl sehe ist das wenn ich z.B. für den Business 2200 Drucker zwei Drucker einrichte; einmal hplip und einmal socket werden zwei PPDs nach /etc/cups/ppd unter dem jeweiligen Druckernamen kopiert. Das hplip File (bij2200.ppd) ruft z.B als Filter auf: *cupsFilter: "application/vnd.cups-raster 0 hpcups"; der bij2200_direkt (socket Verbindung) ruft auf: *cupsFilter: "application/vnd.cups-postscript 0 foomatic-rip"; Es werden also unterschiedliche Filterketten verwendet.
Dass der Drucker dann immer inaktiv ist, ist Standard bei cups, wenn Aufträge nicht gedruckt werden können. Kannst Du aber in der Fehlerbehandlung für cups ändern...
Will ich aber eigentlich nicht. Ich will eigentlich, das keine Fehler auftreten. Wie oben geschrieben konnte ich das gleiche Dokument über den "anderen" Weg sofort ausdrucken. Andreas -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hallo, On Oct 20 12:50 Kyek, Andreas, VF-DE wrote (shortened):
Das hplip File (bij2200.ppd) ruft z.B als Filter auf: *cupsFilter: "application/vnd.cups-raster 0 hpcups";
Der neue hpcups Treiber in HPLIP passt zwar eigentlich besser zu CUPS, hat aber noch so manche Kinderkrankheit im Gegensatz zum traditionellen hpijs Treiber in HPLIP siehe z.B. http://bugzilla.novell.com/show_bug.cgi?id=628225#c1 und http://bugzilla.novell.com/show_bug.cgi?id=630696#c1 Gruß Johannes Meixner -- SUSE LINUX Products GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany AG Nuernberg, HRB 16746, GF: Markus Rex
Hallo Andreas, On Wednesday 20 October 2010 09:51:57 Kyek, Andreas, VF-DE wrote:
Mal druckt er, mal nicht. Nach einer längeren Zeit der Nichtbenutzung (insbesonders wenn der Drucker ausgeschaltet war) muss ich JEDESMAL diesen blöden Drucker in cups wieder starten.
Schau mal in /etc/cups/printers.conf wie dort ErrorPolicy gesetzt ist. Aus der CUPS Doku: The ErrorPolicy directive defines the policy that is used when a backend is unable to send a print job to the printer ... The following values are supported: abort-job - Abort the job and proceed with the next job in the queue retry-job - Retry the job after waiting for N seconds; the cupsd.conf JobRetryInterval directive controls the value of N stop-printer - Stop the printer and keep the job for future printing; this is the default value
Ich habe jetzt zu Hause wieder auf "normale" PPDs ohne HPLIP umgestellt; das funktioniert problemlos.
Das hat IMHO nichts mit HPLIP zu tun.
Geht dieses hplip Zeugs überhaupt irgendwo vernünftig?
Es wuerde viel weiterhelfen, wenn du uns wenigstens deine openSUSE-Version, hplip-Version, CUPS-Version oder sonstige Informationen liefern koenntest. Ich hatte mit hplip bisher auf keinem Rechner und mit keinem HP-Drucker Probleme, was natuerlich noch keine Aussage ueber den Zustand von hplip insgesamt erlaubt Roman -- Roman Fietze Telemotive AG Buero Muehlhausen Breitwiesen 73347 Muehlhausen Tel.: +49(0)7335/18493-45 http://www.telemotive.de -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Roman Fietze wrote:
On Wednesday 20 October 2010 09:51:57 Kyek, Andreas, VF-DE wrote:
Mal druckt er, mal nicht. Nach einer längeren Zeit der Nichtbenutzung (insbesonders wenn der Drucker ausgeschaltet war) muss ich JEDESMAL diesen blöden Drucker in cups wieder starten.
Schau mal in /etc/cups/printers.conf wie dort ErrorPolicy gesetzt ist.
steht auf "stop-printer" und soll auch so bleiben - "wenn" mal Fehler auftreten will ich das normalerweise sehen (OK, bei hplip nervt das!) [...]
Ich habe jetzt zu Hause wieder auf "normale" PPDs ohne HPLIP umgestellt; das funktioniert problemlos.
Das hat IMHO nichts mit HPLIP zu tun.
Wieso? Wenn ich in cups den Drucker über das Web-Interface einrichte, erhalte ich eine Liste von PPDs zur Auswahl; das sind NICHT die gleichen die ausgewählt werden wenn ich die Drucker via hplip einrichte. Ausserdem ist bei "direkt" das Interface bei mir "socket://hp:9100" und bei hplip ist es "hp:/net/<DRUCKER>?ip=<IP-ADRESSE>"
Geht dieses hplip Zeugs überhaupt irgendwo vernünftig?
Es wuerde viel weiterhelfen, wenn du uns wenigstens deine openSUSE-Version, hplip-Version, CUPS-Version oder sonstige Informationen liefern koenntest.
openSUSE 11.3 cups-1.4.4, cups-drivers-1.3.9 hplip und hplip-hpijs 3.10.2
Ich hatte mit hplip bisher auf keinem Rechner und mit keinem HP-Drucker Probleme, was natuerlich noch keine Aussage ueber den Zustand von hplip insgesamt erlaubt
Ich hatte diese "Anschubsen" müssen mit hplip eigentlich immer. Das _könnte_ daran liegen, das mein Drucker fast immer aus ist; wenn jemand druckt wird der Drucker meist erst später irgendwann eingeschaltet wenn man die Ausdrucke abholen will (zwischen Wohnzimmer und Drucker liegt eine Etage!). Alle diese Probleme verschwinden, wenn ich von hplip auf "socket" direkt umstelle. Andreas -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hallo, nur als kleiner Hinweis vorweg: Der Text im Subject ist wenig geeignet, um wohlwollende Hilfe auf freiwilliger Basis zu erhalten (unsachlich, Tippfehler, Ausrufezeichen). On Oct 20 12:40 Kyek, Andreas, VF-DE wrote (shortened):
Ich hatte diese "Anschubsen" müssen mit hplip eigentlich immer. Das _könnte_ daran liegen, das mein Drucker fast immer aus ist; wenn jemand druckt wird der Drucker meist erst später irgendwann eingeschaltet wenn man die Ausdrucke abholen will (zwischen Wohnzimmer und Drucker liegt eine Etage!).
Alle diese Probleme verschwinden, wenn ich von hplip auf "socket" direkt umstelle.
Siehe "What is a CUPS backend and how does it work?" in http://en.opensuse.org/SDB:CUPS_in_a_Nutshell Vergl. auch https://bugzilla.novell.com/show_bug.cgi?id=631266 Anscheinend gibt das "hp" Backend zumindest bei HP Netzwerkdruckern (oder vielleicht nur bei dem speziellen Modell) zu schnell auf, vergl. https://bugzilla.novell.com/show_bug.cgi?id=337794#c16 Für solche Backends kann man normalerweise als Workaround das "beh" Backend (im Paket foomatic-filters dabei) zwischenschalten z.B. mit der YaST Druckerkonfiguration via "Connection Wizard" (ich weiß jetzt nicht, wie der in der deutschen Übersetzung heisst). Aber gemäß http://www.linuxfoundation.org/collaborate/workgroups/openprinting/database/... ------------------------------------------------------------------ beh works with every backend except the hp backend from HPLIP. If beh is used with the hp backend, the HP Toolbox will not find the printers any more. ------------------------------------------------------------------ Also zu http://hplipopensource.com/hplip-web/support.html und den Autoren von HPLIP melden, dass ihr "hp" Backend zumindest bei HP Netzwerkdruckern zu schnell aufgibt. Siehe insbes. https://bugzilla.novell.com/show_bug.cgi?id=337794#c16 -------------------------------------------------------------------- As long as the backend cannot establish a communication with its recipient, it cannot cause damage when it loops infinitely and retries again and again (with a reasonable sleep time between each retry). ... I think that the backends should be more robust against possibly transient errors. I would like to suggest that when there is a chance that an error condition goes away while the backend is about to establish a communication with its recipient, it should loop infinitely and retry again and again. Of course with a reasonable sleep time between each retry preferably with additional options via DeviceURI so that expert users can specify for each queue how many retries are done and what the sleep time is - just like the options of the "beh" backend error wrapper... And with reasonable stderr-messages so that user is continuously informed for each re-try what goes on (e.g. "123th re-try to connect to USB printer ACME FunPrinter 1000: no response"). If the user doesn't like it, he can simply cancel his print job. In contrast only the admin can re-enabe a queue. But if there is a communication error while the backend sends data, it should exit with exit code 3 (CUPS_BACKEND_HOLD) so that the partially printed job is neither lost nor automatically re-printed. The user can then decide what to do with his partially printed job. -------------------------------------------------------------------- Ich habe das den Autoren von HPLIP schon vor Äonen gemeldet, doch nur hinreichend viele (höfliche) Beschwerden von echten Kunden können große Firmen in Bewegung versetzen. Es muß bei denen schon an irgendeiner schmerzempfindlichen Stelle "pieksen" und am meisten schmerzt große Firmen (drohender) Geldverlust weil die im wesentlichen nur Geld messen und in Geld "denken" können. Gruß Johannes Meixner -- SUSE LINUX Products GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany AG Nuernberg, HRB 16746, GF: Markus Rex
Johannes Meixner wrote:
nur als kleiner Hinweis vorweg: Der Text im Subject ist wenig geeignet, um wohlwollende Hilfe auf freiwilliger Basis zu erhalten (unsachlich, Tippfehler, Ausrufezeichen).
D'accord (was den Tippfehler betrifft). Und ob du es glaubst oder nicht: Bis du das erwähnt hast war mir das NICHT aufgefallen. Es ist schon seltsam, was man so überlesen kann ;-) (Ich lasse das subject jetzt aber so stehen; jetzt kann es nicht mehr schlimmer werden)
On Oct 20 12:40 Kyek, Andreas, VF-DE wrote (shortened):
Ich hatte diese "Anschubsen" müssen mit hplip eigentlich immer. Das _könnte_ daran liegen, das mein Drucker fast immer aus ist; wenn jemand druckt wird der Drucker meist erst später irgendwann eingeschaltet wenn man die Ausdrucke abholen will (zwischen Wohnzimmer und Drucker liegt eine Etage!).
Alle diese Probleme verschwinden, wenn ich von hplip auf "socket" direkt umstelle.
Siehe "What is a CUPS backend and how does it work?" in http://en.opensuse.org/SDB:CUPS_in_a_Nutshell
Vergl. auch https://bugzilla.novell.com/show_bug.cgi?id=631266
Anscheinend gibt das "hp" Backend zumindest bei HP Netzwerkdruckern (oder vielleicht nur bei dem speziellen Modell) zu schnell auf, vergl. https://bugzilla.novell.com/show_bug.cgi?id=337794#c16
[Rest der guten Erkärung] Ich werd's mal an HP melden; danke für die Info Andreas -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hallo Leute, da dieses Thema offenbar nicht nur mich, sondern auch jemand anderen Wahnsinnig macht schreibe ich auch "meinen Senf" dazu. Ja, mich macht's auch wahnsinnig! Allerdings nur beim scannen. Beim Drucken habe ich fast kein Problem. Lediglich wenn eine WIN Maschine auf den über Samba freigegebenen Drucker druckt und den "Pseudo-Duplex" Modus des WIN-Treibers dabei verwendet, dann glaubt CUPs (oder wer auch immer) jedesmal dass das Papier im Drucker aus ist. Ich muss dann immer im CUPS den Drucker stoppen und wieder starten, dann gehts wieder. Beim scannen macht's mich allerdings wirklich wahnsinnig. Egal mit welchem Tool ich scanne (xsane, hp-scan, ...), der scan startet, die Daten kommen, und am Ende, wenn der Scanner fertig ist und wieder zurück fährt kommt die Meldung "Error during device I/O" und die Daten sind wieder weg. Das passiert bei ungefähr 80% aller Versuche. Ich hab schon soooo viele Stunden im Google und bei diversen "Lösungsvorschlägen" verbracht dass ich bereits resigniert habe. Wenn ich etwas scannen muss, dann leg ich das Blattt rein, mache ein Terminalfenster auf und starte so lange hp-scan bis es irgendwann funktionert. Wie gesagt, meistens braucht es 5-6 Versuche, dann glückt es 1x Ich habe den Verdacht, es hat irgend etwas mit der USB Geschwindigkeit und der Datenmenge zu tun. Je niedriger die zu übertragende Datenmenge desto eher funktioniert der scan. Z.B. 75dpi, s/w geht so gut wie immer beim 1. Mal, 150dpi Farbe braucht meist 3-4 Versuche, 300dpi Farbe meistens 10 und mehr Versuche 600dpi in Farbe geht fast nie. Drucker: HP LaserJet 3330 mfp, angeschlossen über USB. (Im Prinzip bin ich mit dem Drucker sonst sehr sehr zufrieden) SUSE 11.2, hplip: 3.9.8-3.4.1-x86_64 vom standard openSUSE repo ich habe auch probiert auf die von der HP Seite angebotenen hplip 3.10.??? umzusteigen. Ist mir aber nicht gelungen. Hab's runtergeladen aber die Installation schlug irgendwann mitten drin fehl. Und dann ging gar nichts mehr. Erst als ich mit yast wieder die hplip und hpaio von den originalrepos drüberinstalliert hatte und im yast den scanner neu konfiguriert hatte hat wieder alles funktioniert. Leider immer nur mit dem oben beschriebenen Problem... Das Problem ist definitiv mit HPLIP aufgetaucht. In der Zeit "vor HPLIP" hat der Scanner immer problemlos funktioniert. Norbert -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hallo, On Oct 20 13:21 Norbert Zawodsky wrote (shortened):
der scan startet, die Daten kommen, und am Ende, wenn der Scanner fertig ist und wieder zurück fährt kommt die Meldung "Error during device I/O"
Vermutlich war der Scanner nicht wirklich fertig, sondern hat wegen "Error during device I/O" abgebrochen und ist zurückgefahren. Das ist dann ein low-level USB Problem. Die Datenübertragung auf tieferer Ebene ist unzuverlässig. Vergl. https://bugzilla.novell.com/show_bug.cgi?id=554664#c6
Wie gesagt, meistens braucht es 5-6 Versuche, dann glückt es 1x
Das beweist praktisch, dass die eigentliche Ursache nicht die Software selbst ist, sondern eher die Hardware, denn die Software sollte sich nicht mal so mal so verhalten, wenn sich nicht die Hardware darunter mal so mal so verhält. Siehe auch http://en.opensuse.org/SDB:Configuring_Scanners "USB Cable Connection and Additional USB Hubs"
Ich habe den Verdacht, es hat irgend etwas mit der USB Geschwindigkeit und der Datenmenge zu tun. Je niedriger die zu übertragende Datenmenge desto eher funktioniert der scan.
Z.B. 75dpi, s/w geht so gut wie immer beim 1. Mal, 150dpi Farbe braucht meist 3-4 Versuche, 300dpi Farbe meistens 10 und mehr Versuche 600dpi in Farbe geht fast nie.
Das beweist noch mehr, dass es an der Hardware liegt. Die kann vermutlich high-speed USB nicht zuverlässig.
Das Problem ist definitiv mit HPLIP aufgetaucht. In der Zeit "vor HPLIP" hat der Scanner immer problemlos funktioniert.
Ich glaube dennoch nicht, dass es an HPLIP liegt. Eher ein zeitliches Zusammentreffen von high-speed USB. Vermutlich ging es damals zu low-speed USB Zeiten. Abhilfe: Statt der Kernelmodule für high-speed USB, nur die Kernelmodule für low-speed USB laden. Ich bin aber kein USB-Experte, um sagen zu können, welche Kernelmodule das sind, nur als Hinweis ohne Gewähr vergl. http://bugzilla.novell.com/show_bug.cgi?id=554664#c10 Falsche Kernelmodule können das System schlagartig abstürzen lassen was völligen Datenverlust zur Folge haben kann (muss nicht - aber kann - also Datensicherung machen). Gruß Johannes Meixner -- SUSE LINUX Products GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany AG Nuernberg, HRB 16746, GF: Markus Rex
Am 20.10.2010 13:21, schrieb Norbert Zawodsky:
Beim scannen macht's mich allerdings wirklich wahnsinnig. Egal mit welchem Tool ich scanne (xsane, hp-scan, ...),
der scan startet, die Daten kommen, und am Ende, wenn der Scanner fertig ist und wieder zurück fährt kommt die Meldung "Error during device I/O" und die Daten sind wieder weg. Das passiert bei ungefähr 80% aller Versuche. Ich hab schon soooo viele Stunden im Google und bei diversen "Lösungsvorschlägen" verbracht dass ich bereits resigniert habe. Wenn ich etwas scannen muss, dann leg ich das Blattt rein, mache ein Terminalfenster auf und starte so lange hp-scan bis es irgendwann funktionert. Wie gesagt, meistens braucht es 5-6 Versuche, dann glückt es 1x
Seitdem ich meinen Officejet habe, ist das bei mir reproduzierbar so: - der erste Scanversuch endet _immer_ mit IO Error - der darauffolgende funktioniert _immer_ Hab mich schon daran gewöhnt. Wolfgang -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hallo Wolfgang, On Oct 20 15:06 Wolfgang Rosenauer wrote (shortened):
Seitdem ich meinen Officejet habe, ist das bei mir reproduzierbar so: - der erste Scanversuch endet _immer_ mit IO Error - der darauffolgende funktioniert _immer_
Hab mich schon daran gewöhnt.
Gut so! ;-) Dennoch drei Fragen: Gibt es einen Upstream Bug Report dazu? Hat es was genutzt bzw. am Verhalten geändert, zu verhindern, dass das Kernelmodul "usblp" überhaupt jemals geladen wird. Liefert vielleicht ein "udevadm monitor" während des Einsteckens am USB bzw. beim Anschalten des Geräts irgendwas "erleuchtendes", um der eigentlichen Ursache näher kommen zu können? Ich bin wirklich kein USB-Experte, um sowas ordentlich debuggen zu können. Ich kann auch nur mehr oder weniger hilflos rumstochern (zumal mein HP all-in-one Gerät am USB problemlos funktioniert). "USB macht mich wahnisnng!" Schönen Gruß Johannes Meixner -- SUSE LINUX Products GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany AG Nuernberg, HRB 16746, GF: Markus Rex
On 20/10/10 08:51, Kyek, Andreas, VF-DE wrote:
[...] Geht dieses hplip Zeugs überhaupt irgendwo vernünftig?
Ueberhaupt kein Problem hier mit SuSE 11.3. Cheers, Th. -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Am 20.10.2010 20:05, schrieb Thomas Hertweck:
On 20/10/10 08:51, Kyek, Andreas, VF-DE wrote:
[...] Geht dieses hplip Zeugs überhaupt irgendwo vernünftig?
Ueberhaupt kein Problem hier mit SuSE 11.3.
Cheers, Th.
Na, nicht ganz. https://bugzilla.novell.com/show_bug.cgi?id=643916 Bin iÜ optimistisch, wenn ich das Strategie-Papier lese, daß es einen Qualitätssprung gibt - falls die Strategie umgesetzt wird. Grüße Andreas -- https://code.launchpad.net/~a-roehler/python-mode/python-mode-components https://code.launchpad.net/s-x-emacs-werkstatt/ -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hallo, On Oct 21 10:10 Andreas Röhler wrote (shortened):
Am 20.10.2010 20:05, schrieb Thomas Hertweck:
Ueberhaupt kein Problem hier mit SuSE 11.3.
... Na, nicht ganz. https://bugzilla.novell.com/show_bug.cgi?id=643916
Siehe dazu auch "USB scanner access permissions via udev" in http://en.opensuse.org/SDB:Configuring_Scanners Dass es beim einen geht, beim anderen nicht, zeigt doch klar, dass es kein grundsätzliches Problem ist - sonst hätte ich auch viele solcher Bug-Reports - und wenn ich das Problem selbst reproduzieren könnte, wäre es vermutlich gelöst.
Bin iÜ optimistisch, wenn ich das Strategie-Papier lese, daß es einen Qualitätssprung gibt - falls die Strategie umgesetzt wird.
Es ist dabei hoffentlich klar, dass es bei openSUSE vor allem darum geht, dass viele openSUSE Benutzer tatsächlich mitmachen und einen echten Beitrag zu openSUSE und Linux liefern. Ein echter Beitrag kann insbesondere sein, dass Bugs, die von der jeweiligen Hardware abhängen, auch tatsächlich bei den jeweiligen Upstream Projekten gemeldet werden und zwar von den Benutzern, die die jeweilige Hardware und das Problem damit tatsächlich haben und dass diese Benutzer dann auch bereit sind, mit den Upstream Projekten Schritt für Schritt dem Problem auf den Grund zu gehen, um die eigentliche Ursache finden zu können - was dann wieder einen Bug-Report bei einem ganz anderen Upstream Projekt zur Folge haben kann. Das ist mühsam, das kostet Zeit und Nerven, aber das ist dann auch genau deswegen ein echter Beitrag. Alternativ bietet die Firma Novell für Geld Supportleistungen praktisch jeder Art an für Kunden, die nicht selbst Mühe, Zeit und Nerven investieren wollen oder können bzw. für Kunden, die garantierte Supportbedingungen brauchen und sich nicht nur auf unverbindliche Hilfe auf freiwilliger Basis verlassen wollen oder können. Gruß Johannes Meixner -- SUSE LINUX Products GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany AG Nuernberg, HRB 16746, GF: Markus Rex
Hallo Johannes,
Es ist dabei hoffentlich klar, dass es bei openSUSE vor allem darum geht, dass viele openSUSE Benutzer tatsächlich mitmachen und einen echten Beitrag zu openSUSE und Linux liefern.
Ein echter Beitrag kann insbesondere sein, dass Bugs, die von der jeweiligen Hardware abhängen, auch tatsächlich bei den jeweiligen Upstream Projekten gemeldet werden und zwar von den Benutzern, die die jeweilige Hardware und das Problem damit tatsächlich haben und dass diese Benutzer dann auch bereit sind, mit den Upstream Projekten Schritt für Schritt dem Problem auf den Grund zu gehen, um die eigentliche Ursache finden zu können - was dann wieder einen Bug-Report bei einem ganz anderen Upstream Projekt zur Folge haben kann. Das ist mühsam, das kostet Zeit und Nerven, aber das ist dann auch genau deswegen ein echter Beitrag.
ich bin gerne bereit meinen Beitrag zu leisten. Aber ich muss schon anmerken dass der "Wert" der Fehlermeldung "Error during device I/O" nur marginal größer als 0 ist. Zumal auch in /var/log/messages NICHTS dazu geloggt wird. Wie wäre es wenigstens mit einem Errorcode? Oder vielleicht einer Sourcecode-Linenumber? Programmierer die solche nichtssagenden Fehlermeldungen aus Ihren Programmen ausgeben sind meiner Meinung nach genau so faul wie user die keine Bugreports schreiben. o.k., zurück zur Sachlichkeit: Was soll ich tun damit ich sinnvolle Informationen zu diesem Fehler liefern kann? WO soll ich WIE WELCHEN loglevel aufdrehen? Grüße Norbert -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Am 21.10.2010 11:48, schrieb Johannes Meixner:
Hallo,
On Oct 21 10:10 Andreas Röhler wrote (shortened):
Am 20.10.2010 20:05, schrieb Thomas Hertweck:
Ueberhaupt kein Problem hier mit SuSE 11.3.
... Na, nicht ganz. https://bugzilla.novell.com/show_bug.cgi?id=643916
Siehe dazu auch "USB scanner access permissions via udev" in http://en.opensuse.org/SDB:Configuring_Scanners
Dass es beim einen geht, beim anderen nicht, zeigt doch klar, dass es kein grundsätzliches Problem ist - sonst hätte ich auch viele solcher Bug-Reports - und wenn ich das Problem selbst reproduzieren könnte, wäre es vermutlich gelöst.
Bin iÜ optimistisch, wenn ich das Strategie-Papier lese, daß es einen Qualitätssprung gibt - falls die Strategie umgesetzt wird.
Es ist dabei hoffentlich klar, dass es bei openSUSE vor allem darum geht, dass viele openSUSE Benutzer tatsächlich mitmachen und einen echten Beitrag zu openSUSE und Linux liefern.
Ein echter Beitrag kann insbesondere sein, dass Bugs, die von der jeweiligen Hardware abhängen, auch tatsächlich bei den jeweiligen Upstream Projekten gemeldet werden und zwar von den Benutzern, die die jeweilige Hardware und das Problem damit tatsächlich haben und dass diese Benutzer dann auch bereit sind, mit den Upstream Projekten Schritt für Schritt dem Problem auf den Grund zu gehen, um die eigentliche Ursache finden zu können - was dann wieder einen Bug-Report bei einem ganz anderen Upstream Projekt zur Folge haben kann. Das ist mühsam, das kostet Zeit und Nerven, aber das ist dann auch genau deswegen ein echter Beitrag.
Alternativ bietet die Firma Novell für Geld Supportleistungen praktisch jeder Art an für Kunden, die nicht selbst Mühe, Zeit und Nerven investieren wollen oder können bzw. für Kunden, die garantierte Supportbedingungen brauchen und sich nicht nur auf unverbindliche Hilfe auf freiwilliger Basis verlassen wollen oder können.
Gruß Johannes Meixner
Hallo, wollte nicht meckern, lediglich überzogene Erwartungen dämpfen, die am Ende zu Enttäuschungen führen. Hatte ja bereits eine Lösung für mich gefunden. Ein Fehler bleibt es. Wartungsverträge für den Anschluß von Allerweltsgeräten halte ich nicht für eine realistische Alternative. Ganz einfach scheint der Fall i.Ü. nicht zu liegen, wenn ich den Gang der Fehlerbehebung verfolge. Das war aber nicht der Grund meines Schreibens. Dank an alle Beteiligte bei der Gelegenheit Grüße Andreas -- https://code.launchpad.net/~a-roehler/python-mode/python-mode-components https://code.launchpad.net/s-x-emacs-werkstatt/ -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
participants (8)
-
Andreas Röhler -
Joerg Thuemmler -
Johannes Meixner -
Kyek, Andreas, VF-DE -
Norbert Zawodsky -
Roman Fietze -
Thomas Hertweck -
Wolfgang Rosenauer