Date: Wed, 5 Apr 1995 15:37:35 +0100 (BST) From: Paul Richards <paul@isl.cf.ac.uk> To: rgrimes@gndrsh.aac.dev.com (Rodney W. Grimes) Cc: steve2@freefall.cdrom.com, freebsd-hackers@FreeBSD.org Subject: Re: Colorado Jumbo 250MB ft, and FreeBSD 2.0R Message-ID: <199504051437.PAA04210@isl.cf.ac.uk> In-Reply-To: <199504050515.WAA09768@gndrsh.aac.dev.com> from "Rodney W. Grimes" at Apr 4, 95 10:15:50 pm
next in thread | previous in thread | raw e-mail | index | archive | help
In reply to Rodney W. Grimes who said > > 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. My system's (Gateway P5-90) got the problem. I had to bump the delay from 100 to 150 in order to get the tape recognised. > 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. I'm reluctant to do this too since DELAY shouldn't have to be tweaked for different hardware. If we can fix the delay problem before 2.1 then that's the correct thing to do but I'll test the tape driver before we release and if it's still not working I'll bump the delay until it does just to hack around the problem. -- Paul Richards, FreeBSD core team member. Internet: paul@FreeBSD.org, URL: http://isl.cf.ac.uk/~paul/ Phone: +44 1222 874000 x6646 (work), +44 1222 457651 (home) Dept. Mechanical Engineering, University of Wales, College Cardiff.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199504051437.PAA04210>