sane-project-website/old-archive/1998-03/0132.html

<!-- received="Thu Mar 19 11:11:37 1998 PST" -->
<!-- sent="Thu, 19 Mar 1998 14:11:13 -0500" -->
<!-- name="Matto Marjanovic" -->
<!-- email="maddog@mir.com" -->
<!-- subject="Microtek, SCSI, and Sane-0.71...." -->
<!-- id="199803191911.OAA13449@yoo-hoo.ai.mit.edu" -->
<!-- inreplyto="" -->
<title>sane-devel: Microtek, SCSI, and Sane-0.71....</title>
<h1>Microtek, SCSI, and Sane-0.71....</h1>
<b>Matto Marjanovic</b> (<a href="mailto:maddog@mir.com"><i>maddog@mir.com</i></a>)<br>
<i>Thu, 19 Mar 1998 14:11:13 -0500</i>
<p>
<ul>
<li> <b>Messages sorted by:</b> <a href="date.html#132">[ date ]</a><a href="index.html#132">[ thread ]</a><a href="subject.html#132">[ subject ]</a><a href="author.html#132">[ author ]</a>
<!-- next="start" -->
<li> <b>Next message:</b> <a href="0133.html">Christoph Doerbeck: "SCSI problems during my SANE demo"</a>
<li> <b>Previous message:</b> <a href="0131.html">Rogier Wolff: "Re: MicroTek scanner"</a>
<!-- nextthread="start" -->
<!-- reply="end" -->
</ul>
<!-- body="start" -->
Hiya,<br>
<p>
For all those wondering what the verdict was on the SCSI errors in Microtek<br>
 scanners with SANE-0.71:  I recompiled my kernel with all the copious scsi<br>
 debugging #define's set, and pieced together what was happening.<br>
<p>
The short answer:  The scanners generate predictable but unexplainable error<br>
 conditions.  The best solution is probably to ignore them; following David's<br>
 suggestion, at the end of this message is a patch to "sanei/sanei_scsi.c"<br>
 which allows the backend's sense_handler to decide if an error condition is<br>
 really an error condition.  (The patch is only for the Linux portion of the<br>
 SCSI code...)<br>
<p>
<p>
Now, here's the synopsis of what happens in the Microtek E6, and the Linux<br>
 scsi code, for those who are interested:<br>
<p>
In the E6 (and probably others), the TEST_UNIT_READY command returns a CHECK<br>
 CONDITION code precisely when it is called after START_SCAN, GET_SCAN_STATUS,<br>
 and READ_SCAN_DATA.  This means that you are supposed the call REQUEST_SENSE<br>
 to see what is wrong.  The sense data indicates "SCSI command or data error"<br>
 in the Microtek terminology, but I can't figure out what is wrong, because<br>
 the commands seem to execute properly.<br>
<p>
Part of the problem here is that the interaction with the Linux scsi drivers<br>
 is a bit funny.  In the 2.0.32 kernel, the scsi driver is split into three<br>
 levels:  low, mid, and high.  The card interface (in my case, aha152x) is<br>
 low, the overall manager scsi.c is mid, and the generic scsi interface sg.c<br>
 is high.  <br>
In my tests, the aha152x driver doesn't do anything unusual or stupid that I<br>
 can see (contrary to my original hunch).  When the mid-level driver sees the<br>
 CHECK CONDITION code, it sends a REQUEST_SENSE command to the scanner on its<br>
 own volition.  However, the scanner's sense data does *not* follow SCSI-II<br>
 standards (which is almost forgivable because the scanner does identify<br>
 itself as using the SCSI-I/CCS command set).  This confuses the mid-level<br>
 driver, which decides it has done enough and returns a status result which<br>
 is a combination of DID_OK, DRIVER_SENSE, and SUGGEST_RETRY --- which means<br>
 "I tried getting sense information, and I suggest you retry the command".<br>
The generic scsi high-level code gets this result, sees "DID_OK", figures <br>
 everything is fine, *clears* the result, and returns to the user code.  This<br>
 is dumb, I think, because it could at least pass on the recommendations from<br>
 the mid-level driver.<br>
Anyhow, the SANE scsi code ends up getting an "A-OK" result, although the<br>
 sense data is still in the sense buffer --- which is a good thing, because<br>
 if there were a real error, this is the only way to find out.<br>
