From owner-freebsd-hackers Tue Apr 4 23:16:03 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id XAA04421 for hackers-outgoing; Tue, 4 Apr 1995 23:16:03 -0700 Received: from gndrsh.aac.dev.com (gndrsh.aac.dev.com [198.145.92.241]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id XAA04415 for ; Tue, 4 Apr 1995 23:15:59 -0700 Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.8/8.6.6) id WAA09768; Tue, 4 Apr 1995 22:15:50 -0700 From: "Rodney W. Grimes" Message-Id: <199504050515.WAA09768@gndrsh.aac.dev.com> Subject: Re: Colorado Jumbo 250MB ft, and FreeBSD 2.0R To: steve2@freefall.cdrom.com (Steve Gerakines) Date: Tue, 4 Apr 1995 22:15:50 -0700 (PDT) Cc: freebsd-hackers@FreeBSD.org In-Reply-To: <199504050600.CAA09235@genesis.tiac.net> from "Steve Gerakines" at Apr 5, 95 02:00:30 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 2322 Sender: hackers-owner@FreeBSD.org Precedence: bulk > > > > 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