[Simh] VMS 4.6 won't boot from a Massbus disk

[Bob Supnik]

The performance of your host processor is irrelevant. The simulator times everything in instructions. Interrupts occur the same number of instructions after IO is initiated or completed, regardless of host processor speed.

Are you using a "stock" version of SimH binaries on Windows, or are you running on Linux from binaries that you compiled yourself? If Linux, then which distribution and version, and which C compiler, was used?

As was suggested by another writer, try increasing RP STIME and RTIME from 10 to 1000, and see if that makes a difference.

Finally, you could still be in SYSBOOT. After you type CONTINUE, SYSBOOT does its real work, which is loading VMS itself, setting up the memory environment and tables, and starting the operating system. When the hang occurs, please type ^E and dump the state of the processor:

^E
sim> EX CPU STATE
[long printout]

and mail that information to me.

I find it interesting that the RP has successfully booted everything from V1 to V7 EXCEPT for V4. I'd dearly like to see SYSBOOT and the RH/RP driver for V4...

/Bob

----- Original Message -----
From: "Peter Allan" <petermallan at googlemail.com>
To: "Bob Supnik" <bsupnik at comcast.net>, simh at trailing-edge.com
Sent: Wednesday, January 26, 2011 3:07:43 PM
Subject: Re: [Simh] VMS 4.6 won't boot from a Massbus disk


Thanks to everyone for their suggestions. 

To answer Bob's questions: 

1) I am using the vmb.exe image that comes with simh 

2) The hang does not occur in SYSBOOT. I can get into SYSBOOT, look at the parameter values, change them and type CONTINUE. That is when the system hangs. Yesterday I tried a minimal boot by going into SYSBOOT and typing 
SET/STARTUP OPA0:, but that did not help. 

4) I will try using the Massbus and RP debugging capability and see what it tells me. 

I am running this on a recently purchased quad-core system that is rather fast. I have simh set up on a system that is much slower, so I will give that a try to see if there is a difference. 

Cheers 

Peter Allan 


On 26 January 2011 12:44, Bob Supnik < bsupnik at comcast.net > wrote: 


I agree with Dave Hittner: the hang in booting VMS 4.6 from Massbus is either a timing problem, or a bug in replicating some small detail of the Massbus controller. 

Because booting from an RA81 waits in the same place (but eventually succeeds), the "branch to self" loop where the simulator is waiting appears to be an idle loop, where VMS is waiting for some sort of event, like a disk interrupt. The disk interrupt may have occurred too soon and been lost (a problem which occurred in DEC PDP-11 operating systems and in BSD Unix as well). Or some detail that was unimportant in VMS 7.x mattered in VMS 4.x, such as the handling of attention interrupts versus data transfer interrupts. For an example of the kinds of details that could go wrong, see http://simh.trailing-edge.com/docs/massbusmystery.pdf , which documents an error in the 7.X driver sources for these disks. 

What would be most useful would be a VMS 4.X source set, but up until now, no one in the community has found one. So here are some questions and ideas for debugging this problem. 

1. Are you using the VMB (primary boot) image that comes with the 4.X series, or the default VMB image that comes with the simulator, which is from 7.2? While I don't know of any version skew issues, they could certainly exist. Does the same problem occur when booting with a 4.X VMB? 

2. Does the hang occur in SYSBOOT (secondary boot), or in VMS proper? VMS runs at high virtual memory (8XXXXXXX), yet the branch to self is in low memory. If the hang is in SYSBOOT, the problem is likely to be easier to solve, as the environment is simpler. One thing to check: is memory management enabled? 

3. Other users have reported success in getting early versions of VMS to run. I seem to recall that versions as far back as 1.5 have run successfully. Can we get a census of which versions have been successfully tested on the 780 booting from Massbus, and what version of VMB they use? 

4. Both the Massbus controller (RH) and the device (RP) have debugging capabilities. You can log every register read and write to see how far the the controller gets. 

5. As a last resort, zip up your RP disk image and post it to an uploading site, like Megaupload, so that others in the community can try their hand at the problem. You'll need to include not just the disk image, but configuration data, as well as any auxiliary files (such as an earlier VMB, if you use one). 

/Bob Supnik 


_______________________________________________ 
Simh mailing list 
Simh at trailing-edge.com 
http://mailman.trailing-edge.com/mailman/listinfo/simh