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>