timekeeping problems on -current ?
Radosław Kujawa
I am observing weird timekeeping related problems. Looks like time is flowing way too fast:
229 Entering Extended Passive Mode (|||60925|)
150 Opening BINARY mode data connection for 'netbsd' (4123070 bytes).
100% |***********************************| 4026 KiB 6.00 GiB/s --:-- ETA
226 Transfer complete.
4123070 bytes received in 00:17 (6.00 GiB/s)
or
# vmstat
vmstat: time makes no sense; namelist must be wrong.
or delay() in kernel:
delay(200000000);
was executed in about 1s.
Perhaps delay loop was calculated wrong?
NetBSD 5.99.45 (IVECS) #32: Sun Feb 13 01:05:09 CET 2011
rku...@Radoslaw-Kujawas-MacBook-Pro.local:/Users/rkujawa/repos/NetBSD-current/src/sys/arch/amiga/compile/obj/IVECS
Amiga 600 (m68030 CPU/MMU no FPU)
total memory = 32768 KB
avail memory = 27656 KB
memory segment 0 at 40000000 size 02000000
memory segment 1 at 00000000 size 00200000
FPU software emulation initialized.
mainbus0 (root)
clock0 at mainbus0: CIA B system hz 100 hardware hz 709379
Calibrating delay loop... 332/1024 us
a2kbbc0 at mainbus0
ser0 at mainbus0: input fifo 512 output fifo 32
par0 at mainbus0
kbd0 at mainbus0: CIA A type Amiga
wskbd0 at kbd0 mux 1
ms0 at mainbus0
wsmouse0 at ms0 mux 0
wsmouse1 at ms0 mux 0
fdc0 at mainbus0: dmabuf pa 0x1f8000: dmabuf ka 0x606000
fd0 at fdc0 unit 0: 3.5dd 80 cyl, 2 head, 11 sec [9 sec], 512 bytes/sec
wdc0 at mainbus0
atabus0 at wdc0 channel 0
pccard0 at mainbus0
pcmcia0 at pccard0
pcmcia0: card appears to have bogus CIS
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
audio0 at aucc0: half duplex, playback, capture
zbus0 at mainbus0
wd0 at atabus0 drive 0: <SanDisk SDCFX3-004G>
wd0: 3919 MB, 7964 cyl, 16 head, 63 sec, 512 bytes/sect x 8027712 sectors
4 views configured
root on wd0a dumps on wd0b
root file system type: ffs
/etc/rc.conf is not configured. Multiuser boot aborted.
--
Best regards,
Radosław Kujawa
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-...@muc.de
Frank Wille
> I am observing weird timekeeping related problems. Looks like time is
> flowing way too fast:
>
> 229 Entering Extended Passive Mode (|||60925|)
> 150 Opening BINARY mode data connection for 'netbsd' (4123070 bytes).
> 100% |***********************************| 4026 KiB 6.00 GiB/s
> --:-- ETA 226 Transfer complete.
> 4123070 bytes received in 00:17 (6.00 GiB/s)
>
> or
>
> # vmstat
> vmstat: time makes no sense; namelist must be wrong.
This is probably a different problem. I can reproduce it with 5.1 userland
and a 5.99.45 kernel. There were some changes in vmstat during the last
weeks.
The error message comes from getuptime() in vmstat.c, and it may be due to
this:
# sysctl kern.boottime
sysctl: kern.boottime: sysctl() failed with Cannot allocate memory
> or delay() in kernel:
> delay(200000000);
> was executed in about 1s.
>
> Perhaps delay loop was calculated wrong?
Looks like that. But I cannot reproduce it with 5.99.45 kernel sources from
the 12th of February.
I also did the FTP-transfer test and it showed me a reasonable value of
650KiB/s on my A3000 68060/50.
> 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.
You may want to debug calibrate_delay() in amiga/dev/clock.c and check the
delaydivisor in amiga/amiga/amiga_init.c.
But especially regarding the vmstat-problem I would try it with a recent
userland first.
> 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! :)
--
Frank Wille
Radosław Kujawa
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
>
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
Frank Wille
Rados?aw Kujawa <radosla...@c0ff33.net> wrote:
> I don't remember seeing this problem on my A3000 with 060.
True. Maybe somebody wants to remove the 060 board from his A3000 and
test with the onboard 68030/25? This should be comparable.
I don't feel like that at the moment... :)
> 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...
Yes.
> But then, why doesn't
> in-kernel delay() work reliably? I've looked at locore.s and it does need
> only properly set delaydivisor.
And the delaydivisor is correct. So it should work. Perhaps there is
something special with the ACA630.
> Userland functions like sleep(), nanosleep(), gettimeofday() seem to work
> fine (though, I don't know how are these implemented, maybe that doesn't
> matter).
AFAIK they use the CIA-based timecounter, while delay() is running a
busy-loop with the CPU using the delaydivisor.
Maybe the CPU gets faster after calculating the delaydivisor? ;)
You could try to recalculate the delaydivisor at a later point during
configure, and see if it is still the same.
I cannot explain it. You have the hardware to debug.
--
Frank Wille