driver / kernel ignores TEST UNIT READY command

[Beau James]

--> 	I feel like I'm between a rock and a hard spot!  The program developer 
--> insists that the problem is the SCSI driver.  I have to agree.  The only 
--> thing different between the working 2.2.18 and non-working 2.4.4 that is 
--> involved here is the SCSI driver.  The kernel is different, but the 
--> kernel doesn't impact anything here that I can see.
--> 
--> 	We know that the behaviour of the driver changed.  If it isn't the 
--> driver, what could it possibly be?  The hardware didn't change, the 
--> application didin't change.

If Justin's suspicion is correct:

	- the application depended on a particular timing behavior
		of the device and driver
	- the driver timing improved in a newer release
	- the application+device now fail to work

That does not translate to the problem being in the driver.  The problem
is a timing dependency between the application and the device; the driver
improvements exposed a problem that always existed, but was masked by a
slow driver.

Again, if the hypothesis is correct ...

Beau

--> 
--> 
--> In a message dated 6/21/2001 9:40:29 AM EST, treaves at silverfields.com 
--> writes:
--> 
--> 
-->  >> Can you look at the last response here and write a test program to 
--> see if
-->  >> this is the case?
-->  >
-->  >
-->  >I looked at the response, and it's just a guess.  The problem has
-->  >nothing to do with the speed of the scsi driver.
-->  >
-->  >Regards,
-->  >Ed Hamrick
--> 
--> 
--> 
--> 
--> 
--> Justin T. Gibbs wrote:
--> 
--> >>>Why should the test unit ready fail or wait?  The driver doesn't
--> >>>know anything about the commands that are sent.  The driver just
--> >>>processes commands generically and returns the results.  Perhaps
--> >>>if you better explained the environment (full dmesg) and what
--> >>>you are trying to do, I can help more.
--> >>>
--> >>>
--> >>
--> >>	I'm using a program called vuescan.  It allows me to use my
--> >>Polaroid film scanner under linux.  It is not working properly.  The
--> >>unit - when scan is hit - acts normally (as in the way it did under
--> >>2.2.18) but the app shows immeadiatly that it is receiving data.  The
--> >>app shows that the scan is done long before the unit finishes scanning.
--> >>The image that is displayed is garbage.
--> >>
--> >>	After many e-mails with the author, he looked at a log of a good run 
--> >>under 2.2.18, and a failed run under 2.4.4 with the patched driver.  The 
--> >>only difference was what I mentioned.  If under 2.2.18 the scsi driver 
--> >>either returned an error or waited five seconds, and it is not doing 
--> >>that now, either there was a bug in the old version that allowed it to 
--> >>work well with my scanner and the new 'fixed' version doesn't, or the 
--> >>other way around.  I don't see any other possibilities.  Nothing else 
--> >>changed.  I can still boot into my 2.2.18 and it still works.
--> >>
--> > 
--> > My guess is that the scanner has a very small window, after a scan is
--> > started, where it does not properly either report BUSY status to the
--> > test unit ready, or wait to return status for the test unit ready unil
--> > it has data to send.  The new driver is much faster at delivering
--> > commands than the previous one, and it wouldn't surprise me if this is
--> > the cause for the confusion.
--> > 
--> > If vuescan either performs an additional test unit ready or adds
--> > a small delay after the start of scan before quering the scanner,
--> > it will probably work with the new driver.
--> > 
--> > --
--> > Justin
--> > 
--> > To Unsubscribe: send mail to majordomo at FreeBSD.org
--> > with "unsubscribe aic7xxx" in the body of the message
--> > 
--> > 
--> 
--> 
--> 
--> 
--> To Unsubscribe: send mail to majordomo at FreeBSD.org
--> with "unsubscribe aic7xxx" in the body of the message
--> 

To Unsubscribe: send mail to majordomo at FreeBSD.org
with "unsubscribe aic7xxx" in the body of the message