Red Hat Bugzilla – Full Text Bug Listing
|Summary:||cups printing same page repeatedly|
|Product:||[Fedora] Fedora||Reporter:||Warren Togami <wtogami>|
|Component:||cups||Assignee:||Tim Waugh <twaugh>|
|Status:||CLOSED RAWHIDE||QA Contact:|
|Fixed In Version:||1.1.22-0.rc1.5||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2004-10-14 06:37:29 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:|
Description Warren Togami 2004-10-13 00:06:11 EDT
Description of problem: Print jobs seem to be printing in an infinite loop until all paper is gone. I am unable to cancel the jobs in gnome-printinfo, and soon later Bug #135499 happens. Meanwhile the printer continues to print the same page repeatedly. I was forced to stop service cups and clean out /var/spool/cups to stop it. I was able to reproduce this from the CUPS test page, and a full screen graphic printed from KView. Version-Release number of selected component (if applicable): cups-1.1.21-7
Comment 1 Warren Togami 2004-10-13 03:36:00 EDT
cups-1.1.22-0.rc1.1 Still broken with rawhide upgrade, along with Bug #135499 which I am increasingly suspecting is related somehow.
Comment 2 Warren Togami 2004-10-13 03:47:32 EDT
More Details: My laptop is configured to print using CUPS using IPP 1.0 to my Linksys print server. The print server is plugged in via USB to my Epsons Stylus C84 inkjet printer. This process below seems to linger. root 4829 4780 0 21:33 ? 00:00:00 ipp://172.31.16.3/printers/queue1 2 root testprint.ps 1 page-bottom=86 cpi=12 page-right=57 page-left=57 page-top=72 scaling=100 lpi=7 wrap
Comment 3 Tim Waugh 2004-10-13 04:06:38 EDT
Please alter /etc/cups/cupsd.conf and set LogLevel to debug2, then: /sbin/service cups stop >/var/log/cups/error_log /sbin/service cups start and make the problem occur again. Then please attach error_log. Thanks.
Comment 4 Warren Togami 2004-10-13 04:30:35 EDT
Created attachment 105121 [details] error_log * error_log from "service cups start" with an empty to queue. * CUPS test page from system-config-printer. I [12/Oct/2004:22:30:05 -1000] [Job 1] Printer is busy; retrying print job... This happened when the printer was about 30% done printing the page. Somehow cups thinks that the printer failed so it tries again?
Comment 5 Tim Waugh 2004-10-13 04:57:41 EDT
Please can you capture a tcpdump of this exchange? It will all be on TCP port 631. Thanks. (The raw pcap file will be best.)
Comment 6 Warren Togami 2004-10-13 05:04:48 EDT
Could you please provide me with the exact syntax for the tcpdump you want?
Comment 7 Tim Waugh 2004-10-13 05:08:33 EDT
tcpdump -n -o capture port 631 ought to do what I want I think.
Comment 8 Warren Togami 2004-10-13 05:31:20 EDT
Created attachment 105128 [details] capture.bz2 tcpdump -n port 631 -w capture tcpdump capture file (little-endian) - version 2.4 (Ethernet, capture length 96)
Comment 9 Tim Waugh 2004-10-13 05:58:31 EDT
Sorry, I meant to add '-s 0' to the command line (some of the captured frames are short). Can you try again with this please?: tcpdump -n -w capture -s 0 port 631 Thanks.
Comment 10 Warren Togami 2004-10-13 06:19:26 EDT
Created attachment 105135 [details] capture.bz2 with -s 0
Comment 11 Tim Waugh 2004-10-13 07:19:51 EDT
The problem comes from packet 1269, coming from the linksys server (a PSUS4 I think you said it was): In the 'attributes-natural-language' operation attribute we have this: 48 (Natural language tag) 00 1b (name length 27) 61 74 74 72 69 62 75 74 65 73 2d 6e 61 74 75 72 61 7c 2d 6c 61 6e 67 75 61 67 65 ('attributes-natural-language') 00 05 (value length 5) 02 45 00 07 6a (junk) In fact, the 6a is the first byte of 'job-uri', so I think the value length was intended to be 4 instead of 5. One can only guess what the intended value was! This indicates a bug in the LinkSys device. Had the length been 4 the rest would have decoded nicely, with a job ID and everything. Up to LinkSys to fix this really. We can't go second-guessing corrupt IPP packets. However, I can try to fix CUPS to fail better in this situation.
Comment 12 Tim Waugh 2004-10-13 07:34:50 EDT
Created attachment 105136 [details] cups-ippfail.patch Here is the patch I'd like to try.
Comment 14 Tim Waugh 2004-10-13 08:18:59 EDT
Please try cups-1.1.22rc1-0.rc1.2.
Comment 15 Tim Waugh 2004-10-13 09:55:01 EDT
(Upstream maintainer says he'd prefer a different fix, but he's looking at that.)
Comment 16 Warren Togami 2004-10-14 03:21:58 EDT
Bad news... E [13/Oct/2004:21:23:50 -1000] [Job 1] Print file was not accepted (server-error-service-unavailable)! And it attempts to print again.
Comment 17 Tim Waugh 2004-10-14 04:18:03 EDT
Please try cups-1.2.2-0.rc1.3.
Comment 18 Tim Waugh 2004-10-14 04:49:08 EDT
Er.. I mean cups-1.2.2-0.rc1.4. (This one'll work.)
Comment 19 Warren Togami 2004-10-14 05:19:05 EDT
Created attachment 105188 [details] error_log with .4
Comment 20 Warren Togami 2004-10-14 05:20:33 EDT
Created attachment 105189 [details] capture.bz2 with .4
Comment 21 Tim Waugh 2004-10-14 05:58:54 EDT
Please try cups-1.1.22-0.rc1.5. I really think this will fix it now.
Comment 22 Warren Togami 2004-10-14 06:11:24 EDT
Bad news... E [14/Oct/2004:00:09:02 -1000] [Job 1] Print file was not accepted (server-error-service-unavailable)! But it at least stops rather than attempting to print another page. But this is still bad, because that job is stuck in the queue as "Printing" and all subsequent jobs are stuck in "Pending" status. Should we just accept that the Linksys PSUS4 is just too buggy to be usable with IPP? The 'unable to cancel print job' part of this bug seems to be Bug #135499.
Comment 23 Warren Togami 2004-10-14 06:12:33 EDT
Hmm, not a great idea to accept this situation. cups really needs to handle bad IPP hardware more gracefully than "print until paper is exhausted" or "jam the print queue".
Comment 24 Tim Waugh 2004-10-14 06:37:29 EDT
Not a lot we can do about it -- the linksys device really is broken, and to throw the job away without knowing that it has hit paper would be a bit bold. I note that you tried forcing IPP/1.0 without any change in behaviour, so defaulting to that wouldn't help. We're at the end of the line for things that we can do in CUPS, really. Time for you to complain to your print server vendor.
Comment 25 Warren Togami 2004-11-10 20:35:26 EST
Almost a month after sending notice to Linksys. No response.
Comment 26 Shane Voss 2005-03-09 05:46:28 EST
I found a work-around for this elsewhere. By telling CUPS to use lpd://name.of.box/USB1 I was able to actually use the thing! (I don't think this lets Linksys off the hook, but it saved me returning it as useless/faulty.)
Comment 27 Rob Latham 2005-12-09 23:24:39 EST
googling for 'cups linksys' led me here, so i just wanted to share my experience. The name of the linksys PSUS4 (firmware version 6033) lpd spool was L1. i.e. the CUPS uri should look like lpd://192.168.XX.YY/L1