Re: timekeeping problems on -current ?

[RadosÅaw Kujawa <radoslaw.kujawa%c0ff33.net@localhost>]

On Feb 13, 2011, at 2:00 PM, Frank Wille wrote:
> 
>> clock0 at mainbus0: CIA B system hz 100 hardware hz 709379
>> Calibrating delay loop... 332/1024 us
> 
> 332/1024 looks normal for a 68030 with 50MHz. My 68060 got 21/1024.
amiga_init.c has 163 hardcoded, as a default value for 68030 50MHz. My CPU is a 
25MHz 68030 (ACA630). 

I don't remember seeing this problem on my A3000 with 060.

> You may want to debug calibrate_delay() in amiga/dev/clock.c and check the
> delaydivisor in amiga/amiga/amiga_init.c.

clock0 at mainbus0: CIA B system hz 100 hardware hz 709379
orig value: delaydivisor=163, amiga_clk_interval=7093
Calibrating delay loop... 
diff 2076 us, new divisor 331/1024 us
diff 1032 us, new divisor 334/1024 us
diff 1019 us, new divisor 333/1024 us

If the equation delaydivisor = (1024 * 8) / CPUMHz is right, then value around 
330 seems to be fine for a 25MHz 68030... But then, why doesn't in-kernel 
delay() work reliably? I've looked at locore.s and it does need only properly 
set delaydivisor.

Userland functions like sleep(), nanosleep(), gettimeofday() seem to work fine 
(though, I don't know how are these implemented, maybe that doesn't matter).

> But especially regarding the vmstat-problem I would try it with a recent
> userland first.
Ok, I see that's probably unrelated.

> 
>> ivecs0 at mainbus0
>> ivecs0: couldn't switch to graphics core
>> ivecs0: Indivision ECS graphics core 0: Indivision ECS graphics core 7:
>> Indivision ECS graphics core 7 aucc0 at mainbus0
> 
> Nice! :)

This is still very much work-in-progress. I just needed to insert some 
delay()'s to debug why Indivision FPGA isn't loading what I want, that's how I 
discovered the problem.

--
Best regards,
Radoslaw Kujawa