Date: Wed, 28 Jun 2000 08:47:49 -0500 From: Bob Willcox <bob@luke.immure.com> To: Greg Lehey <grog@lemis.com> Cc: wilko@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG Subject: Re: microuptime() going backwards Message-ID: <20000628084749.A84134@luke.immure.com> In-Reply-To: <20000628121611.C1504@sydney.worldwide.lemis.com>; from grog@lemis.com on Wed, Jun 28, 2000 at 12:16:12PM %2B1000 References: <20000626225629.A525@freebie.wbnet> <20000627120348.B5328@sydney.worldwide.lemis.com> <20000627082648.A3475@freebie.wbnet> <20000628121611.C1504@sydney.worldwide.lemis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Jun 28, 2000 at 12:16:12PM +1000, Greg Lehey wrote: > On Tuesday, 27 June 2000 at 8:26:49 +0200, Wilko Bulte wrote: > > On Tue, Jun 27, 2000 at 12:03:49PM +1000, Greg Lehey wrote: > >> On Monday, 26 June 2000 at 22:56:29 +0200, Wilko Bulte wrote: > >>> I just got tons and tons of > >>> > >>> Jun 26 22:06:33 freebie /kernel: microuptime() went backwards (18951.226366 -> 1 8951,199762) > >>> Jun 26 22:06:34 freebie /kernel: microuptime() went backwards (18951.226366 -> 1 8951,210275) > >>> > >>> (approx 10Mb worth of them). This was during a mpeg video playing operation. > >>> > >>> FreeBSD freebie.wbnet 4.0-STABLE FreeBSD 4.0-STABLE #2: Sat Jun 24 16:52:41 CEST 2000 root@freebie.wbnet:/usr/src/sys/compile/FREEBIE i386 > >>> > >>> System is an Athlon 700Mc, dmesg.boot available if required. > >>> > >>> Any idea what is causing this? > >> > >> Yup. Is this an Epox board? I think it's a bug in the APM code. It > >> even bites if APM is disabled. Try completely removing APM from the > >> kernel. > > > > No, it is an Abit KA7. But I will try removing apm, it is indeed in the > > kernel. I'll see what happens next. Why does apm influence the time stuff? > > It changes the way the timer code works. I've been told various > things, and have quoted some of them in the past, but it seems they > may be wrong. As far as I can tell now, the issue is that > microuptime() is not atomic, and it seems that it's possible for race > conditions to arise where it's called reentrantly and returns the > older time after returning a newer time. If this hypothesis is > correct, you should also be able to eliminate the messages by putting > a splhigh() around the body of microuptime() (in /sys/kern/kern_tc.c). > This isn't the solution though, especially since we're removing spls > with the new SMP code. I just tried the splhigh() around microuptime() on my system here with this problem and it did not solve the problem. Removal of apm from the kernel seems to have, though. Note that this is an Abit KA7 board with a 700MHz Athlon CPU. Also, I have another system here with a similar configuration (same Abit board but with a 800MHz CPU in it and a SCSI disk vs. IDE) that doesn't suffer from this problem (with apm installed). Bob -- Bob Willcox Everyone complains of his memory, no one of bob@immure.com his judgement. Austin, TX -- anonymous To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000628084749.A84134>