Bug 494036
| Summary: | CUPS hplip gs usb deadlock | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Denis Tumpic <dtumpic> | ||||||||
| Component: | kernel | Assignee: | Kernel Maintainer List <kernel-maint> | ||||||||
| Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||
| Severity: | medium | Docs Contact: | |||||||||
| Priority: | low | ||||||||||
| Version: | 12 | CC: | itamar, kernel-maint, twaugh | ||||||||
| Target Milestone: | --- | ||||||||||
| Target Release: | --- | ||||||||||
| Hardware: | x86_64 | ||||||||||
| OS: | Linux | ||||||||||
| Whiteboard: | |||||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||||
| Doc Text: | Story Points: | --- | |||||||||
| Clone Of: | Environment: | ||||||||||
| Last Closed: | 2010-12-05 06:57:34 UTC | Type: | --- | ||||||||
| Regression: | --- | Mount Type: | --- | ||||||||
| Documentation: | --- | CRM: | |||||||||
| Verified Versions: | Category: | --- | |||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||
| Embargoed: | |||||||||||
| Attachments: |
|
||||||||||
Complete version numbers please. rpm -q ghostscript hplip kernel ghostscript-8.63-5.fc10.x86_64 hplip-2.8.12-6.fc10.x86_64 kernel-2.6.27.15-170.2.24.fc10.x86_64 kernel-2.6.27.19-170.2.35.fc10.x86_64 kernel-2.6.27.21-170.2.56.fc10.x86_64 <<<<< Booted Please attach the PPD for the queue you are using (from the /etc/cups/ppd/ directory), and attach the output of 'lpstat -s'. Thanks. Created attachment 338349 [details]
The ppd used when deadlocking
lpstat -s system default destination: DESKJET-932C device for DESKJET-932C: usb://HP/DESKJET%20930C?serial=############ BTW: The printing worked perfectly in Fedora 8, 7, 5, 3 and RedHat 7.3. And used the same setting for CUPS since it was introduced. To isolate the 'usb' backend from the problem, please do the following, as root: lpadmin -p test -P /etc/cups/ppd/DESKJET-932C.ppd cupsenable test accept test then print something to the 'test' queue. Does the job disappear from the queue? What does 'lpstat -t' say afterwards? Well I can't make sure that the queue even gets filled before it is emptied due to it going directly to /dev/null but assuming it actually does get onto the queue it does get emptied. lpstat -t scheduler is running system default destination: DESKJET-932C device for DESKJET-932C: usb://HP/DESKJET%20930C?serial=############ device for test: /dev/null DESKJET-932C accepting requests since Fri 03 Apr 2009 02:55:31 PM EDT test accepting requests since Mon 06 Apr 2009 01:19:26 PM EDT printer DESKJET-932C is idle. enabled since Fri 03 Apr 2009 02:55:31 PM EDT printer test is idle. enabled since Mon 06 Apr 2009 01:19:26 PM EDT Thanks. Now we know that the problem is not due to the print filters. Using system-config-printer (System->Administration->Printing from the main menu), edit the printer's properties and select 'Change...' next to the Device URI. When you select the printer from the list, is there a '> Connection' expander button at the bottom of the window? If so, please use that to select a different connection type (i.e. something other than "A printer connected to a USB port"). Does that give you any better results? Double clicking on the Default Printer Icon in Printer Configuration and changing the Device URI from being a direct usb:/.... to a hp:/usb/.... seems to work better. Ok so what is the real difference here? I mean "hp-info -i" works the same on both types of connections, how does one know which one to use? Is the usb:/... an old way of doing it? I must say that I definitely missed the memo on this one, used usb:/ since Fedora 3 (used Centronics cable with the same printer on Redhat 7.3) All help very much appreciated. The reason I'm asking you to try these things is to try to diagnose what the problem is. You should still be able to use the usb backend, so we need to find out why that's going wrong. Please change the connection type back to USB so that the URI starts with 'usb://...' again, and run the printing troubleshooter: Help->Troubleshoot from the system-config-printer menu bar. Then attach the troubleshoot.txt file to this bug report. Created attachment 340342 [details] Attachment for comment #11 As per usual the job got printed but is still in the queue (lpq.) and lsusb b0rked. BTW packages are now: ghostscript-8.63-6.fc10.x86_64 hplip-2.8.12-6.fc10.x86_64 kernel-2.6.27.15-170.2.24.fc10.x86_64 kernel-2.6.27.19-170.2.35.fc10.x86_64 kernel-2.6.27.21-170.2.56.fc10.x86_64 <-- Booted OK, I think we need to see exactly what the usb backend is doing that triggers this for you. Please install 'strace' (yum install strace) and then use it to capture the system calls of cupsd and its children: set $(ps ax | grep [c]upsd) strace -fp $1 2>cupsd.log Then submit the print job and wait until the job has finished printing. Wait a few moments more and then stop the strace command with control-C. Attach the resulting cupsd.log file here. Thanks. Created attachment 340385 [details] Attachment for comment #14 I did issue an lpq after waiting a couple of seconds of the printout being done. (In reply to comment #15) BTW: strace did not exit after hitting ctrl-c which should be as expected. OK, the last thing the usb backend does is try to close the file descriptor, and this never completes. Changing component to kernel. Can you try kernel-2.6.29.2-52.fc10 from the updates-testing repository? I have tried with kernel-2.6.29.2-52.fc10 and it seems to work with the usb:// path and does not halt anymore. Offtopic: It works even after I have managed to deadlock the USB system by using my cell phones USB connection (this is another bug that has been with the kernel since 2.6.26) Its now happening again with the 2.6.29.5-191.fc11.x86_64 In addition this time I can't get anything printing using hal:/ path... hp:/ is non existent. BTW: ghostscript-8.64-6.fc11.x86_64 hplip-3.9.2-4.fc11.x86_64 kernel-2.6.29.4-167.fc11.x86_64 kernel-2.6.29.5-191.fc11.x86_64 Small correction the hal:/// path actually works correctly as the hp:/// did before. It was the USB lockup that caused the previous test to fail. The USB dealock still happens in F12 hplip-libs-3.9.8-21.fc12.x86_64 hplip-3.9.8-21.fc12.x86_64 kernel-firmware-2.6.31.5-127.fc12.noarch hplip-common-3.9.8-21.fc12.x86_64 kernel-2.6.31.5-127.fc12.x86_64 ghostscript-8.70-1.fc12.x86_64 what is worse now in F12 is that I have only one choice to select the printer connection and it is the one that fails and locks the USB. Denis: don't you have the option to use the USB backend? The description should say "A printer connected to a USB port.". If you aren't able to see that option please file a separate bug report against cups. There seemed to have been an issue with SELinux and after I fixed that it showed the USB method of connectivity (Upgrade from F11.) It too failed in the same fashion. I then deleted all printer configurations and added the non USB device printer listed and it seems to work without locking. Regardless of my workaround to get this working it is quite wrong for anything to be able to deadlock the entire USB bus. Not to mention that the mouse pointer becomes incapable of movement (regardless of video driver.) This is definitely a usage impediment and has not been like this on any Fedora before F9. It doesn't impact me much because I am rarely printing anything BUT I deem this to be quite a serious error. This message is a reminder that Fedora 12 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 12. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '12'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 12's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 12 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping Fedora 12 changed to end-of-life (EOL) status on 2010-12-02. Fedora 12 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed. |
Description of problem: Printing with the hplip driver through CUPS doesn't properly "flush" page when printing finishes (gs is still running but not "doing anything.") This for some reason is a result from either the USB system deadlocking, the hplip driver deadlocking or gs deadlocking. Issuing lsusb causes it to stall when enumerating usb devices. tail on the strace lsusb results in open("/dev/bus/usb/004/001", O_RDWR) = 4 ioctl(4, USBDEVFS_CONNECTINFO Version-Release number of selected component (if applicable): This has been ongoing since Alpha version of Fedora 10 at least (I was thinking this was a hardware error due to other USB devices not working as expected thus the late post.) How reproducible: Every single time I print a document. Whether its a one liner with one word or many pages. Definitely reproducible on 2.6.27.15, 2.6.27.19, 2.6.27.21 Steps to Reproduce: 1. Print document through CUPS on the local computer. 2. Deadlock 3. Actual results: Pages print. CUPS becomes defunct. lsusb halts. Expected results: Pages print and possible to print more documents without rebooting. (Currently I use "pdftk cat" and batch print as many documents as I can to minimize rebooting.) Additional info: 4 core proc. SELinux is in Enforcing mode.