Can you show me output of:
# sudo /usr/lib/cups/backend/usb

Also can you try the following commands and let me know if there's any change:
# hp-setup -g -i 03f0:2b17
# hp-setup -g -i -a 03f0:2b17
# hp-setup -g -i -b usb

If  you want to show me output longer then few lines, please save it into a file and use 'Add an attachment' link above.

See http://hplipopensource.com/hplip-web/tech_docs/man_pages/setup.html
for description of the options.


Thanks

Hi Jiri,

Thank you for the reply.
Here is the additional info.

> Can you show me output of:
> # sudo /usr/lib/cups/backend/usb

[neuron@sshost]~% sudo /usr/lib/cups/backend/usb
[sudo] password for neuron: 
DEBUG: Loading USB quirks from "/usr/share/cups/usb".
DEBUG: Loaded 68 quirks.
DEBUG: list_devices
DEBUG: libusb_get_device_list=11
DEBUG2: Printer found with device ID:  Device URI: usb://Unknown/Printer
direct usb://Unknown/Printer "Unknown" "Unknown" "" ""

> Also can you try the following commands and let me know if there's any change:
> # hp-setup -g -i 03f0:2b17
> # hp-setup -g -i -a 03f0:2b17
> # hp-setup -g -i -b usb

Please refer to hp-setup1.log, hp-setup2.log, hp-setup3.log respectively.

Created attachment 846700 [details]
hp-setup -g -i 03f0:2b17

Created attachment 846701 [details]
hp-setup -g -i -a 03f0:2b17

Created attachment 846702 [details]
hp-setup -g -i -b usb

