6 Mar
2018
6 Mar
'18
2:46 a.m.
I have this to report:
On the test system where cpu idling appears to work, time interval is set
to "INTRP", and internal clock is set to "OSINT".
On my production system (where idling is failing), time interval is
"SYNCH", and internal clock is "COUNT".
These are conditionally detected compile-time options of KLH10, if I'm not
mistaken, and I can only conclude are the source of the problem.
I'll investigate why, on my production machine, these options were detected
differently.
-Mark
On Mon, Mar 5, 2018 at 5:07 PM, Mark Abene <phiber at phiber.com> wrote:
Thanks for confirming that, Johnny. On my test linux
machine with a clean
KLH10 build, I can confirm that the CPU idling IS in fact working once
TOPS-20 is booted. I was being misled by the 100% CPU usage at the BOOT
prompt. Now that I've confirmed that the KLH10 code isn't at fault in its
interaction with this version of linux, I need to track down why, on my
production machine, the interval timer isn't working correctly to support
idling.
I'll report back with my findings since I'm sure this has affected other
folks seemingly "at random".
Regards,
Mark
On Mon, Mar 5, 2018 at 10:11 AM, Johnny Eriksson <bygg at cafax.se> wrote:
Mark Abene <phiber at phiber.com> wrote:
I'm posting this here in the hopes that there
are other KLH10 emulator
users on HECnet.
There are, I am one of them.
I've been using KLH10 with the tap patches
for years and years, and
idling
has always worked fine. At some point over the
recent couple of years,
idling stopped working for me on linux (I run ubuntu 16.04.4 LTS with
latest updates as of yesterday, on a 64-bit intel machine). My CPU is
stuck
at 100% utilization, without even starting an
emulated OS (I run
TOPS-20).
In fact, as soon as I type "GO" in
KLH10 and before doing anything else,
the CPU immediately shoots to 100%. Is anyone else seeing this? In older
versions of ubuntu/linux this didn't happen.
Handful of points:
* the idling is done by modifying the idle loop in the guest operating
system to interact with the KLH10 idler device, not by identifying
the idle loop like SIMH does.
* until the OS is up and running, there is no idling. In other words,
while at the BOOT> prompt there will be a loop consuming 100% CPU
waiting for terminal input. This is normal, and it has always been
that way.
* if you have had the same TOPS20 system running, with idling, earlier
everything points at your host os (ubuntu) no longer cooperating with
KLH10. I myself run (mostly) FreeBSD, and I have never had problems
with idling the TOPSxx systems.
* for TOPS10, there are a couple of more things to consider, one of them
is that the idler device by default is at device code 700, which can't
be accessed from the mode the -10 idle code runs in. Using 740 works.
I would look for what has changed in your host os (ubuntu) regarding
system timers and such. Your setup *should* work.
Thanks,
Mark
--Johnny