Brother HL-1440 printing extra page with PJL codes

Can you follow the instructions on https://wiki.ubuntu.com/DebuggingPrintingProblems, especially of the sections "Reporting bugs", "CUPS error_log", and (if it is not already done with your attachment on comment #1) "Capturing print job data"? Thanks.

Error_log attached

Bug report attached. I couldn't figure out how to get it to report to this bug number, so I saved it to a file.

LibreOffice file that was used to generate the error. Printing from other sources (e.g., printing a web page from Firefox) generates the same problem.

Can you blacklist the usblp kernel module by the following commands in a terminal window:

sudo -s
echo blacklist usblp > /etc/modprobe.d/blacklist-usblp.conf
rmmod usblp
exit

Then clean up the queue with the command

cancel -a

Turn off and turn on your printer again. Then try to print again. Does it work now?

Scan of error printout attached.

Will try the suggested blacklist this evening (after 6:00 PST) and report back. Thanks.

After having done the blacklisting test and reported here, undo the blacklisting by removing /etc/modprobe.d/blacklist-usblp.conf and turning off and turning on your printer again. Then please add my PPA to your system as described on

https://launchpad.net/~till-kamppeter/+archive/ppa

and update your system. This should give you an update of the CUPS packages (version 1.5.2-9ubuntu1.1~ppa2). Please cancel all jobs and turn off and turn on your printer again. Then try whether your problem gets solved.

Blacklisted usblp as instructed above. This appears to be successful. I can't be 100% certain, as the problem was intermittent, but it has not reappeared after several tests.

Should I undo the blacklisting, since it worked? What is the advantage of using the updated CUPS package instead? Or will this update make it into the main repositories at some time?

We want to avoid generally blacklisting the usblp module as there are some proprietary drivers from printer manufacturers which need it. Therefore we are trying to make CUPS working without blacklisting the module and if we succeed we will issue the resulting change as an update. Therefore I ask you to undo the blacklisting and to test the package from my PPA.

If the problem persists, blacklist the module again so that you can print.

Got it. I will test this evening, and let you know the results. And thanks!

Unsuccessful. I was able to remove the blacklist and to update the CUPS packages to 1.5.2-9ubuntu1.1~ppa2, but under that the printing problem still exists.

I am re-blacklisting for now, and will await further instructions. Thanks again.

Please remove the blacklist again and try uninstalling system-config-printer-udev by entering the following command in a terminal window:

sudo dpkg -P --force-depends system-config-printer-udev

Then remove all jobs with

cancel -a

and turn off and turn on your printer. Now try to print. Does it work normally now? Can you print an arbitrary number of jobs?

If this still does not help, try uninstalling foo2zjs:

sudo dpkg -P --force-depends foo2zjs

Remove all jobs, turn off and turn on the printer again and try whether this helps.

Uninstalling system-config-printer-udev was unsuccessful: still prints the extra page with PJL codes.

Uninstalling foo2zjs was unsuccessful: returned the message:
dpkg: warning: there's no installed package matching foo2zjs

Sorry, the foo2zjs package got renamed. Do

sudo dpkg -P --force-depends printer-driver-foo2zjs

Remove all jobs, turn off and turn on the printer again and try whether this helps.

Restore your system with

sudo apt-get install -f

Still unsuccessful. The package was removed, but it still prints the extra page.

Also, sudo apt-get install -f does not appear to have reinstalled any of the removed packages:
Reading package lists... Done
Building dependency tree
Reading state information... Done
0 upgraded, 0 newly installed, 0 to remove and 3 not upgraded.

Please undo the blacklisting by removing /etc/modprobe.d/blacklist-usblp.conf and turning off and turning on your printer again. Then please update from my PPA to get the CUPS packages version 1.5.2-9ubuntu1.1~ppa3. Please cancel all jobs and turn off and turn on your printer again. Then try whether your problem gets solved.

1.5.2-9ubuntu1.1~ppa3 loaded, but did not solve the problem. Still printing out the extra page.

This bug was fixed in the package cups - 1.5.3-1

