Bug 214280
Summary: | printing on Laser Jet 4L does not work with cups | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Stas Sergeev <stsp2> | ||||||||||
Component: | kernel | Assignee: | Kernel Maintainer List <kernel-maint> | ||||||||||
Status: | CLOSED WORKSFORME | QA Contact: | Brian Brock <bbrock> | ||||||||||
Severity: | high | Docs Contact: | |||||||||||
Priority: | medium | ||||||||||||
Version: | 6 | CC: | twaugh, wtogami | ||||||||||
Target Milestone: | --- | ||||||||||||
Target Release: | --- | ||||||||||||
Hardware: | All | ||||||||||||
OS: | Linux | ||||||||||||
Whiteboard: | |||||||||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||||||||
Doc Text: | Story Points: | --- | |||||||||||
Clone Of: | Environment: | ||||||||||||
Last Closed: | 2006-11-11 10:36:23 UTC | Type: | --- | ||||||||||
Regression: | --- | Mount Type: | --- | ||||||||||
Documentation: | --- | CRM: | |||||||||||
Verified Versions: | Category: | --- | |||||||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||||||
Embargoed: | |||||||||||||
Bug Depends On: | |||||||||||||
Bug Blocks: | 207681 | ||||||||||||
Attachments: |
|
Description
Stas Sergeev
2006-11-06 21:14:45 UTC
Created attachment 140507 [details]
cupsd.conf
Created attachment 140509 [details]
printer.ppd
Created attachment 140512 [details]
/etc/printcap
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]
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.
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... 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
case.
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 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. Okay, closing as WORKSFORME since the as-shipped kernel presumably works. |