Red Hat Bugzilla – Bug 214280
printing on Laser Jet 4L does not work with cups
Last modified: 2007-11-30 17:11:47 EST
Description of problem:
Printing on my HP LJ 4L used to work perfectly for years.
Up to the point where lpd was replaced by CUPS. Both on
FC5 and FC6 I can't get it to work no matter what I try.
I use the GUI configuration tool, I select my printer, select
the ljet4 driver (tried every other one too) etc. I'll attach
the printer.conf and printer.ppd here. I don't think I am doing
the configuration wrong - I was doing it for 8 years without a
If I am trying to print something (including the test page from
the config gui), the printer starts to consume paper, printing a
few strange letters on every page.
I rush to enter "lprm", but it doesn't work either. It asks me
for the user password. No matter whether I type the correct or
wrong password, it asks me the password again (if the password
is correct, it re-asks immediately; if wrong - after a few seconds).
Ctrl-c doesn't work, so I use Ctrl-z and "kill %1" to get rid of
"lprm" first. In a meantime the printer still eats the paper. I do
"sudo lprm", and that seem to succeed. lpq says that there are
no printer jobs, yet the printer keeps consuming paper. I reset
the printer by hands, but it starts consuming the paper immediately
as soon as it is back online. "ps -A" showed the process with name
"parallel", running as root. SIGTERM didn'd stop it, but SIGKILL
did. Only after killing that process and resetting the printer, I
stopped it from consuming the paper.
I tried all the above many times (selected different drivers etc),
with always the same results.
I guess this can drive the one physically sick, even not taking
into account the fact that I have to boot up FC3 on my old PC to
print something usefull.
Is CUPS really completely broken or its just me?
Version-Release number of selected component (if applicable):
cups-1.2.4-9 right now, but was using other versions of FC5 too.
Steps to Reproduce:
1. Set up the HP LJ 4L printer with the printconf-gui
2. Try to print something, test page for example
3. Be prepared to press Reset button, because there is no,
completely no way to stop the printer at that point! Even
if you reset or power-down the printer, it will continue
eating your paper as soon as it is back online. So you have
to reset your PC and then reset also the printer.
Madness - all the paper spoiled, PC rebooted, printer restarted,
the user is completely crazy!
I only wanted to print a single page...
Sorry for the emotional posting. :) Let me know if the additional
info is needed.
Created attachment 140507 [details]
Created attachment 140509 [details]
Created attachment 140512 [details]
IIRC on FC4 (or FC3?) it was possible to choose between
the lpd and CUPS. CUPS didn't work and lpd did (with other
packages all the same), so this is a problem of CUPS most
certainly (or of its config).
Created attachment 140879 [details]
This file is the output of:
gs -q -dBATCH -dPARANOIDSAFER -dNOPAUSE -sDEVICE=ljet4 \
-sPAPERSIZE=a4 -sOutputFile=ljet4test.prn \
Please try printing it with 'lp -oraw -dprinter ljet4test.prn' and let me know
if you get a test page. Thanks.
Thanks for the reply - this bug is very severe for me.
With your test file and with your test command (no editing
applied, command copy/pasted with mouse), I still get the
But fixing "lprm" is also very important. When I try to
print the test-page from the printconf-gui, the job is
started as root. But the "lprm" I enter as the user. I guess
you can easily reproduce the problem - it asks for the
password but doesn't accept any. "sudo lprm" works but
doesn't stop the printing.
Considering that I am getting the crap even with youre
test file, is it a gs bug or what? I don't think so - after
all I was trying CUPS and lprng with the same gs, and
I've filed bug #215054 to track the problem with cancelling test pages, and bug
#215059 to track the problem with cancelling jobs in general.
Yes, this points to the gs driver being the culprit. The original test with
LPRng and CUPS may have been a different problem.
OK, that's something to think about on my side too. I now
have a material to investigate myself - after all I still
have an FC3 on other PC, so I can locate the faulty component.
I'll post back if I have some info.
Thanks for filling other bugs. They do not seem to cover the
fact that "lprm" asks for the password infinitely, or do they?
They don't. Just press 'enter' to get out of that. You need to run 'lprm -U
root ...' to get the right prompt for the default configuration -- I'm afraid
that's just the way CUPS works. :-/
Both hints work - thanks. And the fact that "lprm -U root"
doesn't actually stops anything, you have already mentioned
in your reports.
> to get the right prompt for the default configuration -- I'm afraid
> that's just the way CUPS works. :-/
So do you mean asking the password infinitely is not a bug??
I have difficulties beleiving this. Can you please explain?
In the mean time I have tracked the original bug down to the
parport_pc module. And as you seem to be its author, I guess
this is almost the right place to discuss it. :)
I don't know why, but when the DMA is enabled, the bug happens.
The problem is that the parport_pc module completely ignores
the irq and dma parameters, so even though I had "dma=none",
it still used dma=3. That's because the parport_pc_pnp_probe()
ignores the irqval and dmaval variables which store the
modparameters. Maybe also the other probe functions do ignore
these parameters either. Also, if the parameter is not specified,
the parport_parse_param() doesn't alter "*val". It looks like
the parse_parport_params() gets the "val" uninitialized in this
With a few hacks I made the thing to work, but maybe you can
code up some good fix?
Changing component to kernel. Please open a separate bug report for the
password prompt thing if you like -- perhaps we can get the SysV CUPS tools to
handle SIGINT or something.
OK, I filled the bugs
I think this bug can be closed because I was using not
the FC-supplied kernel.
Okay, closing as WORKSFORME since the as-shipped kernel presumably works.