[TUHS] UNIX v4 Source Code Commentary - complete book now available

[Briam Rodriguez via TUHS]

Angelo,

I took a look at the v4 RK driver source to see what might be going on here.

The v4 driver does something clever with multiple disks: overlapped 
seeks. When rkstart() runs, it iterates through all four drive queues 
and fires off SEEK commands for every drive that has pending work. The 
idea is that while drive 0 is seeking, drive 1 can be transferring data. 
Good for throughput on real hardware.

The tricky part is the interrupt handler. When an interrupt comes in, 
rkintr() checks the SEEKCMP bit in rkcs to figure out if this is a "seek 
finished" or "transfer finished" interrupt. For seek completion, it 
reads bits 13-15 of rkds to determine which drive just finished seeking, 
then kicks off the actual data transfer for that drive.

There's a global variable rk_ap that tracks which drive queue is 
currently mid-transfer. It gets set when a seek completes and used when 
the subsequent transfer completes. This is the state that ties the 
two-phase operation together.

My theory: SIMH isn't correctly emulating the behavior when multiple 
seeks complete at the same (or nearly the same) simulated time. On real 
hardware, you'd get separate interrupts as each drive's seek finishes, 
with rkds properly reflecting which drive triggered each interrupt. But 
in emulation, if two seeks "complete simultaneously," you might only get 
one interrupt, or rkds might only reflect one of the drives.

If that happens, the other drive's seek completion never triggers 
devstart(), so its read/write never actually happens. The process 
waiting in iowait() sleeps forever on B_DONE that never gets set. Hung 
process, exactly as you're seeing.

The busy-waits in the driver (waiting for CTLRDY after commands, waiting 
for DRY|ARDY in error recovery) could also be problematic if the 
emulated status bits don't update with the timing the code expects.

This would explain why v5 works: if they rewrote it to serialize 
operations more conservatively, or changed the state machine to not 
depend on precise interrupt ordering, the emulation timing issues 
wouldn't matter as much.

Might be worth instrumenting rkintr() to log the rkcs and rkds values on 
each interrupt, and see if the drive identification is coming through 
correctly when multiple disks are in use.

cheers

-- Briam R.

On 1/15/26 8:41 AM, Angelo Papenhoff via TUHS wrote:
> I was wondering about the RK driver, because there are issues with it.
> The v4 RK11 driver does not work with simh emulation correctly when
> using multiple disks. I've had to use the v5 driver for my v4
> installation guide to get a usable system. Looking at the code i had the
> impression that the v4 driver is fine (it also matches the nsys RK
> driver, which i've also had trouble with recently. haven't tried v5 RK
> with nsys yet). What i suspect is happening is that the seek/read dance
> isn't working correctly, either in simh, or there were faulty
> assumptions that only work on real hardware more or less accidentially
> (the rewrite in v5 might suggest the latter).
> In any case it looks like blocks aren't being read correctly, and
> whatever process is waiting for the read will hang.
>
> Would be nice to get to the bottom of this.
>
> cheers,
> aap