HP Scanject 2100c not working on USB 3 root hub

Status changed to 'Confirmed' because the bug affects multiple users.

I have a CanoScan LiDE 20 which worked fine unless i got a new notebook with usb 3.0 although the scanner is well recognized. I have been testing with kubuntu 12.04 and kubuntu 13.10. With both the scanner works with the old usb 2.0 notebook and does not with the new one.

The new notebook claims to also have usb 2.0, but it does not matter where i put the scanner in.

notebook@acer:~$ lsusb
Bus 002 Device 002: ID 8087:8000 Intel Corp.
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 8087:8008 Intel Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 011: ID 04a9:220d Canon, Inc. CanoScan N670U/N676U/LiDE 20
Bus 003 Device 002: ID 1bcf:2c55 Sunplus Innovation Technology Inc.
Bus 003 Device 003: ID 04ca:300b Lite-On Technology Corp.
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

I used the following commands to get the attached debug output (please see file sanedebug.txt):

root@acer:~# export LIBUSB_DEBUG=255
root@acer:~# export SANE_DEBUG_DLL=255
root@acer:~# export SANE_DEBUG_SANEI_USB=255
root@acer:~# export USB_DEBUG=255
root@acer:~# export SANE_DEBUG_PLUSTEK=255
root@acer:~# scanimage -L 2>sanedebug.txt

This snippet from the attached debug output shows the occurence of the error:

#############

[plustek] MISC I/O after RESET: 0x66, 0x16, 0x91
[sanei_usb] sanei_usb_write_bulk: trying to write 4 bytes
[sanei_usb] 000 01 07 00 01 ....
libusbx: debug [add_to_flying_list] arm timerfd for timeout in 30000ms (first in line)
libusbx: debug [submit_bulk_transfer] need 1 urbs for new transfer with length 4
libusbx: debug [libusb_handle_events_timeout_completed] doing our own event handling
libusbx: debug [handle_events] poll() 4 fds with timeout in 60000ms
libusbx: debug [handle_events] poll() returned 1
libusbx: debug [reap_for_handle] urb type=3 status=-71 transferred=0
libusbx: debug [handle_bulk_completion] handling completion status -71 of bulk urb 1/1
libusbx: debug [handle_bulk_completion] low level error -71
libusbx: debug [disarm_timerfd]
libusbx: debug [usbi_handle_transfer_completion] transfer 0xc74d78 has callback 0x7f610b80c7f0
libusbx: debug [sync_transfer_cb] actual_length=0
[sanei_usb] sanei_usb_write_bulk: write failed: Input/output error
libusbx: debug [libusb_clear_halt] endpoint 3
libusbx: error [op_clear_halt] clear_halt failed error -1 errno 71

#############

Unfortunately I could not get any information about the error code "-71".

I have the same problem with an Epson Perfection 1250.

[plustek] usbDev_open(auto,) - 0x1386510
[plustek] Vendor ID=0x04B8, Product ID=0x010F
[plustek] usbio_DetectLM983x
[plustek] * could not read version register!
[plustek] open failed: -1

The scanner is pugged in a USB 2 port. The kernel is x86_64.

Also not working with the same hardware but Fedora 20 i686

Also not working for me, same message with my Canoscan LIDE 25

since upgrading to a Board with USB 3.0 (Intel H87 chipset) I have the same problems with my Canon LIDE20.
If I install an old USB 2.0 PCI Controller card, it works.

I was having a similar problem with my Epson Perfection V33 flatbed and Xsane. The Xsane community (Mark Buda) pointed out that there is a problem with Linux handling XHCI mode. I went into my BIOS and disabled XHCI mode and now my scanner is working normally. I forgot to point out that my problem emerged when I purchased a new desktop machine withthe latest Gigabyte motherboard.

Thank Roger for the advice but I can't find anything related to XHCI in my BIOS (ASRock Motherboard).
Can I disable it with some kernel settings?

My LiDE 30 scanner stopped working after an upgrade from Fedora 19 to Fedora 20 yesterday. No hardware was changed.

Sometimes 150dpi-scans work (but afterwards reboot or reconenct is needed), 300dpi scans always fail.