---------------
cups (1.5.3-1) unstable; urgency=low

  [ Till Kamppeter ]
  * New upstream release
     - Numerous fixes on IPP (LP: #945028, LP: #973270, LP: #990734,
       LP: #992468, LP: #992982, LP: #1000172, LP: #1000758)
     - USB backend based on the maintained libusb 1.0.x with support for
       bi-directional communication
     - Fixes on SNMP-based supply level reporting
     - PostScript prtinter auto-configuration reliable now
     - Several fixes on PostScript, SSL, authenticated printing, and
       networking issues
  * debian/patches/ipp-fixes-1.5.3.patch,
    debian/patches/fix-empty-translations.patch,
    debian/patches/ppd-cache-fix-crash.patch,
    debian/patches/commandtops-make-robust-against-broken-postscript.patch,
    debian/patches/cups-polld-reconnect.patch,
    debian/patches/usb-backend-libusb-1.0.patch,
    debian/patches/usb-backend-backchannel-support.patch: Removed patches which
    got included upstream.
  * debian/patches/fix-supply-level-computation-for-percent-supply-unit.patch,
    debian/patches/fix-supply-levels-for-enumerated-prtmarkersupplieslevel.patch,
    debian/patches/fix-status-reports-when-supply-levels-grow.patch,
    debian/patches/add-status-reports-for-full-waste-trays-and-cleaner-unit-eol.patch,
    debian/patches/match-marker-colorants-which-use-non-standard-string.patch,
    debian/patches/truncate-marker-supply-names-at-comma.patch: Removed supply
    level report fixes. This got solved differently upstream.
  * debian/patches/do-not-suppress-inputslot-setting-with-empty-ap-d-inputslot.patch:
    Removed, problem solved differently upstream.
  * debian/patches/cups-avahi.patch: Manually regenerated to adapt to upstream
    changes.
  * debian/patches/ppd-poll-with-client-conf.patch,
    debian/patches/colord-support.patch,
    debian/patches/airprint-support.patch,
    debian/patches/no-conffile-timestamp.patch,
    debian/patches/drop_unnecessary_dependencies.patch,
    debian/patches/read-embedded-options-from-incoming-postscript-and-add-to-ipp-attrs.patch,
    debian/patches/show-compile-command-lines.patch: Refreshed using quilt.
  * debian/patches/usb-backend-busy-loop-fix.patch: Correct loops to repeat
    claiming interfaces on USB devices when they are busy. Before, hitting busy
    state made the device opening function error out without comment
    (LP: #987485).
  * debian/patches/usb-backend-detach-usblp-earlier-crash-guards.patch: Protect
    against crashes by checking error codes of libusb functions (LP: #997040)
    and detach usblp kernel module in an earlier stage when opening a device
    (LP: #987485, LP: #997040).
  * debian/patches/usb-backend-initialize-usblp-attached-state.patch: Initialize
    usblp_attached field in printer data structure to assure that detaching
    and re-attaching the usblp kernel module is always done correctly
    (LP: #902535, LP: #959676, LP: #960666, LP: #987485,
    LP: #995111, LP: #997040, LP: #1000253, LP: #1001028).
  * debian/patches/install-sh-remove-bashism.patch: Removed bashism.
  * debian/local/blacklist-cups-usblp.conf, debian/cups.postinst,
    debian/cups.install: Bla...

New CUPS package with the following (and some addtional) fixes uploaded to precise-proposed (proposed updates for 12.04 (Precise)):

 - Crash and busy loop fixes on the USB backend
 - "usblp" kernel module blacklisted again as it also causes problems with the new USB backend
 - Lots of fixes on the IPP backend and also on the IPP server part in the CUPS daemon
 - Other networking issues

These fixes should address most of the bugs reported shortly after the release of Precise, especially the problems with USB printing and network printing. As soon as the package is approved and made available for testing and additional comment with installation instructions will get posted here. Please test the new package then and report here whether this solves your problems. We will decide on the results whether the package will be made an official update for Precise.

Please remove/cancel all jobs and turn off and turn on your printer before testing.

debdiff attached.

Hello Gary, or anyone else affected,

Accepted cups into precise-proposed. The package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

Confirmed. I was able to install the proposed package (using slightly different method than shown in the link), and the printing error is no longer reproduced. Thanks again to everyone working on this.

Thank you for testing, marking bug as verified.

I also confirm that cups in precise-proposed fixes the similar problem I was having (printing .ps -> PJL headers + blank page) in https://bugs.launchpad.net/bugs/1005857 .

This bug was fixed in the package cups - 1.5.3-0ubuntu1

---------------
cups (1.5.3-0ubuntu1) precise-proposed; urgency=low

  [ Till Kamppeter ]
  * New upstream release
     - Numerous fixes on IPP (LP: #945028, LP: #973270, LP: #990734,
       LP: #992468, LP: #992982, LP: #1000172, LP: #1000758)
     - USB backend based on the maintained libusb 1.0.x with support for
       bi-directional communication
     - Fixes on SNMP-based supply level reporting
     - PostScript prtinter auto-configuration reliable now
     - Several fixes on PostScript, SSL, authenticated printing, and
       networking issues
  * debian/patches/ipp-fixes-1.5.3.patch,
    debian/patches/fix-empty-translations.patch,
    debian/patches/ppd-cache-fix-crash.patch,
    debian/patches/commandtops-make-robust-against-broken-postscript.patch,
    debian/patches/cups-polld-reconnect.patch,
    debian/patches/usb-backend-libusb-1.0.patch,
    debian/patches/usb-backend-backchannel-support.patch: Removed patches which
    got included upstream.
  * debian/patches/fix-supply-level-computation-for-percent-supply-unit.patch,
    debian/patches/fix-supply-levels-for-enumerated-prtmarkersupplieslevel.patch,
    debian/patches/fix-status-reports-when-supply-levels-grow.patch,
    debian/patches/add-status-reports-for-full-waste-trays-and-cleaner-unit-eol.patch,
    debian/patches/match-marker-colorants-which-use-non-standard-string.patch,
    debian/patches/truncate-marker-supply-names-at-comma.patch: Removed supply
    level report fixes. This got solved differently upstream.
  * debian/patches/do-not-suppress-inputslot-setting-with-empty-ap-d-inputslot.patch:
    Removed, problem solved differently upstream.
  * debian/patches/cups-avahi.patch: Manually regenerated to adapt to upstream
    changes.
  * debian/patches/ppd-poll-with-client-conf.patch,
    debian/patches/colord-support.patch,
    debian/patches/airprint-support.patch,
    debian/patches/no-conffile-timestamp.patch,
    debian/patches/drop_unnecessary_dependencies.patch,
    debian/patches/read-embedded-options-from-incoming-postscript-and-add-to-ipp-attrs.patch,
    debian/patches/show-compile-command-lines.patch: Refreshed using quilt.
  * debian/patches/usb-backend-busy-loop-fix.patch: Correct loops to repeat
    claiming interfaces on USB devices when they are busy. Before, hitting busy
    state made the device opening function error out without comment
    (LP: #987485).
  * debian/patches/usb-backend-detach-usblp-earlier-crash-guards.patch: Protect
    against crashes by checking error codes of libusb functions (LP: #997040)
    and detach usblp kernel module in an earlier stage when opening a device
    (LP: #987485, LP: #997040).
  * debian/patches/usb-backend-initialize-usblp-attached-state.patch: Initialize
    usblp_attached field in printer data structure to assure that detaching
    and re-attaching the usblp kernel module is always done correctly
    (LP: #902535, LP: #959676, LP: #960666, LP: #987485,
    LP: #995111, LP: #997040, LP: #1000253, LP: #1001028).
  * debian/patches/install-sh-remove-bashism.patch: Removed bashism.
  * debian/local/blacklist-cups-usblp.conf, debian/cups.postinst,
    de...

Special thanks to Till & Gary. Yes, it works. Until you fixed this, I must have almost wasted a tree. :)

I was just testing, but you're welcome. Glad to hear that the tree I wasted saved someone else's.

I want to ask you to do another test, so that we can find out whether we can stop blacklisting the usblp kernel module:

I have uploaded a modified CUPS package to my PPA now. Please add my PPA to your system as described on

https://launchpad.net/~till-kamppeter/+archive/ppa

in the section "Adding this PPA to your system" and then install the new CUPS package, preferably by simply doing a full system update. The CUPS version must be 1.5.3-0ubuntu2~ppa2.

Now turn off and turn on your USB printer and re-plug the USB (with the printer turned on). Try to print. does it work now?

Independent whether printing works for you now or not, reactivate the usblp kernel module by running the following two commands in a terminal window:

sudo mv /etc/modprobe.d/blacklist-cups-usblp.conf ~
sudo modprobe usblp

Turn off and turn on your printer again and re-plug the USB (with the printer turned on). Try to print again. does it also work now?

If it works, you are done. If it worked in the first test and stopped in the second, return to the configuration of the first test by running the following commands in a terminal window:

sudo mv ~/blacklist-cups-usblp.conf /etc/modprobe.d/
sudo rmmod usblp

Still does not work without blacklist. Successful download and install of 1.5.3-0ubuntu2~ppa2, which works while the usblp module is blacklisted, but as soon as I turn off the blacklist the old problem recurs.

My CUPS upload to my PPA (1.5.3-0ubuntu2~ppa2) is broken. In some hours the new version 1.5.3-0ubuntu2~ppa3 will be available. Please wait for this new version, update your system then, check whether you actually have 1.5.3-0ubuntu2~ppa3 and then do the tests of comment #30 again.

Next testing round to get the USB backend working: In some hours cups 1.5.3-0ubuntu2~ppa4 will be available on my PPA, update your system to get it, check whether you actually got it, and do the tests of comment #30 again. For each failed test attach the error_log and /var/log/syslog, thanks.

New version uploaded which does not do an initial reset on the printer (~ppa5). please do the same tests with this version.

Well, I spaced on ~ppa3 (sorry). Started testing ~ppa4 (failed), when I noticed that ~ppa5 was available. Attached file relates to ~ppa5, which still produces the error output.

The attachment is the last part of /var/log/syslog. There was no /var/log/cups/error_log generated (I deleted the old one before testing the printer; hope that didn't mess it up).

Gary, can you restart CUPS via

sudo restart cups

to get logging working again and try again? Thanks.

Do you get the error output with ~ppa5 only with the usblp module active or always? Can you print with ~ppa5 when the usblp module is blacklisted?

error_log file is attached. It appears to have restarted when I rebooted this morning.

So far with all versions (including ~ppa5), printing works correctly with usblp blacklisted, but the error persists when it is active.

Next testing round: cups 1.5.3-0ubuntu2~ppa7 is uploaded to my PPA now and this respects uni-directional devices and gives some more messages in error_log.

Please repeat the tests with it (with and without blacklisting usblp) and attach syslog and error_log of the failing tests.

In addition, you can try to force uni-directional mode by

lpadmin -p <queue> -o usb-unidir-default=true

and restore to normal mode via

lpadmin -p <queue> -o usb-unidir-default=false

For <queue> the name of your print queue has to be inserted.

Please repeat your tests with forced uni-directional mode.

Loaded ~ppa7 and tested with and without blacklist, and with and without forced uni-directional mode. I was not able to reproduce the error. Therefore, no error file to attach.

Does this mean that this version fixed the bug perfectly for you? Especially that you can print without need of blacklisting the kernel module and without need of forced uni-directional mode?

Yes, it appears to be fixed. The bug was always intermittent--that is, it would appear when printing some things, and not with others, even things that seem quite similar. However, I have been using one particular document as a test which regularly reproduced the error, and it does not reproduce with this latest version.

If something else reproduces the error, I will report back.

I think this is a successful fix. I have attempted printing several different documents with the blacklist removed, and have not been able to reproduce the error. Thanks again!

Reopening bug as we will replace the workaround (blacklisting usblp kernel module) by the real fix (current PPA version of CUPS).

Gary, thank you very much for testing!

Well, the error has recurred today. This time, the PJL codes appeared in the middle of the document being printed. Copy of error_log is attached (edited to only include the entries since I rebooted).

Then, as I was writing this, the printer suddenly started up again, and reprinted the page (correclty) that previously had the error on it.

Unfortunately, while I'm happy to continue testing, I am no longer confident that I can reproduce the error on request, so it may be difficult to confirm when it is fixed.

Gary, Is the frequency of bad printouts lower than before, higher, or is there no perceivable difference?

It is less frequent.

Prior to this most recent version of CUPS, I was able to reproduce the error using a particular word processing document. If I printed this letter twice, it would print once, then print the page of PJL codes. That has stopped.

A few days later, I tried to print a different letter, and got similar symptoms. Just now trying to print the second letter, I noticed that the second copy gets listed in the print queue as "held," and then when released I get a page of PJL codes (similar to, but not identical to, the old ones) and then the second copy.

I have looked into the source code of the usblp module and there is an exception rule exactly for this printer (Brother HL-1440) because it has problems with bi-directional communication. Try forcing uni-directional with

lpadmin -p <printer> -o usb-unidir-default=true

Does this work for you?

Uni-directional seems to work. I can no longer reproduce the error with either test document.

Gary, thanks. I think I will overtake the printer quirk rules from the usblp kernel module into the USB CUPS backend.

Not sure I understood that, but I'm glad it helped!

Can you all try cups 1.5.3-0ubuntu2~ppa12 from my PPA? This could solve the problem. Test it, with and without the blacklisting of usblp and with and without forcing uni-directional mode and tell whether it works. Especially I want to know whether it actually works without blacklisting and without forcing uni-directional now.

Independent whether it works, please attach your error_log.

Installed ~ppa12

Tested as follows:
no blacklist, no unidirectional = error
blacklist, no unidirectional = no error
no blacklist, unidirectional = error

error_log attached

Gary, does this mean that you are back to the initial state of before I touched this, meaning that without blacklisting usblp you get the error of the initial posting solidly, with every document, and with blacklisting usblp all works fine for you?

Can you run the command

sudo chmod -x /lib/udev/udev-configure-printer

and after that do the tests again?

Gary, can you do the following additional tests:

Update to cups 1.5.3-0ubuntu2~ppa13, make sure that the usblp module is not blacklisted and that the module is loaded.

Now run

lpadmin -p <queue> -o usb-no-reattach-default=true

to make the USB backend not reattach the usblp kernel module after a print job. Does this solve your problem?

Try with both Plug'n'Print active

sudo chmod +x /lib/udev/udev-configure-printer

and suppressed

sudo chmod -x /lib/udev/udev-configure-printer

Get back to the old state via

lpadmin -p <queue> -R usb-no-reattach

Always replace "<queue>" by your print queue name.

Try also manually reloading the usblp module via "sudo rmmod usblp; sudo modprobe usblp" after a job has completely finished (all pages have come out) and before sending the next job.

Installed ~ppa13.
Confirmed usblp not blacklisted and module loaded; uni-directional force off. Test print still showed error.
Turned on no-reattach mode. Test printed with no error.
Plug'n'Print active; still no error.
Plug'n'Print suppressed; still no error.
Manually reloaded usblp module; still no error.

error_log attached.

Gary, so it seems that I have finally reached the state of having all info to fix the problem for your printer model. I will change the exception (quirk) rule for your printer in the USB CUPS backend so that the usblp kernel module does not get re-attached after a print job has finished. After that the HL-1440 will just work with the new USB backend. Thank you very much for all the testing.

I will issue the changes also for Ubuntu Precise (stable release update, SRU), so please stay tuned as you will have to test the proposed SRU package for Precise as soon as it gets available for testing.

Gary, can you try cups 1.5.3-0ubuntu2~ppa14 from my PPA, without blacklisting the kernel module and turning off all special options. Before starting the test run the commands

cancel -a
sudo chmod +x /lib/udev/udev-configure-printer
lpadmin -p <queue> -R usb-no-reattach
lpadmin -p <queue> -R usb-unidir
mv /etc/modprobe.d/blacklist-cups-usblp.conf ~
sudo rmmod usblp
sudo modprobe usblp

then turn off and turn on your printer. Does your printer now work without any problems?

I'm happy to continue contributing tests to this bugfix. Keeping in mind that I am uncertain whether my test document will always display the bug:

Installed ~ppa14
Ran suggested commands
Turned printer off/on, and unplugged/replugged USB cable

Test documents printed with no error. If the error creeps back in at a future date, I'll report back. Thanks once again for all your time and effort!

Gary, thank you. So the USB backend in current state seems to work for you.

Gary, please stay tuned as in the next days I will call for testing the poroposewd update for Precise. The test feedback is required for getting the package be an official update.

This bug was fixed in the package cups - 1.5.3-3

---------------
cups (1.5.3-3) experimental; urgency=low

  * debian/patches/usb-backend-further-enhancements.patch: Added latest
    development work on the libusb-based USB backend:
     - Support for uni-directional devices, both protocol-1 devices and
       devices where no read endpoint is found.
     - Soft reset specific to the "PRINTER" device class. This allows a
       reset without reconnecting.
     - When closing the device, it will also get reset to its original
       configuration, before re-attaching the usblp kernel module. Do not
       restore the configuration setting when the old configuration was zero,
       as zero means "unconfigured".
     - Added option "usb-unidir" to force the backend into uni-directional
       mode. This allows to work around problems with bi-di communications,
       especially also a delay at the end of the job caused by closing the
       read channel (happens only for some devices, LP: #1001028). Also
       useful for debugging.
     - Added the quirk management of the usblp kernel module. So the problems
       of all printers which were worked around in the kernel module are
       also worked around in the libusb-based CUPS backend now (LP: #1000253).
     - Added new quirk type to quirk manager: Printers for which the usblp
       kernel module should not get reattached after printing a job
       (LP: #1000253, perhaps also LP: #995111).
     - Added additional quirks for the Prolific Technology USB -> Parallel
       adapter, as the adapter needs uni-directional mode to be forced and
       also does not like re-attaching the usblp kernel module after the
       job (last third of last page gets cut off, re-attaching probably
       sends a reset to the printer while there is still data to be printed
       in the printer's internal buffer (LP: #987485).
     - Added the command line option "usb-no-reattach". With the option set
       the usblp kernel module does not get reattached after a job has been
       printed. Some printers cut off the end of the job or even crash by
       re-attaching the module. This is a development/debug mode to test
       whether re-attaching was the culprit of a problem. Users should
       report such issues so that their printers can get added to the quirk
       list.
     - Some extra debug messages.
     - Added a missing libusb_free_config_descriptor().
    This patch is submitted upstream as CUPS STR #4128.
  * debian/patches/add-ipp-backend-of-cups-1.4.patch, debian/cups.config,
    debian/cups.lintian-overrides, debian/cups.postinst, debian/cups.prerm,
    debian/cups.templates: Add the IPP backend of CUPS 1.4.x to the current
    CUPS package as independent backend "ipp14". Some devices (like the
    LiveBox 2) do not work with the current IPP backend (LP: #945028,
    LP: #973270, LP: #990734, LP: #992468, LP: #992982).
  * debian/patches/ipp-backend-cups-1.5.4-fixes.patch: Backported latest
    fixes on the IPP backend from upstream.
  * debian/local/blacklist-cups-usblp.conf, debian/cups.postinst,
    debian/cups.install, debian/cups.preinst, debian/cups.postinst,
    debian/cups.postrm:...

Bug appeared in an unusual situation, as follows:

I was printing two jobs, and the printer ran out of paper during the first job. After adding paper and pressing the button to continue, the first job finished without incident. However, the first page of the second job (which was already queued when the paper ran out) had the PJL codes on it.

Reprinting the second job worked normally, even without making any changes.

Forgot to add the error_log

Uploaded proposed fix for Precise to the precise-proposed package repository. As soon as it gets approved we will post another comment here with instructions how to install and test it. Please test it that as your feedback here is required for making the package an official update.

For the SRU team: debdiff attached to bug 945028: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/945028/+attachment/3219011/+files/cups_1.5.3-0ubuntu1_1.5.3-0ubuntu2.debdiff

SRU is for bug 945028, bug 973270, bug 987485, bug 997040, bug 1000253, and bug 1001028.

Note, the removal of the blacklisting only works if you upgrade from stock Precise or from the first SRU of CUPS. It does not work when upgrading from my PPA. In this case run

sudo rm /etc/modprobe.d/blacklist-cups-usblp.conf

and turn off and turn on the printer.

Please use "In progress" instead of "Fix commited" as the status for bugs that have a fix in the queue but not yet accepted to -proposed, otherwise it's making our reports quite confusing...
The SRU script will automatically changed it to "Fix commited" when it lands in -proposed and then "Fix released" when it lands in -updates.

Thanks

Hello Gary, or anyone else affected,

Accepted cups into precise-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/cups/1.5.3-0ubuntu2 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please change the bug tag from verification-needed to verification-done. If it does not, change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Installed 1.5.3-0ubuntu2 from precise-proposed.
Cycled printer off/on & unplugged/replugged USB cable.
Confirmed usblp module was not blacklisted and was loaded.
Tested printer with files that had previously generated errors in testing.
(LibreOffice Writer initially identified the printer as "generic printer" instead of "HL-1440-series" and seemed to be printing with a slightly different font. Closing and restarting LibreOffice Writer eliminated this problem, so I presume it was related to the fact that it was open while I did the update.)
No error was generated.
Changing status to verification-done, as requested
error_log attached just for old time's sake.

Gary, thank you very much for testing.

You're more than welcome; I'm happy to have been of assistance. And thank you for all your hard work in giving me things to test.

The verification of this Stable Release Update has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regresssions.

This bug was fixed in the package cups - 1.5.3-0ubuntu2

---------------
cups (1.5.3-0ubuntu2) precise-proposed; urgency=low

  * debian/patches/usb-backend-further-enhancements.patch: Added latest
    development work on the libusb-based USB backend:
     - Support for uni-directional devices, both protocol-1 devices and
       devices where no read endpoint is found (LP: #1000253, LP: #1001028).
     - Soft reset specific to the "PRINTER" device class. This allows a
       reset without reconnecting.
     - When closing the device, it will also get reset to its original
       configuration, before re-attaching the usblp kernel module. Do not
       restore the configuration setting when the old configuration was zero,
       as zero means "unconfigured".
     - Added option "usb-unidir" to force the backend into uni-directional
       mode. This allows to work around problems with bi-di communications,
       especially also a delay at the end of the job caused by closing the
       read channel (happens only for some devices, LP: #1001028). Also
       useful for debugging.
     - Added the quirk management of the usblp kernel module. So the problems
       of all printers which were worked around in the kernel module are
       also worked around in the libusb-based CUPS backend now (LP: #1000253).
     - Added new quirk type to quirk manager: Printers for which the usblp
       kernel module should not get reattached after printing a job
       (LP: #1000253).
     - Added additional quirks for the Prolific Technology USB -> Parallel
       adapter, as the adapter needs uni-directional mode to be forced and
       also does not like re-attaching the usblp kernel module after the
       job (last third of last page gets cut off, re-attaching probably
       sends a reset to the printer while there is still data to be printed
       in the printer's internal buffer, LP: #987485).
     - Added the command line option "usb-no-reattach". With the option set
       the usblp kernel module does not get reattached after a job has been
       printed. Some printers cut off the end of the job or even crash by
       re-attaching the module. This is a development/debug mode to test
       whether re-attaching was the culprit of a problem. Users should
       report such issues so that their printers can get added to the quirk
       list.
     - Do a printer reset after each job, this makes the Prolific USB ->
       Parallel adapter finally work (LP: #987485) and makes it unnecessary
       to blacklist the usblp kernel module for some printers (LP: #997040).
     - Some extra debug messages.
     - Added a missing libusb_free_config_descriptor().
    This patch is submitted upstream as CUPS STR #4128.
  * debian/patches/add-ipp-backend-of-cups-1.4.patch, debian/cups.config,
    debian/cups.lintian-overrides, debian/cups.postinst, debian/cups.prerm,
    debian/cups.templates: Add the IPP backend of CUPS 1.4.x to the current
    CUPS package as independent backend "ipp14". Some devices (like the
    LiveBox 2 and some Samsung printers) do not work with the current IPP
    backend (LP: #945028, LP: #973270).
  * debian/local/blacklist-cups-usblp.co...

I regret to say that after a recent package update, this problem reappeared for me. I have
the cups 1.5.3-0ubuntu4 package installed. Applying the patches in comment #59
does work around the problem however.

I re-checked after the last comment, and the problem has not reappeared on my system. I got fully updated before testing, and am also running cups 1.5.3-0ubuntu4.

Oddhack, can you tell the exact steps which you did to solve the problem for you?

Everyone still having this problem, an you run the command

lsusb

in a terminal window and post the output here.

Then do the following:

In a terminal window, run the command

lpadmin -p <printer> -o usb-unidir-default=true

with <printer> being the name of your printer as displayed by the
"lpstat -p" command.

Now turn off and turn on your printer, then try to print several jobs.
Does this solve the problem?

If not,

run

lpadmin -p <printer> -R usb-unidir-default

and then

lpadmin -p <printer> -o usb-no-reattach-default=true

Again, turn off and turn on your printer, then try to print several
jobs. Does this solve the problem?

If not, try

lpadmin -p <printer> -o usb-no-reattach-default=true
lpadmin -p <printer> -o usb-unidir-default=true

and turn off and turn on your printer, then try to print several jobs.
Does this solve the problem?

Please tell what works for you.

If nothing works, reset all to defaults via

lpadmin -p <printer> -R usb-no-reattach-default
lpadmin -p <printer> -R usb-unidir-default

Till @#77: Initially I tried just

lpadmin -p <queue> -o usb-unidir-default=true

which did not change anything. Then I applied the full set of commands in comment #59:

cancel -a
sudo chmod +x /lib/udev/udev-configure-printer
lpadmin -p <queue> -R usb-no-reattach
lpadmin -p <queue> -R usb-unidir
mv /etc/modprobe.d/blacklist-cups-usblp.conf ~
sudo rmmod usblp
sudo modprobe usblp

and at that point I could print successfully. Re lsusb:

Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 002: ID 046d:c040 Logitech, Inc. Corded Tilt-Wheel Mouse
Bus 004 Device 004: ID 04f9:000e Brother Industries, Ltd HL-1450 series
Bus 005 Device 002: ID 046d:c52e Logitech, Inc.

FWIW, I just updated to Ubuntu 12.10 and cups 1.6.1-0ubuntu11, and
this problem has once again gone away for me - hopefully it will stay
gone this time.

I regret to say that the problem did *not* stay away. After rebooting, I get the page with the PJL codes and a bunch of blank pages corresponding to pages of the document that should be printed.

And, following up by setting -o usb-unidir-default=true , now the behavior is sporadic - some print jobs give me a cover
page with PJL codes and nothing else, some give me the PJL codes followed by blank pages, and some give me my
actual print job. The most frustrating aspect is the randomness / lack of reproducibility :-( Again this is with a stock
Ubuntu 12.10 install on an HL-1450 printer, printing several ways (direct print of PostScript file, print from PDF reader,
print from Firefox).

lsusb results:

Bus 004 Device 003: ID 04f9:000e Brother Industries, Ltd HL-1450 series
Bus 005 Device 002: ID 046d:c52e Logitech, Inc.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

I'm guessing by the lack of response to my comments above that there's little prospect of CUPS printing working for me again anytime in the forseeable future. Right now I can only print by actually attaching the printer to a WinXP instance running in VirtualBox, but this is way too annoying and resource-intensive to keep doing.

Before I give up and punt to another distro, would anyone care to comment on the feasibility of ripping out the entire 12.10 userspace print stack and replacing with the one from 10.04, which worked perfectly well for me for years? I'm guessing I'll run into dependency hell that will make it practically impossible, but maybe it's not as bad as I'm imagining?

Similar symptoms as above. Occasionally printing PJL codes at the first page, before queue useful data. After this "garbage" page, the queue printing as expected.

Printer:
    HP-LaserJet-5100
    Printer work as local and network shared.
    Printer connected through LPT-USB "noname" adapter.

System:
    Linux 3.5.0-26-generic #40-Ubuntu SMP Tue Feb 26 19:57:24 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
    Distributor ID: Ubuntu
    Description: Ubuntu 12.10
    Release: 12.10
    Codename: quantal

CUPS:
    1.6.2-1ubuntu3

Printer worked fine with CUPS 1.5.3, PJL codes appeared after update to 1.6.x

After reading this topic, made some changes:
    echo blacklist usblp > /etc/modprobe.d/blacklist-usblp.conf
    rmmod usblp

Done some tests, so far no errors.
Logs in attach, but they have been written after blacklisting usblp. Sorry: work machine, haven't much time for debugging. By the way, I haven't notice any appropriate errors in logs before. May be, need to change debug level?

irrelative, can you run the follwowing command in a terminal window

cancel -a
lpadmin -p <queue> -o usb-unidir-default=true

with <queue> being the print queue name of the printer with problems. Does printing work correctly now?

Now run

lpadmin -p <queue> -R usb-unidir-default

and

cancel -a
lpadmin -p <queue> -o usb-no-reattach-default=true

Does printing work correctly for you now?

then run

lpadmin -p <queue> -R usb-no-reattach-default
cancel -a
lpadmin -p <queue> -o usb-unidir-default=true

Does printing work correctly for you with these settings?

Run

lpadmin -p <queue> -R usb-unidir-default

to get back to the standard settings.

Please run also the command

lsusb

abd post the output here.

$ cancel -a
$ lpadmin -p 'HP-LaserJet-5100-Series' -o usb-unidir-default=true
(usblp blacklisted!)
-> five jobs printed, no PJL codes, succesful

$ lpadmin -p 'HP-LaserJet-5100-Series' -R usb-unidir-default
$ cancel -a
$ lpadmin -p 'HP-LaserJet-5100-Series' -o usb-no-reattach-default=true
(usblp blacklisted!)
-> five jobs printed, no PJL codes, succesful

$ lpadmin -p 'HP-LaserJet-5100-Series' -R usb-no-reattach-default
$ cancel -a
$ lpadmin -p 'HP-LaserJet-5100-Series' -o usb-unidir-default=true
(usblp blacklisted!)
-> five jobs printed, no PJL codes, succesful

$ lpadmin -p 'HP-LaserJet-5100-Series' -R usb-unidir-default
$ lsusb
Bus 003 Device 004: ID 093a:2510 Pixart Imaging, Inc. Optical Mouse
Bus 004 Device 032: ID 1a86:7584 QinHeng Electronics CH340S
Bus 005 Device 003: ID 055f:0210 Mustek Systems, Inc. ScanExpress A3 USB
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 008 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

I understood you correctly? May be I should cancel blacklisting "usblp" first (due to determined incompatibility)?

Yes, you need to cancel blacklisting "usblp" first and then do these tests.

$ modprobe -l | grep usblp
kernel/drivers/usb/class/usblp.ko

reboot printer
$ cancel -a
$ lpadmin -p 'HP-LaserJet-5100-Series' -o usb-unidir-default=true
-> 5 tests: ok, PJL, ok, PJL, ok

$ lpadmin -p 'HP-LaserJet-5100-Series' -R usb-unidir-default
$ cancel -a
reboot printer
$ lpadmin -p 'HP-LaserJet-5100-Series' -o usb-no-reattach-default=true
-> 5 tests: ok, ok, ok, ok, ok

$ lpadmin -p 'HP-LaserJet-5100-Series' -R usb-no-reattach-default
$ cancel -a
reboot printer
$ lpadmin -p 'HP-LaserJet-5100-Series' -o usb-unidir-default=true
-> 5 tests: ok, ok, ok, ok, ok

$ lpadmin -p 'HP-LaserJet-5100-Series' -R usb-unidir-default

May be, five tests is not sufficient. Errors appear in about 20% of print jobs. Should I test more thoroughly?

It seems that the solution is

cancel -a
lpadmin -p 'HP-LaserJet-5100-Series' -R usb-unidir-default
lpadmin -p 'HP-LaserJet-5100-Series' -o usb-no-reattach-default=true

please run more tests in this mode and keep it for the time being.

Please tell if it really solves your problem.

Understood. Will try this for a few days.
Thank you for paying attention to me!

No PJL pages for a week. Therefore, it's a solution.

usb-unidir-default
usb-no-reattach-default=true

What does these settings mean?
Should they persist after cups update?
Should they be included in cups package?

Unfortunately, Google shows only related bugs.

Thank you!

irrelative, can you turn on your printer and connect it to the computer's USB and while it is turned on and connected, run

lsusb

and post the result here? It should contain a line with "HP" or "Hewlett Packard".

$ lsusb
Bus 003 Device 005: ID 093a:2510 Pixart Imaging, Inc. Optical Mouse
Bus 004 Device 004: ID 1a86:7584 QinHeng Electronics CH340S
Bus 005 Device 002: ID 055f:0210 Mustek Systems, Inc. ScanExpress A3 USB
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 008 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

No HP printers, no printers at all, but printing works. Connection through LPT-USB "noname" adapter! I think, not much choises, here is it:
Bus 004 Device 004: ID 1a86:7584 QinHeng Electronics CH340S

Yes, by the way! "hp-toolbox" (hplip-gui package) couldn't find any printers, not automatically, not manually (Bus 004 Device 004), but CUPS do (web interface -> administration -> add printer):

Local Printers: * Serial Port #1
                                * Serial Port #2
                                * HP LaserJet 5100 Series (HP LaserJet 5100 Series)
                                * HP Printer (HPLIP)
                                * CUPS-PDF (Virtual PDF Printer)
                                * LPT #1
                                * HP Fax (HPLIP)

Thank you for the information. With this I can add exception rules to the CUPS USB backend so that your USB->Parallel adapter will work out of the box.

Note that HPLIP only fully supports HP printers directly connected to the computer or network, without non-HP adapters. Otherwise you have only limited support (printing usually works, but not scanning and/or the HP Toolbox).

irrelative, fix for your adapter uploaded for the upcoming cups 1.6.2-1ubuntu5 package in Raring. Thanks for your report.

Thank you for your work!

irrelative, your QinHeng CH340S USB->Parallel adapter has an actual hardware/firmware bug which is probably the reason why we had to add a quirk rule to the USB backend of CUPS. See also bug 1156210, especially comment #2.