(In reply to Kuznetsov Vyacheslav from comment #0)
> Bus 002 Device 004: ID 03f0:2b17 Hewlett-Packard LaserJet 1020

(In reply to Jiri Popelka from comment #1)
> # hp-setup -g -i 03f0:2b17

grr, my bad, sorry. It should have been 002:004, not 03f0:2b17
Check lsusb before you run it next time to check the Bus and Device numbers.

Also take a look at the options and examples in
http://hplipopensource.com/hplip-web/tech_docs/man_pages/setup.html
and try to experiment with them. Maybe you'll find anything useful, I'm quite clueless what could be the culprit.

Created attachment 848853 [details]
hp-setup -g -i 002:004

Hi,

The problem is still here. I'm attaching the test for

hp-setup -g -i 002:004

In the same log you can find lsusb output as well.

As I wrote originally, there issue arose after upgrade to Fedora 20. Probably there is a library incompatibility in Fedora 20. 

All updates are installed. Selinux is disabled in /etc/selinux/config.

Created attachment 848854 [details]
hp-doctor output

Here is what I see in journalctl related to the test:

---
Jan 11 14:32:09 sshost python[14404]: io/hpmud/musb.c 150: unable get_string_descriptor -7: Resource temporarily unavailable
Jan 11 14:32:09 sshost python[14404]: io/hpmud/musb.c 2206: invalid product id string ret=-7
Jan 11 14:32:14 sshost python[14404]: io/hpmud/musb.c 150: unable get_string_descriptor -7: Resource temporarily unavailable
Jan 11 14:32:14 sshost python[14404]: io/hpmud/musb.c 2211: invalid serial id string ret=-7
Jan 11 14:32:19 sshost python[14404]: io/hpmud/musb.c 150: unable get_string_descriptor -7: Resource temporarily unavailable
Jan 11 14:32:19 sshost python[14404]: io/hpmud/musb.c 2078: invalid product id string ret=-7
Jan 11 14:32:24 sshost python[14404]: io/hpmud/musb.c 150: unable get_string_descriptor -7: Resource temporarily unavailable
Jan 11 14:32:24 sshost python[14404]: io/hpmud/musb.c 2083: invalid serial id string ret=-7
Jan 11 14:32:29 sshost python[14404]: io/hpmud/musb.c 150: unable get_string_descriptor -7: Resource temporarily unavailable
Jan 11 14:32:29 sshost python[14404]: io/hpmud/musb.c 2088: invalid manufacturer string ret=-7
Jan 11 14:32:36 sshost python[14404]: io/hpmud/musb.c 150: unable get_string_descriptor -7: Resource temporarily unavailable
Jan 11 14:32:36 sshost python[14404]: io/hpmud/musb.c 2078: invalid product id string ret=-7
Jan 11 14:32:41 sshost python[14404]: io/hpmud/musb.c 150: unable get_string_descriptor -7: Resource temporarily unavailable
Jan 11 14:32:41 sshost python[14404]: io/hpmud/musb.c 2083: invalid serial id string ret=-7
Jan 11 14:32:46 sshost python[14404]: io/hpmud/musb.c 150: unable get_string_descriptor -7: Resource temporarily unavailable
Jan 11 14:32:46 sshost python[14404]: io/hpmud/musb.c 2088: invalid manufacturer string ret=-7
Jan 11 14:32:46 sshost hp-setup[14404]: hp-setup[14404]: error: Invalid device URI:
Jan 11 14:32:46 sshost hp-setup[14404]: hp-setup[14404]: error: No device selected/specified or that supports this functionality.
---

Then I found out about hp-check and hp-doctor utilities. The most significant part of output:

---
Checking for Deprecated items....
error: This distro (i.e fedora  20) is either deprecated or not yet supported.
---

Could you possibly contact hplip package maintainer join them to the ticket.

Thanks in advance.

Please try this (it's all one line):

strace -s100 python -c "import hpmudext; print hpmudext.make_usb_uri('002','004')"

Replace 002 and 004 with the USB bus/device as before. Hopefully this will tell us why it isn't spotting the printer.

Created attachment 849523 [details]
strace -s100 python -c "import hpmudext; print hpmudext.make_usb_uri('002','004')" > strace.log 2>&1

>Please try this (it's all one line):

> strace -s100 python -c "import hpmudext; print hpmudext.make_usb_uri('002','004')"

Here's the result. I made sure 002 and 004 are still correct codes.

Thank you.

Looks to me like it timed out (at least, poll() is returning because of the timerfd instead of the USB device node fd).

Could it be possible that the cable coincidentally broke at the time you upgraded? Do you have another cable you can try, or else are you able to verify that the cable is working?

Hi Tim,

There are two points here:

1. I successfully print all this time from Air with OS X (Air) with the same cable.

2. Accidentally I have another cable suitable for HP 1020. I just tried it as well. The results are the same.

So I suppose the problem is with my Fedora installation. If needed I can provide an ssh access to my host so we can investigate the issue together, say, in tmux session + skype.

Thank you.

I am also experiencing this bug with Fedora 20 and an HP Laserjet 1020 printer. The printer works fine with the same cable in other systems. My experience is the same: The printer shows up in lsusb but not in hp-setup.

Almost the same thing is happening on my system. I still have the ppd file for the 1020, and hp-setup recognizes that the printer is there.

However, when I try to print the test page, it gives me this:

error: Unable to communicate with device (code=12): hp:/usb/HP_LaserJet_1020?serial=FN15359
error:  Unable to print to printer.  Please check device and try again.

The gnome notification says:

HP_LaserJet_1020 Printer (FN15359)
Device communication error (5012)

code=12 is an I/O error, most likely due to the same thing as in comment #11: poll() is timing out for some reason when trying to transfer an URB.

I'm not sure why that would happen.

Same issue with the HP 1020. Printer works fine via OSX

I'm using Ubuntu 14.04 unstable, and I have the same problem with my HP LaserJet 1020.

IIRC it worked a couple of weeks ago (on Ubuntu 14.04 unstable), but I could just be forgetful. It certainly worked on Ubuntu 13.10. I have tried two USB cables, on various working USB ports on my computer.

hplip 3.14.3-0ubuntu1, cups 1.7.1-5ubuntu9

Interestingly: sometimes "lsusb" stalls for minutes before _not_ showing "Bus 002 Device 036: ID 03f0:2b17 Hewlett-Packard LaserJet 1020". The effect happens in hp-setup, too: the probe sometimes lasts several minutes. I've seen this several times, but I don't know how to reproduce it. (Maybe by disconnecting and reconnecting the USB cable without power-cycling the printer?) Right now, the device is showing up in "lsusb" and my strace result is practically identical to Kuznetsov's.

I'll cross-post this to Ubuntu's launchpad. There, it's bug 1296085: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1296085

I also have the LaserJet 1020 and did the following test: I connected the printer to a running Ubuntu 14.04 system. The system recognized the printer and a wizard for downloading the firmware (HPLIP plugin) popped up. I was able to successfully install the firmware package and the printer made the usual noise of receiving its firmware file. After that I could set up the printer with both hp-setup and system-config-printer and both print queues allowed me to print (I simply printed the Ubuntu test page).

As I could not reproduce the bug I tried a system update (14.04 is still under development, so there are tons of updates every day). The updated consisted of hundreds of packages including the kernel. I rebooted (the printer all the time connected and turned on) to get the system using the new kernel. At the time when the login screen appeared the printer made the firmware loading noise.

Right after logging in I started hp-setup, to see whether it is able to create a queue for this printer and then I got the bug reproduced. hp-setup needed longer time to search for USB printers and in the end no printer was found, so it did not see my printer. "lsusb" lists my printer though.

Now I power-cycled the printer. It made noise once for its startup and a second time for receiving its firmware from the computer. After that it was again listed by "lsusb" but this time hp-setup could find it. I also could print.

So the problem seems booting with the printer turned on. It works if turning it on after boot or power-cycling it after a boot with the printer already turned on.

Please everyone with this problem test whether this is also the case for you.

After trying almost everything in earth, I finally try the power-cycled... a little bit different though.

I turned off the printer; wait a few seconds; turned on again. When asked to download the plugin, I decided to NOT let it (I chose the non-recommended option - I believe it is the last one).

Run hp-setup; choose the usb; voila: the printer shows up. (finally!!!!)

Hope it helps other.

P.S. It is still a bug though, in my opinion.

This message is a reminder that Fedora 20 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 20. 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 EOL if it remains open with a Fedora  'version'
of '20'.

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.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 20 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, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

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.

Fedora 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 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. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

Still broken in Fedora 21

Please see comment #18: more information is required.

This message is a reminder that Fedora 21 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 21. 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 EOL if it remains open with a Fedora  'version'
of '21'.

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.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 21 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, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

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.

Fedora 21 changed to end-of-life (EOL) status on 2015-12-01. Fedora 21 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. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.