1 files changed, 117 insertions, 0 deletions
diff --git a/static/v10/man8/analyze.8 b/static/v10/man8/analyze.8
new file mode 100644
index 00000000..72c8769c
--- /dev/null
+++ b/static/v10/man8/analyze.8
@@ -0,0 +1,117 @@
+.lg 0
+.TH ANALYZE 8
+.UC 4
+.SH NAME
+analyze \- Virtual UNIX postmortem crash analyzer
+.SH SYNOPSIS
+.B /etc/analyze
+[
+.B \-s
+swapfile
+] [
+.B \-f
+] [
+.B \-m
+] [
+.B \-d
+] [
+.B \-D
+] [
+.B \-v
+]
+corefile
+[ system ]
+.SH DESCRIPTION
+.I Analyze
+is the post-mortem analyzer for the state of the paging system.
+In order to use
+.I analyze
+you must arrange to get a image of the memory (and possibly the
+paging area) of the system after it crashes (see
+.IR crash (8)).
+.PP
+The
+.I analyze
+program reads the relevant system data structures from the core
+image file and indexing information from 
+.B /vmunix
+(or the specified file).
+to determine the state of the paging subsystem at the point of crash.
+It looks at each process in the system, and the resources each is
+using in an attempt to determine inconsistencies in the paging system
+state.  Normally, the output consists of a sequence of lines showing
+each active process, its state (whether swapped in or not), its
+.I p0br,
+and the number and location of its page table pages.
+Any pages which are locked while raw i/o is in progress, or which
+are locked because they are
+.I intransit
+are also printed.  (Intransit text pages often diagnose as duplicated;
+you will have to weed these out by hand.)
+.PP
+The program checks that any pages in core which are marked as not
+modified are, in fact, identical to the swap space copies.
+It also checks for non-overlap of the swap space, and that the core
+map entries correspond to the page tables.
+The state of the free list is also checked.
+.PP
+Options to
+.I analyze:
+.TP
+.B \-D
+causes the diskmap for each process to be printed.
+.TP
+.B \-d
+causes the (sorted) paging area usage to be printed.
+.TP
+.B \-f
+which causes the free list to be dumped.
+.TP
+.B \-m
+causes the entire coremap state to be dumped.
+.TP
+.B \-v
+(long unused) which causes a hugely verbose output format to be used.
+.PP
+In general, the output from this program can be confused by processes
+which were forking, swapping, or exiting or
+happened to be in unusual states when the
+crash occurred.  You should examine the flags fields of relevant processes
+in the output of a
+.IR pstat (8)
+to weed out such processes.
+.PP
+It is possible to look at the core dump with
+.I adb
+if you do
+.IP
+adb /vmunix /vmcore
+.br
+.lg 0
+/m 80000000 #ffffffff
+.LP
+which fixes the map of
+.I vmcore
+so that symbols in data space will work.
+Note that the debugger is looking at the physical memory at the point
+of crash; you will have to determine which pages of physical memory
+virtual pages are in if you wish to look at them.
+If
+.I analyze
+says that a processes page tables are in page 218 (hex of course), then
+you can look at them by looking at address 0x80043000 in the dump, i.e.
+\*(lq80043000,80/X\*(rq will print the page of page tables.
+.SH FILES
+/vmunix	default system namelist
+.SH SEE ALSO
+ps(1), crash(8), pstat(8)
+.SH AUTHORS
+Ozalp Babaoglu and William Joy
+.SH DIAGNOSTICS
+Various diagnostics about overlaps in swap mappings, missing swap mappings,
+page table entries inconsistent with the core map, incore pages which
+are marked clean but differ from disk-image copies, pages which are
+locked or intransit, and inconsistencies in the free list.
+.PP
+It would be nice if this program analyzed the system in general, rather
+than just the paging system in particular.