VAX-11/730 %BOOT-F-Unexpected Machine Check
Johnny Billquist
bqt at update.uu.se
Tue Jun 9 16:43:22 CDT 2015
On 2015-06-09 20:01, Mark J. Blair wrote:
>
>> On Jun 9, 2015, at 09:57 , Peter Coghlan <cctalk at beyondthepale.ie> wrote:
>> [Lots of great stuff]
>
> Thank you very much! The clue about R5 on other VAXen may prove to be critically helpful. I can study the various boot scripts for clues to see if the register use looks consistent. I did see one hint that sticking 1 instead of 0 into one particular register (I don't recall which one of the top of my head) seemed to indicate a conversational boot instead of turnkey one.
>
> Is there VMB.EXE documentation out there that I don't know how to
find yet? Even if it's for VMB.EXE for a different VAX-11 machine, the
one for my 730 might follow the same register conventions.
Yes, R5 is more or less used the same on all VAXen, since this is used
by VMB, which almost all VAXen use in one form or another.
The documentation exists in various places. Here is from the VAX86x0 help:
! R5: - software boot control flags. The value -1 is reserved.
!
! Bit Meaning
! --- -------
!
! 0 RPB$V_CONV.
! Conversational boot. At various points in the
! system boot procedure, the bootstrap code
! solicits parameters and other input from the
! console terminal. If the DIAG is also on, then
! the diagnostic supervisor should enter "MENU"
! mode and prompt user for devices to test.
!
! 1 RPB$V_DEBUG.
! Debug. If this flag is set, VMS maps the code
! for the XDELTA debugger into the system page
! tables of the running system.
!
! 2 RPB$V_INIBPT.
! Initial breakpoint. If RPB$V_DEBUG is set, VMS
! executes a BPT instruction immediately after
! enabling mapping.
!
! 3 RPB$V_BBLOCK.
! Secondary boot from boot block. Secondary
! bootstrap is a single 512-byte block, whose
! LBN is specified in R4.
!
! 4 RPB$V_DIAG.
! Diagnostic boot. Secondary bootstrap is image
! called [SYSMAINT]DIAGBOOT.EXE.
!
! 5 RPB$V_BOOBPT.
! Bootstrap breakpoint. Stops the primary
! and secondary bootstraps with a breakpoint
! instruction before testing memory.
!
! 6 RPB$V_HEADER.
! Image header. Takes the transfer address of the
! secondary bootstrap image from that file's
! image header. If RPB$V_HEADER is not set,
! transfers control to the first byte of the
! secondary boot file.
!
! 7 RPB$V_NOTEST.
! Memory test inhibit. Sets a bit in the PFN bit
! map for each page of memory present. Does not
! test the memory.
!
! 8 RPB$V_SOLICT.
! File name. VM at prompts for the name of a
! secondary bootstrap file.
!
! 9 RPB$V_HALT.
! Halt before transfer. Executes a HALT
! instruction before transferring control to the
! secondary bootstrap.
!
! 10 RPB$V_NOPFND.
! No PFN deletion (not implemented; intended to
! tell VM at not to read a file from the boot device
! that identifies bad or reserved memory pages,
! so that VM at does not mark these pages as valid
! in the PFN bitmap).
!
! 11 RPB$V_MPM.
! Specifies that multi-port memory is to be used
! for the total exec memory requirement. No local
! memory is to be used. This is for tightly-coupled
! multi-processing.
!
! 12 RPB$V_USEMPM.
! Specifies that multi-port memory should be used in
! addition to local memory, as though both were one
! single pool of pages.
!
! 13 RPB$V_MEMTEST
! Specifies that a more extensive algorithm be used
! when testing main memory for hardware uncorrectable
! (RDS) errors.
!
! 14 RPB$V_FINDMEM
! Requests use of MA780 memory if MS780 is
insufficient
! for booting. Used for 11/782 installations.
!
! 15 RPB$V_AUTOTEST
! Used by Diagnostic Supervisor.
!
! 16 RPB$V_CRDTEST
! Specifies that memory pages with correctable (CRD)
! errors NOT be discarded at bootstrap time. By
default,
! pages with CRD errors are removed from use
during the
! bootstrap memory test.
!
! <27:17> MBZ - Reserved for future expansion.
!
! <31:28> RPB$V_TOPSYS
! Specifies the top level directory number for system
! disks with multiple systems
> Another approach came to mind that might be a lot easier than swapping a humorously large number of virtual TU58 cassettes, or might be yet another goose chase. One of my last recent eBay purchases before I quit both eBay and PayPal in a huff over terms of service changes was a TK50 drive and both UNIBUS and QBUS interface cards for it. All of the pieces are unknown quantities, and I'll need to kludge a power supply and fabricate an interface cable, but the drive can theoretically be plugged into my 730. If the 5.3 standalone backup knows about TK50 drives, then I may be able to try backing up whatever is on the hard drives to TK50 cartridges.
Yes, the standalone BACKUP knows about the TK50. More generally, it
knows most any kind of TMSCP tape controller you might possibly attach
to the machine, and it can deal with them.
> Next, if I get a TZ30 drive, I wonder if I might be able to plug it into my Sun Ultra 60 running Solaris 8 (since that's my workingest computer with both a SCSI interface and a familiar UNIXy operating system), and then use that to slurp data off the backup cartridge(s) for further analysis. Does this approach sound plausible? Unless somebody happens to know that the TZ30 is incompatible with generic SCSI tape support on UNIX boxen, I think I'll contact the same seller I bought the TK50 from and see if they have a TZ30 sitting around.
Yes, you should be able to plug a TZ30 in to pretty much any Unix box,
and read TK50 tapes off that.
> Yet another approach might be doing the same scheme with my system's existing magtape drive, and then trying to get my hands on a SCSI magtape drive to plug into my Sun. But that would involve shipping a much larger and heavier piece of equipment.
Agreed.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
More information about the cctech
mailing list