[HECnet] KLH10 not idling host CPU

[Mark Abene]

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/324ed55d/attachment.html>