Arch Linux

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#15998 - [cups] 1.4-1 - USB printers do not work + Print Processs Hangs

Attached to Project: Arch Linux
Opened by Matthew Gyurgyik (pyther) - Friday, 04 September 2009, 21:45 GMT
Last edited by Andreas Radke (AndyRTR) - Sunday, 11 October 2009, 18:55 GMT
Task Type Bug Report
Category Packages: Testing
Status Closed
Assigned To Tobias Powalowski (tpowa)
Thomas Bächler (brain0)
Andreas Radke (AndyRTR)
Architecture All
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 3
Private No


In the cups 1.4-1 package there are two issues:
1) USB printers are not detected by default
2) You can only print one job, before the USB process hangs

The the 1st issue usblp must be unloaded from the kernel and the /dev/bus/usb/*/* files corresponding to printers must have the permissions 664 with group ownership "lp".

I used this udev rule which sort-off works, however it overrides the virtualbox rules. I do not have a good understanding on udev, and I believe a better rule can be written.

ACTION=="add", SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", ID_USB_INTERFACES=":0701*:", GROUP="lp", MODE="660"

In order to prevent usblp from loading there are two options:
1) Remove usblp from the kernel
2) Blacklist usblp

As for the second issue a bug has been submitted upstream The patch in the bug report applies cleanly to vanilla 1.4 and appears to fix the issue.

Ubuntu bug ticket: (where I found all this information)
This task depends upon

Closed by  Andreas Radke (AndyRTR)
Sunday, 11 October 2009, 18:55 GMT
Reason for closing:  Fixed
Comment by Tobias Powalowski (tpowa) - Monday, 07 September 2009, 06:31 GMT
should work again with udev-146-2 package, please confirm.
Comment by Matthew Gyurgyik (pyther) - Monday, 07 September 2009, 16:18 GMT
Works well! Thanks!

We need to decide if usblp should be removed from the kernel or if it should be blacklisted. I think it should be removed from the kernel as the only program that I can think of that still needs usblp would be p910nd (small printer daemon intended for diskless workstations). We do not have p910nd in the repos and those who need it, could always compile the module.

Lastly this patch: needs to be applied to prevent the new usb processes that cups uses from hanging.
Comment by Tobias Powalowski (tpowa) - Monday, 07 September 2009, 16:28 GMT
is blacklisting of usblp still needed if the patch is applied?
Comment by Matthew Gyurgyik (pyther) - Monday, 07 September 2009, 16:34 GMT
Yes it is. From my understanding cups new usb backend conflicts with usblp.
The patch fixes an issue where you can print once, but then any other prints will cause the usb process to hang at 100% cpu usage
Comment by Matthew Gyurgyik (pyther) - Wednesday, 09 September 2009, 17:54 GMT
usblp is not blacklisted. Is usblp going to be removed from the kernel? If so should I open a bug report?
Comment by David (alleluia20) - Thursday, 10 September 2009, 20:36 GMT
I do not know the ins and outs of the problem, but I can say two things:

* The printer stopped working (all jobs where in the "processing" status forever and ever).
* Removing the printer and adding it worked for me (well, I printed several things, but only in one session so far).

If things are like that, the problem is not that big, but the upgrade is not clean at all...
Comment by Seynthan Thanapalan (ST.x) - Tuesday, 15 September 2009, 21:16 GMT
I had to change the /dev/bus/usb/002/007 group to lp for the cups interface to find my USB printer as detailed in
Comment by Matthew Gyurgyik (pyther) - Tuesday, 15 September 2009, 23:12 GMT
Based on the past two reports, especially the last one it appears that the udev rule is only working in some cases or only for specific devices.
Comment by Tobias Powalowski (tpowa) - Sunday, 20 September 2009, 19:43 GMT
should work now with 1.4.1
Comment by Jakub Schmidtke (sjakub) - Monday, 21 September 2009, 07:02 GMT
I still have the same problem. One pdf job and it won't print anything else.
Comment by Miroslaw Czachor (forest76) - Monday, 21 September 2009, 11:36 GMT
My printer work or do not work randomly on cups 1.4.1 too. Once time, when I had opened cups config site and I was trying to print, message: ,,pstoraster error'' was appear.
Comment by Tobias Powalowski (tpowa) - Monday, 21 September 2009, 18:54 GMT
Please higher the debug level and look at /var/cups/errors.log to get more information
Comment by Matthew Gyurgyik (pyther) - Monday, 21 September 2009, 19:17 GMT
I just wanted to note that cups 1.4.1 seems to be working without any problems for me.

However, it still needs to be determined what gets done with usblp. On the forum somebody stated that they need this module to make their scanner work (multifunctional printer). If this is true then it might be best to advice users to blacklist usblp in post_install/upgrade()

Lastly it seems as if the udev rule needs some fine tweaking (see ST.x's report)
Comment by Mat (hickop) - Wednesday, 23 September 2009, 07:08 GMT
Reported this issue on forum with my multifunction Samsung SCX-4200 (usb) with cups 1.4.1.
Printer is not recognized when I click the 'Find New Printers' button on the administration page.
'Add Printer' provides me with SCSI as a local printer option but gives nothing to proceed further.

Here is my error_log with LogLevel set to debug:
Comment by Tobias Powalowski (tpowa) - Wednesday, 23 September 2009, 07:23 GMT
have you also repleced your cupsd.conf? the 1.4 file has changed imho.
Comment by Matthew Gyurgyik (pyther) - Wednesday, 23 September 2009, 11:55 GMT

Do you have usblp unloaded?
What are results of this command? ls -l /dev/bus/usb/*/* (with you printer plugged in of course)

