Date: Wed, 28 Jun 2000 20:12:59 +0200 From: Wilko Bulte <wkb@chello.nl> To: Bob Willcox <bob@immure.com> Cc: Greg Lehey <grog@lemis.com>, wilko@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG Subject: Re: microuptime() going backwards Message-ID: <20000628201259.C1136@freebie.wbnet> In-Reply-To: <20000628084749.A84134@luke.immure.com>; from bob@luke.immure.com on Wed, Jun 28, 2000 at 08:47:49AM -0500 References: <20000626225629.A525@freebie.wbnet> <20000627120348.B5328@sydney.worldwide.lemis.com> <20000627082648.A3475@freebie.wbnet> <20000628121611.C1504@sydney.worldwide.lemis.com> <20000628084749.A84134@luke.immure.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Jun 28, 2000 at 08:47:49AM -0500, Bob Willcox wrote: > 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 OK, same board/CPU here. > 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). Mine is SCSI-only, Adaptec 2940UW based. So there is no relation with the disksubsystem type. -- Wilko Bulte http://www.freebsd.org "Do, or do not. There is no try" wilko@freebsd.org http://www.nlfug.nl Yoda - The Empire Strikes Back 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?20000628201259.C1136>