TENEX now boots to interactive EXEC (@): root causes of the 2022 hangs + working emulator combination

[ajfa]

Good news: with three emulator-side fixes, the install now runs all the way to a fully interactive EXEC — banner, date prompt, @, DIR/DAYTIME/SYSTAT, ENABLE, SSAVE of <SYSTEM>EXEC.SAV, and DLUSER completing with its usual "CAN'T CREATE USER ... CONTINUING" chatter. Transcript tail:

TENEX IN OPERATION
NO EXEC
.INIT BIT TABLE.
READ BADSPOTS FROM FILE: TTY: [Confirm] ^Z
.GET FILE DTA0:EXEC.SAV [Confirm]
.START.
 SUMEX-AIM Tenex 1.31.82, SUMEX-AIM EXEC 1.51
 ENTER DATE AND TIME AS MM/DD/YY HH:MM -- 08/01/76 08:00
@DIR
   <SYSTEM>
 DIRECTORY.;1 / DSKBTTBL.;1 / EXEC.SAV;1 / INDEX.;1 / JOBPMF.;...
@SYSTAT
 UP 0:20:27  ONE JOB

What was blocking it

1. The post-restart hang ("TENEX RESTARTING, WAIT... NO CHECKDSK" then silence forever): fork 0 blocks in the SKIPE TTOCT(line) wait for DC10 scanner line 0's output queue to drain — TTMSG sends "TENEX IN OPERATION" to all TTYs. The emulator's kx10_dc.c only consumes output when a TCP client is connected to the line, so with nobody attached the queue never drains. Workaround: keep a TCP client connected to the DC port (12345) throughout the boot — the instant it connects, the system unwedges. Reported with a suggested device fix at rcornwell/sims (kx10_dc should complete transmission on unconnected lines, as real hardware does).

2. GET FILE DTA0:EXEC.SAV crashing into a tight loop at absolute 45: the branch point of lars/tenex-patches predates Richard's upstream fixes for KI10 second-instruction interrupt dispatch. When the channel-2 vector's CONSZ does not skip, the emulator executed the "second instruction" from absolute 45 instead of EPT+45 (EB=050000). Cherry-picking upstream 62805b8 ("Fixed second instruction interrupt address") and 047beb0 ("Fix second interrupt instruction") on top of lars/tenex-patches + lars/dt fixes it.

3. Minor: current rcornwell/sims HEAD additionally SIGFPEs in kx10_tym.c (room() divides by a ring size read from uninitialized guest memory) with the stock hardware.do's set tym enabled — also reported upstream. Workaround: set tym disabled.

Working combination

• Emulator: larsbrinkhoff/ka10-simh branch lars/tenex-patches + cherry-picks 5e8c0b9 (lars/dt), 62805b8, 047beb0 (upstream sims).
• Media regenerated with the repo's install/media.sh (tendmp round-trips byte-identical, so the tooling is fine).
• Install dialogue exactly as in simh/syslod.do, plus a socket client parked on the DC port.
• One timing note: mini-exec GET FILE DTA0:EXEC.SAV takes ~4 minutes of realistic DECtape crawl; typing ahead during it can wedge things, so scripts should wait for the next . prompt before sending S.

