Bug 312491

Update:

The 79.01BF error seems to be associate with a page from a long time ago, thus I
don't think it's relevant.

The error is not restricted to the end of the print job, I've seen it manifest
it self in the middle of printing as well.

One more thing, the HP troubleshooting guide suggests the behavior could be
caused by the printer being in manual feed mode. Printing out the printer
configuration page shows this is not the case.

I suspect it's a postscript interpreter error. The printer is set not to print
out postscript errors. Enabling this seems like it might be a good diagnostic,
but I don't know how to do that.

Evolution and evince no longer print after updating to the latest
version of rawhide [05-Oct-07].  Other applications print OK as does the
test page from the printer set up. I can also print text files from the
command line using lp.

-Joseph

Joseph: since that is an entirely separate bug, please file a separate bug
report (against gtk2 I would suggest).  Thanks.

John: Please set up a raw queue ("Generic" as the manufacturer and "Raw Queue"
as the model, or else if you have an older system-config-printer it will appear
as manufacturer "Raw") for this device so that we can try sending it PostScript
files without them being modified in any way by CUPS or by foomatic.

Created attachment 217721 [details]
test.ps

Next, print this file (lp -drawqueue test.ps) and let me know what the results
are.

Can you also attach the PPD file that the real queue (not the raw queue you
just set up) is using?	It will be in /etc/cups/ppd/$name.ppd.	Thanks.

Other than being sized slightly incorrectly (A4 vs. letter?) the file test.ps
printed fine and did not induce any errors.

Great; sorry, yes, it was A4.  Don't forget to attach the PPD file, and then
I'll be able to start hunting down what the difference is between the successful
print and the unsuccessful one.

*ping*

O.K. I'm not sure what you're looking for. The test file printed successfully.
However, the printer still goes into error state frequently. I suspect this has
less to do with the postscript file than the protocol interactions used to
encapsulate it. Is there anything which can be used to monitor the protocol
transactions between the host and the printer? It seems much more productive for
the printer to tell us what it thinks is wrong. Unexpected data? Bad length? etc.

