> Not since v0.51 has sane-os2 worked with the E3, at least not for
>me - see several postings last July & August under the thread title
>"Microtek E3 won't scan but II-G okay (SANE OS/2)".
Man, I just re-discovered that entire thread in my mailbox, patiently
waiting to be dealt with....
> With the new snapshot, the E3 no longer executes those
>preliminary moves - Sane-OS/2 just reports an I/O error. I'm
>attaching a pair of log files created by redirecting stdout to file;
>"10test.log" is a typical aborted run with last summer's build, and
>"11test.log" uses the 0.11.1 microtek backend as included in last
>weekend' developmental snapshot. Both tests were run with
>sane_debug_sanei_scsi=128 and sane_debug_microtek = 128.
Ok, first just a nit-pick: "10test.log" bugged out because of an
"unrecognized option `--calib_once=yes'" to scanimage (the option
is new with v0.11.0 of the backend). But, I still have the logs
you sent from last summer, so I'm set with that.
Something changed in the OS/2 scsi code between the two releases,
because the new version is actually calling the sense handler, which
reports "ERR_SCSICMD", i.e. a "SCSI Command Error" in Microtek
parlance, which could mean a number of things, among them:
a) the command was just not recognized.
b) the command was sent at an inoportune time.
The command that bombed was the magic, undocumented "start calibration"
command, which *should* work on an E3 just as well as an E6 -- well,
that is a guess, since the entire command stream for that was kind
of a guess. However, if you add "norealcal" and "noprecal" to the
.conf file, all this calibration stuff will be skipped --- please
do this, see what happens, send the full log to me.
(Assuming the .conf file is parsed correctly; the log file will reveal
this one way or the other.)
In one of your earlier messages, you suggested that maybe there was
a *timing* problem involved here. That is not out of the realm of
possibilities --- although the E3/E6 seem to be pretty well designed
in this regard. My E6 will happily accept a command and finish
whatever it was doing before it executes it, whereas the previous
generation of scanners seem to complain if they are asked for something
else too soon.
So, possibility (b) might be related to that. After I get a look at
the non-precal debug log, I'll try adding some retry-code to the
backend --- I haven't done this before because the original lame
linux scsi drivers never returned reliable sense codes, so I never
got any sense errors to act upon anyway. (I think the new drivers
have fixed that now/soon. I'm not sure. Anyone know?)
But, as far as (b) is concerned, the process fails at a point where
timing just shouldn't be a problem. Hmmmm. It would be nice to
get more detailed look of what the scsi system thinks is happening.
Anyhow, if the ERR_SCSICMD can be trusted, then the scanner is
bitching about something, and it's not just that the OS/2 scsi
system has bombed out. But, maybe the OS/2 scsi system sent
bogus stuff to the scanner, and the scanner is bitching about
that.
This (older) generation of Microtek scanners seem pretty well built
and designed to me, *except* for the scsi interface. That part was
definitely coded by a crack team consisting of a monkey and maybe
a racoon or squirrel.
-matt m.
-- Source code, list archive, and docs: http://www.mostang.com/sane/ To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com
This archive was generated by hypermail 2b29 : Mon Feb 14 2000 - 21:23:29 PST