Date: Tue, 4 Apr 1995 22:15:50 -0700 (PDT) From: "Rodney W. Grimes" <rgrimes@gndrsh.aac.dev.com> To: steve2@freefall.cdrom.com (Steve Gerakines) Cc: freebsd-hackers@FreeBSD.org Subject: Re: Colorado Jumbo 250MB ft, and FreeBSD 2.0R Message-ID: <199504050515.WAA09768@gndrsh.aac.dev.com> In-Reply-To: <199504050600.CAA09235@genesis.tiac.net> from "Steve Gerakines" at Apr 5, 95 02:00:30 am
next in thread | previous in thread | raw e-mail | index | archive | help
>
> > > Also, a number of people have reported to be having problems with the
> > > driver recognizing their tape drives. They sound very much like
> > > timing problems. At one time the timing characteristics of the driver
> > > worked for almost everyone as long as your CPU and bus speed was not
> > > on the extreme in either direction. It seems with PCI and/or pentium
> > > systems this may no longer be the case. Has anyone examined the DELAY
> > > (microtime?) function to see if it is running noticeably faster on those
> > > systems?
> >
> > Bruce, do we need to something with the DELAY code? I have 4 different
> > Pentiums here, 3 w/PCI if you need someone to run some test code.
>
> This turned out to be the culprit. If you look at the code around line
> 1473 of the driver in ftintr_wait() it is doing:
>
> for (retries = 0; retries < 10000; retries++) {
> DELAY(100);
> ...
> }
>
> This used to allow up to 1 second for a recalibrate or seek to
> succeed before giving up but now it is a bit too fast for some systems.
> Someone had suggested a while back that the count be bumped up to
> 100000 and I thought that was a committed fix. I thought wrong. :-(
If infact this is not giving a full second for the operation to occur
there is a problem in DELAY and we need to fix DELAY rather than
hide the problem in ft.c. As sooner or later DELAY will get fixed
for some other reason, and then we will have a needless long delay
in ft.c.
Can you point me to a system that is having this problem. I will
find some code to test the kernel DELAY routine and have the person
test it out.
Bruce, do you know of any current problems with our DELAY code?
> I asked Paul Richards to bump up the retries to 20000 and increase
> the delay in that loop to 200. That should give us around 3-4 seconds
> and should be enough to avoid any further grief. If you're in there
> mucking around anyhow Rod maybe you could do this at the same time.
Is this really the right thing to do? Somehow I have the feeling that
1 second is plenty of time for a seek operation to complete for any
given floppy drive and the real bug is in the DELAY code.
--
Rod Grimes rgrimes@gndrsh.aac.dev.com
Accurate Automation Company Custom computers for FreeBSD
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199504050515.WAA09768>