Bug 141732 - sane hoses usb scanner
sane hoses usb scanner
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: sane-backends (Show other bugs)
3
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Tim Waugh
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-12-03 07:39 EST by Sitsofe Wheeler
Modified: 2007-11-30 17:10 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-12-06 07:17:58 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Sitsofe Wheeler 2004-12-03 07:39:42 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040804 Galeon/1.3.17

Description of problem:
After some config file tweaking and firmware downloading I managed to get scanimage -l to detect an attached usb scanner. However doing scanimage by itself fails with some USB errrors reported by the kernel. scanimage -L no longer works.

Version-Release number of selected component (if applicable):
sane-backends-1.0.14-6

How reproducible:
Always

Steps to Reproduce:
1. Boot computer.
2. Log in as root over ssh.
3. Do scanimage -L . Note that:
device `snapscan:libusb:001:002' is a Acer FlatbedScanner22 flatbed scanner
is returned.
4. Do scanimage > /dev/null

Actual Results:  The following output is produced:
scanimage: open of device snapscan:libusb:001:002 failed: Error during device I/O

Expected Results:  Not sure. Never seen success.

Additional info:

The following is in dmesg:
usb 1-1: bulk timeout on ep1in
usb 1-1: usbfs: USBDEVFS_BULK failed ep 0x81 len 8 ret -110
usb 1-1: bulk timeout on ep2out
usb 1-1: usbfs: USBDEVFS_BULK failed ep 0x2 len 6 ret -110

scanimage -L no longer finds anything.

Unplugging and replugging the scanner moves it to a different address making scanimage -L work again, but repeating the steps results in the same problem.

Doing rmmod ohci_hcd; modprobe ohci_hcd makes whichever socket the USB scanner went wrong on disappear for good.
Comment 1 Sitsofe Wheeler 2004-12-03 07:40:49 EST
Argh! Sorry for the long lines... This was done using the (Guided) bug entry
form on the beta bugzilla.
Comment 2 Tim Waugh 2004-12-03 07:49:20 EST
There were some snapscan changes between SANE 1.0.14 and 1.0.15.  Please try
downloading and installing the sane-backends-1.0.15-7 package from here:

ftp://download.fedora.redhat.com/pub/fedora/linux/core/development/i386/Fedora/RPMS

Does that still give the same problem?
Comment 3 Sitsofe Wheeler 2004-12-03 08:15:15 EST
I might be a little while I am rebuilding the src.rpm against FC3 bits because I
don't want drag the system too far away from a "standard" install (I think it
wanted a newer pam and hotplug).
Comment 4 Sitsofe Wheeler 2004-12-03 08:49:10 EST
And after all that the rebuilt RPM still wanted a newer pam and hotplug. Hpmph,
why didn't it warn me when I was installing the SRPM? Ah well, I shoved it on
using --nodeps.

Sigh. After upgrading /sbin/lsusb no longer detects the scanner at all. The
following is in dmesg:

ohci_hcd 0000:00:02.0: wakeup
hub 1-0:1.0: Cannot enable port 2.  Maybe the USB cable is bad?
hub 1-0:1.0: Cannot enable port 2.  Maybe the USB cable is bad?
usb 1-2: new full speed USB device using address 4
usb 1-2: device not accepting address 4, error -110
usb 1-2: new full speed USB device using address 5
usb 1-2: device not accepting address 5, error -110
Comment 5 Sitsofe Wheeler 2004-12-03 09:36:47 EST
I figured I'd just double check whether I had the right firmware, you know, just
in case...

It turns out I had the wrong firmware. The scanner is an Acer/BenQ 4300U and is
reported as:
Bus 001 Device 017: ID 04a5:20b0 Acer Peripherals Inc. (now BenQ Corp.) S2W
3300U/4300U
in lsusb. According to http://snapscan.sourceforge.net/ this means I should need
the "u222v067.bin" firmware if you go via the "ID String" column. However, the
USB ID column for 0x04a5, 0x20b0 says you need the "u176v046.bin". The USB ID
column was the right one for me.

Clearly this is a user created problem. I think the only way I could salvage a
bit of dignity out of this bug is perhaps if I turn it into an enhancement
request for SANE to warn users about uploading the wrong firmware...
Comment 6 Tim Waugh 2004-12-06 07:17:58 EST
Nice try. :-)
Comment 7 Sitsofe Wheeler 2004-12-06 07:42:21 EST
Dang! I'll get you next time Waugh! : )

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