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
