[sane-devel] old Agfa DuoScan / Floating point exception

[Matto Marjanovic]

 >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
 >128
 >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".  Unfortunately,
 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.
 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.)
And even then, it may indicate the backend has sent an illegal value,
 or it may indicate nothing at all.

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.

 ...
 >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?  That could do wonders
 for figuring out what is wrong.  (Or, it could confuse matters horribly.)

-matt m.