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 [EMAIL PROTECTED]:/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"
[EMAIL PROTECTED] http://www.nlfug.nl Yoda - The Empire Strikes Back
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message
