Date: Thu, 21 Jun 2001 11:13:04 -0700 (PDT) From: Beau James <bjames@cisco.com> To: gibbs@scsiguy.com, treaves@silverfields.com Cc: aic7xxx@FreeBSD.ORG Subject: Re: driver / kernel ignores TEST UNIT READY command Message-ID: <200106211813.LAA07705@cisco.com>
next in thread | raw e-mail | index | archive | help
--> 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@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@FreeBSD.org --> > with "unsubscribe aic7xxx" in the body of the message --> > --> > --> --> --> --> --> To Unsubscribe: send mail to majordomo@FreeBSD.org --> with "unsubscribe aic7xxx" in the body of the message --> To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe aic7xxx" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200106211813.LAA07705>