Date: Thu, 31 Aug 1995 17:18:37 -0700 (PDT) From: "Rodney W. Grimes" <rgrimes@gndrsh.aac.dev.com> To: gibbs@freefall.FreeBSD.org (Justin T. Gibbs) Cc: FreeBSD-hackers@freebsd.org Subject: Re: 4GB Drives Message-ID: <199509010018.RAA13189@gndrsh.aac.dev.com> In-Reply-To: <199508312221.PAA29434@freefall.FreeBSD.org> from "Justin T. Gibbs" at Aug 31, 95 03:21:57 pm
next in thread | previous in thread | raw e-mail | index | archive | help
... > >Actually I would like to turn off queued commands for the time being, > >is there an easy way to do that (I have not been delving into the aic > >code like I should be if I need to ask that one, but since I have your > >attention any way :-). > > Just don't enable it. Its a kernel config option (AHC_TAGENABLE). I am not concerned about the drive queueing things up, that is past the point I am trying to analyze right now. More below (I already don't have AHC_TAGENABLE) in my kernel. > One thing to watch out for is that even without tagged queuing, you > can get up to two requests per target sitting on the board. You'll Those are the 2 I need to eliminate for my analysis. Any quick dirty hack I can do to turn them off? > have to blink something when the command that gets taken off the queue > is for a target that has an active command pending since it will re-queue > the transaction in that case. This will happen when the first transaction > to the disk disconnects to do the seek. Test case has already eliminated all seeks. Seeks do not occur as my total transfer is smaller than 1 cylinder * stripe width. I am trying to find the proper parameters and emperical data to improve my theoritcal caclulations and formulas. I can't find the errors in these algorithms without some correlation to real measured data to find the bad assumptions in them :-(. The data I need is being very difficult to obtain without spending major dollars on a scsi bus analyzer and a large logic analyzer :-(. I guess I could go out to the labs some weekend, but it is a pain to check in this much equipment. > >I need to fully evaluate very simple systems to understand how things > >are going to behave, and complications like having the controller stacking > >up queued I/O's on me is going to confuse me looking at timing with respect > >to when the host releases the I/O in the driver (right now I have a bit > >to watch on the scope when the stripe layer drops the I/O to the driver > >layer and then watch the busy bit on the scsi bus, command queueing in > >the controller is screwing me correlationg the two events :-(). > > Understood. So can you help me ``dumb down'' a bit of the smarts in the aha2940 driver, ie, kill that last 2 deep queue? It might explain a major descrepancy between my algorithms and what I am currently seeing actually occur. -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Reliable computers for FreeBSD
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199509010018.RAA13189>