#### some log ####

[plustek] ###### ADJUST WHITE (FINE) #######
[sanei_usb] sanei_usb_write_bulk: trying to write 5 bytes
[sanei_usb] 000 00 58 00 01 04 .X...
libusb:error [reap_for_handle] unrecognised endpoint type 22
libusb:error [handle_events] backend handle_events failed with error -99
[sanei_usb] sanei_usb_write_bulk: write failed: Other error
libusb:error [op_clear_halt] clear_halt failed error -1 errno 71
[sanei_usb] sanei_usb_write_bulk: trying to write 4 bytes
[sanei_usb] 000 01 02 00 01 ....
libusb:warning [do_sync_bulk_transfer] unrecognised status code 1
[sanei_usb] sanei_usb_write_bulk: write failed: Other error
libusb:error [op_clear_halt] clear_halt failed error -1 errno 71
[plustek] UIO error
[sanei_usb] sanei_usb_write_bulk: trying to write 4 bytes
[sanei_usb] 000 01 02 00 01 ....
libusb:warning [handle_bulk_completion] unrecognised urb status -2
libusb:warning [do_sync_bulk_transfer] unrecognised status code 1
[sanei_usb] sanei_usb_write_bulk: write failed: Other error
libusb:error [op_clear_halt] clear_halt failed error -1 errno 71
[sanei_usb] sanei_usb_write_bulk: trying to write 4 bytes
[sanei_usb] 000 01 07 00 01 ....
libusb:warning [do_sync_bulk_transfer] unrecognised status code 1
[sanei_usb] sanei_usb_write_bulk: write failed: Other error
libusb:error [op_clear_halt] clear_halt failed error -1 errno 71
[plustek] UIO error
[plustek] cano_PrepareToReadWhiteCal() failed
[plustek] calibration failed!!!
[plustek] IPC: Transferrate = 292480 Bytes/s
[plustek] sane_read - read 0 bytes
[plustek] drvclose()
[plustek] TIME END 1: 19s
[plustek] usbDev_stopScan()
[plustek] usbDev_ScanEnd(), start=0, park=0
[sanei_usb] sanei_usb_write_bulk: trying to write 4 bytes
[sanei_usb] 000 01 07 00 01 ....
[plustek] reader_process: read failed, status = -9004, errno 71
Segmentation fault

################################

sane backends version

[root@# ~]$ yum info sane-backends
Loaded plugins: auto-update-debuginfo, langpacks, refresh-packagekit
Installed Packages
Name : sane-backends
Arch : x86_64
Version : 1.0.24
Release : 7.fc20

Same problem with a CanoScan N670U on a ZBook 15. It works on my older computers with USB2.

It's not a general problem with USB3. An external USB3 disk works, pendrives work too. Connecting my Android phone also works. Another device that doesn't work yet is a Samson USB mic. I still have to investigate that issue.

No it isn't a gneral USB3 problem - I would imagine far more people would be getting excited if it was (although I've seen some sporadic disconnects with USB1 printers but not convinced that is related). My guess (and it is just a guess) is that it is something about the userspace interface that the kernel exposes which isn't quite right OR something fundamental has changed in that arena and the libusb developers have yet to pick up on it.

It looks like a patch could fix this bug:
https://<email address hidden>/msg30015.html
but it is not queued for integration yet in any kernel version.

One year passed from the patch (07 Oct 2013), why it isn't pushed in any kernel release?

It looks like the patch had some shortcomings and I can't find a revised version anywhere.

I tried applying it to Debian Jessie's 3.16 kernel and it had (what appeared to be) only minor conflicts which I resolved. Unfortunately the patched kernel doesn't compile due to incompatible upstream changes.

This same bug I posted on the SANE developers page - #314472, https://alioth.debian.org/tracker/?func=detail&atid=410366&aid=314472&group_id=30186 has now been marked as fixed by one of the developers (Gerhard Jaeger) as follows:

"I close this PR now, as it is fixed in the sources since 16.12.2014.
Successfully tested with USB 3 and a LiDE30."

So I guess at some point this will make it's way into the Ubuntu sources....

Same issue here with a LiDE 30, in all the ports in my system (USB 2.0 and 3.0).

