driver / kernel ignores TEST UNIT READY command

[Timothy Reaves]

	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.



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