Created attachment 819865 [details] Troubleshoot report Description of problem: When printing to a USB printer that has no paper loaded to start with, the output is wrong. Version-Release number of selected component (if applicable): cups-1.7.0-4.fc20.x86_64 hpijs-3.13.9-2.fc20.x86_64 How reproducible: Every time. Steps to Reproduce: 1.Take out the paper. 2.Print something. 3.Wait until the printer has stopped making noises. 4.Put the paper back in and tell it to continue printing. Actual results: I'll scan it in.
Created attachment 819870 [details] bad output
Created attachment 819871 [details] Original document
It's probably to do with this: D [05/Nov/2013:16:00:48 +0000] [Job 31] Got USB transaction timeout during write. I guess the usb backend handles this badly.
Also happens with gutenprint-cups driver, so this is not driver-specific.
Doesn't seem to happen with the hp backend from hplip, only the usb backend from cups.
Turning off the read channel (by adding a "unidir" quick line to /usr/share/cups/usb/org.cups.usb-quirks) has no effect. The filter sends the same data in both fail and success cases, so the problem is definitely in the usb backend.
I can't see anything wrong with the usb-libusb.c code. Can anyone else reproduce the problem?
Comparison with the hp backend shows the reason it is unaffected: libhpmud's musb backend uses a libusb bulk transfer timeout of 72 hours, compared with the CUPS usb backend's timeout of 60 seconds.
To reproduce this: set up a queue using the 'usb' backend (i.e. system-config-printer reports the Device URI starts with 'usb://'). If using the 'hp' backend, click on the 'Change...' button next to Device URI and select the 'USB' connection as opposed to 'HPLIP'. Remove paper from the printer. Print the document in comment #2. After the printer stops making noise from realising there is no paper, wait for 2 minutes. Now put paper in the tray and allow it to continue.
Created attachment 830313 [details] cups-usb-timeout.patch (workaround) Here's a workaround that avoids the problem for me.
cups-1.7.0-6.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/cups-1.7.0-6.fc20
In fact, a timeout of 0 would be even better.
Reported upstream: http://lists.linuxfoundation.org/pipermail/printing-architecture/2013/002815.html
Package cups-1.7.0-6.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing cups-1.7.0-6.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-22353/cups-1.7.0-6.fc20 then log in and leave karma (feedback).
cups-1.7.0-6.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
cups-1.6.4-5.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.