Bug 494036 - CUPS hplip gs usb deadlock
CUPS hplip gs usb deadlock
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
12
x86_64 Linux
low Severity medium
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-04-03 15:56 EDT by Denis Tumpic
Modified: 2010-12-05 01:57 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-12-05 01:57:34 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
The ppd used when deadlocking (4.47 KB, application/x-gzip)
2009-04-06 11:23 EDT, Denis Tumpic
no flags Details
Attachment for comment #11 (8.03 KB, application/x-gzip)
2009-04-20 09:48 EDT, Denis Tumpic
no flags Details
Attachment for comment #14 (119.50 KB, application/x-gzip)
2009-04-20 13:13 EDT, Denis Tumpic
no flags Details

  None (edit)
Description Denis Tumpic 2009-04-03 15:56:57 EDT
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.
Comment 1 Tim Waugh 2009-04-05 08:04:45 EDT
Complete version numbers please.

rpm -q ghostscript hplip kernel
Comment 2 Denis Tumpic 2009-04-05 08:37:19 EDT
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
Comment 3 Tim Waugh 2009-04-06 11:01:06 EDT
Please attach the PPD for the queue you are using (from the /etc/cups/ppd/ directory), and attach the output of 'lpstat -s'.  Thanks.
Comment 4 Denis Tumpic 2009-04-06 11:23:41 EDT
Created attachment 338349 [details]
The ppd used when deadlocking
Comment 5 Denis Tumpic 2009-04-06 11:24:02 EDT
 lpstat -s
system default destination: DESKJET-932C
device for DESKJET-932C: usb://HP/DESKJET%20930C?serial=############
Comment 6 Denis Tumpic 2009-04-06 11:27:09 EDT
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.
Comment 7 Tim Waugh 2009-04-06 11:53:15 EDT
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?
Comment 8 Denis Tumpic 2009-04-06 13:26:29 EDT
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
Comment 9 Tim Waugh 2009-04-20 07:57:09 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?
Comment 10 Denis Tumpic 2009-04-20 09:14:53 EDT
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.
Comment 11 Tim Waugh 2009-04-20 09:27:35 EDT
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.
Comment 12 Denis Tumpic 2009-04-20 09:48:52 EDT
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.
Comment 13 Denis Tumpic 2009-04-20 09:50:39 EDT
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
Comment 14 Tim Waugh 2009-04-20 11:41:46 EDT
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.
Comment 15 Denis Tumpic 2009-04-20 13:13:47 EDT
Created attachment 340385 [details]
Attachment for comment #14

I did issue an lpq after waiting a couple of seconds of the printout being done.
Comment 16 Denis Tumpic 2009-04-20 13:17:01 EDT
(In reply to comment #15)

BTW: strace did not exit after hitting ctrl-c which should be as expected.
Comment 17 Tim Waugh 2009-04-20 13:43:37 EDT
OK, the last thing the usb backend does is try to close the file descriptor, and this never completes.

Changing component to kernel.
Comment 18 Chuck Ebbert 2009-05-05 18:39:26 EDT
Can you try kernel-2.6.29.2-52.fc10 from the updates-testing repository?
Comment 19 Denis Tumpic 2009-05-05 19:21:48 EDT
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)
Comment 20 Denis Tumpic 2009-07-01 12:05:40 EDT
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.
Comment 21 Denis Tumpic 2009-07-01 12:06:49 EDT
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
Comment 22 Denis Tumpic 2009-07-01 13:30:46 EDT
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.
Comment 23 Denis Tumpic 2009-11-19 18:26:58 EST
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.
Comment 24 Tim Waugh 2009-11-20 05:59:54 EST
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.
Comment 25 Denis Tumpic 2009-11-20 14:25:09 EST
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.
Comment 26 Bug Zapper 2010-11-04 07:23:05 EDT
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
Comment 27 Bug Zapper 2010-12-05 01:57:34 EST
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.

Note You need to log in before you can comment on or make changes to this bug.