The reason I ask is because it seem as if there is a permission issue. The lp group need to have rw permissions on your printer. If this is indeed the case the udev rules need to be modified. I am aware of at least one other person with a permission issue.

#D [23/Sep/2009:08:54:41 +0200] [CGI] Failed to set configuration 1 for 04e8:341b
#D [23/Sep/2009:08:54:41 +0200] [CGI] Failed to claim interface 1 for 04e8:341b: Operation not permitted
Comment by Mat (hickop) - Wednesday, 23 September 2009, 18:17 GMT
So, yes I did replace my cupsd.conf with the cupsd.conf.pacnew that was generated.

Doing 'ls -l /dev/bus/usb/*/*' I can see my multifuction has been set to scanner group (by xsane I guess)
crw-rw-r-- 1 root scanner 189, 2 2009-09-20 10:04 /dev/bus/usb/001/003

With cups 1.4.1, if I unload usblp and I set group to lp printer is recognized and works.

This configuration works with cups 1.3.11 and usblp (I can use both my printer and scanner).
Comment by Tobias Powalowski (tpowa) - Thursday, 24 September 2009, 14:26 GMT
then you need a custom udev rule for it, you can only set one group.
Comment by Andreas Radke (AndyRTR) - Wednesday, 30 September 2009, 12:45 GMT
I confirmed my printer now working. The udev rule fixed it for me and is going upstream anyway in the next udev release.

@Mat: ask udev devs upstream for a solution. cups devs usually reject asking core linux device handling questions.

tpowa? can we close this one as fixed?
Comment by Andreas Radke (AndyRTR) - Wednesday, 30 September 2009, 18:51 GMT
Stop. We can't close this one.

I confirmed a problem for my usb printer. The device doesn't get back automatically the right group once you switch the printer of and on again. yiu get a root:root permission. Calling udevadm trigger manually brings back the right "lp" group.

What's wrong?
Comment by Andreas Radke (AndyRTR) - Thursday, 01 October 2009, 05:11 GMT

"[ Till Kamppeter ]
* debian/patches/usb-backend-both-usblp-and-libusb.dpatch: Make the USB
backend supporting both printer access via libusb and via the usblp kernel
module. Make it also printing via libusb if the URI for the queue was
generated via usblp and vice versa. This should solve most USB printing
problems which occured on the transition to CUPS 1.4.x (LP: #420015,
LP: #436495; Closes: #546558, #545288, #545453).

[ Martin Pitt ]
* debian/rules: Make the USB backend run as root again, udev rules do not
cover all printers. (LP: #420015)"

urgh, what now? options:

1) let's wait how upstream will handle this? leave cups 1.4.x longer in testing
2) recommend affected users to call udevadm trigger and pray it gets detected with proper permission
3) go back to root:root permission like debian did.
Comment by Thomas Bächler (brain0) - Thursday, 01 October 2009, 07:11 GMT
The udev rule should work - we should find out why it doesn't.
Comment by Mat (hickop) - Thursday, 01 October 2009, 09:45 GMT
@AndyRTR: In my case i'd choose case 3)
This debian patch will make it work like it did in 1.3.

I think proper behaving should not prevent usblp to be active as it is required by multifunctions (printers/scanners).
And also that printer should be recognized even if not in lp group , as udev will set it to scanner.

Comment by Andreas Radke (AndyRTR) - Monday, 05 October 2009, 16:57 GMT
I confirmed the new udev to be working everytime I switch my printer off and on but only with kernel 2.6.31 not with my 2.6.27.xx LTS kernel!
Comment by Andreas Radke (AndyRTR) - Sunday, 11 October 2009, 18:55 GMT
ok. solved my issue with a custom udev rule for workaround needed with LTS kernel and my printer. because I haven't heard of anybody else having that problem I close this bug as solved.