Subject: Re: "frequency error ... exceeeds tolerance"
To: None <tnn@NetBSD.org>
From: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
List: port-alpha
Date: 08/22/2007 01:22:04
tnn@NetBSD.org wrote:

> > > The fix on netbsd-3 is to define the CLKF_BASEPRI macro to 0.
> > 
> > This appears to be in sys/alpha/include/cpu.h, and, looking at
> > kern/kern_clock.c, it doesn't look as though it makes sense to casually
> > define it to zero.  How does that fix this problem?
> 
> If I understand things correctly, it avoids short circuiting softclock
> handling from the hardclock handler. The palcode that invokes hardclock
> doesn't seem to be reentrant, and this makes the system lose hardclock
> ticks.

Yes. There is some description about this in the Design and
Implementation of the 4.4BSD Section 3.4 "Timeout":

>> As an optimiztion, if the state of the processor is such
>> that the softclock() execution will occur as soon as
>> the hardclock interrupt returns, hardclock() simply lowers
>> the processor priority and calls softclock() directly,
>> avoiding the cost of returning from one interupt only
>> to reenter another.

CLKF_BASEPRI() is used to check "the state of the processor" and
spllowersoftclock() is (was) used to "lower the processor priority."

If spllowersoftclock() doesn't enable higher interrupts properly,
softclock() (which might take a bit long time) could be executed
at splclock(9), not splsoftclock(9).
(though I don't know how alpha's spllowersoftclock() worked)

Note after newlock2 merge this optimization has been removed
and softintr is always scheduled if any callout is set.
(to make it MP friendly?)
---
Izumi Tsutsui