On 2003.04.11 11:57 Henning Meier-Geinitz wrote:
> I have no experience with your scanner but maybe the comments help
> nevertheless.
Yes, thanks to everybody who responded.
It is a SMP system.
I've tried scanimage and see the same problems.
'modprobe sg' prior to starting xsane gets rid of the problem
where no devices are recognized the first time. Thanks.
I've tried with scsi reconnect disabled on the bus and that doesn't
help.
The thing that would be odd if it was a scsi problem is that I
haven't touched the hardware (until this happened and I started
poking with a stick.)
Sounds like the consensus is to upgrade.
So, I've installed the sane-backend and sane-frontend 1.0.11 (rpm
release 1)
rpms uploaded by T. Ribbrock to Redhat's site. (I couldn't compile them
without installing too many dependencies.) And recompiled and
installed the
xsane 0.90 (rpm release 1) rpm. (I couldn't install the binary because
of
dependencies.) And now what's happening is that the scanner device is
never found. scanimage doesn't find the scanner either, but
sane-find-scanner
does. Something overwrote my config file without telling me. The new
/etc/sane.d/hp.conf file (after my messing with it) is:
/dev/sg3
scsi HP C2520A * * * * *
sane-find-scanner says:
[root@mofo root]# sane-find-scanner
found SCSI processor "HP C2520A 3644" at /dev/sg3
found SCSI processor "HP C2520A 3644" at /dev/sgd
/dev/sg3 has world read/write permissions.
Old messages quoted below. Nothing new here. Move along folks:
>
> > I've got a HP Scanjet model 6100C (product C2520A) attached
> > to a Adaptec 1524 scsi card. Right now I'm running the
> > latest RedHat 7.2:
> >
> > xsane-0.82-3.1
> > sane-backends-devel-1.0.5-4.1
> > sane-backends-1.0.5-4.1
> > xsane-gimp-0.82-3.1
> > sane-frontends-1.0.5-2
>
> That's really old (sane-backends 1.0.11 is current).
>
> > Linux mofo.meme.com 2.4.18-27.7.xsmp #1 SMP Fri Mar 14 05:52:30 EST
> > 2003 i686 unknown
>
> Is this really a SMP system?
>
> > One upon a time, it worked. (I recall somewhere in the early .60
> > xsane releases, maybe.)
>
> XSane is only the frontend (scan application) so most probably yor
> problem does not depend on xsane (or any other frontend). But to make
> sure, you can try scanning with xscanimage or scanimage.
>
> > As time has gone by it's taken longer and longer to scan. The delay
> > is 'between' the little noises the scanner makes. Right away
> there's
> > a noise (where the scanner resets?) Then a pause. Then another nose
> > a bip-bop (where the scan head zeros?) Then a noise when it first
> > scans and then moves the scan head back to the resting position.
> The
> > pause between the noises gets longer and longer. After installing
> > the latest kernel upgrade it now takes about 10 minutes or so to go
> > through the whole cycle and, this is new, the resultant image is
> > black.
>
> For me that looks like a SCSI command times out or some other SCSI
> trouble. Have you changed the kernel version in the meantime? Updating
> (or even changing to an older version) may help.
>
> > I don't use the scanner much at all, and leave the machine up for
> > months. I used to be able to rmmod the aha152x module and then
> > modprobe it and the delays would go away. I figured there was a
> > memory leak (mozilla/galeon seems to have one) or something
> somewhere.
> > Now, the scanner is unusable. (And it's tax time. :)
>
> I would be surprised if a memory hole in a userspace application would
> cause such problems.
>
> > FWIW, for quite a while I've had to start xsane twice.
> > The first time it always says
> > that no device is found.
>
> One reason for that may be that automatic loading of the sg module
> doesn't work as expected. If /dev/scanner points to your scanner, this
> shouldn't be a problem, however.
>
> Try modprobe sg before running xsane. If this works with the first
> call of xsane it's the problem I menitioned. It's not connected to
> your other problem.
>
> > IIRC, maybe, that when I first got the scanner working I didn't have
> > this problem. The scsi II cable is a little long, going from the
> > floor to the desk but.... There are also 2 other devices attached
> to
> > the same scsi chain, and they seem to work. There's no messages in
> > dmesg or /var/log/messages. (Except for the bus reset related stuff
> > from my module reloading.)
>
> That's odd. But too long or bad cables and wrong termination can have
> all kinds of nasty effects. And sometimes some of the devices work
> anyway.
>
> > What's the best way to approach fixing this problem? I once had
> faith
> > that HP devices would continue to work, but their printers now seem
> to
> > break regularly. Is this a hardware problem? The lamp is old and
> > weak or a sensor needs the dust removed? It doesn't have that sort
> of
> > feel. (It has the feel of scsi hell.) I've tried disconnecting
> some
> > of the other devices on the bus (and adding an active terminator) to
> no
> > effect.
>
> I also think it's SCSI-related. Maybe also a problem with the SCSI
> driver. But to make sure, you could try the scanner on a different
> computer, e.g. with MS Windows.
>
> > (I've just downloaded the RH 9 sane and xsane source rpms, but I
> don't
> > know if they'll compile without a lot of hassle and I'm not
> confident
> > that will fix the problem.)
>
> If it's a SANE problem, updating sane-backends should solve it.
>
> > hp.conf is:
> >
> > scsi HP C2520A * * * * *
>
> Adding /dev/scanner (or /dev/sgwhatever) before that may solve the
> detection problem.
>
> > modules.conf is:
> >
> > alias scsi_hostadapter aic7xxx
> > alias scsi1 aha152x
> > options aha152x io=0x340, irq=10, sync=0
>
> Have you checked for io/irq conflicts?
>
> > Here's some relevant /var/log/messages output:
> >
> > Apr 10 21:28:35 mofo kernel: aha152x1: vital data: rev=1, io=0x340
> > (0x340/0x340), irq=10, scsiid=7, reconnect=enabled, parity=enabled,
> > synchronous=disabled, delay=1000, extended translation=disabled
>
> Some scanners don't like reconnect.
Peter Kirchgessner <peter@kirchgessner.net> wrote:
> if you believe it is a memory problem, you can run xosview to watch
> the memory use during scan.
> But it really may be a hardware problem. The scanner is warming up
> the lamp and is waiting until the light stabilizes. And maybe you
> have a version of the hp-backend that switches off the lamp after
> each scan. The current backend will not do that. This could also
> speed up the following scans.
Karl <kop@meme.com>
Free Software: "You don't pay back, you pay forward."
-- Robert A. Heinlein