Description of problem: For some reason usblp pokes the printer "wrong" and I end up having to powercycle the printer many times (sometimes 30 times!) before Linux finally manages to download the firmware and start printing. /var/log/messages is filled with lines like these: Dec 26 18:39:22 imladris kernel: usb 1-2: control timeout on ep0in Dec 26 18:39:22 imladris kernel: drivers/usb/class/usblp.c: usblp0: error -110 reading printer status Version-Release number of selected component (if applicable): 2.6.9-22.0.1.EL The printer is an HP laserjet 1020. David Woodhouse has a laserjet 1200 and is experiencing similar problems, so it does not appear to be a single bad printer... Steps to Reproduce: 1. plug in printer 2. try to print something 3. tear out hair Actual results: printer often needs to be powercycled MANY times before the system can start printing, sometimes Linux needs to be rebooted before it can print again (khubd is "stuck" spinning in D state, occasionally waking up and going back into D state) Expected results: I would really like to be able to use my printer. Additional info: This happens on all my computers at home here, with Intel, VIA and AMD USB controllers. Because of this I believe this is unlikely to be a USB controller issue.
I do not think this has anything to do with usblp, and everything to do with hpoj or whatever actually messes with printer's brains. Do you want me to look at khubd specifically? It's largely unrelated. It can be fixable, but it won't help you print.
I haven't ever seen it need power cycling repeatedly; once is usually sufficient. The machine I which I saw this has since developed other USB problems though -- repeatedly complaining about every port on the root hub which _doesn't_ have something connected, along the following lines: hub 1-0:1.0: connect-debounce failed, port 1 disabled hub 1-0:1.0: connect-debounce failed, port 2 disabled hub 1-0:1.0: connect-debounce failed, port 4 disabled This causes all kinds of problems, and apparent deadlock with anything using libusb (which includes something in my boot sequence). I've just moved _all_ the USB peripherals to the new G5 and blacklisted ohci_hcd on the offending box. I have yet to see the laserjet play up on the Mac, although it hasn't been there long.
I believe things go wrong before hpoj gets involved, since the printer firmware is uploaded from the hotplug daemon using an extremely simple script (basically cat firmware > /dev/usb/lp0). This script already goes wrong.
I think it's safe to split this with dwmw2 and his 1200. They are different printers. See also bug 174961. Please do not dup for now, I do not want the waves in that bug, but let's use all the material available there.
Thank you for submitting this issue for consideration in Red Hat Enterprise Linux. The release for which you requested us to review is now End of Life. Please See https://access.redhat.com/support/policy/updates/errata/ If you would like Red Hat to re-consider your feature request for an active release, please re-open the request via appropriate support channels and provide additional supporting details about the importance of this issue.