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): sane-backends-1.0.18-2.fc5 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 scanning order. Further: 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 dpi_range.min=100). 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 debug-sane-backends-1.0.18-5.krp1-colour-preview
Created attachment 156997 [details] sane-backends-1.0.18-5 patched with latest CVS - colour preview FAILS - stuck scan head debug-sane-backends-1.0.18-5.krp1-colour-preview-STUCKHEAD
Created attachment 156998 [details] sane-backends-1.0.18-5 with dpi_range.min=100 (otherwise unpatched) - colour preview scan FAILS - stuck scan head debug-sane-backends-1.0.18-5.fc6_range100-colour-preview-STUCKHEAD 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 distributions).
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 since... - I still have the preview scan / stuck head failures
Is that the -33 or -41 kernel?
kernel-2.6.22.1-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 avail).
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.