Bug 206094
|
Description
Kevin R. Page
2006-09-11 23:35:42 UTC
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. |