5 Mar
2018
5 Mar
'18
9:11 a.m.
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
6 Mar
6 Mar
2:07 a.m.
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
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
3:11 a.m.
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
2:41 p.m.
New subject: DECnet for Tru64 5.1B
Hi,
Is there any way to obtain a copy of DECnet for Tru64 5.1B (OSF1 V5.1
2650 alpha)? I would love to join the club of TIGER, MISSY, ERBIUM,
KALIUM and VISMUT if possible.
BTW I also just cross-posted a request for Pathworks for OS/2 and DECnet
for Tru64 at comp.os.vms.
Thank you,
Supratim
2452
days inactive
2453
days old
4 comments
3 participants
participants (3)
-
bygg＠cafax.se -
phiber＠phiber.com -
supratim＠riseup.net