On Fri, 31 Aug 2001 [EMAIL PROTECTED] wrote:
> 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.
I remember this a bit better after reading my log message for rev.1.134
of clock.c :-).
At the time, the clock interrupt handler was not fast. However, it
could be delayed for a while by a fast interrupt handler (it still
can). Since it is delayed, it can't set clkintr_pending and we have
to rely on the irr overflow test working for longer. Rev.1.134 only
claims to work for the non-SMP case. The irr test apparently never
worked for SMP. Otherwise, it might be preferable to use the irr
overflow check instead of or as a backup to clkintr_pending, but it
can't be, since the irr bit is cleared when the irq is acked. This
behaviour also gives races for SMP: the irr bit may become invalid
while you're looking it when another CPU acks the irq.
Making the clock interrupt handler fast doesn't significantly change
the problems as far as I can see.
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
