In message <[EMAIL PROTECTED]>, Matthew Dillon wri
tes:
> 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_test();
- 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;
tc_init(&acpi_timer_timecounter);
--
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
