driver / kernel ignores TEST UNIT READY command
treaves at silverfields.com
Thu Jun 21 10:41:53 PDT 2001
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
>> Can you look at the last response here and write a test program to
>> 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.
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.
> 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
More information about the aic7xxx