Description of problem: Preview fails in xsane with a ScanJet 5370C using the
avision sane backend.
On the first attempt, the preview scan is successful. On the second, and all
further, attempts the scan head moves back and forth a small amount (initial
alignment?), then makes the noise (possibly motor strain?) or trying to make the
preview scan - but the scan head doesn't move.
All further attempts fail until _all_ the following have been performed:
1) unplug the scanner from mains and USB
2) modprobe out, then modprobe in ehci_usb (I can't try uhci_usb due to bug 200122)
3) plug the scanner back in
4) run a preview scan in VueScan
Now, 4) seems odd - but if I don't do this then xsane hangs on startup with
device I/O errors. This behavior bears a striking similarity to the problems I
had in bug 205092 comment 1; indeed after the first failed preview scan, if I
unplug the scanners USB cable then plug it back in (without bus or scanner
reset) I get the error:
Sep 12 00:13:10 localhost kernel: usb 1-1.3: new full speed USB device using
ehci_hcd and address 8
Sep 12 00:13:13 localhost kernel: usb 1-1.3: device descriptor read/64, error -110
This is also the "another (different again) USB" error of bug 205092 comment 1;
this bug is now solved, but the behavior seems similar. I don't know what's
going on in the avision backend, but it seems almost as though it puts the
scanner into some kind of undefined state.
Version-Release number of selected component (if applicable):
How reproducible: Once triggered, always.
Created attachment 136043 [details]
xsane output with successful preview scan
Created attachment 136044 [details]
xsane debug with a preview scan that fails
Sorry for taking so long to respond. The needed rmmod/insmod thing and the
device I/O error hint at a kernel problem though.
Changing component to kernel.
Created attachment 156852 [details]
Mail to sane-avision list
I'm not convinced this is a kernel problem.
N.B. I only get the I/O errors _after_ the problem has been triggered in SANE.
i.e. I suspect I only need to use rmmod/insmod to reset the USB bus, kicking the
scanner out of the invalid state it seems to have been placed into (by SANE?
Could SANE do this?).
I posted some progress earlier in the year to the sane-avision mailing list, but
haven't had a chance to do anything further recently. This email is attached.
This is a regression, as this scanner is known to have worked in earlier versions.
Changing back the component to sane-backends.
Kevin, unfortunately the amount of scanner hardware I have is rather limited but
theoretically the sane backend could "confuse" your scanner enough that
power-cycling it is needed. If I understand your mail to the list correctly,
there have been some improvements in the SVN version of the time of your mail
(Jan 2007), but some regressions as well. Are there any changes -- good or bad
-- with the current SVN version?
I have re-tested with sane-backends-1.0.18-5.fc6, and also a rebuild of the
package with the latest CVS versions of avision.c and avision.h applied.
The "stuck head" problem (the scanhead doesn't move on any preview scan after
the first) happens with both; once in this state, it can only be cleared by the
process described in comment 0.
Interestingly, the if the following sequence if followed:
1) start scanner
2) perform colour preview scan
3) perform colour full scan
4) perform gray preview scan
5) perform gray full scan
the head _doesn't_ become stuck.
Unfortunately, the scanner is remotely located, so I need assistance at the
remote end to perform any tests which end up in the stuck-head state. This means
I don't really have the time or ability to exhaustively test all combinations of
patching sane-backends-1.0.18-5.fc6 to set dpi_range.min to 100 rather than 80
gives good scans (without this the gray fullscan is unusably dark).
Unfortunately, the CVS versions don't scan well - all colour scans are heavily
tinted in blue, and the gray full scan is unusably dark (even with
I will attach 3 further debug outputs.
I also include a summary of some tests I made back in January, trying to
pinpoint which CVS revision broke this scanner.
Hardware for all is:
[avision] attach: Inquiry gives mfg=HP, model=ScanJet 5370C, product revision=3.00.
[avision] attach: Found model: 51
Created attachment 156996 [details]
sane-backends-1.0.18-5 patched with latest CVS - colour preview scan working
Created attachment 156997 [details]
sane-backends-1.0.18-5 patched with latest CVS - colour preview FAILS - stuck scan head
Created attachment 156998 [details]
sane-backends-1.0.18-5 with dpi_range.min=100 (otherwise unpatched) - colour preview scan FAILS - stuck scan head
unfortunately I don't consider the corresponding
debug-sane-backends-1.0.18-5.fc6_range100-colour-preview to be reliable - I
screwed up when collecting that particular log :(
Created attachment 157002 [details]
Analysing changes in avision CVS revisions
From these, and further test, I'd guess the "stuck-head" problem was introduced
between r209 and r210.
The avision developer prefers to work through the sane-avision mailing list;
unfortunately there isn't currently an archive.
Nils, would it help if you had the hardware?
Kevin, because I don't possess the hardware I'm not familiar with the backend
code and I'd need quite some time to become that. Unfortunately, the time I can
spend on sane-backends is rather limited, so I guess your problem will be solved
faster if you work with upstream (as there should be developers who own the
hardware and know the code). I'd be glad if you let me know when there are
improvements that I can massage back into the package (sane-backends is not that
frequent with releases).
I'll close this as UPSTREAM, meaning I can't help you right now. Please reopen
this BZ when there are changes upstream that may help with your problem so I can
possibly update the package with a fix.
Progress upstream is, unfortunately, very slow and I don't think I've really got
anywhere in 6 months. I've collected a lot of debug information and I think I've
narrowed down the point at which the regression occured, but I'm also unfamiliar
with the backend code, so unable to guess the consequenses of reverting any code.
I fear that changes made for newer hardware have caused this regression breaking
the driver for older hardware - I guess this once working hardware will now just
have to be chalked up as incompatible on Fedora/Redhat (and probably most other
Kevin, I've put sane-backends-1.0.18-12 into updates-testing which contains a
lot of fixes pertaining to USB scanners. You might want to try it out even
though I know there aren't any special changes for the avision backend. Check
your kernel version though if you use F7 -- see bug #243953.
Using sane-backends-1.0.18-12 and the latest F7 kernel:
- any user except root cannot access the scanner. It looks like the bug you
references, but I didn't have time to investigate further, and it's irrelevant
- I still have the preview scan / stuck head failures
Is that the -33 or -41 kernel?
kernel-22.214.171.124-33.fc7 - I'll track the device access / udev issues via bug
243953, where it looks like they're fixed.
(I recently tested some upstream changes re: the stuck head problem, but to no
This wasn't resolved upstream, unfortunately. I eventually received some help
from the developer, but he has a different revision of the hardware which
doesn't exhibit this problem. I provided copious amounts of debug, and narrowed
the problem down to a few sections of code, but this didn't really get me
anywhere. It's older hardware, and there can't be many users - so I can see why
there's little interest in fixing it... it not really worth expending any more
time on. Annoyingly there's no archive of the sane-avision list.
So, as of Fedora 8 there are definitely some revisions of this scanner (with C5
ASICs) that don't work. The particular 5370C in question was retired after a
year of trying.