[sane-devel] old Agfa DuoScan / Floating point exception
linux at daniel-bauer.com
Mon Apr 17 18:53:30 UTC 2006
Am Montag, 17. April 2006 19:39 schrieb Matto Marjanovic:
thank you Matto, for taking your time, too!
> >From: Daniel Bauer <linux at daniel-bauer.com>
> >Date: Mon, 17 Apr 2006 18:08:06 +0200
> >I've added the above in "microtek.c" and compiled again. Now there's much
> > more output (all done as root):
> >venus:~ # export SANE_DEBUG_MICROTEK=128
> >venus:~ # echo $SANE_DEBUG_MICROTEK
> >venus:~ # scanimage --device-name=microtek:/dev/sg0
> >[sanei_debug] Setting debug level of microtek to 128.
> >[microtek] .scanning_frame...
> >[microtek] .scanning_frame: in- 0,0 8299,13499
> >[microtek] .scanning_frame: out- 0,0 8299,13499
> >[microtek] .accessory...
> >[microtek] .download_gamma...
> >[microtek] .download_gamma: 4096 entries of 2 bytes, max 255
> >[microtek] .download_gamma: by default
> >[microtek] .mode_select 3...
> >[microtek] .mode_select: pap_len: 13499
> >[microtek] .mode_select_1 3...
> >[microtek] .wait_ready 3...
> >[microtek] .start_scan...
> >[microtek] .get_scan_status 3...
> >[microtek] SENSE! fd = 3
> >[microtek] sense = 00 00 00 00.
> >[microtek] get_scan_status(6): 0, 0, 0 -> #0
> >[microtek] > 0 0 0 0 0 0
> >Floating point exception
> >venus:~ #
> >does this better point to the problem?
> A little: the scanner is balking at the get_scan_status --- the "SENSE!"
> is due to a scsi error activating the "sense handler".
Too bad that I am not able to really understand the C syntax (and logic) !
I took a curious amateur look at the "sense handler" and received the
impression that this function exits either with an error message (at least
with "unknown error") or with "SANE_STATUS_GOOD", what in my eyes would mean
"ok, no error". If this is true then the problem would appear later, at
Sorry if I'm completely wrong. I'm just trying to learn and understand...
> the backend is not receiving any sense data. The linux scsi drivers
> have a way of swallowing microtek sense data, because it is kind of odd
> (with respect to the SCSI-2.0 std, but these scanners do not claim to
> adhere to 2.0).
> Activating sane's scsi debugging (SANE_DEBUG_SANEI_SCSI=255) may help.
Should I do the same test again with activated sane scsi debugging and then
post the output to the list again?
> However, locating the lost sense bits may require turning on debugging
> at the kernel/driver level. (I have no recollection of how to do that.)
Nor do I.
> And even then, it may indicate the backend has sent an illegal value,
> or it may indicate nothing at all.
So maybe there's another idea to come closer to the solution?
> Some firmware mis-identifies scanner parameters, such as the actual
> length/width of the gamma table, and the only way to figure it out
> is by trial-and-error.
Ok, where and how do you think I should beguin to try? I have no experience
and the only idea I have is trying with Kooka with dfferent settings like
"color" or "b/w" etc., is it that what you mean?
> >btw.: VueScan evaluation version works on this machine with this scanner,
> > but it's not OpenSource, which I'd prefer (and it's not free - which I
> > understand; everybody has to pay it's bills somehow...). But at least
> > this tells me that the SCSI-card and the Scanner themselves _can_
> > work...
> Yep, we all have bills... :)
> Hmm... if you turn on enough kernel-level scsi debugging, you would be able
> to capture the command stream for a working scan, no?
As you said, we don't have no idea how. I will search google - with not much
hope to find anything I understand. And then, will you interpret the
> That could do
> wonders for figuring out what is wrong. (Or, it could confuse matters
Could it confuse my computer or just the thinking about the problem? The
former I wouldn't risk...
> -matt m.
Daniel Bauer photographer Basel Switzerland
professional photography: http://www.daniel-bauer.com
special interest site: http://www.bauer-nudes.com
More information about the sane-devel