Date: Thu, 6 Apr 1995 00:16:45 +1000 From: Bruce Evans <bde@zeta.org.au> To: freebsd-hackers@FreeBSD.org, steve2@freefall.cdrom.com Subject: Re: Colorado Jumbo 250MB ft, and FreeBSD 2.0R Message-ID: <199504051416.AAA21676@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>> 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.
^^^
It allows at least 0.8 seconds, probably closer to 1.0 than 0.8.
>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. :-(
I think a factor of 10 larger can't be right (unless 1 second was never
right :-).
There should be an interface to a global counter. E.g., DELAY()
could simply increment a counter for each tick that it notices (it
can be changed a little so that it is guaranteed to notice all
ticks provided it is called at least once every 10msec). Then the
above loop could be better written as;
extern volatile u_long proposed_counter;
u_long start_count, end_count;
reset_proposed_counter(); /* avoid overflow */
proposed_counter = start_count;
end_count = start_count + 1000000 * proposed_counter_freq;
do {
DELAY(100); /* maybe less */
...
} while (proposed_counter < end_count);
Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199504051416.AAA21676>