I need to see the PPD file (see comment #5 and comment #7).

Created attachment 295930 [details]
ppd file

Created attachment 295934 [details]
LaserJet_2100-pstops.ps

Try printing this through a raw queue, as in comment #4.  This is the result of
running the CUPS test page through CUPS pstops filter against the PPD you're
using.

Does it print?

Hi Tim: Yes the LaserJet_2100-pstops.ps file prints just fine, no problems.

FWIW, this morning I was printing emails from Thunderbird and many of them put
the printer into error mode. I also get a notification from the printer (status
icon??) that there is an error, but all it says is "other".

If you are seeing problems primarily with evince, would it be possible for you
to try cairo 1.5.10 or newer? There was a significant set of PostScript
optimzations put into this release which may address your problem.

John: the notification is interesting.  What does 'lpstat -t' say?

Can you also try printing a test page using the System->Administration->Printing
tool?  You should also get a successful print job.

I never use evince, I do use Adobe Reader, not sure if they might share a common
library.

To be honest there is nothing which directly points to postscript being the culprit.

Just from observing the failures I'm going to go completely out on a limb and
draw a wildly unsupported conclusion. It feels like it's a protocol error
between the host and the printer where the printer is either expecting data
which does not arrive or gets more data than expected. One reason I draw that
conclusion is in the majority of cases the error presents itself after it's
printed a page, in many cases there are no further pages to print (e.g. a one
page job). From an observational point of view the job completed successfully,
but printer then goes into error state. So did something arrive it wasn't
expecting? Or did it not get everything it expected and flushed the page? The
error does not happen on the last page, sometimes it happens in the middle of
multi page job, but I could imagine if there is something which "frames" a page
or "frames" a data block which does not always compute a boundary correctly it
could be seen in each of these scenarios. But as I say, this is just wild
speculation without foundation.

The System->Administration->Printing test page prints fine.

Let me correct an error in comment #16, you have to first hit the button on the
printer to clear the error before the page prints, but then it immediately prints.

Here is the lpstat output:

$ lpstat -t
scheduler is running
system default destination: LaserJet_2100
device for LaserJet_2100: hp:/net/HP_LaserJet_2100_Series?ip=192.168.1.103
device for raw: lpd://192.168.1.103/raw
LaserJet_2100 accepting requests since Tue 26 Feb 2008 11:26:17 AM EST
raw accepting requests since Tue 26 Feb 2008 11:18:26 AM EST
printer LaserJet_2100 now printing LaserJet_2100-199.  enabled since Tue 26 Feb
2008 11:26:17 AM EST
        check device; will retry in 30 seconds...
printer raw is idle.  enabled since Tue 26 Feb 2008 11:18:26 AM EST
LaserJet_2100-199       jdennis          50176   Tue 26 Feb 2008 11:26:17 AM EST

I just printed the printer's status page. There is a section called "Status Log"
with two columns "Code" and "Page". Code looks like an error code and I assume
Page is the page it occurred on. The most recent error is 50013 on page 38651,
but the total page count is 38946 so the 50013 error would have to have occurred
295 pages ago, well before any of the recent errors I've seen so I'm not sure
it's relevant.

Also under settings is "PRT PS ERRS = OFF". I assume this mean when there is a
Postscript error print it. That might be a useful diagnostic, but I don't know
how to enable that, do you?

I can telnet into this printer and I assume once you're in you can do all sorts
of things, but it's all a bit cryptic and I'm not sure what to poke at.

Please try adding a queue that uses the CUPS 'socket' backend, as follows:

Start the System->Administration->Printing tool
Click 'New Printer'
Select 'AppSocket/HP JetDirect' for the connection
Type in '192.168.1.103' in the hostname field
Click Next, and follow the prompts.

Name this printer 'LaserJet_socket' or something.  How does that queue behave? 
Any better?

re comment #19, it seems to me this is exactly the way I created the printer in
the first place. I did create it as suggested and the behavior is identical.
Although FWIW the page did print without having to hit the printer button to
clear it first, but the error light did come on.

John: what does 'lpstat -t' say now?  The queue you originally had was using the
'hp' backend; the raw queue you created was using the 'lpd' backend, and I was
asking you to try the 'socket' backend.

Are you running rawhide?  Can you run the System->Administration->Printing tool
and select Help->Troubleshoot?

The error light is on, send a print job to laserjet_socket, lpstat shows this:

$ lpstat -t
scheduler is running
system default destination: LaserJet_2100
device for LaserJet_2100: hp:/net/HP_LaserJet_2100_Series?ip=192.168.1.103
device for laserjet_socket: hp:/net/HP_LaserJet_2100_Series?ip=192.168.1.103

device for raw: lpd://192.168.1.103/raw
LaserJet_2100 accepting requests since Tue 26 Feb 2008 12:05:08 PM EST
laserjet_socket accepting requests since Tue 26 Feb 2008 01:57:06 PM EST
raw accepting requests since Tue 26 Feb 2008 11:18:26 AM EST
printer LaserJet_2100 is idle.  enabled since Tue 26 Feb 2008 12:05:08 PM EST
printer laserjet_socket now printing laserjet_socket-203.  enabled since Tue 26
Feb 2008 01:57:06 PM EST
        Printing...
printer raw is idle.  enabled since Tue 26 Feb 2008 11:18:26 AM EST
laserjet_socket-203     jdennis          50176   Tue 26 Feb 2008 01:57:06 PM EST

Now wait for about a minute, the notification comes up and lpstat shows this:

$ lpstat -t
scheduler is running
system default destination: LaserJet_2100
device for LaserJet_2100: hp:/net/HP_LaserJet_2100_Series?ip=192.168.1.103
device for laserjet_socket: hp:/net/HP_LaserJet_2100_Series?ip=192.168.1.103

device for raw: lpd://192.168.1.103/raw
LaserJet_2100 accepting requests since Tue 26 Feb 2008 12:05:08 PM EST
laserjet_socket accepting requests since Tue 26 Feb 2008 01:57:06 PM EST
raw accepting requests since Tue 26 Feb 2008 11:18:26 AM EST
printer LaserJet_2100 is idle.  enabled since Tue 26 Feb 2008 12:05:08 PM EST
printer laserjet_socket now printing laserjet_socket-203.  enabled since Tue 26
Feb 2008 01:57:06 PM EST
        check device; will retry in 30 seconds...
printer raw is idle.  enabled since Tue 26 Feb 2008 11:18:26 AM EST
laserjet_socket-203     jdennis          50176   Tue 26 Feb 2008 01:57:06 PM EST

So it seems like when the printer goes into error state it won't accept new jobs
until the printer button is pressed to clear the error.

I've still don't have any idea what the error is.

These experiments seem like a rat hole, can't we do something to query the exact
error?

No, I'm not running rawhide, it's a bit too raw these days. This is F-8 with all
updates applied, would prefer to keep it that way, but I"m happy to install a
small debugging utility which doesn't pull in a lot of dependencies.

As for querying the exact error, changing "PRT PS ERRS = OFF" would certainly
help, but I have no idea how to do that.  Maybe the manual gives a hint?

I see that system-config-printer has substituted the 'hp:' URI when we tried to
make a 'socket:' URI.  Try this:

lpadmin -p laserjet_socket -d socket://192.168.1.103/raw

So far I believe the only error has only occurred with queues that use 'hp:...'
for the device.  Do you agree?

This message is a reminder that Fedora 8 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 8.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '8'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 8's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 8 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Fedora 8 changed to end-of-life (EOL) status on 2009-01-07. Fedora 8 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days