Bug 59979 - scanimage -L fails with modular SCSI drivers
Summary: scanimage -L fails with modular SCSI drivers
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: sane-backends
Version: 7.2
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Tim Waugh
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2002-02-17 15:21 UTC by Tethys
Modified: 2008-05-01 15:38 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2002-03-05 10:17:03 UTC
Embargoed:


Attachments (Terms of Use)

Description Tethys 2002-02-17 15:21:38 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011221

Description of problem:
When checking for the presence of devices, scanimage merely checks
the contents of /proc/scsi/scsi, rather than actually scanning the
SCSI bus. If using modular SCSI drivers that aren't currently loaded,
then this causes it to incorrectly report that no devices are attached.
The workaround is trivial -- merely do something that causes the
module to be loaded (echo something to a SCSI device, or run
something like "cdrecord -scanbus"). However, that's not much use
to non-technical users, who don't know such things.

Note that this is a generic sane-backend problem, rather than being
specific to scanimage. xsane and xscanimage exhibit the same behaviour.

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. Make sure your SCSI modules aren't loaded
2. Run scanimage -L
3.
	

Actual Results:  It reports that no scanners were idenitifed

Expected Results:  It should have detected the presence of my scanner

Additional info:

leto:~% cat /proc/scsi/scsi 
Attached devices: none
leto:~% cat /proc/modules 
es1371                 26640   0 (autoclean)
ac97_codec              9664   0 (autoclean) [es1371]
soundcore               3984   4 (autoclean) [es1371]
ide-cd                 26784   0 (autoclean)
cdrom                  27808   0 (autoclean) [ide-cd]
binfmt_misc             6064   1
3c59x                  25696   1
vfat                   10032   1 (autoclean)
fat                    31680   0 (autoclean) [vfat]
leto:~% scanimage -L

No scanners were identified. If you were expecting something different,
check that the scanner is plugged in, turned on and detected by the
sane-find-scanner tool (if appropriate). Please read the documentation
which came with this software (README, FAQ, manpages).
leto:~% echo abc > /dev/sg0
leto:~% scanimage -L
device `epson:/dev/sg0' is a Epson GT-7000 flatbed scanner
leto:~% cat /proc/modules 
dc395x_trm             49824   0 (autoclean)
sg                     29968   0 (autoclean)
es1371                 26640   0 (autoclean)
ac97_codec              9664   0 (autoclean) [es1371]
soundcore               3984   4 (autoclean) [es1371]
ide-cd                 26784   0 (autoclean)
cdrom                  27808   0 (autoclean) [ide-cd]
binfmt_misc             6064   1
3c59x                  25696   1
vfat                   10032   1 (autoclean)
fat                    31680   0 (autoclean) [vfat]
leto:~% cat /proc/scsi/scsi 
Attached devices: 
Host: scsi0 Channel: 00 Id: 04 Lun: 00
  Vendor: EPSON    Model: SCANNER GT-7000  Rev: 1.14
  Type:   Processor                        ANSI SCSI revision: 02
Host: scsi0 Channel: 00 Id: 06 Lun: 00
  Vendor: YAMAHA   Model: CRW8824S         Rev: 1.00
  Type:   CD-ROM                           ANSI SCSI revision: 02

Comment 1 Tim Waugh 2002-02-19 14:46:01 UTC
Thanks.  Reported upstream.
<http://panda.mostang.com/pipermail/sane-devel/2002-February/002477.html>

Comment 2 Tethys 2002-02-19 21:49:12 UTC
You say:

>After running it once (and it fails), the drivers appear to have been
>automatically loaded (by an open("/dev/sg0") I think), and so a
>subsequent 'scanimage -L' works.

However, this isn't true in my case. Repeated invocations of scanimage -L
*all* fail. The first one doesn't cause the modules to be loaded, and it's
not trying to open /dev/sg0. As I said before, it appears to be determining
the presence of a device purely by checking /proc/scsi/scsi:

leto:~# strace -e open scanimage -L
open("/etc/ld.so.preload", O_RDONLY)    = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY)      = 3
open("/usr/lib/libsane.so.1", O_RDONLY) = 3
open("/lib/libnsl.so.1", O_RDONLY)      = 3
open("/lib/i686/libm.so.6", O_RDONLY)   = 3
open("/usr/lib/libjpeg.so.62", O_RDONLY) = 3
open("/lib/libdl.so.2", O_RDONLY)       = 3
open("/lib/i686/libc.so.6", O_RDONLY)   = 3
open("./dll.conf", O_RDONLY)            = -1 ENOENT (No such file or directory)
open("/etc/sane.d/dll.conf", O_RDONLY)  = 3
open("./dll.aliases", O_RDONLY)         = -1 ENOENT (No such file or directory)
open("/etc/sane.d/dll.aliases", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/lib/sane/libsane-epson.so.1", O_RDONLY) = 3
open("/usr/lib/sane/libsane-epson.so.1", O_RDONLY) = 3
open("./epson.conf", O_RDONLY)          = -1 ENOENT (No such file or directory)
open("/etc/sane.d/epson.conf", O_RDONLY) = 3
open("/proc/scsi/scsi", O_RDONLY)       = 4

No scanners were identified. If you were expecting something different,
check that the scanner is plugged in, turned on and detected by the
sane-find-scanner tool (if appropriate). Please read the documentation
which came with this software (README, FAQ, manpages).


This is with the epson backend. "epson" is the only entry in my dll.conf.
My epson.conf file merely says:

scsi EPSON

Comment 3 Tim Waugh 2002-02-22 14:30:38 UTC
Different symptoms of the same bug, I think.

Comment 4 Tim Waugh 2002-02-25 10:52:44 UTC
Are you able to try out the patch at
<http://panda.mostang.com/pipermail/sane-devel/2002-February/002602.html> at all?

It opens /dev/sg0 immediately before looking at /proc/scsi/scsi.  I'd be
interested to know if this fixes the problem for you.

Comment 5 Tethys 2002-02-28 00:27:10 UTC
Yep, the patch fixes the problem for me with the epson backend
(against 1.0.7, rather than the 1.0.5-4 that you ship with 7.2).
Not sure why it's failing for you. Testing revealed a strange
side effect, though (see bug 60470, which is triggered both with
and without this patch).

Comment 6 Tim Waugh 2002-04-22 15:42:18 UTC
Fixed in 1.0.7-6.


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