In message <[EMAIL PROTECTED]>, Matthew Dillon wri
>    Whoop!  I take it back.  I'm still getting the errors:
>microuptime() went backwards (458.168990 -> 458.168882)
>microuptime() went backwards (578.609995 -> 577.929801)
>microuptime() went backwards (748.912755 -> 748.237402)
>microuptime() went backwards (775.159625 -> 775.159612)
>    I also think this retry loop has to be done everywhere where the
>    timecounter structure is accessed directly.

No, only where the timecounter hardware is read and the math
done.  As far as I know, this is the only place.

As I said, I am far from convinced this is the solution to the problem
we are looking at with the PIIX timecounter.

Msmith has some magic code in sys/dev/acpi/acpi_timer.c which tries
to identify if the PIIX counter is broken or OK and I notice that
the mask seems to always be set to 24 bits even if the hardware
is 32 bits.

I am not sure I read his code right, but he seems to default to the
unsafe method, can you try this copy&pasted patch ?

Index: acpi_timer.c
RCS file: /home/ncvs/src/sys/dev/acpica/acpi_timer.c,v
retrieving revision 1.11
diff -u -r1.11 acpi_timer.c
--- acpi_timer.c        8 Jan 2002 06:45:56 -0000       1.11
+++ acpi_timer.c        17 Feb 2002 20:48:23 -0000
@@ -138,7 +138,7 @@
     if (getenv("debug.acpi.timer_test") != NULL)
-    acpi_timer_timecounter.tc_get_timecount = acpi_timer_get_timecount;
+    acpi_timer_timecounter.tc_get_timecount = acpi_timer_get_timecount_safe;
     acpi_timer_timecounter.tc_frequency = acpi_timer_frequency;

Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED]         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to