From owner-cvs-sys Sat Mar 9 12:11:29 1996 Return-Path: owner-cvs-sys Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id MAA20474 for cvs-sys-outgoing; Sat, 9 Mar 1996 12:11:29 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id MAA20468 Sat, 9 Mar 1996 12:11:25 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id HAA22595; Sun, 10 Mar 1996 07:09:03 +1100 Date: Sun, 10 Mar 1996 07:09:03 +1100 From: Bruce Evans Message-Id: <199603092009.HAA22595@godzilla.zeta.org.au> To: rgrimes@freefall.freebsd.org, rgrimes@gndrsh.aac.dev.com Subject: Re: cvs commit: src/sys/i386/isa rc.c Cc: CVS-committers@freefall.freebsd.org, cvs-all@freefall.freebsd.org, cvs-sys@freefall.freebsd.org Sender: owner-cvs-sys@FreeBSD.ORG X-Loop: owner-cvs-sys@FreeBSD.ORG Precedence: bulk >Note that this patch really points to a problem in DELAY(X) for X >smaller than 20. Right now the DELAY code does an X=-20 and never >really goes into the DELAY loop. >It seems that on 133Mhz and faster Pentium systems the assumed overhead >time of 20uS is no longer valid and something needs to be done to >correct this. This is especially true when calling short DELAY's in >a loop since that all ends up running from the internal cache. >If you spot DELAY being called in an loop some place with values of >20 or below I suggest that the code be corrected to do what I did here >or we are going to see more of these types of problems as system >speeds increase. Very short delays should only have been used when the precise delay isn't critical. It isn't practical to guarantee a maximum delay (slow machines take several usec just to call DELAY(), and interrupts may extend the delay for several thousand usec). Perhaps DELAY() should guarantee a minimal delay. This would make all the stupid timeout loops with DELAY(SMALL) give huge timeouts on slow machines :-(. Bruce