[its-hackers] sys; atsign dragon

Eric Swenson eric at swenson.org
Thu Nov 17 04:53:40 CET 2016

> On Nov 16, 2016, at 6:17 PM, Ken Harrenstien <iceklh at gmail.com> wrote:

> Since you’ve written, perhaps you can clarify something for me.  If we use the klh10 branch of https://github.com/PDP-10/its <https://github.com/PDP-10/its> to create a disk image, and in so doing are writing ITS and NSALV to the disk image, and then I boot KLH10 with “load @.its-647-es-u” (my ES-ITS image), is the version of ITS in the FE file system of the disk image used at all?  Are we just loading ITS in memory from the host file @.its-647-es-u, rather than from the disk?
> You're loading ITS into memory from the host filesystem, not from the emulated
> ITS filesystem.

That’s what I thought. That is why I think it is so strange that when I take a disk image created from the https://github.com/PDP-10/its <https://github.com/PDP-10/its> (klh10 branch) bootstrap, and then boot with the version of ITS from the host file system (known good, and which works fine with disk images created by customizing the PI/MD disk), that I would run into issues when I assemble midas and then try to assemble any program with the newly built midas. This suggests corruption of the midas image on disk (created with NSALV) or with the some aspect of the file system that causes the wrong stuff to get written when ITS (known good, remember) writes to the new MIDAS BIN or TS MIDAS (after purify step) to the file system.

If I boot a normal KLH10 ITS system (e.g. ES or PI or MD) and then assemble midas and dump a purifed version to disk, I have no issues using that midas to assemble other programs.  It is *only* when I use a disk volume produced using the https://github.com/PDP-10/its <https://github.com/PDP-10/its> bootstrap.

I don’t know what is going on.

Are there step-by-step instructions for using KLH10 and starting with NO disk, to create an ITS disk with the minimum file system required for boot?  I’ve only seen steps that start from a PI/MD file system — never a MINSYS tape.

> Note there are timing races in the original DSKDMP (or am I thinking about
> NSALV?) that will cause it to fail, since the code expects the hardware disk
> to take a long time but the virtual disk responds instantly and wipes out the
> code that is still being executed.

Now that might explain things.  The file system created during the bootstrap was created by NSALV.  This includes the contents of the FE file system before new FE files are created, and system binaries required to boot.  Since *that* file system was created by NSALV, it is conceivable that it got corrupted somehow.  

The problem is: the klh10 bootstrap works fine for Lars on his Ubuntu 14.04 LTS system (and fails for me on the same Linux version).

>  (This, is as opposed to loading @.ddt-u and dskdump.216bin into KLH10, and then loading the @.its (or whatever it is called) from the disk’s FE file system).  The reason I asked is that when I built a disk image using the above repo (klh10) branch, which writes an ITS in the FE file system, but rather than booting with dskdump, I boot with “load @.its-647-es-u” and “go”, I still exhibit corruption when attempt to rebuild midas and then use that built midas to assemble anything.
> We all exhibit corruption of one kind or another, but I think you're referring
> to something about the MIDAS binary, right?  What sort of corruption?

Well, as to what the corruption is, I have no idea.  the symptoms are as shown below:

> ES ITS 1647 IN OPERATION AT 22:20:00
> ES ITS.1647. DDT.1546.
> TTY 0
> You're all alone, Fair share = 0%
> ?? ^Z??
> IT IS NOW 10:20:35 PM EST, THURSDAY, MAR 15,2018
> LL:midas .temp.;_midas;midas
> (Please Log In)
> Pure pages = 13
> ST = 12537
> 1755 words initialization coding.
> Wasted gap pages (MINPUR-MAXMAC) = 7
> Constants area inclusive
> From    To
> 422252  424653
> 37204   37211
> Run time = 0.37
> 3693 Symbols including initial ones (36% used)
> :KILL 
> *:job midas
> !
> *:load .temp.; midas bin
> *purify$g
> :$ Purified, type CR to dump $
> *:find  dnif:?? ?? ?? ?? ?? .temp.^F
> ES   .TEMP.
> FREE BLOCKS #0=35054
>   0   MIDAS  BIN    18 ! 3/15/118 22:20:44
>   0   TS     MIDAS  23 ! 3/15/118 22:21:20
> *$$v
> * MIDAS P 3
> *$^X.
> *midas$j!
> *$l .temp.;ts midasdd
> *$g
>                 0        0.     1-001    ===== Fatal MIDAS internal error! =====
> Please send a message to BUG-MIDAS describing circumstances.
> Error was at location: 
> As you can see, I booted with KLH10 and with host-based ITS (customized by me to change hostname to ES from PI).  The system clearly boots fine, and I’m able to execute the sys3; ts midas that the bootstrap placed on the disk.  This was the version that NSALV wrote from the MINSYS-like tape.  The output from midas suggests that this worked ok.  I was able to load this image into a job and PDUMP a purified image successfully.  It is only when I try to create a new job, load in the newly-built MIDAS, that I get the fatal error when trying to start it up.

> It is entirely possible that the MIDAS binary as distributed includes some
> patches that were never reflected in the MIDAS source.  Also, some programs
> needed to be explicitly run and dumped (or patched and dumped) right after
> being built.  PEEK is a good example of something that tried to do this
> automatically based on the ITS version.

I don’t think this is the issue.  The same bootstrap works perfectly fine with SIMH.  The tape MINSYS tape created by the bootstrap and loaded with NSALV, when run under SIMH, works perfectly fine.  I can rebuilt the assembler, as well as a whole slew of other programs.

> In the ITS distribution notes I tried to record all of the patches and hacks
> that were needed to bring things up, but it wouldn't surprise me if I missed
> a few or if there were some patches that always existed that nobody was
> ever interested in cleaning up.  As you noticed, there are various bits of
> software that simply remained in binary form for so long that the sources
> were lost without being noticed.
> I do hope you're keeping notes about everything you're running into :-)

Hmm…. I guess I should do a better job of that.

> --Ken
>  The thing I find weird about this is that I don’t think I’m using the ITS from the disk, but a pre-built ITS that I know works perfectly fine (since it is the same ITS that I use to run es-its.swenson.org <http://es-its.swenson.org/>).  
> Any help would be appreciated. — Eric
>> On Nov 16, 2016, at 16:02, Ken Harrenstien <iceklh at gmail.com <mailto:iceklh at gmail.com>> wrote:
>> Hmm - don't remember previous msgs... build on what platform?  It was working for me, but my code is a bit newer.
>> On Nov 16, 2016 11:59 AM, "Eric Swenson" <eric at swenson.org <mailto:eric at swenson.org>> wrote:
>> Looks like I’m going to be stuck and the daemon effort. CHANNA; RAKASH NETIME dies on run (with a .val 0) — probably because it can’t access the network.
>> CHANNA; RAKASH PFTHMG is unhappy because there is no DRAGON; DRAGON HOARD.  But I suspect even if I include on in sources.tape, DRAGON will be unhappy because of the clock’s not being set.  It needs to read/write accounting data to DRAGON; DRAGON HOARD.  It appears to start up and go into a wait state — that is probably fine, and perhaps if I set the time before it wakes up again, everything will be good.
>> But:
>>  1) we really need SIMH to return the current time to ITS.  KLH10 does this fine — but as reported earlier, I cannot get KLH10 to work with your build.
>> 2) we need IMP support. KLH10 has it. Does SIMH?  How do we enable/configure it in SIMH?
>> 3) I wasn’t able to run the KLH10 build the last time I tried, and the klh10 branch hasn’t been updated since the last time I tried. I’m inclined to think that I can’t make progress until we have time and network support.  So I was thinking I’d switch to KLH10 — however, as I reported earlier, the build doesn’t succeed on that branch.
>> Suggestions? — Eric

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://its.victor.se/mailman/private/its-hackers_its.victor.se/attachments/20161116/d0b4781f/attachment-0001.html>

More information about the its-hackers mailing list