In message <[EMAIL PROTECTED]>, Bruce Evans writes:
>> 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. The Gian removal doesn't come anywhere near this. >The fact that the timecounter usually goes backwards by about 0.68 seconds >is probably significant, but I can't quite explain it. >> acpi_timer0: <32-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 Well: 2^32 / 3579545 = 1199.86 seconds. 2^24 / 3579545 = 4.68 seconds. So even assuming that ACPI reported a wrong width, four seconds should still be enough to prevent a wraparound even though we cycle through the timecounter ring in one second. >I just wrote the following fix for some of the overflow problems. It is true that if a process is not running for arbitrary long time the timecounter may be modified underneat it, and bruce's patch is actually a pretty elegant solution for that case. By all means try it. I have had one other report of a similar problem, with the added information that changing to the TSC or i8254 instead of PIXX made it go away so I am not entirely convinced this is really what we are looking for in this case. -- 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