Bug 312491

Summary: Laserjet 2100 with postscript driver puts printer in error state
Product: [Fedora] Fedora Reporter: John Dennis <jdennis>
Component: cupsAssignee: Tim Waugh <twaugh>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: low    
Version: 8CC: adam
Target Milestone: ---Flags: twaugh: needinfo? (jdennis)
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-01-09 02:17:17 EST Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On:    
Bug Blocks: 235704    
Attachments:
Description Flags
test.ps
none
ppd file
none
LaserJet_2100-pstops.ps none

Description John Dennis 2007-09-29 13:24:08 EDT
My apologies, I'm really not sure what component this should be assigned to, my
guess is it's not cups, but I'm not sure what it should be.

When printing from my F-8 box the error light on the printer comes on. I believe
this only occurs at the conclusion of a print job, but I can't confirm that yet.
Once the error light comes on I have to press the button on the printer to clear
it, further printing is blocked until such time. I'm pretty sure this is a
regression in F-8, the same printer serves machines running RHEL5 and Windows
XP, only jobs from the F-8 box induce the problem.

I'm not the best way query the printer for it's error code (can this be done via
a utility?). So I printed the self test configuration page, it has a section
labeled status log and the most recent error codes listed are 79.01BF, hope that
helps.

Here are what I'm guessing are the relevant rpm versions:

foomatic-3.0.2-51.fc8
cups-1.3.2-3.fc8
ghostscript-8.60-2.fc8

The laserjet is configured as a network printer using JetDirect with the default
postscipt driver.
Comment 1 John Dennis 2007-10-05 12:53:22 EDT
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.
Comment 2 John Dennis 2007-10-05 12:55:58 EDT
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.
Comment 3 Joseph Sacco 2007-10-05 13:10:14 EDT
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
Comment 4 Tim Waugh 2007-10-05 13:17:11 EDT
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.
Comment 5 Tim Waugh 2007-10-05 13:23:38 EDT
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.
Comment 6 John Dennis 2007-10-12 11:38:33 EDT
Other than being sized slightly incorrectly (A4 vs. letter?) the file test.ps
printed fine and did not induce any errors.
Comment 7 Tim Waugh 2007-10-12 11:57:38 EDT
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.
Comment 8 Tim Waugh 2008-02-26 06:42:42 EST
*ping*
Comment 9 John Dennis 2008-02-26 09:07:20 EST
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.
Comment 10 Tim Waugh 2008-02-26 09:23:35 EST
I need to see the PPD file (see comment #5 and comment #7).
Comment 11 John Dennis 2008-02-26 10:11:39 EST
Created attachment 295930 [details]
ppd file
Comment 12 Tim Waugh 2008-02-26 10:33:41 EST
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?
Comment 13 John Dennis 2008-02-26 11:29:25 EST
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".
Comment 14 Adam Goode 2008-02-26 11:30:33 EST
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.
Comment 15 Tim Waugh 2008-02-26 11:49:27 EST
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.
Comment 16 John Dennis 2008-02-26 11:58:34 EST
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.
Comment 17 John Dennis 2008-02-26 12:08:23 EST
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
Comment 18 John Dennis 2008-02-26 12:18:30 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.
Comment 19 Tim Waugh 2008-02-26 12:28:30 EST
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?
Comment 20 John Dennis 2008-02-26 12:46:18 EST
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.
Comment 21 Tim Waugh 2008-02-26 12:56:20 EST
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?
Comment 22 John Dennis 2008-02-26 14:07:49 EST
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.


Comment 23 Tim Waugh 2008-02-27 09:42:20 EST
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?
Comment 24 Bug Zapper 2008-11-26 02:52:57 EST
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
Comment 25 Bug Zapper 2009-01-09 02:17:17 EST
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.