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