Bug 214280 - printing on Laser Jet 4L does not work with cups
printing on Laser Jet 4L does not work with cups
Status: CLOSED WORKSFORME
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
6
All Linux
medium Severity high
: ---
: ---
Assigned To: Kernel Maintainer List
Brian Brock
:
Depends On:
Blocks: FC6Update
  Show dependency treegraph
 
Reported: 2006-11-06 16:14 EST by Stas Sergeev
Modified: 2007-11-30 17:11 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-11-11 05:36:23 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
cupsd.conf (2.41 KB, text/plain)
2006-11-06 16:14 EST, Stas Sergeev
no flags Details
printer.ppd (18.19 KB, text/plain)
2006-11-06 16:16 EST, Stas Sergeev
no flags Details
/etc/printcap (171 bytes, text/plain)
2006-11-06 16:36 EST, Stas Sergeev
no flags Details
ljet4test.prn (417.88 KB, application/octet-stream)
2006-11-10 06:05 EST, Tim Waugh
no flags Details

  None (edit)
Description Stas Sergeev 2006-11-06 16:14:45 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
single problem.
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.

How reproducible:
Always!

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.
  
Actual results:
Madness - all the paper spoiled, PC rebooted, printer restarted,
the user is completely crazy!

Expected results:
I only wanted to print a single page...

Additional info:
Sorry for the emotional posting. :) Let me know if the additional
info is needed.
Comment 1 Stas Sergeev 2006-11-06 16:14:45 EST
Created attachment 140507 [details]
cupsd.conf
Comment 2 Stas Sergeev 2006-11-06 16:16:54 EST
Created attachment 140509 [details]
printer.ppd
Comment 3 Stas Sergeev 2006-11-06 16:36:38 EST
Created attachment 140512 [details]
/etc/printcap
Comment 4 Stas Sergeev 2006-11-06 16:41:31 EST
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).
Comment 5 Tim Waugh 2006-11-10 06:05:42 EST
Created attachment 140879 [details]
ljet4test.prn

This file is the output of:

gs -q -dBATCH -dPARANOIDSAFER -dNOPAUSE -sDEVICE=ljet4 \
  -sPAPERSIZE=a4 -sOutputFile=ljet4test.prn \
  /usr/share/cups/data/testprint.ps

Please try printing it with 'lp -oraw -dprinter ljet4test.prn' and let me know
if you get a test page.  Thanks.
Comment 6 Stas Sergeev 2006-11-10 13:24:45 EST
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
paper-spoiling scenario.
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
lprng worked...
Comment 7 Tim Waugh 2006-11-10 13:52:02 EST
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.
Comment 8 Stas Sergeev 2006-11-10 14:01:32 EST
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?
Comment 9 Tim Waugh 2006-11-10 14:11:29 EST
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. :-/
Comment 10 Stas Sergeev 2006-11-10 16:24:01 EST
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
case.
With a few hacks I made the thing to work, but maybe you can
code up some good fix?
Comment 11 Tim Waugh 2006-11-10 18:36:08 EST
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.
Comment 12 Stas Sergeev 2006-11-11 03:59:33 EST
OK, I filled the bugs
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=215133
http://bugme.osdl.org/show_bug.cgi?id=7491
http://bugme.osdl.org/show_bug.cgi?id=7492

I think this bug can be closed because I was using not
the FC-supplied kernel.
Comment 13 Tim Waugh 2006-11-11 05:36:23 EST
Okay, closing as WORKSFORME since the as-shipped kernel presumably works.

Note You need to log in before you can comment on or make changes to this bug.