[Simh] write errors attempting to install 4.3BSD on vax; simh from git

[Mark Pizzolato - Info Comm]

On Thursday, May 22, 2014 at 1:21 PM, Brad Parker wrote:
> Hi,
> 
> I pulled the latest from the simh git hub and built vax730, vax750 and
> vax780.
> 
> I initially tried to install the UWisc 4.3+NFS from a tape image, using
> a recipe I found.
> It fails when I try to "newfs ra0h ra81".  The error is "write error:
> 759667"
> 
> It looks like the driver is trying to write past the end of the disk;
> but the rq code in simh is not seeing that.
> It does not seem to be throwing any errors.

A driver which trys to write beyond the end of the disk will cause the simulation to return an error to the driver, but won't blow up in the simulator.  Real software could have done the same thing and the hardware would merely have returned an error just like the simulated device does.

> I'm not sure how to debug this;  I added some printfs to pdp_rq.c; There
> seems to be some debug disk logging inside simh but I can't find any
> docs about how to use it...

Debugging within the simh device simulation generally requires significant detailed knowledge of how the guts of thing are working.  That said, you can always learn.

Simh debug output is enabled with a combination of several things:

1) Debug output must be enabled and a destination specified.  This is done with:
     
      sim> set debug debug-output-destination

     see HELP SET DEBUG

2) one or more devices need to be put into debug mode or have specific debug flags enabled.  This is done with:

      sim> set dev debug
or
      sim> set dev debug=flagx;flagy

     see "HELP dev SET" (i.e. HELP RQ SET)

If you think the newfs command is trying to write beyond the end of the disk, you could avoid that by using a bigger disk than what you mention in the 'newfs' command (i.e. make rq0 a RA82...

> I also tried a stock 4.3BSD distribution and I see exactly the same
> behavior.
> 
> My memory is dim on where the partition info is, but I think in this
> case it's hard coded in the unix kernel.
> 
> I might go back and try some very old simh vax releases, since it seems
> like this use to work.  If anyone has any ideas or insight, I'm all ears.

As it turns out, there were issues with some newer BSD variants on older VAX models.  No one had actually done an install on one of these older machines once they started working with MicroVAX systems (MicroVAX II and MicroVAX III (CVAX)).  We discovered a bug in the newer versions of boot block code when booting an older VAX.  I have a version of VMB.exe which can work with either the old paradigm or the broken one and let these older systems boot these various versions.  You haven't gotten that far, so even if the problem I'm talking about actually affects the 4.3 system you're working with you wouldn't have noticed yet.

- Mark