[sane-devel] sanei_scsi.c: SCSI command complained: Success

[abel deuring]

Henning Meier-Geinitz wrote:
> 
> Hi,
> 
> during the last year I had some bug reports that included the
> following or a similar debug log:
> 
> [...]
> [sanei_scsi] sanei_scsi_req_wait: SCSI command complained: Success
> [sanei_scsi] sense buffer: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> [sanei_scsi] target status: 00 host status: 0003 driver status: 0000
> [...]
> 
> Where can I read about the meaning of the status numbers?

http://www.torque.net/sg/p/scsi-generic_long.txt and
http://www.torque.net/sg/p/scsi-generic_v3.txt

> 
> The output was usually caused by a backend bug (mustek) but I didn't
> understand the "Success". The corresponding code is the following:
> 
>              /* check for errors, but let the sense_handler decide.... */
>              if (   ((req->sgdata.sg3.hdr.info & SG_INFO_CHECK) != 0)
>                  || (req->sgdata.sg3.hdr.sb_len_wr > 0 &&
>                  ((req->sgdata.sg3.sense_buffer[0] & 0x7f) != 0)))
> 
> /* what do the first two tests mean? */

That the SG driver reports an error; either via the flag SG_INFO_CHECK
or via the length of the data in the sense buffer.

>                {
>                  SANEI_SCSI_Sense_Handler handler
>                    = fd_info[req->fd].sense_handler;
>                  void *arg = fd_info[req->fd].sense_handler_arg;
> 
>                  DBG (1, "sanei_scsi_req_wait: SCSI command complained: %s\n",
>                       strerror(errno));
> 
> /* Is errno really the result of the SG access or maybe just the
>    result of a DBG write? */

errno is quite often zero on completion of a SCSI command, even if some
error occured, but every time (see the docs mentioned above). I
considered to enclose the DBG statement in an "if (errno) { ... }" but
was too lazy to do that.

> 
>                  DBG(10, "sense buffer: %02x %02x %02x %02x %02x %02x %02x %02x"
>                          " %02x %02x %02x %02x %02x %02x %02x %02x\n",
>                          req->sgdata.sg3.sense_buffer[0],
>                          req->sgdata.sg3.sense_buffer[1],
>                          req->sgdata.sg3.sense_buffer[2],
>                          req->sgdata.sg3.sense_buffer[3],
>                          req->sgdata.sg3.sense_buffer[4],
>                          req->sgdata.sg3.sense_buffer[5],
>                          req->sgdata.sg3.sense_buffer[6],
>                          req->sgdata.sg3.sense_buffer[7],
>                          req->sgdata.sg3.sense_buffer[8],
>                          req->sgdata.sg3.sense_buffer[9],
>                          req->sgdata.sg3.sense_buffer[10],
>                          req->sgdata.sg3.sense_buffer[11],
>                          req->sgdata.sg3.sense_buffer[12],
>                          req->sgdata.sg3.sense_buffer[13],
>                          req->sgdata.sg3.sense_buffer[14],
>                          req->sgdata.sg3.sense_buffer[15]);
>                  DBG(10, "target status: %02x host status: %04x"
>                          " driver status: %04x\n",
>                          req->sgdata.sg3.hdr.status,
>                          req->sgdata.sg3.hdr.host_status,
>                          req->sgdata.sg3.hdr.driver_status);
> 
> Or finally: Is the above mentioned output correct and intended?

Well, I hope that it is correct ;) But the interpretation can sometimes
be a bit complicated, because the status codes can originate from
different parts of Linux SCSI system.

> On Fri, Mar 08, 2002 at 10:53:31PM +0100, Henning Meier-Geinitz wrote:
> > [...]
> > [sanei_scsi] sanei_scsi_req_wait: SCSI command complained: Success
> > [sanei_scsi] sense buffer: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > [sanei_scsi] target status: 00 host status: 0003 driver status: 0000
> > [...]
> > 
> > Where can I read about the meaning of the status numbers?
> 
> Ok, I found linux_sg3err.h. So this means "Timeout"? Should I just try
> again in the backend? How can these timeouts occur, are they normal or
> an indication for a hardware problem?