[HECnet] KLH10 not idling host CPU

[Mark Abene]

I'm pleased to report that I've found and fixed the problem.
In the "base-kl" rule of src/Makefile.mk, the following settings were in
effect:
-DKLH10_ITIME_SYNC=1
-DKLH10_CTYIO_INT=0

The first one is crucially wrong, and is only really for testing things
related to the interval timer. The second isn't related to idling, but
should be enabled for interrupt-driven console tty i/o.
I compared this to a stock KLH10 Makefile.mk to see the differences, and
corrected accordingly. No idea when or why these got set that way, but I
must've been testing something quite a while ago and forgot about it.
The optimal settings are:
-DKLH10_ITIME_INTRP=1
-DKLH10_CTYIO_INT=1
...with the "-DKLH10_ITIME_SYNC=1" line deleted entirely.

After doing this and recompiling, KLH10 is now correctly idling the CPU in
TOPS-20.
If anyone else is experiencing idling problems, I recommend they check
these Makefile options.

Regards,
Mark



On Mon, Mar 5, 2018 at 5:46 PM, Mark Abene <phiber at phiber.com> wrote:

> 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
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sonic.net/pipermail/hecnet-list/attachments/20180305/385ba6ae/attachment-0001.html>