Re: Keyboard lockup with NetBSD5

[Ignatios Souvatzis <is%netbsd.org@localhost>]

Hi,

On Mon, Nov 16, 2009 at 11:30:29PM +0100, Frank Wille wrote:
> Ignatios Souvatzis wrote:
> 
> On 14.11.09 09:40:41 you wrote:
> 
> > DraCo Rev 4. has no guaranteed CIA, - for the clock interupt, it has a 
> > freerunning counter instead - so the easiest and cleanest solution was
> > to copy the Sun3 method for DELAY, which was a calibrated counter at a
> > cache-aligned position, (initialized to the value for the fastest CPU
> > of each type, and calibrated by the clock device at early
> > initialization.) This way, it was independent of additional hardware.
> 
> Ok. I had a look at the 4.0 source. I'm not sure if it had the same
> precision (it probably has), but it definitely had less overhead.

The resolution is 8 cpu clocks for 68020/68030, 3 cpu clocks for
68040 (or was it: 8 for 020, 3 for 030/040 ?) and 1 cpu clock for
68060. It's pre-calibrated to the fastest known CPU clocks of each
type (which might make delays up to three times as long as nominal
if used on a 16 MHz 68030), and then calibrated when clock.c
initializes.

If I recall correctly, the maximum possible delay value is 2^32-1
clock ticks, that's 85 seconds for a 50 MHz 68060, and 65 seconds
on a 66 MHz one (the 75 MHz 68060 are MMU-less, afaik).

The systematic error is one call overhead (same for the new
implementation) plus: probably one cache-line loading time
and possibly (on the '60) one unpredicted branch time.

The precision is the same as for the new method, once it's calibrated.
(basically, we need to measure the CPU clock, as contrary to saner
architectures, the firmware provides no knowledge of that...), but
with the pre-5 method, we only access the timer hardware for
calibration.

> > I did not look closely at the timecounter implementation - I've always
> > meant to, but didn't find the time - but I never suspected it would 
> > replace the DELAY routine.
> 
> It doesn't have to. But did you try it on a DraCo? Both, the timecounter and
> delay(), are calling clk_gettick(), which also seems to be prepared for the
> DraCo Rev.4 timer.
...
> A timecounter has to return the current value of a counter with a fixed
> frequency. How can you do that with a calibrated loop?

Yesyes. But why would that influence the DELAY/delay implementation?

Regards,
        -is