Enter your search terms Submit search form
	Web pdp-10.trailing-edge.com

+---------------+
! d i g i t a l !   I N T E R O F F I C E  M E M O R A N D U M
+---------------+

                                       Date: 19-February-82
                                       From: TSG/NCSS
                                       Loc:  MR1-2/H22
                                       Ext:  HOTLINE  5911


Subj:   Debugging Hints for RSX20F

The following is a general guide to debugging RSX20F  problems.   It
is  not  meant to provide a sure-fire way to analyze and correct all
RSX20F problems.  Instead it is more of a directory of resources and
information gathering proceedures.



1.0  ATTACKING THE PROBLEM


When you encounter a RSX20F problem:

     1.  Read the "RSX20F System Reference Manual" in  the  notebook
         set  particularly Chapters 9 and 10.  Appendix A contains a
         list of RSX20F stop codes and their meaning.

     2.  Write down exactly what  seemed  to  be  happening  on  the
         system,  what  signals told you a problem existed, and what
         attempts you made to recover from the problem.   This  will
         often  help  clarify  your  thinking  and  will provide the
         hotline with necessary background information.   Also  find
         out  when the problem was first noticed and if there is any
         way to reproduce the problem.

     3.  Find out exactly what devices are involved, in  particular,
         what the hardware interface is and what it is connected to.
         Also check for any nonstandard device that has been  hooked
         to  RSX20F,  since  these  are  often  the cause of unusual
         problems.

     4.  Get a copy of the console typeout at the time of the  crash
         along  with  any  recent  odd  occurrences,  and  the CHK11
         typeout described in this SWSKIT.

     5.  Use SYSERR (or SPEAR) to check for any entries generated by
         the  problem  or  that  were  generated around the time the
         problem occured.

     6.  Use DDT11 to look at the running RSX20F.  DDT11.MEM in  the
         SWSKIT  describes the /FESYMB switch to load the symbols to
         make a front end specific DDT11 and the  /FE:n  to  examine
         it.

                                                              Page 2
ATTACKING THE PROBLEM


     7.  Use DDT11 and the command files  provided  to  examine  any
         dumps  that  have  been  taken  of  the  Console Front End.
         Chapter 10 in the RSX20F System Reference manual is devoted
         to  error  debugging and has a sample dump analysis and the
         data structures.  See page 10-41 for how to  access  device
         registers in the I/O page.





2.0  AUTOMATIC RELOADING


There are two circumstances under which TOPS10 or TOPS20 will  cause
a  dump  of  RSX20F to be taken.  The first is when TOPS10 or TOPS20
detects that RSX20F is  not  incrementing  the  KEEP-ALIVE  COUNTER.
This  can  happen  when RSX20F loops or when RSX20F halts (either by
executing the HALT instruction or by depressing the HALT  SWITCH  on
the front panel).  A dump taken under this condition will be missing
a good deal of information since the RSX20F crash routines were  not
executed.   The second case is when RSX20F detects an internal error
and crashes.  The last thing the crash code does is to ring the KL's
DOORBELL and request a reload.  In this case the state of RSX20F has
been saved by the crash code and may be extracted from the  dump  by
using DDT11.

Please note that when RSX20F crashes TOPS20 will always try to  dump
and  reload  it.   TOPS10,  however,  requires that a program called
DTELDR be running with the /DUMP and  /AUTO  switches  in  order  to
effect an automatic reload.



3.0  TAKING A DUMP

The best dump is one produced when the PDP-11 detects an  error  and
crashes.   However,  RSX20F does not always cooperate and crash when
you want it to.  Sometimes you must induce a reload so you can  look
at  RSX20F's  databases.  Producing a dump manually can be done in a
number of ways:

     1.  By depressing and raising the halt switch.

     2.  Use DNLOAD under TOPS20 or DTELDR under TOPS10.  (Refer  to
         the appropriate documentation in the software notebooks.

     3.  Use DDT11 to poke an illegal instruction into  the  running
         front  end's  memory in a place you feel reasonably sure it
         will  get   executed   (i.e.    in   the   DH11   interrupt
         routines...).   This  will  cause a stopcode giving you the
         maximum amount of information and can  be  used  to  narrow
         down   a   problem   until  you  get  a  dump  with  useful
         information.

                                                              Page 3
THE HOTLINE


4.0  THE HOTLINE

Finally, when in doubt, CALL THE HOTLINE.  We will be quite happy to
assist you.