$ lspci | grep USB
00:14.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family USB xHCI (rev 05)
00:1a.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family USB EHCI #2 (rev 05)
00:1d.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family USB EHCI #1 (rev 05)

$ lsusb | grep Canon
Bus 003 Device 006: ID 04a9:220e Canon, Inc. CanoScan N1240U/LiDE 30

If there is a fix around, as it looks like, any idea of which package to monitor, upgrade or compile?

I just upgraded SANE as the git version in ppa:rolfbensch/sane-git (https://launchpad.net/~rolfbensch/+archive/ubuntu/sane-git), and so far it seems to be working great.

Note: the version I have tested with is 1.0.25-git20141220-utopic0, and a Canon LiDE 30 scanner.

I tested sane package 1.0.25-git20150101-trusty0 with a Canon N670U and it solves my issues as well. Thanks for the hint to the ppa!

I installed sane-backends - 1.0.25-git20150121-precise0 and upgraded libsane, sane-utils and libsane-common but this didn't fix the issue for me.

scanimage -L

now appears to consistently identify the scanner:

device `plustek:libusb:001:019' is a Hewlett-Packard Scanjet 2100c flatbed scanner

but issuing a scanimage command just bails out after a few seconds:

 scanimage -vvv -format pnm >outfile.pnm
Calling sane_exit
scanimage: finished

there is no activity from the scanner.

When I first raised the bug I'd been playing around with various sources from sane & libusb so it's possible something isn't quite linking together but I'm pretty sure I've removed all those remnants from the /usr/local area and everything now appears to be linking to the "correct" (ie. in the /usr/lib/x86...) area.

Allow me to retract my last comment, those eagle eyed amongst you may have spotted the syntax error in my use of the scanimage command (should be --format not -format, clearly operator incompetence there). With that corrected, I too can also confirm correct operation with the Scanjet. There does appear to be a slight permissions thing going on with the saned daemon itself, in that unless I launch it as root (as opposed to the sane user) I get:

Jan 24 17:45:52 monolith saned[30265]: io/hpmud/musb.c 139: unable get_string_descriptor -1: Operation not permitted
Jan 24 17:45:52 monolith saned[30265]: io/hpmud/musb.c 2040: invalid product id string ret=-1
Jan 24 17:45:52 monolith saned[30265]: io/hpmud/musb.c 139: unable get_string_descriptor -1: Operation not permitted
Jan 24 17:45:52 monolith saned[30265]: io/hpmud/musb.c 2045: invalid serial id string ret=-1
Jan 24 17:45:52 monolith saned[30265]: io/hpmud/musb.c 139: unable get_string_descriptor -1: Operation not permitted
Jan 24 17:45:52 monolith saned[30265]: io/hpmud/musb.c 2050: invalid manufacturer string ret=-1
Jan 24 17:45:54 monolith saned[30265]: quit: exiting

and it doesn't then scan - but that's a separate issue..

I compiled sane-backends-1.0.25+git20150102 and changed the old libsane.so with the new one.
Scanner is now working: CanoScan LiDE 25.

System Fedora 21

thank you.

Any fix for vivid?
Tried the sane backend dev ppa, but was getting crash notifications on boot.

Have a lide 210.

Please where was the fix committed?
In the Jörg's PPAs https://launchpad.net/~jff-de I do not see it?

What is preventing the fix to be released?

Running trusty with N670U (LiDE 20) the issues were resolved using https://launchpad.net/~rolfbensch/+archive/ubuntu/sane-git/+build/7834143 . I'm also missing updated packages in default ubuntu repositories.

This issue is still present with my LiDE 30, even using Rolf's the PPA (1.0.26-git20160103-wily0).

Actually, it does work with the PPA when connecting it to a different USB slot.

Reported a separate bug for the intermittent issue I am having now, with more detail added. https://bugs.launchpad.net/ubuntu/+source/sane-backends/+bug/1532292

It may be a fully separate issue, or it may be related.

Does this help?

I'm using an Epson Perfection 2450 Photo, which some time ago I thought had gone wrong because it suddenly stopped working with my desktop computer. When using xsane it finds the scanner OK, then when I try to get a preview it puts up an error message:- "Error during read: Error during device I/O". Damn.

When I lspci on the desktop computer I get (pruning out everything other than the USB parts

00:02.0 USB controller: NVIDIA Corporation CK804 USB Controller (rev a2)
00:02.1 USB controller: NVIDIA Corporation CK804 USB Controller (rev a3)
.
.
01:07.0 USB controller: NEC Corporation OHCI USB Controller (rev 41)
01:07.1 USB controller: NEC Corporation OHCI USB Controller (rev 41)
01:07.2 USB controller: NEC Corporation uPD72010x USB 2.0 Controller (rev 02)
02:00.0 USB controller: VIA Technologies, Inc. VL80x xHCI USB 3.0 Controller (rev 03)

Now it gets really interesting. If I plug the same scanner into my little 10" Toshiba laptop, it works perfectly. Both computers are running 64 bit Mint 17/Mate.

I think the crucial difference might be in the hardware When I lspci on the laptop the USB controller lines all say
Intel Corporation NM10/ICH7 Family USB UHCI Controller#1-4 (rev 02)

So maybe the problem is actually with a USB driver? Intel has a reputation for being better supported than other hardware.

re #31, in my original bug report, I'd tentatively concluded this was an issue with USB3 and I note in your report you also have issues with USB3. For me, as I mentioned in #23, installing the updated sane backends pretty much fixed this problem for me on a USB3 root hub. It's still fairly temperamental though, the major annoyance being it seems to take 30s to a minute to start scanning.

Personally, I think the USB3 subsystem is as buggy as anything, particularly with slower devices. I have encountered numerous spurious messages emitted from the kernel and complete system lockups all related to USB regardless of the type of peripheral in use.

It's worse than that for me - as far as I can tell the problem is with ANY non-Intel USB hub. As I have an AMD motherboard in this computer and Intel, I believe, do not make standalone chips for supporting USB i.e. there's no chance of getting a PCIE board with an Intel USB hub on it, I'm pretty well stuffed with this computer.

Unless somebody fixes whatever it was that was screwed up when my scanner stopped working.

It's been a couple of months now since I last commented.

I would really like to know if anybody is looking at this bug?

Seems to me that the only way to have this scanner working with my desktop PC is to build a new PC with Intel rather than AMD parts when not so long ago it worked perfectly well with my AMD PC. That would be silly.

If there is any way I can help by providing diagnostics please say so.

Another three months has gone by. It still doesn't work. Seems like either the relevant person doesn't know, hasn't had time to fix it, is out of touch or doesn't care.

I have now kind of side stepped the problem. Anther computer that I own and built is a little server, running 24/7, with an Atom processor. I connected the scanner to my server instead of my desktop and installed sane-utils as in a how-to, edited the configs on the server and AMD desktop, rebooted.

Now I can scan again, via my network. Obviously I shouldn't have to screw around like this but at least I appear to have a solution unlike anybody who only has one, AMD based computer.

Status changed to 'Confirmed' because the bug affects multiple users.

jon bird, thank you for reporting this and helping make Ubuntu better.

To see if this is already fixed in Ubuntu, could you please test for this via http://cdimage.ubuntu.com/daily-live/current/ and advise to the results?

since kubuntu 16.04 my canoscan lide 20 works fine again plugged in usb3.

I've performed the upgrade from 12.04 to 14.04 over the Christmas break which has restored all the repositories back to default (I was using the PPA from Rolf's PPA to work round this) and can confirm it's all working now. There's still the massive delay on the start of the initial scan (as mentioned in #32) which consumes 100% of the CPU but I can live with that.

jon bird, this bug report is being closed due to your last comment https://bugs.launchpad.net/ubuntu/+source/sane-backends/+bug/1250196/comments/39 regarding this being fixed with an update. For future reference you can manage the status of your own bugs by clicking on the current status in the yellow line and then choosing a new status in the revealed drop down box. You can learn more about bug statuses at https://wiki.ubuntu.com/Bugs/Status. Thank you again for taking the time to report this bug and helping to make Ubuntu better. Please submit any future bugs you may find.