[sane-devel] sanei_scsi.c: SCSI command complained: Success
abel deuring
a.deuring@satzbau-gmbh.de
Sat, 09 Mar 2002 14:32:13 +0100
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?
From the SG3 docs:
Status: O
> unsigned int timeout; /* [i] MAX_UINT->no timeout (unit: millisec) */
> This value is used to timeout the given command. The units of this
> value are milliseconds. The time being measured is from when a command
> is sent until when sg is informed the request has been completed. A
> following read() can take as long as the user likes. When a timeout
> is exceeded the command is aborted and DID_TIME_OUT is set in the
> 'host_status' and DRIVER_TIMEOUT is set in the 'driver_status'.
[...]
> unsigned short host_status; /* [o] errors from host adapter */
> These codes potentially come from the firmware on a host adapter
> or from one of several hosts that an adapter driver controls.
> The 'host_status' field has the following values whose #defines mimic
> those which are only visible within the kernel (with the "SG_ERR_"
> removed from the front of each define). A copy of these defines can be
> found in sg_err.h (see the utilities section):
> SG_ERR_DID_OK 0x00 /* NO error */
> SG_ERR_DID_NO_CONNECT 0x01 /* Couldn't connect before timeout period */
> SG_ERR_DID_BUS_BUSY 0x02 /* BUS stayed busy through time out period */
> SG_ERR_DID_TIME_OUT 0x03 /* TIMED OUT for other reason */
> SG_ERR_DID_BAD_TARGET 0x04 /* BAD target, device not responding? */
> SG_ERR_DID_ABORT 0x05 /* Told to abort for some other reason */
> SG_ERR_DID_PARITY 0x06 /* Parity error */
> SG_ERR_DID_ERROR 0x07 /* Internal error [DMA underrun on aic7xxx]*/
> SG_ERR_DID_RESET 0x08 /* Reset by somebody. */
> SG_ERR_DID_BAD_INTR 0x09 /* Got an interrupt we weren't expecting. */
> SG_ERR_DID_PASSTHROUGH 0x0a /* Force command past mid-layer */
> SG_ERR_DID_SOFT_ERROR 0x0b /* The low level driver wants a retry */
Since driver_status is 0, we don't have the "regular" command time out
of 1 minute, so something else went wrong. The docs I know don't tell
what that could be; but as a guess, the driver might have "seen" a SCSI
bus that was occupied by some other device than the scanner for a too
long time.
Abel