<p>
Some people have said that they had no problems with an Adaptec 2940 card<br>
 (the aic7xxx driver).  It could be that the card/low-level driver are doing<br>
 the REQUEST_SENSE, getting confused, and not returning any codes in this case.<br>
<p>
<p>
Anyhow, the best thing to do seems to be to let the backend's sense handler<br>
 decide when an error is really an error.  Here is a patch which does that<br>
 for the Linux-specific code.  Please tell me what you think.<br>
<p>
-matt m.<br>
<p>
===========================================================================<br>
<p>
--- sanei_scsi.c-dist	Sat Mar  7 00:55:21 1998<br>
+++ sanei_scsi.c	Thu Mar 19 13:40:06 1998<br>
@@ -726,36 +726,44 @@<br>
 	{<br>
 	  nread -= sizeof (req-&gt;cdb.hdr);<br>
 <br>
-	  if (req-&gt;cdb.hdr.result == 0<br>
-	      &amp;&amp; (req-&gt;cdb.hdr.sense_buffer[0] &amp; 0x7f) == 0)<br>
-	    {<br>
-	      if (req-&gt;dst)<br>
-		memcpy (req-&gt;dst, req-&gt;cdb.data, nread);<br>
-<br>
-	      if (req-&gt;dst_len)<br>
-		*req-&gt;dst_len = nread;<br>
-<br>
-	      status = SANE_STATUS_GOOD;<br>
-	    }<br>
-	  else<br>
+	  /* check for errors, but let the sense_handler decide.... */<br>
+	  if ((req-&gt;cdb.hdr.result != 0) ||<br>
+	      ((req-&gt;cdb.hdr.sense_buffer[0] &amp; 0x7f) != 0))<br>
 	    {<br>
 	      SANEI_SCSI_Sense_Handler handler<br>
 		= fd_info[req-&gt;fd].sense_handler;<br>
 	      void *arg = fd_info[req-&gt;fd].sense_handler_arg;<br>
 <br>
-	      DBG(1, "sanei_scsi_req_wait: SCSI command failed: %s\n",<br>
+	      DBG(1, "sanei_scsi_req_wait: SCSI command complained: %s\n",<br>
 		  strerror (req-&gt;cdb.hdr.result));<br>
 <br>
 	      if (req-&gt;cdb.hdr.result == EBUSY)<br>
 		status = SANE_STATUS_DEVICE_BUSY;<br>
 	      else if (handler)<br>
+		/* sense handler should return SANE_STATUS_GOOD if it<br>
+		   decided all was ok afterall */<br>
 		status = (*handler) (req-&gt;fd, req-&gt;cdb.hdr.sense_buffer, arg);<br>
 	      else<br>
 		status = SANE_STATUS_IO_ERROR;<br>
 	    }<br>
+	  else<br>
+	    {<br>
+	      status = SANE_STATUS_GOOD; /* i.e. no scsi error */<br>
+	    }<br>
+<br>
+	  /* if we are ok so far, copy over the return data */<br>
+	  if (status == SANE_STATUS_GOOD) <br>
+	    {<br>
+	      if (req-&gt;dst)<br>
+		memcpy (req-&gt;dst, req-&gt;cdb.data, nread);<br>
+<br>
+	      if (req-&gt;dst_len)<br>
+		*req-&gt;dst_len = nread;<br>
+	    }<br>
+<br>
 	}<br>
     }<br>
-<br>
+  <br>
 <br>
   /* dequeue and release processed request: */<br>
   ATOMIC(qhead = qhead-&gt;next;<br>
<p>
<pre>
--
Source code, list archive, and docs: <a href="http://www.mostang.com/sane/">http://www.mostang.com/sane/</a>
To unsubscribe: echo unsubscribe sane-devel | mail <a href="mailto:majordomo@mostang.com">majordomo@mostang.com</a>
</pre>
<!-- body="end" -->
<p>
<ul>
<!-- next="start" -->
<li> <b>Next message:</b> <a href="0133.html">Christoph Doerbeck: "SCSI problems during my SANE demo"</a>
<li> <b>Previous message:</b> <a href="0131.html">Rogier Wolff: "Re: MicroTek scanner"</a>
<!-- nextthread="start" -->
<!-- reply="end" -->
</ul>