Port-amiga archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: timekeeping problems on -current ?



Radoslaw Kujawa wrote:

> 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



Home | Main Index | Thread Index | Old Index