> Hmm, does -current even need clkintr_pending anymore?  What is its purpose?

There is a problem if i8254_get_timecount locks clock_lock right
before a rollover but reads the timer right afterwards.  In that case,
a too low value can be returned (resulting in 1/Hz too small time
value) although the result will still be monotonous.

For RELENG_4, which uses Xintr0, this problem is reduced by adding the
clkintr_pending variable (cf. revision 1.134 of clock.c and revision
1.38 of apic_vector.s)

Looking more at the code, I now see that clkintr_pending is never set
in -current due to Xintr0 not being used (Xfastintr0 is now used).
Using a fast interrupt for the clock interrupt gives some of the same
reduction of the race window size as the use of clkintr_pending.

- Tor Egge

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

Reply via email to