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?
