Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 16 Feb 2002 16:28:26 -0800 (PST)
From:      Matthew Dillon <dillon@apollo.backplane.com>
To:        freebsd-current@freebsd.org
Subject:   'microuptime() went backwards ...' using ACPI timer.  Shouldn't that be impossible?
Message-ID:  <200202170028.g1H0SQZ41827@apollo.backplane.com>

next in thread | raw e-mail | index | archive | help
Testing with a 'make -j 10 buildworld' on a -current box I am getting
regular:

    microuptime() went backwards (146.826785 -> 146.156715)
    microuptime() went backwards (146.826782 -> 146.228636)
    ...
    microuptime() went backwards (8945.938288 -> 8945.251603)
    microuptime() went backwards (8945.938306 -> 8945.347173)
    microuptime() went backwards (9142.847550 -> 9142.847546)

This occurs both with and without the gettimeofday Giant-removal patch, so
I am fairly sure it has nothing to do with any of my current work.  This is
running -current on a DELL2550 (2xCPUs), compiled with the SMP option.

    Timecounter "i8254"  frequency 1193182 Hz
    ...
    Timecounter "ACPI"  frequency 3579545 Hz
    acpi_timer0: <32-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0
    acpi_cpu0: <CPU> on acpi0
    acpi_cpu1: <CPU> on acpi0
    acpi_pcib0: <Host-PCI bridge> on acpi0
    ...

Question:  How can this be occuring at all?  Isn't the ACPI counter a
32 bit counter that does not have the rollover problems that the 8254 timer
has?

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200202170028.g1H0SQZ41827>