:Bruce's patch amounts to a retry if the current timecounter was updated
:while we were calculating time. It is a bit more defensive than it
:needs to be and generally pessimizes the timecounters elegant lockless
:design a fair bit, but it is still much better than slamming a mutex
:around the entire clock code.
:If this patch cures the PIIX problem, something I'm not at all convinced
:about, it should go in, if not only the comment should go in.
:Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
Ok, I've tested Bruce's patch and it appeaars to mostly solve the problem.
I no longer get 'microuptime ... backwards' errors on a -current SMP
However, I think to be complete we need to make it even less elegant.
The TC module is only flip-flopping between two time counters, which
means that it can flip-flop twice and the test will not work. We need
a generation count on the timecounter as well:
tc = timecounter;
gen = tc->tc_generation;
*bt = tc->tc_offset;
bintime_addx(bt, tc->tc_scale * tco_delta(tc));
} while (tc != timecounter || tc->tc_generation != gen);
There is also an issue on non-i386 machines. The timecounter swapping
code requires a memory synchronization point after updating the
contents of the new timecounter but before setting the 'timecounter' global
to the new timecounter. If this is not done, non-i386 machines running
SMP may see the new timecounter structure but access pre-updated values
(i386 boxes do not have this problem because writes are ordered so the
inherent synchronication point at the end of the timer interrupt is
Is there a memory synchronization point macro available?
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message