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
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
|
Details
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 http://www.cups.org/str.php?L3318+Qversion:1.4 The patch in the bug report applies cleanly to vanilla 1.4 and appears to fix the issue. Ubuntu bug ticket: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/420015 (where I found all this information) |
This task depends upon
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: http://www.cups.org/strfiles/3318/usb-backend-infinite-loop-on-end-of-job.dpatch needs to be applied to prevent the new usb processes that cups uses from hanging.
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
* 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...
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)
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:
http://pastebin.com/m3a851da4
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
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).
@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?
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?
"[ 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.
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.