incomplete work. moved them, repaired some, it is a giant mess

3 files changed, 336 insertions, 241 deletions

diff --git a/share/man/man8/man8.vax/Makefile b/share/man/man8/man8.vax/Makefile
index 712892af312..3d0611a88a6 100644
--- a/share/man/man8/man8.vax/Makefile
+++ b/share/man/man8/man8.vax/Makefile
@@ -1,7 +1,7 @@
 #	@(#)Makefile	5.5 (Berkeley) 3/22/91
 #	$NetBSD: Makefile,v 1.5 1995/09/06 21:36:42 jtc Exp $
 
-MAN=	MAKEDEV.8 crash.8 drtest.8 format.8 installboot.8
+MAN=	MAKEDEV.8 boot_vax.8 drtest.8 format.8 installboot.8
 MLINKS=	MAKEDEV.8 makedev.8
 MANSUBDIR=/vax
 
diff --git a/share/man/man8/man8.vax/boot_vax.8 b/share/man/man8/man8.vax/boot_vax.8
new file mode 100644
index 00000000000..047b3111212
--- /dev/null
+++ b/share/man/man8/man8.vax/boot_vax.8
@@ -0,0 +1,335 @@
+.\"	$OpenBSD: boot_vax.8,v 1.1 2000/11/09 03:57:35 deraadt Exp $
+.\"	$NetBSD: boot_vax.8,v 1.3 1995/04/23 10:33:39 cgd Exp $
+.\"
+.\" Copyright (c) 1980, 1991, 1993
+.\"	The Regents of the University of California.  All rights reserved.
+.\"
+.\" Redistribution and use in source and binary forms, with or without
+.\" modification, are permitted provided that the following conditions
+.\" are met:
+.\" 1. Redistributions of source code must retain the above copyright
+.\"    notice, this list of conditions and the following disclaimer.
+.\" 2. Redistributions in binary form must reproduce the above copyright
+.\"    notice, this list of conditions and the following disclaimer in the
+.\"    documentation and/or other materials provided with the distribution.
+.\" 3. All advertising materials mentioning features or use of this software
+.\"    must display the following acknowledgement:
+.\"	This product includes software developed by the University of
+.\"	California, Berkeley and its contributors.
+.\" 4. Neither the name of the University nor the names of its contributors
+.\"    may be used to endorse or promote products derived from this software
+.\"    without specific prior written permission.
+.\"
+.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
+.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+.\" ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
+.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+.\" SUCH DAMAGE.
+.\"
+.\"     @(#)boot_vax.8	8.2 (Berkeley) 4/19/94
+.\"
+.Dd April 19, 1994
+.Dt BOOT_VAX 8 vax
+.Os
+.Sh NAME
+.Nm boot
+.Nd
+.Tn vax-specific
+system bootstrapping procedures
+.Sh DESCRIPTION
+.Ss Power fail and crash recovery
+Normally, the system will reboot itself at power-up or after crashes.
+Provided the auto-restart is enabled on the machine's front panel,
+an automatic consistency check of the file systems will be performed,
+and unless this fails, the system will resume multi-user operations.
+.Pp
+.Ss Cold starts
+These are processor-type dependent.
+On an 11/780, there are two floppy files for each disk controller,
+both of which cause boots from unit 0 of the root file system
+of a controller located on mba0 or uba0.
+One gives a single-user shell, while the other invokes the multi-user
+automatic reboot.
+Thus these files are
+.Tn HPS
+and
+.Tn HPM
+for the single
+and multi-user boot from
+.Tn MASSBUS
+RP06/RM03/RM05 disks,
+.Tn UPS
+and
+.Tn UPM
+for
+.Tn UNIBUS
+storage module controller and disks
+such as the
+.Tn EMULEX
+SC-21
+and
+.Tn AMPEX
+9300 pair,
+.Tn RAS
+and
+.Tn RAM
+to boot from
+.Tn MSCP
+controllers and disks such as the RA81,
+or
+.Tn HKS
+and
+.Tn HKM
+for RK07 disks.
+There is also a script for booting from the default device,
+which is normally a copy of one of the standard multi-user boot scripts,
+but which may be modified to perform other actions
+or to boot from a different unit.
+The situation on the 8600 is similar, with scripts loaded from the console RL02.
+.Pp
+Giving the command
+.Pp
+.Dl >>>BOOT HPM
+.Pp
+would boot the system from (e.g.) an RP06 and run the automatic consistency
+check as described in
+.Xr fsck 8 .
+(Note that it may
+be necessary to type control-P
+and halt the processor
+to gain the attention of the
+.Tn LSI-11
+before getting the >>> prompt.)
+The command
+.Pp
+.Dl >>>BOOT ANY
+.Pp
+invokes a version of the boot program in a way which allows you to
+specify any system as the system to be booted.
+It reads from the console a device specification (see below) followed
+immediately by a pathname.
+.Pp
+The scripts may be modified for local configuration if necessary.
+The flags are placed in register 11 (as defined in
+.Aq Pa sys/reboot.h ) .
+The boot device is specified in register 10.
+The encoding of this register is also defined in
+.Aq Pa sys/reboot.h .
+The current encoding has a historical basis, and is shown in the following
+table:
+.Pp
+.Bd -unfilled -offset indent -compact
+bits		usage
+0-7		boot device type (the device major number)
+8-15		disk partition
+16-19	drive unit
+20-23	controller number
+24-27	adaptor number (UNIBUS or MASSBUS as appropriate)
+.Ed
+.Pp
+The adaptor number corresponds to the normal configuration on the 11/750,
+and to the order in which adaptors are found on the 11/780 and 8600
+(generally the same as the numbers used by
+.Tn UNIX ) .
+.Pp
+On an 11/750, the reset button will boot from the device
+selected by the front panel boot device switch.
+In systems with RK07's, position B normally selects the RK07 for boot.
+This will boot multi-user.
+To boot from RK07 with boot flags you may specify
+.Pp
+.Bd -unfilled -offset indent -compact
+.Li \&>>>B/ Ns Fl n No DMA0
+.Ed
+.Pp
+where, giving an
+.Ar n
+of 1 causes the boot program
+to ask for the name of the system to be bootstrapped,
+giving an
+.Ar n
+of 2 causes the boot program to come up single-user,
+and an
+.Ar n
+of 3 causes both of these actions to occur.
+The
+.Dq DM
+specifies RK07, the
+.Dq A
+represents the adaptor number
+.Pf ( Tn UNIBUS
+or
+.Tn MASSBUS ) ,
+and the
+.Dq 0
+is the drive unit number.
+Other disk types which may be used are DB
+.Pq Tn MASSBUS ,
+DD (TU58),
+and DU
+.Pf ( Tn UDA-50/RA
+disk).
+A non-zero disk partition can be used by adding (partition times 1000 hex)
+to
+.Ar n .
+.Pp
+The boot procedure on the Micro
+.Tn VAX
+II
+is similar.
+A switch on the back panel sets the power-up action
+to autoboot or to halt.
+When halted, the processor may be booted using the same syntax
+as on the 11/750.
+.Pp
+The 11/750 boot procedure uses the boot ROMs to load block 0 off
+the specified device.
+The
+.Pa /usr/mdec
+directory contains a number
+of bootstrap programs for the various disks which should be placed
+in a new pack by
+.Xr disklabel 8 .
+Similarly, the Micro
+.Tn VAX
+II boot procedure loads a boot parameter block
+from block 0 of the disk.
+The
+.Xr rdboot
+.Dq bootstrap
+contains the correct parameters for an
+.Tn MSCP
+disk such
+as the RD53.
+.Pp
+On any processor, the
+.Nm boot
+program
+finds the corresponding file on the given device
+.Pf ( Pa bsd
+by default), loads that file
+into memory location zero, and starts the program at the entry address
+specified in the program header (after clearing off the high bit
+of the specified entry address).
+.Pp
+The file specifications used with
+.Dq BOOT ANY
+or
+.Dq \&B/3
+are of the form:
+.Pp
+.Dl device(adaptor,controller,unit,minor)
+.Pp
+where
+.Ar device
+is the type of the device to be searched,
+.Ar adaptor
+is the
+.Tn UNIBUS
+or
+.Tn MASSBUS
+number of the adaptor to which the device is attached,
+.Ar controller
+is the unit number of the controller or
+.Tn MASSBUS
+tape formatter on that adaptor,
+.Ar unit
+is the unit number of the disk or transport slave unit of the tape,
+and
+.Ar minor
+is the disk partition or tape file number.
+Leading adaptor or controller numbers default to 0.
+Normal line editing characters can be used when typing the file specification.
+The following list of supported devices may vary from installation to
+installation:
+.Pp
+.Bd -unfilled -offset indent -compact
+hp	MASSBUS disk drive
+up	UNIBUS storage module drive
+ht	TE16,TU45,TU77 on MASSBUS
+kra	storage module on a KDB50
+mt	TU78 on MASSBUS
+hk	RK07 on UNIBUS
+ra	storage module on a MSCP-compatible UNIBUS controller
+rb	storage module on a 730 IDC
+rl	RL02 on UNIBUS
+tm	TM11 emulation tape drives on UNIBUS
+tms	TMSCP-compatible tape
+ts	TS11 on UNIBUS
+ut	UNIBUS TU45 emulator
+.Ed
+.Pp
+For example,
+to boot from a file system which starts at cylinder 0
+of unit 0 of a
+.Tn MASSBUS
+disk, type
+.Dq hp(0,0)bsd
+at the boot prompt;
+.Dq hp(2,0,1,0)bsd
+would specify drive 1 on
+.Tn MASSBUS
+adaptor 2;
+.Dq up(0,0)bsd
+would specify a
+.Tn UNIBUS
+drive,
+.Dq hk(0,0)bsd
+would specify
+an RK07 disk drive,
+.Dq ra(1,0,0,0)bsd
+would specify a
+.Tn UDA50
+disk drive on a second
+.Tn UNIBUS ,
+and
+.Dq rb(0,0)bsd
+would specify a
+disk on a 730
+.Tn IDC .
+For tapes, the minor device number gives a file offset;
+.Dq mt(1,2,3,4)
+would specify the fifth file on slave 3 of the formatter
+at
+.Dq drive
+2 on mba 1.
+.Pp
+On an 11/750 with patchable control store,
+microcode patches will be installed by
+.Nm boot
+if the file
+.Pa psc750.bin
+exists in the root of the filesystem from which the system is booted.
+.Pp
+In an emergency, the bootstrap methods described in the paper
+.%T Installing and Operating 4.3bsd
+can be used to boot from a distribution tape.
+.Sh FILES
+.Bl -tag -width /usr/mdec/xxboot -compact
+.It Pa /bsd
+system code
+.It Pa /boot
+system bootstrap
+.It Pa /usr/mdec/xxboot
+sector-0 boot block for 750, xx is disk type
+.It Pa /usr/mdec/bootxx
+second-stage boot for 750, xx is disk type
+.It Pa /pcs750.bin
+microcode patch file on 750
+.El
+.Sh SEE ALSO
+.Xr arff 8 ,
+.Xr halt 8 ,
+.Xr reboot 8 ,
+.Xr shutdown 8
+.Sh HISTORY
+The
+.Nm
+command appeared in
+.Bx 4.0 .
diff --git a/share/man/man8/man8.vax/crash.8 b/share/man/man8/man8.vax/crash.8
deleted file mode 100644
index 1f1ab7b90cd..00000000000
--- a/share/man/man8/man8.vax/crash.8
+++ /dev/null
@@ -1,240 +0,0 @@
-.\"	$OpenBSD: crash.8,v 1.4 2000/10/13 04:09:23 aaron Exp $
-.\" Copyright (c) 1980, 1991 The Regents of the University of California.
-.\" All rights reserved.
-.\"
-.\" Redistribution and use in source and binary forms, with or without
-.\" modification, are permitted provided that the following conditions
-.\" are met:
-.\" 1. Redistributions of source code must retain the above copyright
-.\"    notice, this list of conditions and the following disclaimer.
-.\" 2. Redistributions in binary form must reproduce the above copyright
-.\"    notice, this list of conditions and the following disclaimer in the
-.\"    documentation and/or other materials provided with the distribution.
-.\" 3. All advertising materials mentioning features or use of this software
-.\"    must display the following acknowledgement:
-.\"	This product includes software developed by the University of
-.\"	California, Berkeley and its contributors.
-.\" 4. Neither the name of the University nor the names of its contributors
-.\"    may be used to endorse or promote products derived from this software
-.\"    without specific prior written permission.
-.\"
-.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
-.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
-.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
-.\" ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
-.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
-.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
-.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
-.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
-.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
-.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
-.\" SUCH DAMAGE.
-.\"
-.\"	from: @(#)crash.8	6.5 (Berkeley) 4/20/91
-.\"
-.TH CRASH 8 "April 20, 1991"
-.UC 4
-.SH NAME
-crash \- UNIX system failures
-.SH DESCRIPTION
-This section explains what happens when the system crashes
-and (very briefly) how to analyze crash dumps.
-.PP
-When the system crashes voluntarily it prints a message of the form
-.IP
-panic: why i gave up the ghost
-.LP
-on the console, takes a dump on a mass storage peripheral,
-and then invokes an automatic reboot procedure as
-described in
-.IR reboot (8).
-(If auto-reboot is disabled on the front panel of the machine the system
-will simply halt at this point.)
-Unless some unexpected inconsistency is encountered in the state
-of the file systems due to hardware or software failure, the system
-will then resume multi-user operations.
-.PP
-The system has a large number of internal consistency checks; if one
-of these fails, then it will panic with a very short message indicating
-which one failed.
-In many instances, this will be the name of the routine which detected
-the error, or a two-word description of the inconsistency.
-A full understanding of most panic messages requires perusal of the
-source code for the system.
-.PP
-The most common cause of system failures is hardware failure, which
-can reflect itself in different ways.  Here are the messages which
-are most likely, with some hints as to causes.
-Left unstated in all cases is the possibility that hardware or software
-error produced the message in some unexpected way.
-.TP
-.B iinit
-This cryptic panic message results from a failure to mount the root filesystem
-during the bootstrap process.
-Either the root filesystem has been corrupted,
-or the system is attempting to use the wrong device as root filesystem.
-Usually, an alternate copy of the system binary or an alternate root
-filesystem can be used to bring up the system to investigate.
-.TP
-.B Can't exec /sbin/init
-This is not a panic message, as reboots are likely to be futile.
-Late in the bootstrap procedure, the system was unable to locate
-and execute the initialization process,
-.IR init (8).
-The root filesystem is incorrect or has been corrupted, or the mode
-or type of /sbin/init forbids execution.
-.TP
-.B IO err in push
-.ns
-.TP
-.B hard IO err in swap
-The system encountered an error trying to write to the paging device
-or an error in reading critical information from a disk drive.
-The offending disk should be fixed if it is broken or unreliable.
-.TP
-.B realloccg: bad optim
-.ns
-.TP
-.B ialloc: dup alloc
-.ns
-.TP
-.B alloccgblk: cyl groups corrupted
-.ns
-.TP
-.B ialloccg: map corrupted
-.ns
-.TP
-.B free: freeing free block
-.ns
-.TP
-.B free: freeing free frag
-.ns
-.TP
-.B ifree: freeing free inode
-.ns
-.TP
-.B alloccg: map corrupted
-These panic messages are among those that may be produced
-when filesystem inconsistencies are detected.
-The problem generally results from a failure to repair damaged filesystems
-after a crash, hardware failures, or other condition that should not
-normally occur.
-A filesystem check will normally correct the problem.
-.TP
-.B timeout table overflow
-.ns
-This really shouldn't be a panic, but until the data structure
-involved is made to be extensible, running out of entries causes a crash.
-If this happens, make the timeout table bigger.
-.TP
-.B KSP not valid
-.ns
-.TP
-.B SBI fault
-.ns
-.TP
-.B CHM? in kernel
-These indicate either a serious bug in the system or, more often,
-a glitch or failing hardware.
-If SBI faults recur, check out the hardware or call
-field service.  If the other faults recur, there is likely a bug somewhere
-in the system, although these can be caused by a flakey processor.
-Run processor microdiagnostics.
-.TP
-.B machine check %x:
-.I description
-.ns
-.TP
-.I \0\0\0machine dependent machine-check information
-.ns
-Machine checks are different on each type of CPU.
-Most of the internal processor registers are saved at the time of the fault
-and are printed on the console.
-For most processors, there is one line that summarizes the type of machine
-check.
-Often, the nature of the problem is apparent from this message
-and/or the contents of key registers.
-The VAX Hardware Handbook should be consulted,
-and, if necessary, your friendly field service people should be informed
-of the problem.
-.TP
-.B trap type %d, code=%x, pc=%x
-A unexpected trap has occurred within the system; the trap types are:
-.sp
-.nf
-0	reserved addressing fault
-1	privileged instruction fault
-2	reserved operand fault
-3	bpt instruction fault
-4	xfc instruction fault
-5	system call trap
-6	arithmetic trap
-7	ast delivery trap
-8	segmentation fault
-9	protection fault
-10	trace trap
-11	compatibility mode fault
-12	page fault
-13	page table fault
-.fi
-.sp
-The favorite trap types in system crashes are trap types 8 and 9,
-indicating
-a wild reference.  The code is the referenced address, and the pc at the
-time of the fault is printed.  These problems tend to be easy to track
-down if they are kernel bugs since the processor stops cold, but random
-flakiness seems to cause this sometimes.
-The debugger can be used to locate the instruction and subroutine
-corresponding to the PC value.
-If that is insufficient to suggest the nature of the problem,
-more detailed examination of the system status at the time of the trap
-usually can produce an explanation.
-.TP
-.B init died
-The system initialization process has exited.  This is bad news, as no new
-users will then be able to log in.  Rebooting is the only fix, so the
-system just does it right away.
-.TP
-.B out of mbufs: map full
-The network has exhausted its private page map for network buffers.
-This usually indicates that buffers are being lost, and rather than
-allow the system to slowly degrade, it reboots immediately.
-The map may be made larger if necessary.
-.PP
-That completes the list of panic types you are likely to see.
-.PP
-When the system crashes it writes (or at least attempts to write)
-an image of memory into the back end of the dump device,
-usually the same as the primary swap
-area.  After the system is rebooted, the program
-.IR savecore (8)
-runs and preserves a copy of this core image and the current
-system in a specified directory for later perusal.  See
-.IR savecore (8)
-for details.
-.PP
-To analyze a dump you should begin by running
-.IR adb (1)
-with the
-.B \-k
-flag on the system load image and core dump.
-If the core image is the result of a panic,
-the panic message is printed.
-Normally the command
-``$c''
-will provide a stack trace from the point of
-the crash and this will provide a clue as to
-what went wrong.
-For more detail
-see
-``Using ADB to Debug the UNIX Kernel''.
-.SH "SEE ALSO"
-adb(1),
-reboot(8)
-.br
-.I "VAX 11/780 System Maintenance Guide"
-and
-.I "VAX Hardware Handbook"
-for more information about machine checks.
-.br
-.I "Using ADB to Debug the UNIX Kernel"