[sane-devel] lost with FUJITSU scanner M3096G

[abel deuring]

Frank Zago wrote:
> 
> abel deuring wrote:
> > Frank Zago wrote:
> >
> >>>[fujitsu] set_window_param
> >>>[fujitsu] Window set
> >>>[fujitsu] 000: 00 00 01 2c 01 2c 00 00 00 00 00 00 00 00 00 00
> >>>[fujitsu] 016: 03 b0 00 00 05 89 00 00 00 02 08 00 00 00 00 00
> >>>[fujitsu] 032: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0
> >>>[fujitsu] 048: 20 00 00 00 00 84 00 00 00 00 00 00 00 00 00 00
> >>>[fujitsu]       5/38/0: Invalid field in parm list
> >>>[fujitsu] sanei_scsi_cmd: returning 0x00000004
> >>>[fujitsu] sane_start: ERROR: failed to set window
> >>
> >>The scanner rejected the window parameter. If the scsi implementation is decent,
> >>the sense might contain the offset of the offending byte somewhere around byte
> >>16 oy 17. To get that, at the beginning of scsi_sense_handler, add this line:
> >>
> >>   hexdump (MSG_IO, "Sense", sensed_data, sensed_data[7]+8);
> >
> >
> > Frank,
> >
> > you're right, the sense bytes 16 and 17 should point to the offending
> > byte, but unfortunately the Linux SCSI system returns only the first 16
> > bytes of a SCSI command.
> 
> Are you sure of that? There are devices out there that return more than 100
> bytes of data in the sense. I assume someone would have fixed such a problem.

This is the definition of sg_header from sg.h:

#define SG_MAX_SENSE 16   /* this only applies to the sg_header
interface */
 
struct sg_header
 {
   /* Length of incoming packet (including header).  */
   int pack_len;
   /* Maximal length of expected reply.  */
   int reply_len;
   /* Id number of packet.  */
   int pack_id;
   /* 0==ok, otherwise error number.  */
   int result;
   /* Force 12 byte command length for group 6 & 7 commands.  */
   unsigned int twelve_byte:1;
   /* SCSI status from target.  */
   unsigned int target_status:5;
   /* Host status (see "DID" codes).  */
   unsigned int host_status:8;
   /* Driver status+suggestion.  */
   unsigned int driver_status:8;
   /* Unused.  */
   unsigned int other_flags:10;
   /* Output in 3 cases:
      when target_status is CHECK_CONDITION or
      when target_status is COMMAND_TERMINATED or
      when (driver_status & DRIVER_SENSE) is true.  */
   unsigned char sense_buffer[SG_MAX_SENSE];
 };

Using the new header structure, I am not 100% sure though -- would be
worth some tests ;)

> 
> > But it might help to issue a REQUEST SENSE manually after the failing
> > SET WINDOW and print the result of this command.
> 
> Unless the system caches the sense (and more than 16 bytes), the next request
> sense isn't going to return anything.

Right, there is not guarantee that the data returned from a second
REQUEST SENSE call is valid -- but that depends on the device, I think
(and the usage conditions, of course). At least one backend issued
REQUEST SENSE via sanei_scsi_cmd in older versions of Sane, obviously
without problems.

Abel