The SYSGO$G reboot ("INTERRUPT AT 0") and MINI-DUMPER issues from the README are still there, and the sporadic *DISK ERROR: reports (error counter words show they're mostly recoverable retries; the non-rec ones cluster around the Tymnet-base code paths touching drives 4/5) are unchanged — but a fresh SYSLOD install now reliably reaches a usable TENEX in ~10 minutes of wall clock.

Thanks for rescuing this system — happy to share the scripted install (SIMH expect-driven, lands at @ unattended) if useful.

[larsbrinkhoff]

Thank you so much, that's great news! I'm happy to take any pull requests you want to post. Your suggested fixes are of course spot on.

The system isn't exactly rescued yet, although of course these problems were hard blockers for making progress. Now it's time to add more system and subsystem files, of which there are plenty.

[larsbrinkhoff]

I rebased lars/tenex-patches on top of @rcornwell's lastest master.

[ajfa]

Follow-up: the sporadic *DISK ERROR: / ***NON-REC DISK ERROR: reports (and the "DLUSER emits error messages" behaviour) are also emulator-side, and there is a one-line fix.

Diagnosis

The five words TENEX prints are: running error counter, DSKDAW (the DATAO command), DSKCAW (DF10 CCW), DSKSTS (driver-internal status), and the CONI error bits. Decoding the failing operations showed them all legal (e.g. READ drive 1, cyl 356., surf 7, sect 2 — well within RP03 geometry), each retried in an endless DCLERR (CONO 175735) loop with CONI reading 055.

Bit-level story (with set dpa debug=coni;cono;detail):

• Good completions read CONI 045 = CCW_COMP(040) | PIA(5).
• Failing ones read 055 = CCW_COMP | PI_ENABLE(010) | PIA.
• PI_ENABLE sticks when a unit still has SEEK_DONE pending: a seek that completes while the DF10 is busy has its attention interrupt suppressed (if ((df10->status & BUSY) == 0) df10_setirq(df10); in kx10_dp.c), and the ack-CONO path then keeps re-requesting the interrupt.
• On the re-entered service loop TENEX executes DSZERR: CONSZ DSK,177760 — and bit 040 is in that error mask. CCW_COMP is DF10-internal bookkeeping that the emulator ORs into the RP10 CONI (*data = df10->status | uptr->STATUS); the real RP10 never presents a "CCW written" flag there. So TENEX sees a phantom error condition, DSKERR retries forever, the recoverable-error counter climbs (~0340 per boot!), and after DSKNTR retries you get the NON-REC report plus the BUGCHKs.

Fix (verified)

Mask the internal bit out of CONI in kx10_dp.c:

     case CONI:
        *data = (uint64)((df10->status & ~CCW_COMP) | uptr->STATUS);

With this, a full install + EXEC session + the previously guaranteed trigger (connecting to a DC line and poking LOGIN, which exercises the TYMBAS path) runs with DSKRCE = DSKNRE = 0 — not a single disk error, recoverable or otherwise, where before each boot accumulated ~224 recoverable retries and the trigger produced NON-RECs within seconds.

Upstream rcornwell/sims fixed the same thing more thoroughly in 56d5ca2 ("Fixed handling of CCW complete flag to match documentations", 2022-04-25 — three days after this repo's status note) by removing CCW_COMP from df10->status entirely. That commit postdates the lars/tenex-patches branch point; in my quick attempt cherry-picking it wholesale onto the branch didn't boot (probably needs adjacent follow-ups), so for this tree the one-line CONI mask is the safe equivalent.

So the current full working set on top of lars/tenex-patches is: 5e8c0b9 (lars/dt) + 62805b8 + 047beb0 (upstream, interrupt dispatch) + the CONI mask above — TENEX installs, runs, and now does so with a completely clean disk error log.

[larsbrinkhoff]

CCW_COMP is DF10-internal bookkeeping that the emulator ORs into the RP10 CONI (*data = df10->status | uptr->STATUS); the real RP10 never presents a "CCW written" flag there. So TENEX sees a phantom error condition

While it may well be that the emulator handling of CCW_COMP is a problem for TENEX, I don't understand how you reached the conclusion that it's something RP10 never presents. Checking the RP10-C manual https://bitsavers.org/pdf/dec/pdp10/periph/DEC-10-HRPC-D_RP10-C_Disk_Pack_Synchronizer_Maint_Oct73.pdf#page=52 we can see the CONI bits.

In any case, I rebased my lars/tenex-patches, so it now includes 56d5ca2. Please check if it solves the DISK ERROR problem.

[ajfa]

You're right about bit 30, thanks for the correction — I overclaimed with "never presents". Reading the RP10-C manual you linked (3-20/3-21): the bit exists, and its description is "indicates that the channel control word was written into memory only when that request was made by the synchronizer via a CONO". So the divergence wasn't the bit's existence but its lifetime: the pre-56d5ca2 emulator set it after every transfer completion (df10_writecw), whereas the hardware only raises it on explicit CONO request — which TENEX never issues, so on real iron TENEX never saw bit 040 in its DSZERR mask. 56d5ca2 implements exactly the manual's semantics; my one-line mask was just the safe equivalent for the pre-rebase tree.

Rebased branch: tested — it works, but it needed three repairs

Result first: with the fixes below, the rebased branch installs to a fully interactive EXEC and the disk error counters stay at zero (DSKRCE = DSKNRE = 0) through the install plus the TYMBAS trigger that previously produced NON-RECs within seconds. So yes — with the rebase (i.e. with 56d5ca2's CCW_COMP semantics) the DISK ERROR problem is solved.

What I had to fix to get there:

1. KI build breakage (rebase artifacts)

• kx10_defs.h: upstream master now defines NUM_DEVS_DDC 1 for KA | KI (the DDC10 drum), so the branch's #if KI / #define NUM_DEVS_DDC TENEX is a redefinition error under -Werror.
• kx10_sys.c: &ddc_dev ends up in sim_devices[] twice (upstream's entry + the branch's), which at runtime gives DDC device number conflict at 440 and a HALT loop as soon as set ddc enabled runs.
• kx10_dk.c: the branch's debug prints use %012llo for INT_REG/CLK_REG, which are now int32 upstream → -Werror=format.
• Also: ki10_ddc.c (the RES-10 stub) is no longer referenced by the makefile, so it silently doesn't build; upstream's kx10_ddc now owns 0440.

2. A serious upstream master regression (this is why the branch seemed dead)

With the branch building, SYSLOD went completely silent. Root cause via git bisect (77 commits, automated on "does SYSLOD start writing the disk"):

881114ef "KA10: Updated PiDP10 display of memory indicator register" (2025-09-10) — among ~50 no-op UPDATE_MI() insertions there is one stray functional line in the KI Mem_read, in the previous-context AC path:

            if (!cur_context && ((xct_flag & 1) != 0)) {
                ...
                    MB = FM[fm_sel|AB];          /* previous-context fast AC */
                ...
                if (fetch == 0 && hst_lnt) {
                    hst[hst_p].mb = MB;
                }
                MB = get_reg(AB);   /* <-- stray: clobbers it with the CURRENT-context AC */
                return 0;
            }

Every XCTR-style previous-context AC read returns the monitor's own AC instead of the user's, so TENEX's JSYS dispatch (user PC doing JSYS 114510) loops forever in MENTR. Deleting that line fixes it — verified on pure master and on your branch. This presumably affects any KI monitor doing prev-context AC reads, not just TENEX. Reported upstream with the bisect details.

3. Upstream kx10_ddc segfaults when enabled but not attached

After the XCTR fix, the install crashed with SIGSEGV: ddc_svc → __fseeko(fp=0x0). The master DDC10 drum service doesn't check UNIT_ATT before seeking on fileref, and TENEX touches 0440 during the restart. Workaround: attach files to ddc0-3 (which is also what SUMEX would want eventually). Also reported upstream; the fix is a one-line UNIT_ATT guard in ddc_svc.

Still needed on any base

The DC10 unconnected-line drain issue (rcornwell/sims#336) is unchanged in master, so the TCP-client-on-the-DC-port workaround is still required to get past TENEX IN OPERATION.

Happy to send PRs for the branch build fixes if useful. And yes — on to DLUSER/DUMPER and populating <SYSTEM> and <SUBSYS>.

(Upstream reports: rcornwell/sims#339 for the XCTR regression, rcornwell/sims#340 for the DDC segfault.)

[larsbrinkhoff]

I have made fixes for the above; I will submit pull requests tomorrow.

The problem I'm seeing is that once the system is restarted, the .SAV files aren't runnable. In particular <SYSTEM>EXEC.SAV doesn't work, so I can't log in. Are you seeing this too?

When I worked on this some years ago, I did not see the file data being written to disk. Although they appear in the <SYSTEM> directory, the file contents wasn't there.

[ajfa]

Yes — I see exactly what you describe, and your memory of "the file contents wasn't there" is measurably right. I dug into it; here's what I can confirm, plus one real emulator bug found along the way (which turns out to be necessary but not sufficient).

Reproduction, measured from outside the machine

Fresh SYSLOD install, then ENABLE / MOUNT DTA0: / GET DTA0:EXEC.SAV / SSAVE 0 777 EXEC.SAV / DIR. EXEC.SAV;1 duly appears in <SYSTEM>. Then I halted the system properly (QUIT, HALT TENEX.) and exited the simulator so all buffers were flushed, and counted the non-zero bytes of every disk image before and after:

image	before SSAVE	after SSAVE + clean shutdown
tenex1.rp03	764	764
tenex4.rp03	25656	25656
tenex6.rp03	246371	246371

Not one byte changed. With set dpa debug=detail over the whole GET+SSAVE+DIR window, the RP10 sees exactly 16 sector writes and zero reads — nowhere near the ~160 sectors that ~40 pages of EXEC would need. So the file data never reaches the disk at all; those 16 writes are just directory/index housekeeping.

Rebooting with SYSLOD$G and answering N to the clobber question ("I THOUGHT NOT. PLEASE BE MORE CAREFUL IN THE FUTURE.") never gets past TENEX RESTARTING, WAIT... — the on-disk file system is missing too much to come back up.

Where the data does go: the drum — and an emulator bug there

The pages go to the RES-10 drum, and there the current kx10_ddc.c loses them. The transfer direction and the flush-to-file test disagree about the function code:

   if (func == 2) {            /* buffer -> memory: a READ  */
       Mem_write_word(...)
   } else if (func == 1) {     /* memory -> buffer: a WRITE */
       Mem_read_word(...)
...
done:
       if (func == 2) {        /* but the flush happens on the READ code */
          sim_fwrite(&ddc_buf[0], ...);

TENEX issues func == 1 commands throughout, so with set ddc debug=detail you get Read/Set done lines and never a single Write — the drum files stay 0 bytes all session, and every page swapped out comes back as zeros. Changing that test to func == 1 makes the same session log 46 drum writes and grow the drum image to ~132 KB of real data. Reported as rcornwell/sims#342.

Honest verdict: necessary, but not the whole story

I want to be careful not to oversell that fix:

• It does not change the disk picture. With the fix applied, the RP10 still sees exactly the same 16 writes during SSAVE; the file contents still never land on disk, and a CLOBBER? N restart still hangs at TENEX RESTARTING.
• In-session, <SYSTEM>EXEC.SAV is actually fine either way. GET EXEC.SAV (from disk, not DECtape) followed by START gives me the banner and a working @ — DIR, DAYTIME and all — and it does so both with and without the drum fix, because the pages are still in core. So that test doesn't discriminate; the failure is specifically about surviving a restart.

So the picture I have is: the file system metadata is written, the file pages are not — they live in core (and, with the fix, in the drum), and nothing ever copies them down to the disk. That looks less like a device bug now and more like the page-out/checkpoint path never running: whatever should force modified pages of a closed file out to the RP03s isn't happening. You know the monitor far better than I do — is DRUMP/the swapping configuration relevant here (drum vs. disk swapping area), or is there a CHKPNT-style flush that a normally-shut-down system would be expected to perform?

I can run any experiment you want on this rig — it reinstalls to an interactive EXEC unattended in about five minutes, and I can trace the RP10 and the drum at sector level.

[larsbrinkhoff]

I updated rcornwell/sims#343 to include a fix for writing to the RES-10 drum.

I don't have any clue about flushing paged out pages to the file system.