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.
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.