1.0 INTRODUCTION . . . . . . . . . . . . . . . . . . . . 3 1.1 Instructors . . . . . . . . . . . . . . . . . . . 3 1.2 Seminar Goal . . . . . . . . . . . . . . . . . . . 4 1.3 Seminar Outline . . . . . . . . . . . . . . . . . 4 1.4 Seminar Materials . . . . . . . . . . . . . . . . 5 2.0 FOUNDATIONS . . . . . . . . . . . . . . . . . . . . 6 2.1 What Is A Crash? . . . . . . . . . . . . . . . . . 6 2.2 Why Analyze Crashes? . . . . . . . . . . . . . . . 6 2.3 How Do Systems Crash? . . . . . . . . . . . . . . 7 2.4 Key Points . . . . . . . . . . . . . . . . . . . . 7 3.0 CRASH MANAGEMENT . . . . . . . . . . . . . . . . . . 8 3.1 Preparation . . . . . . . . . . . . . . . . . . . 8 3.1.1 Materials . . . . . . . . . . . . . . . . . . . 8 3.1.2 Actions . . . . . . . . . . . . . . . . . . . 10 3.2 How To Crash Your System . . . . . . . . . . . . 12 3.3 Record Crash To Media . . . . . . . . . . . . . 13 3.4 Post-Crash Procedure . . . . . . . . . . . . . . 14 3.5 Practice And Train Personnel . . . . . . . . . . 15 4.0 BASIC CRASH ANALYSIS . . . . . . . . . . . . . . . 16 4.1 CDA Usage . . . . . . . . . . . . . . . . . . . 16 4.1.1 Command Format . . . . . . . . . . . . . . . . 16 4.1.2 Switches . . . . . . . . . . . . . . . . . . . 17 4.2 Find The Obvious And The Unexpected . . . . . . 19 4.3 System Stack Analysis . . . . . . . . . . . . . 21 4.3.1 The Kernel Stack . . . . . . . . . . . . . . . 21 4.3.2 The Crash Module ($CRASH) . . . . . . . . . . 22 4.3.3 What Happens When A Crash Occurs? . . . . . . 23 4.3.3.1 Start At Location 40 . . . . . . . . . . . . 23 4.3.3.2 Stack Limit Violation . . . . . . . . . . . 24 4.3.3.3 IOT - The CRASH Macro . . . . . . . . . . . 26 4.3.3.4 SST's . . . . . . . . . . . . . . . . . . . 28 4.3.3.4.1 Trap Through Location 4 . . . . . . . . . 30 4.3.3.4.2 Illegal Instruction Trap . . . . . . . . . 32 4.3.3.4.3 Breakpoint . . . . . . . . . . . . . . . . 33 4.3.3.4.4 Segment Fault . . . . . . . . . . . . . . 34 4.3.3.5 TRAP's And EMT's . . . . . . . . . . . . . . 35 4.3.3.5.1 EMT . . . . . . . . . . . . . . . . . . . 36 4.3.3.5.2 TRAP . . . . . . . . . . . . . . . . . . . 37 4.3.4 Tracing The Original Trap . . . . . . . . . . 38 5.0 CRASH DETECTIVE . . . . . . . . . . . . . . . . . 39 5.1 The CDA File . . . . . . . . . . . . . . . . . . 40 5.2 Tools . . . . . . . . . . . . . . . . . . . . . 41 5.2.1 ZAP . . . . . . . . . . . . . . . . . . . . . 41 5.2.2 BINCMP . . . . . . . . . . . . . . . . . . . . 43 5.2.3 Specials . . . . . . . . . . . . . . . . . . . 44 5.3 Tricks . . . . . . . . . . . . . . . . . . . . . 45 5.3.1 Branch-on-self . . . . . . . . . . . . . . . . 45 5.3.2 On-line Patches . . . . . . . . . . . . . . . 46 5.3.3 Logic Analyzer . . . . . . . . . . . . . . . . 47 5.3.4 T-Bit Traps . . . . . . . . . . . . . . . . . 48 5.3.5 Mousetraps . . . . . . . . . . . . . . . . . . 49 5.4 Mathematics Of RSX-11M . . . . . . . . . . . . . 51 Page 2 APPENDIX A CONCATENATED EXECUTIVE ASSEMBLY A.1 STEP0.CMD . . . . . . . . . . . . . . . . . . . . A-3 A.2 STEP1.TEC . . . . . . . . . . . . . . . . . . . . A-4 A.3 STEP2.TEC . . . . . . . . . . . . . . . . . . . . A-5 A.4 MASTER.MAC . . . . . . . . . . . . . . . . . . . . A-6 A.5 C5TA.MAC . . . . . . . . . . . . . . . . . . . . . A-7 APPENDIX B CRASH MANAGMENT COMMAND FILE APPENDIX C CDA AND RELATED PATCHES C.1 LOWCR.COR . . . . . . . . . . . . . . . . . . . . C-2 C.2 CRASH.COR . . . . . . . . . . . . . . . . . . . . C-3 C.3 CDA.CMD . . . . . . . . . . . . . . . . . . . . . C-8 C.4 CDACLQ.PAT . . . . . . . . . . . . . . . . . . . . C-9 C.5 LUDMP.COR . . . . . . . . . . . . . . . . . . . C-10 C.6 TDUMP.PAT . . . . . . . . . . . . . . . . . . . C-12 APPENDIX D RSX-11M DATA STRUCTURES APPENDIX D DATA STRUCTURES D.1 SYSCM . . . . . . . . . . . . . . . . . . . . . . D-2 D.2 TCB . . . . . . . . . . . . . . . . . . . . . . . D-8 D.3 OCB . . . . . . . . . . . . . . . . . . . . . . D-12 D.4 AST CONTROL BLOCK . . . . . . . . . . . . . . . D-13 D.5 SEND/RECEIVE PACKET . . . . . . . . . . . . . . D-15 D.6 RECEIVE-BY-REFERENCE PACKET . . . . . . . . . . D-16 D.7 GROUP GLOBAL EVENT FLAGS . . . . . . . . . . . . D-17 D.8 TASK HEADER . . . . . . . . . . . . . . . . . . D-18 D.9 PCB . . . . . . . . . . . . . . . . . . . . . . D-22 D.10 ATTACHMENT DESCRIPTOR . . . . . . . . . . . . . D-25 D.11 CLOCK QUEUE . . . . . . . . . . . . . . . . . . D-26 D.12 I/O PACKET . . . . . . . . . . . . . . . . . . . D-29 D.13 LCB . . . . . . . . . . . . . . . . . . . . . . D-31 D.14 ITB . . . . . . . . . . . . . . . . . . . . . . D-32 D.15 DCB . . . . . . . . . . . . . . . . . . . . . . D-35 D.16 UCB . . . . . . . . . . . . . . . . . . . . . . D-37 D.17 SCB . . . . . . . . . . . . . . . . . . . . . . D-45 D.18 MAPPING ASSIGNMENT BLOCK . . . . . . . . . . . . D-47 D.19 MOUNTED VOLUME LIST . . . . . . . . . . . . . . D-48 D.20 F11ACP VCB . . . . . . . . . . . . . . . . . . . D-49 D.21 F11ACP WINDOW . . . . . . . . . . . . . . . . . D-51 D.22 LOCK BLOCK LIST . . . . . . . . . . . . . . . . D-53 D.23 FCB . . . . . . . . . . . . . . . . . . . . . . D-54 D.24 MTAACP VCB . . . . . . . . . . . . . . . . . . . D-56 D.25 EMB . . . . . . . . . . . . . . . . . . . . . . D-58 D.26 INDEX FILE FORMAT . . . . . . . . . . . . . . . D-61 D.27 HOME BLOCK . . . . . . . . . . . . . . . . . . . D-62 D.28 FILE HEADER . . . . . . . . . . . . . . . . . . D-64 Page 3 D.29 DIRECTORY ENTRY . . . . . . . . . . . . . . . . D-67 D.30 FDB . . . . . . . . . . . . . . . . . . . . . . D-68 D.31 FNB . . . . . . . . . . . . . . . . . . . . . . D-70 D.32 DSD . . . . . . . . . . . . . . . . . . . . . . D-71 D.33 $$FSR1 . . . . . . . . . . . . . . . . . . . . . D-72 D.34 $$FSR2 . . . . . . . . . . . . . . . . . . . . . D-73 APPENDIX E EXAMPLE CRASHES E.1 CRAYZO . . . . . . . . . . . . . . . . . . . . . . E-1 E.2 SST CRASHES - CRAT04, CRAILI, CRABPT, CRASEG . . . E-1 E.3 CRATRP AND CRAEMT . . . . . . . . . . . . . . . . E-1 E.4 CRAOSP . . . . . . . . . . . . . . . . . . . . . . E-1 E.5 ODD VECTOR CRASHES . . . . . . . . . . . . . . . . E-2 E.5.1 CRAOD4 . . . . . . . . . . . . . . . . . . . . . E-2 E.5.2 CRAIOS And CRAIOU . . . . . . . . . . . . . . . E-2 E.5.3 CRAEVO . . . . . . . . . . . . . . . . . . . . . E-3 CRASH DUMP ANALYSIS Seminar Workbook May 17, 1981 Kenneth Johnson Monsanto Ralph Stamerjohn Monsanto 1 Crash Dump Analysis Workbook This page left intentionally blank. 2 Crash Dump Analysis Workbook INTRODUCTION 1.0 INTRODUCTION Welcome to the RSX-11M Crash Dump Analysis Seminar. This is the seminar workbook, which follows the graphics used in our presentation. The workbook records the important points we will make, allowing participants to spend the day thinking rather than writing. Space has been provided for additional notes to be made in the workbook itself. Please feel free to ask questions at any time during the day. 1.1 Instructors Kenneth Johnson Programmer/Analyst I Monsanto Agricultural Products Co. Mail Stop T1C 800 N. Lindbergh Blvd. St. Louis, MO 63166 Ken is the system manager of a major laboratory data system which includes two PDP 11/70's and over 20 PDP 11/03's. He has analyzed over 50 crashes, most related to the development, startup, and operation of that system. He has been working in RSX-11M about 2 years. Ralph Stamerjohn Senior System Programming Specialist Monsanto Agricultural Products Co. Mail Stop T1A 800 N. Lindbergh Blvd. St. Louis, MO 63166 Ralph has responsibilities for providing system consulting to the MAPC network. A large part of this is trouble shooting system problems and crashes. He has worked on RSX-11M for 6 years (since version 1.0), and has long lost track of the number of crashes he has examined (at least 400). 3 Crash Dump Analysis Workbook INTRODUCTION 1.2 Seminar Goal "After the course, you will be able to properly handle RSX-11M system crashes and understand the basic principles of crash analysis." Specifically, participants will learn how systems crash, how to obtain a crash dump, the material needed for crash analysis, what is proper crash management, how to use CDA, adn the basic steps of crash analysis. A number of "tricks of the trade" will also be presented. 1.3 Seminar Outline 1. Introduction 2. Foundations 3. Crash Management 4. Basic Crash Analysis ** LUNCH ** 5. Crash Detective 6. Case Studies 7. Class Problems 4 Crash Dump Analysis Workbook INTRODUCTION 1.4 Seminar Materials The seminar materials are all contained in this binder. The first part of the binder is the workbook. Reference materials, labeled as appendices, follow the workbook itself. Also, all material for this seminar has been submitted to the RSX/IAS SIG Tapes in UIC [346,101]. A. Concatenated Executive Assembly B. Sample Crash Management Command File C. Patches to CDA and Crash Module o Patch to LOWCR for JMP $CRALT (Digital) o Patch to CRASH to correct user stack pointer (Digital) o Patch to CRASH for RK06, TS11, and TU58 (Digital) o Patch to CRASH to save location 4 (Monsanto) o Patch to CDA for clock time problem (Monsanto) o Patch to CDA on non-Files-11 headers (Digital) o Patch to CDA on pre-AST status (Monsanto) D. Toggle-In Crash Routines E. RSX-11M Data Structures 5 Crash Dump Analysis Workbook FOUNDATIONS 2.0 FOUNDATIONS 2.1 What Is A Crash? "A crash is defined as when an RSX-11M system becomes unuseable for unexpected reasons and must be rebooted." Examples of a crash include system halts, exhausted pool, system in crash routine, break to XDT, system looping, F11ACP abort, or application fault. 2.2 Why Analyze Crashes? o Maintain or improve system reliability (frequency of failures). o Maintain or improve system availability (% uptime). o Diagnose hardware problems. o Improve system performance. When properly used, crash analysis is a powerful development tool resulting in reliable, available, and high-performance systems. 6 Crash Dump Analysis Workbook FOUNDATIONS 2.3 How Do Systems Crash? A system crashes when it reaches a state that the executive cannot reliably handle. The final state (physical error) is triggered by some event (logical error) which occured in the past. If the same series of events are repeated, the system will crash again. A crash dump is a frozen copy of the system at the point of the physical error. This is rarely the real cause of the crash. The whole point of crash analysis is to track backwards in time from the physical error to the initial logical error and correct that problem. 2.4 Key Points o Cost Crash analysis is costly, particularly in terms of time. It is difficult to judge how long it will take to resolve a crash. If the crash is merely annoying, ignore it. However keep in mind that if unsolved, the problem may occur again. o Skill Anyone can analyze a crash. However, unless you work with crashes regularly, you will find yourself starting from scratch each time. Don't be discouraged. o Serial Operations One thing happens at time in computer; things just happen very fast. Keep in mind that a sequential series of events occurred to cause your crash. Your job is to trace these events back to the real error. o Reproducibility If you can reliably reproduce a problem, it is solved. 7 Crash Dump Analysis Workbook CRASH MANAGEMENT 3.0 CRASH MANAGEMENT "The purpose of crash management is to guarantee that you have everything you need to determine and resolve the cause of the crash." 3.1 Preparation One of the most important steps in preventing system crashes is to be prepared for a crash to occur. When your system crashes, you must be ready to grab ALL of the pieces and put them in a safe place until you can eliminate the problem that broke it. 3.1.1 Materials o Executive symbol table file (RSX11M.STB) The symbol table file is required by the CDA program to find data strutures in the crash image. o Executive map and cross-reference The executive map is used to translate a PC value into a location in the listings. The cross-reference is useful to find out where a routine is called or a variable modified. Always cref the map! o Executive listings Used to follow what happened prior to the crash. A useful technique is to prepare a concatenated listing - see appendix A. The STB file, the map, and the listings are all outputs from SYSGEN and should be saved. 8 Crash Dump Analysis Workbook CRASH MANAGEMENT o Other maps and listings It is good to have maps and listings of all privileged tasks which are mapped to the executive and maps and listings of drivers. When a crash occurs, either the executive or one of these processes is probably executing. o Processor handbook and programming card The card is useful for assembly and disassembly of MACRO-11 by hand. The processor handbook is necessary to understand what the hardware is doing, particulary with reference to traps, error conditions, and memory management. o RSX-11M manuals Of particular interest is the "Guide to Writing an I/O Driver" and the CDA manual. The CDA manual lists macros which define RSX data structures. o RSX-11M Logic Manual While this document is based on 3.1, it is still useful for the written description of executive modules, macro expansions for all executive macros, and nice diagrams of the linkage of the executive data structures. 9 Crash Dump Analysis Workbook CRASH MANAGEMENT 3.1.2 Actions o Sysgen crash support into system The following questions in SYSGEN relate to crash support. We recommend selecting the console terminal for stack dump support (question 45), CDA support for dump analysis (question 48), the console terminal for crash notification (question 49), and the appropriate device and CSR for the memory dump (questions 50 and 51). * 45. System crash register and stack dump CSR [O R:0-177700 D:177564]: * 48. Dump analysis: A- PANIC B- Crash (CDA) [S]: * 49. Output notification device CSR [O R:160000-177700 D:177564]: * 50. Memory dump device (ddu:) [S R:3-4]: * 51. CSR address of dump device [O R:160000-177700 D:default]: o Set up permanent storage for crashes You must be prepared to keep crashes until they are resolved or for the life of the system; this depends on how reliable the system must be, of course. You should have a designated location to store crashes. A UFD should be reserved for current crashes. Old unresolved crashes may be put on tape, but should be kept if there is a likelihood of recurrence. 10 Crash Dump Analysis Workbook CRASH MANAGEMENT o Define naming convention for crashes The crashes must be named so that they can be identified. We recommend a naming convention based on system name, date, and crash that day. The sample crash management command file assigns the filenames "namemmdda". "name" is a four letter name for your system. "mm" is the current month; "dd" is the date; both numerical. "a" is an alphabetic sequence number. This only allows 26 crashes per day. When you hit 27, go drinking. Note that the use of the command file also guarantees that the .CDA file winds up in the correct UFD. o Define documentation procedure A procedure for documenting the crash ensures that the transient information associated with the crash is not lost. A practice that we like is to write the information on the initial listing. This keeps everything in one package. The information that one wants is a description of what was happening to the system just before the crash. Emphasis should be given to anything new or unusual - both acts of ommision and commision. 11 Crash Dump Analysis Workbook CRASH MANAGEMENT 3.2 How To Crash Your System o Already crashed The simplest case is that the crash message has printed on the console and you only need to mount a scratch medium and proceed. o XDT>X If the executive has broken to XDT, typing an "X" will cause the exec to jump to the crash routine and print the crash message. Now you have the "already crashed case". o Running - odd clock vector If you want to crash the system when it is still running, OPEn the clock vector (location 100 (8)) and deposit an odd number. Your system will crash at the next clock interrupt. o Halted - start at location 40 If the system is halted at an unknown location or if it was hung and you halted it, then you can get a dump by starting the processor at location 40 (8). This location contains the instruction "JMP $CRASH". 12 Crash Dump Analysis Workbook CRASH MANAGEMENT 3.3 Record Crash To Media o Protect your disks If you MUST use a disk as your dump media, be SURE that you remove or write-protect your regular disk first. $CRASH writes out over the first n blocks of the device, which is a sure-fire method of destroying the boot block and home block of a FILES-11 disk. o Preallocated media It is a good idea to have a reserved tape (or disk) for taking crashes. I have a crash dump tape for each of my 11/70's. You don't want to be in the situation where you lose a crash dump just because you haven't got a tape. o Toggle-in dump routines In some cases, the $CRASH routine may be partly or totally destroyed by whatever crashed your system. If only part of it is gone, get your executive listings and toggle it back in. Alternatively, see the handout on toggle-in dump routines. These may also be used on a system which does not have crash support but which you would like to crash dump. 13 Crash Dump Analysis Workbook CRASH MANAGEMENT 3.4 Post-Crash Procedure After the crash, it is time to put the planning you did into action. o Read in crash to .CDA file and name This is easy since you have a command file which does everything for you; mount the tape and type @CRASHREAD. o Get initial listing (/ACT/HDR/PCB) We recommend these switches for the intial listing; the reasons will be discussed in the Basic Crash Analysis section. The command file does this for you. o Record system and user activity After you get the listing you write down what happened. THIS IS ESSENTIAL. The crash dump will tell you only what the system looked like at the time of the crash. It does not provide any history. This you must get by recording what was going on. Do not rely on the memory of yourself and others. It may be days before you look at the crash. o File for future reference. At this point you can put the crash aside with the confidence that the steps you have followed guarantee that you have the information that you need. 14 Crash Dump Analysis Workbook CRASH MANAGEMENT 3.5 Practice And Train Personnel "We maintain that anyone with the knowledge and authority to boot a system should know how to get a crash dump." It is required that you and your staff practice crashing the system and getting a dump. This ensures that you will get it right under the pressure of the real thing. 15 Crash Dump Analysis Workbook BASIC CRASH ANALYSIS 4.0 BASIC CRASH ANALYSIS 4.1 CDA Usage 4.1.1 Command Format list(/-SP),binary_file=symbol_table/STB,crash_input/sw1... Note that CDA is smart enough to use the binary file for analysis which considerably reduces analysis time. 16 Crash Dump Analysis Workbook BASIC CRASH ANALYSIS 4.1.2 Switches o /ALL Logical or of all analysis switches o /ACT (/ATL) * Active Task List (TCB's) o /BL:n Identify starting block of crash input device o /CLQ Clock Queue o /DEV (/DCB, /SCB, /UCB all same as /DEV) Dumps data structures for all devices on the system o /DUMP:a:b (/DMP:a:b) Octal, Rad50, and ascii dump of memory. Works for 22 bit addresses. o /EXIT:n CDA exits after detecting n analysis errors o /HDR * Task Headers o /LIMIT:n Limits output to n pages o /KMR * Recommended for initial listing 17 Crash Dump Analysis Workbook BASIC CRASH ANALYSIS Force standard values for kernel mapping registers o /MEMSIZ:n CDA saves nK words of memory in a binary file o /NET No function. If you have Phase III Decnet, try NDA. o /PCB (/PAR) * PCB's, attachment descriptors, and memory map o /POOL Octal, Rad50, and Ascii dump of pool. This includes indication of used/free/preallocated. o /-SP Don't spool the output o /STB Identifies symbol table file o /STD (/TCB, /TAL) Dump of TCB's o /-SYS Suppress system information o /TASK:task:a:b Dump relative to beginning of task 18 Crash Dump Analysis Workbook BASIC CRASH ANALYSIS 4.2 Find The Obvious And The Unexpected Start by looking through the initial listing. Get a picture of what was happening in the system when the crash occurred. This overview will help you fit pieces together later on. 1. CDA Error Messages CDA will report analysis errors such as bad links. These are usually symptoms of the problem. 2. Task Status o Active tasks that shouldn't be active. Examples might be TKTN or PMD, plus some specific to your system. o Tasks which should be active but aren't. Examples are NETACP, F11ACP, MCR..., ...MCR, or your application. o Tasks in unusual states. Tasks with ABO, HLT, or RDN set should be looked at carefully. Why didn't this task get cleaned up? F11ACP with an ABO status is a definite problem indiciator. o Tasks with outstanding I/O. Does a task have too many or too few outstanding I/O's? An I/O count of 255 decimal is a bad sign - this is realy a -1. Also, many crashes, particularly hardware related, come from I/O in progress. 19 Crash Dump Analysis Workbook BASIC CRASH ANALYSIS 3. Pool Exhausted Why is all of your pool gone? Often this is apparent from the initial listing. Look for such things as the CDA pool link error message, receive data queue which exceed the CDA list count, receive by reference queues, or a PCB list which exceeds the list count. If you can't tell where pool went, the /POOL option will dump all of pool. See the handout on RSX pool usage. Note that a complete pool analysis is time consuming - more on this in Crash Detective. 4. Original Crash Notes The original crash notes should be examined for any mention of something new or different. Try to correlate the written description with the CDA output -- how does this information fit together. 20 Crash Dump Analysis Workbook BASIC CRASH ANALYSIS 4.3 System Stack Analysis 4.3.1 The Kernel Stack The Kernel Stack is a condensed history of your computer's activity since it was last executing in user state. Control is transferred to the RSX executive from a task when the processor executes a trap instruction or when an interrupt occurs. The new PSW from the interupt vector in low core determines which stack pointer is used to push the old PC and PSW. Thus the PC and PS from the user task are pushed onto the kernel stack. The variable $STKDP (stack depth), located in SYSCM, is used to keep track of the depth of nested interrupts or traps on the stack. $STKDP is 1 when a task is executing at user state. $STKDP is zero if a single trap or interupt has occurred. The stack depth is negative if more than one trap and interrupt have occurred. $STKDP is decremented in two routines, $DIRSV (directive save) and $INTSV (interrupt save). These routines are called to save the state of the processor when a trap or interrupt occurs. The stack depth is incremented in code common to $DIRXT (directive exit) and $INTXT (interrupt exit). The stack depth is also incremented in SSTSR (SST routines) if a trap has occurred during certain directive processing. This protects the executive from a bad address in a directive parameter block. There are four instructions which cause traps in PDP-11's: EMT, BPT, TRAP, and IOT. The EMT is used by tasks to request executive services. EMT 377 is used for executive directives. EMT 376 is used by privileged programs to switch to system state. If XDT is built into your system, the BPT instruction is used similarly to it's use in ODT in user tasks. The TRAP instruction is used at system state to return directive status. The macro DRSTS is what you see in the executive listings. TRAP is also used by XDT to print characters on the console. The IOT instruction is used by RSX11-M to transfer control to the CRASH module. The CRASH macro is just an IOT. The IOT trap handler checks the system state and jumps to $CRASH if the stack depth is less than one. In addition to the trap instructions, there are 3 other traps which are also handled by the executive as SST's. These are the illegal instruction trap, the segment fault or memory protect violation, and the trap through location 4 or odd address trap. The unexpected occurence of any of these 7 traps while the processor is in Kernel state will crash your system. 21 Crash Dump Analysis Workbook BASIC CRASH ANALYSIS 4.3.2 The Crash Module ($CRASH) The CRASH module has three basic functions: print out the crash message, save the volatile registers on the crash stack, and dump the contents of memory to the crash device. The first two instructions after $CRASH pop the PC and PS from the stack, on the assumption that the transfer of control to $CRASH occurred after an IOT or other trap. If the machine was halted and 40G was used to restart it, then that assumption is false and results in incorrect values for the PS, PC, and SP on the crash dump output. The entry point $CRALT is right after PC and PS are popped, so PC and PS show as zero, while SP comes out correct. 22 Crash Dump Analysis Workbook BASIC CRASH ANALYSIS 4.3.3 What Happens When A Crash Occurs? This section describes how your system goes down, and what the CDA output looks like afterwards. Specifically, the events leading up to the more common types of crashes are discussed here. The important aspects of the CDA output are the contents of the kernel stack, the value of the stack depth variable ($STKDP), the PC and the kernel stack pointer. The aim is to determine the point of the "physical" crash, the PC of the first trap which led up to the transfer of control to the crash routine. The "real" or "logical" cause of the crash may or may not be the same. 4.3.3.1 Start At Location 40 The contents of the executive stack are unknown, as are the user and kernel stack pointer, and the PC. If you have incorporated the patch for $CRALT into your system, the registers on the CDA output accurately reflect the registers at the time that the system was halted. 23 Crash Dump Analysis Workbook BASIC CRASH ANALYSIS 4.3.3.2 Stack Limit Violation The first instruction in the $TRP04 routine is a check on the depth of the kernel stack. If the stack pointer is less than 400, a jump to $CRASH occurs. Thus as soon as the first yellow zone violation occurs, the system is crashed without trying to push anything else on the stack. Recall that for most 11's, if the stack limit register contents are 0, then a trap will occur after instruction completion if the stack pointer goes below 400. The instruction will be aborted if the stack pointer goes below 340. 24 Crash Dump Analysis Workbook BASIC CRASH ANALYSIS |-----------------------------------------------| | PC FROM TRAP THROUGH 4 | [1],[3] |-----------------------------------------------| | PS FROM TRAP THROUGH 4 | |-----------------------------------------------| | UNKNOWN CONTENTS OF EXECUTIVE STACK | LOCATION 376, [2] / ...... / $STKDP is less than or equal to 0. [1] This is the "BEFORE CRASH" PC shown on the CDA listing. [2] This is the "AFTER CRASH" kernel SP shown on the CDA listing. [3] This is the PC following the "physical" cause of the crash; i.e., the instruction which caused the stack limit trap. 25 Crash Dump Analysis Workbook BASIC CRASH ANALYSIS 4.3.3.3 IOT - The CRASH Macro There are at least five places in the executive or other kernel processes where the system is deliberately crashed. This occurs when an unrecoverable error is detected. o DRDSP - illegal TRAP or EMT instruction at system state o SSTSR - SST at system state o DRQIO - device mask work inconsistency o CORAL - pool allocation error o NSPSBC - DECNET error The crashes in DRDSP and SSTSR result in a special stack structure and will be discussed separately. The I/O function code is checked against the function mask in the DCB (device control block) during QIO processing. If it is a legal function then the function code is used to generate an offset into a dispatch table. The system is crashed if the resulting offset is less than zero. The stack depth would be zero, and the crash PC would be in DRQIO. The symbol R$$DER is used to turn on some optional debugging code in CORAL (pool allocation routines). This optional code makes consistency checks during allocation and deallocation of executive pool. The system is crashed if any of these checks fail. The stack depth would be less than one, and the crash PC would be in CORAL. The DECNET module NSPSBC, part of the NT.NSP process in RSX-11M DECNET Phase II, contains a CRASH macro commented "Temporary debugging aid." The system will crash if certain unusual error conditions are detected. 26 Crash Dump Analysis Workbook BASIC CRASH ANALYSIS |-----------------------------------------------| | PC FROM IOT (CRASH MACRO) | [1] |-----------------------------------------------| | PS FROM IOT | |-----------------------------------------------| | UNKNOWN EXECUTIVE STACK | [2] / ...... / $STKDP is less than or equal to 0. [1] This is the "BEFORE CRASH" PC shown on the CDA listing. [2] This is the "AFTER CRASH" kernel SP shown on the CDA listing. 27 Crash Dump Analysis Workbook BASIC CRASH ANALYSIS 4.3.3.4 SST's There are four synchronous system traps (SST) which crash the system when they occur at system state. These are: o Trap through location 4 (other than stack violations) o Illegal instruction trap o Breakpoint or trace trap o Segment fault (memory protect violation) The SST at system state is probably the most common kind of system crash. Of these four, the trap through 4 is most frequent. The appearence of the system stack is similiar, though not identical, for these four crashes. 28 Crash Dump Analysis Workbook BASIC CRASH ANALYSIS |-----------------------------------------------| | PC FROM IOT (CRASH MACRO) IN SSTSR | [1] |-----------------------------------------------| | PS PRIOR TO IOT | |-----------------------------------------------| | NO. OF BYTES (n) FOR SST | [2] |-----------------------------------------------| | SST CODE | |-----------------------------------------------| / OPTIONAL PARAMETERS (n-4 bytes) / |-----------------------------------------------| | RETURN ADDRESS TO $DIRSV COROUTINE | |-----------------------------------------------| | R0 AT TIME OF SST | |-----------------------------------------------| | R1 ... | |-----------------------------------------------| | R2 ... | |-----------------------------------------------| | R3 ... | |-----------------------------------------------| | R4 ... | |-----------------------------------------------| | R5 ... | |-----------------------------------------------| | PC FROM SST | [3] |-----------------------------------------------| | PS AT TIME OF SST | |-----------------------------------------------| / UNKNOWN EXECUTIVE STACK / / ...... / $STKDP is less than or equal to -1. [1] This is the "BEFORE CRASH" PC shown on the CDA listing. [2] This is the "AFTER CRASH" kernel SP shown on the CDA listing. [3] This is the PC following the "physical" cause of the crash. 29 Crash Dump Analysis Workbook BASIC CRASH ANALYSIS 4.3.3.4.1 Trap Through Location 4 The trap through location 4 at kernel state is the most common type of crash that you will see. These traps are ususally from odd address faults, but also include nonexistant memory, bus timeouts, and stack limit traps. When a trap through 4 occurs, the first action in the trap handler is to check for a stack limit violation. That case was discussed earlier. In the non stack violation cases, the odd address code (zero) and the byte count are pushed onto the stack, and the exec branches to the common SST exit routine (SSTXT). The next processing checks if the SST occurred in protected areas of the executive. These are directive dispatching, QIO processing, and PLAS processing. If the SST occurs in one of those areas, and at stack depth 0, then the system will clean up. Otherwise, the system is crashed via a CRASH macro. At this point the stack looks like the picture shown. The key point to recognizing this crash is that the kernel stack pointer points to the 4,0 byte count and SST code. Above that on the stack are the return to DIRSV and the saved registers and PSW. So now we know where the trap occurred and the contents of the registers at the time. 30 Crash Dump Analysis Workbook BASIC CRASH ANALYSIS |-----------------------------------------------| | PC FROM IOT (CRASH MACRO) IN SSTSR | [1] |-----------------------------------------------| | PS PRIOR TO IOT | |-----------------------------------------------| | 000004 | [2] |-----------------------------------------------| | 000000 | |-----------------------------------------------| | RETURN ADDRESS FOR $DIRSV COROUTINE | |-----------------------------------------------| | R0 AT TIME OF TRAP THRU 4 | |-----------------------------------------------| | R1 ... | |-----------------------------------------------| | R2 ... | |-----------------------------------------------| | R3 ... | |-----------------------------------------------| | R4 ... | |-----------------------------------------------| | R5 ... | |-----------------------------------------------| | PC FROM TRAP THRU 4 | [3] |-----------------------------------------------| | PS PRIOR TO TRAP THRU 4 | |-----------------------------------------------| / UNKNOWN CONTENTS OF EXECUTIVE STACK / / ...... / $STKDP is less than or equal to -1. [1] This is the "BEFORE CRASH" PC shown by CDA. [2] The "AFTER CRASH" kernel SP shown by CDA points here. [3] This is the location of the "physical" cause of the crash. 31 Crash Dump Analysis Workbook BASIC CRASH ANALYSIS 4.3.3.4.2 Illegal Instruction Trap |-----------------------------------------------| | PC FROM IOT (CRASH MACRO) IN SSTSR | [1] |-----------------------------------------------| | PS PRIOR TO IOT | |-----------------------------------------------| | 000004 | [2] |-----------------------------------------------| | 000010 | |-----------------------------------------------| | RETURN ADDRESS TO $DIRSV COROUTINE | |-----------------------------------------------| | R0 PRIOR TO ILLEGAL INS. TRAP | |-----------------------------------------------| | R1 ... | |-----------------------------------------------| | R2 ... | |-----------------------------------------------| | R3 ... | |-----------------------------------------------| | R4 ... | |-----------------------------------------------| | R5 ... | |-----------------------------------------------| | PC FROM ILLEGAL INS. TRAP | [3] |-----------------------------------------------| | PS PRIOR TO ILLEGAL INS. TRAP | |-----------------------------------------------| / UNKNOWN EXECUTIVE STACK / / ...... / $STKDP is less than or equal to -1. [1] This is the "BEFORE CRASH" PC shown on the CDA listing. [2] This is the "AFTER CRASH" kernel SP shown on the CDA listing. [3] This is the PC following the "physical" cause of the crash. 32 Crash Dump Analysis Workbook BASIC CRASH ANALYSIS 4.3.3.4.3 Breakpoint |-----------------------------------------------| | PC FROM IOT (CRASH MACRO) IN SSTSR | [1] |-----------------------------------------------| | PS PRIOR TO IOT | |-----------------------------------------------| | 000004 | [2] |-----------------------------------------------| | 000004 | |-----------------------------------------------| | RETURN ADDRESS TO $DIRSV COROUTINE | |-----------------------------------------------| | R0 AT TIME OF BPT | |-----------------------------------------------| | R1 ... | |-----------------------------------------------| | R2 ... | |-----------------------------------------------| | R3 ... | |-----------------------------------------------| | R4 ... | |-----------------------------------------------| | R5 ... | |-----------------------------------------------| | PC FROM BPT | [3] |-----------------------------------------------| | PS AT TIME OF BPT | |-----------------------------------------------| / UNKNOWN EXECUTIVE STACK / / ...... / $STKDP is less than or equal to -1. [1] This is the "BEFORE CRASH" PC shown on the CDA listing. [2] This is the "AFTER CRASH" kernel SP shown on the CDA listing. [3] This is the PC following the "physical" cause of the crash. 33 Crash Dump Analysis Workbook BASIC CRASH ANALYSIS 4.3.3.4.4 Segment Fault |-----------------------------------------------| | PC FROM IOT (CRASH MACRO) IN SSTSR | [1] |-----------------------------------------------| | PS PRIOR TO IOT | |-----------------------------------------------| | 000012 | [2] |-----------------------------------------------| | 000002 | |-----------------------------------------------| | SAVED SR1 | |-----------------------------------------------| | SAVED SR2 | |-----------------------------------------------| | SAVED SR3 | |-----------------------------------------------| | RETURN ADDRESS TO $DIRSV COROUTINE | |-----------------------------------------------| | R0 AT TIME OF SEGMENT FAULT | |-----------------------------------------------| | R1 ... | |-----------------------------------------------| | R2 ... | |-----------------------------------------------| | R3 ... | |-----------------------------------------------| | R4 ... | |-----------------------------------------------| | R5 ... | |-----------------------------------------------| | PC FROM SEGMENT FAULT | [3] |-----------------------------------------------| | PS AT TIME OF SEGMENT FAULT | |-----------------------------------------------| / UNKNOWN EXECUTIVE STACK / / ...... / $STKDP is less than or equal to -1. [1] This is the "BEFORE CRASH" PC shown on the CDA listing. [2] This is the "AFTER CRASH" kernel SP shown on the CDA listing. [3] This is the PC following the "physical" cause of the crash. 34 Crash Dump Analysis Workbook BASIC CRASH ANALYSIS 4.3.3.5 TRAP's And EMT's The appearence of the stack after a spurious TRAP or EMT instruction in kernel state is very similar to the SST stack. The major diferences are that the PC of the IOT is in DRDSP instead of SSTSR, and that there is no SST code or SST parameters. The occurence of a spurious TRAP or EMT is fairly rare. Note that the stack depth for this type of TRAP crash is less than or equal to -2. Recall that a TRAP at stack depth 0 is used to return directive status. 35 Crash Dump Analysis Workbook BASIC CRASH ANALYSIS 4.3.3.5.1 EMT |-----------------------------------------------| | PC FROM IOT (CRASH MACRO) IN DRDSP | [1] |-----------------------------------------------| | PS PRIOR TO IOT | |-----------------------------------------------| | RETURN ADDRESS TO $DIRSV COROUTINE | [2] |-----------------------------------------------| | R0 AT TIME OF EMT | |-----------------------------------------------| | R1 ... | |-----------------------------------------------| | R2 ... | |-----------------------------------------------| | R3 ... | |-----------------------------------------------| | R4 ... | |-----------------------------------------------| | R5 ... | |-----------------------------------------------| | PC FROM EMT | [3] |-----------------------------------------------| | PS AT TIME OF EMT | |-----------------------------------------------| / UNKNOWN EXECUTIVE STACK / / ...... / $STKDP is less than or equal to -1. [1] This is the "BEFORE CRASH" PC shown on the CDA listing. [2] This is the "AFTER CRASH" kernel SP shown on the CDA listing. [3] This is the PC following the "physical" cause of the crash. 36 Crash Dump Analysis Workbook BASIC CRASH ANALYSIS 4.3.3.5.2 TRAP |-----------------------------------------------| | PC FROM IOT (CRASH MACRO) IN DRDSP | [1] |-----------------------------------------------| | PS PRIOR TO IOT | |-----------------------------------------------| | RETURN ADDRESS TO $DIRSV COROUTINE | [2] |-----------------------------------------------| | R0 PRIOR TO TRAP | |-----------------------------------------------| | R1 ... | |-----------------------------------------------| | R2 ... | |-----------------------------------------------| | R3 ... | |-----------------------------------------------| | R4 ... | |-----------------------------------------------| | R5 ... | |-----------------------------------------------| | PC FROM TRAP | [3] |-----------------------------------------------| | PS PRIOR TO TRAP | |-----------------------------------------------| / UNKNOWN EXECUTIVE STACK / / ...... / $STKDP is less than or equal to -2. [1] This is the "BEFORE CRASH" PC shown on the CDA listing. [2] This is the "AFTER CRASH" kernel SP shown on the CDA listing. [3] This is the PC following the "physical" cause of the crash. 37 Crash Dump Analysis Workbook BASIC CRASH ANALYSIS 4.3.4 Tracing The Original Trap 1. Get mapping. The mapping at the time of the crash is determined from the APR's saved by $CRASH. Determine both the Kernel and User mapping. Look to see which tasks and processes were mapped. Remember that RSX-11M can only see 64 KW at a time, 32 KW kernel and 32 KW user. 2. Get registers. Determine the contents of the registers at the physical point of crash. That is easy for an SST crash, since $DIRSV saved them on the stack. For an IOT crash, stack limit violation or "40G" crash, use the registers from the CDA listing. 3. Study the code. From the mapping and the our examination of the kernel stack we know what was executing at the physical point of crash. Get the appropriate maps and listings and study the code. What was going on? Since we know the registers it should be possible to have a fair idea of the answer to that question. If we are lucky, then at this point we have resolved the crash. That is, it turns out that the physical point of crash was also the real point of crash. 38 Crash Dump Analysis Workbook CRASH DETECTIVE 5.0 CRASH DETECTIVE In this section we will discuss what to do if the basic analysis fails to find the problem. There is no specific cookbook to use at this point. Rather, you dig into your bag of tricks and tools and use whatever is appropriate for the crash. 39 Crash Dump Analysis Workbook CRASH DETECTIVE 5.1 The CDA File Your basic source of information as a crash detective is the CDA file. There is much more information in the file than reported by CDA. It is crucial you understand the format of this file so you can understand how to look at it. A CDA file is an image of the system at the point a failure occurs. The following diagrams compare the CDA file to the virgin system and saved system images. CDA Virgin Saved |-----------| |-----------| |-----------| Block 1 | Address 0 | | Label 1 | | Label 1 | |-- --| |-- --| |-- --| Block 2 | 1000 | | Label 2 | | Label 2 | |-- --| |-- --| |-- --| Block 3 | 2000 | | Address 0 | | Bootstrap | |-- --| |-- --| |-- --| Block 4 | 3000 | | 1000 | | 1000 | A few numbers to remember are: 1 Block = 1000(8) bytes 4 Blocks = 1KW 200(8) Blocks = 32KW Also remember, files start with block 1. Therefore, in a CDA file, address 0 is [block 1, offset 0] and address 3114 is [block 4, offset 114]. The formulas for caculating [block, offset] for an address are: block = (address/1000) + 1 (1000 is octal) offset = MOD (address/1000) (1000 is octal) 40 Crash Dump Analysis Workbook CRASH DETECTIVE 5.2 Tools Besides CDA, there are other tools you can use on crashes. In this section we will discuss two specific programs, ZAP and BINCMP, and how you can write simple Fortran programs to look at crashes. 5.2.1 ZAP ZAP is a very powerful tool when looking at crashes. It will let you examine any location in the crash dump. In particular, ZAP is useful for examining data structures not output by CDA, executive and task code related to the crash, and general poking around inside the crash dump file. Points to remember about ZAP include: o ZAP commands are similar to ODT. o ZAP is documented in Chapter 19 of the Utilities Manual. o ZAP is invoked as follows: >RUN $ZAP ZAP>file specification[/SW] or >ZAP ZAP>file specification[/sw] /AB Absolute image /LI List task mapping /RO Read-only access o Note, >ZAP file specification is not allowed. o When using ZAP on a CDA file, use /AB/RO switches. 41 Crash Dump Analysis Workbook CRASH DETECTIVE ZAP can only access 32KW from a given base address. When looking at a CDA file, it is useful to set relocation registers. For example, 1:0;1R sets relocation register 1 to the start of the executive (address 0). Assume you wanted to examine location 123404 in F11ACP. According to the CDA listing, F11ACP is located at physical address 345200. The following commands will examine this address: _346:200-120000;2R _2,123404/ or _346:200;2R _2,3404/ 42 Crash Dump Analysis Workbook CRASH DETECTIVE 5.2.2 BINCMP BINCMP is a program written at Monsanto to perform a binary, word-by-word compare of two files. It was especially written to compare a CDA file to the virgin or saved system. This is useful for checking to see if code has been modified. BINCMP is written in F4P and is available on the Spring, 1979 DECUS tape in [346,100]. It will also be in the crash submission on this symposium tape set. The following example shows how to use BINCMP to compare a CDA file against the virgin system image. In the example, locations 0 to 64230 (the executive) are compared. RUN $BINCMP BINARY COMPARE - V01.01 OUTPUT FILE [A]: TI: INPUT FILE 1[A]: CRASH.CDA INPUT FILE 2[A]: RSX11M.TSK FILE 1 OFFSET [O]: 0 FILE 2 OFFSET [0]: 2000 ADDRESS OFFSET [O]: 0 START ADDRESS [0]: 0 LAST ADDRESS [0]: 64230 SEGMENT OUTPUT [Y/N]: Y VALUE OUTPUT [Y/N]: Y A few notes about BINCMP. All numbers are entered in octal and are stored in I*4 variables. If segment output is selected, the addresses of all differences will be listed. If value output is selected, the actual values will be listed. When comparing a CDA file to a virgin system, there are many expected differences. The system stack, SYSCM, and SYSTB will all change as the system is executing. Also, many of the executive modules have temporary variables in them. 43 Crash Dump Analysis Workbook CRASH DETECTIVE 5.2.3 Specials Finally, it is not difficult to write you own programs to do special analysis of a CDA file. CDA files, system images, and tasks are considered as fixed length, 512 byte record files. For example, your analysis shows that something is illegally referencing location 30 (EMT trap) and storing a 102456 in it. The following F4P program will read the crash dump file and output the phyiscal address of all occurances of either "30" or "102456". This will give you possible problem areas. PROGRAM EXAMPL C C OPEN 'CRASH.CDA' AND SEARCH FOR ALL OCCURANCES OF EITHER C "30" OR "102456". C C DEFINE VARIABLES C INTEGER*2 IBLK !BLOCK NUMBER INTEGER*2 IWRD !BLOCK OFFSET INTEGER*4 IADR !PHYSICAL ADDRESS C C OPEN CRASH FILE FOR INPUT. C OPEN (UNIT=1,FILE='CRASH.CDA',TYPE='OLD',READONLY, 1 ACCESS='DIRECT',RECORDSIZE=128) C C READ FILE SEQUENTIAL UNTIL EOF, CHECK FOR 4 OR 102456. C IBLK = 1 100 CONTINUE READ (1'IBLK,END=999) IBUF DO 200 IWRD = 1,256 IF (IBUF(IWRD).EQ."000030) GOTO 210 IF (IBUF(IWRD).EQ."102456) GOTO 210 GOTO 200 210 CONTINUE IADR = (IBLK-1)*512+(IWRD*2) WRITE (5,1000) IADR,IBUF(IWRD) 200 CONTINUE IBLK = IBLK+1 GOTO 100 C C CLOSE FILE AND EXIT. C 999 CLOSE (UNIT=1) STOP C C FORMAT STATEMENTS. C 1000 FORMAT (' ADDRESS ,O12,' HAS VALUE ',O6) END 44 Crash Dump Analysis Workbook CRASH DETECTIVE 5.3 Tricks The following are tricks we use at Monsanto to solve problems. There are probably others. In general, we start using tricks when we get a handle on a problem but cannot nail it down. 5.3.1 Branch-on-self The branch-on-self instruction (777) is a useful, poor-man's debugging tool. When executed, the executive or a program will patiently loop on itself. This provides a quick and dirty way to stop the execution of something, examine various values, and continue execution. Branch-on-self is most useful when you can reproduce a problem and need to trace back to the source. For example, you have a program which aborts because a certain location has a bad value but you do not know who sets the value bad. By using the OPEN command and branch-on-self, you can easily trace the program by the following steps: 1. Fix the program in core. 2. Set a branch-on-self at an appropriate point. 3. Run the program and cause the problem to reproduce. 4. When the branch-on-self is executed (check with ATL), examine the location which is going bad. If it is bad, you have narrowed the problem to the code executed before the patch. 5. Set the next 777 at the appropriate point. 6. Restore the orginal contents of the previous patch. The program will resume execution and loop when it hits the new patch. 7. Loop through steps 4, 5, and 6. Some notes about this technique. If working on a program, make sure its priority is less than MCR. Otherwise, you will lock-up your system. Also, if using branch-on-self for executive, driver, or system state code, you will have to use the console to do the examines and deposits. 45 Crash Dump Analysis Workbook CRASH DETECTIVE 5.3.2 On-line Patches Often, to trap a problem, you will want to make a patch to the executive. This is rather easy to do with the OPEN command. One problem is finding space to put the patch. There are several possibilities: o The bottom of the kernel stack is almost never used. The stack runs from the top of the vector space (V$$CTR) to the label $STACK. Usually 10 to 20 words at the bottom can be used for patches. Note, you run the risk of the kernel stack pushing down and wiping out the patch. o The stack space used by CRASH can be used for patches. These locations are between $CRPBF and $CRSBN. This provides 173 words of space on a mapped system. Note, that the patch will be wiped out if the system crashes. o At Monsanto, we always include a module in our executives which allocates a 64 word area. o On the SIG tapes in the crash seminar area is a program named POL. This program will takes the number of bytes and allocates a buffer from pool of this size. It reports the starting address of the allocated area. This space can then be used for patches. Some notes about this technique. If patching code which may be executed, either use the console switches or XDT (see loadable XDT on SIG tapes). Also, the patch will only remain in the system until it is rebooted. If needed, use ZAP to patch the system save file to make the patch permanent. 46 Crash Dump Analysis Workbook CRASH DETECTIVE 5.3.3 Logic Analyzer If you have them, logic analyzers can be an invaluable tool for troubleshooting certain types of bugs, particularly unknown errors which modified known locations. At Monsanto, we have the HP 1610 logic analyzer and its interface boards for the Unibus and Q-bus. By fitting the boards into the backplane and programming the HP 1610, we can have it watch the Unibus address and data lines. For example, if location 30 is being modified, we can have the analyizer watch for a write cycle to address 30. Then, by looking at the trace, we can get the PC of the instruction which wrote to location 30. 47 Crash Dump Analysis Workbook CRASH DETECTIVE 5.3.4 T-Bit Traps The T-Bit traps provide another method of "watching" program execution. It is possible in RSX-11M to trace-trap every instruction. Consider the problem from before, some unknown instruction is setting location 30 to a 102456. The following steps will setup trace-trap to watch location 30 and crash the system if it changes from its normal value (23242). 1. Using OPEN, write a special service routine to examine location 30. In this example, we will using the bottom of the kernel stack. Note the use of the RTT to return from the T-Bit trap. Also, the T-Bit is set in the PS of the trap. This is in case the trace instruction turned the T-Bit off. >OPEN 400 000400/ 000000 022737 ;CMP #23242,@#30 000402/ 000000 023242 ; 000404/ 000000 000030 ; 000406/ 000000 000401 ;BEQ .+4 000410/ 000000 000000 ;HALT 000412/ 000000 052766 ;BIS #20,2(SP) 000414/ 000000 000020 ; 000416/ 000000 000002 ; 000420/ 000000 000006$ ;RTT > 2. Using OPEN, modify the T-Bit trap vector to point to your special code. This will make any programs using the BPT trap useless (like ODT). >OPEN 14 000014/ 021526 000400$ ;Set to special code > 3. Using OPEN, modify the PS of all vectors whose could should be traced to set the T-Bit. For example, to trace directives, set the T-Bit for the EMT trap. Then, when that vector is used, the T-Bit trap will be enabled and the special code executed. The system will halt when it sees location 30 change from its normal value. >OPEN 32 000032/ 000340 000360$ ;Set T-Bit on interrupt > 48 Crash Dump Analysis Workbook CRASH DETECTIVE 5.3.5 Mousetraps Mousetraps are a powerful concept in crash analysis. In basic crash analysis, the process is to work up the stack and backwards in time to the real cause of the error. However, basic analysis can only go so far back before the necessary tracks have been destroyed. Here is where you use a mousetrap. A mousetrap is a patch designed to detect an error condition closer to the real cause of the error. For example, your analysis shows the system crashed because something corrupted location 4. However, the real error occured sometime in the past and only was detected when a user program odd-address trapped. What you would like to do is detect the error as soon as possible after location 4 is overwritten. One method would be to write a dummy task that caused an odd-address trap and continually run the task. This is a mousetrap in its crudest form. Another technique would be to use the T-Bit trap and continually monitor location 4. However, this introduces a great deal of overhead on your system. A better technique would be to place checks for location 4 at strategic points in the system. The structure of RSX-11M lends itself very well for this. For example, all context switches into the executive enter and exit using a common co-routine, $DIRSV. Similarly, all interrupts are processed using the co-routine $INTSV. By patching this code to monitor location 4, you can narrow the error down to the current task or executive context. If the error is trapped on entering the executive, you know the current task is the culprit. If the error is trapped on exiting the executive, you know the problem occured in the current context of the executive. The variety and scope of possible mousetraps is limitless. The list below has some of the types used at Monsanto to shoot problems. o SYSXT The module SYSXT processes all changes in context for RSX-11M. In this module are the $DIRSV and $INTSV co-routines, fork processing and the task context switch code. If the problem is executive code or data structure corruption, this is a good module for adding mousetraps. By putting the trap here, you will at least catch the problem in the current context it occured. 49 Crash Dump Analysis Workbook CRASH DETECTIVE o SYSCM Sometimes, analysis traces a problem to the executive data structures in SYSCM. If this is the case, a concatenated executive listing can give you all references to the structure. Then you can put mousetraps at all the appropriate points. For example, analysis shows a bad value is being put into $RQSCH. By putting mousetraps at every point in the executive which writes this value, we can find out the source of the bad data. o Special Drivers When a problem is I/O related, special drivers can be used to catch it. For example, at Monsanto we have an system where every three months or so, block 2 in a certain file is corrupted. To catch this problem, we have put a special driver between the executive and the disk driver. This driver watches all disk writes and when it sees an IO.WLB to the block in question, it checks the data for validity. This way, we can catch the source of the problem in the context of the user task. Special drivers for use as mousetraps are fairly easy. The technique is to write a loadable driver with a copy of the real drivers data base. The mousetrap driver gets the I/O packets, performs the necessary checks, and then forwards the I/O packet onto the real driver by queuing directly to the driver queue ($DRQRQ). The mousetrap driver is enabled by redirecting the real driver to it. Mousetraps come in two forms. The first watches for a problem and crashes the system. Another flavor is used to gather and record past history to aid in tracking down a problem. For example, to continue your analysis, you would like to see what tasks where executing in the immediate past. A mousetrap could be added to store the TCB of the new task each time a context switch was made in a circular buffer. Then when the system crashes, your could get the last 'n' tasks which ran. The same technique can be used to gather any historical data. The limit is only how much circular buffer you can make available. 50 Crash Dump Analysis Workbook CRASH DETECTIVE 5.4 Mathematics Of RSX-11M Your best tool to solve crashes is your intuition. People good at debugging have a difficult time explaining the thought process they use. To them it is mearly a matter of "the problem is 'x' because the symptoms were 'y'". Because of this, many people consider crash analysis and debugging to be a black art which is only to be practiced by believers in the occult. Nothing could be further from the truth. Crash analysis, if anything, is a scientific discipline. A computer system is a finite-state system which is governed by a set of basic rules. Crash analysis is the process of determining how the system reached one particular, undesirable state. Skilled programmers understand the rules of the system. This allows them to intuitively draw conclusions that others must slowly work out by hand. An analogy can be drawn between the study of RSX-11M and other, more traditional, scientific disciplines. For example, in physics, knowledge of Newton's Laws of Motion provides a basis for intuitively explaining how an object will react to a given force. A similar understanding of the fundamental laws of RSX-11M will provide insight into explaining how crashes occur. The following are Stamerjohn's Laws of RSX-11M. Note, the lists are grouped from most fundamental to most complex. If a basic law is violated, the nature of the beast is changed. * PDP-11 CPU o The CPU executed instructions correctly. o The CPU fault mechanisms worked correctly. o The CPU priority mechanism worked correctly. o The CPU memory management mechanism worked correctly. This means that at any given moment, an instruction can only address the 32 KW's currently addressed by the hardware (except for the MTPI and MFPI instructions). * Peripherals o In general, assume peripherals work correctly, including whatever fault mechanisms are built into them. However, certain classes of faults will go undetected by both the hardware and RSX-11M: * Unexpected interrupts generally go undetected by Digital-written device drivers and cause executive and database corruption. A good rule is for all drivers to check for unexpected interrupts and dismiss them. * Both "HOT" and "COLD" bits in device logic, particularly DMA addresses will go undetected by both hardware and software and cause errors. 51 Crash Dump Analysis Workbook CRASH DETECTIVE o Peripheral-caused crashes look strange. However, remember that the device did not randomly pick how the system crashed. Some error occured in the device and from that point, it performed as it should. The question to answer for such errors is "What condition will cause the device to generate the symptoms observed?" And then prove that is what happened. * Memory Mapping (20K option assumed) o The RSX-11M executive always maps the first 20 KW's of physical memory with APR0-4 and the I/O page with APR7. These mappings never change. This holds true even if pool does not extend to 20KW. This is how DECNET common executive works. o The excutive uses APR6 to map buffers and things. o Loadable drivers are always mapped with APR5. APR6 is free for their use. o Privilege tasks are mapped with APR5-6. They are also mapped to the executive APR0-4. They may use APR7 for code and not the I/O page, but when switching to the executive, it will map APR7 to the I/O page. * RSX-11M Executive/User Interface o The interface between a user task and the executive is always a trap. o All traps have a common entry and exit point inside the executive. * RSX-11M Executive Processing o The executive services all events serially, i.e. the processing of one event (an EMT) is completely finished before processing another event (I/O completion). Not until all executive events are processed will the executive return to the user task. Note, finished in this case could mean queuing the processing to some queue. o For the executive, the context of the current user task is valid only to the point where processing results in queuing to some queue. When processing resumes because of dequeuing, the state of the current user task must be assumed to have changed. * Pool/Data Structures 52 Crash Dump Analysis Workbook CRASH DETECTIVE o Once created, a data structure does not moved until it is destroyed. However, be careful in assuming when that is. o Some data structures are a very static existence (the PCB for GEN). Structures in the class include device DCB's, UCB's, and SCB's, main partition PCB's and such. o Data structures associated with tasks are less static but remain typically remain valid as long as the task does. Note, task headers are only valid as long as a task is in memory. o Once you run out of enough pool to create a task header, your system is dead. o RSX-11M cannot run more than 140 tasks in memory at the same time. This is assuming you have 12KW of free pool and each task has has mimumun data structures size. To execute, a task must have a TCB, PCB, and task header. The minimum size of these structures is 60(8) (TCB), 34(8) (PCB), and 144 (task header) for a total of 260(8) per task. With 60000(8) bytes of pool, this works out to 214(8) tasks or 140(10). Note, in this senario, the tasks have no luns, send no messages, and in general, do nothing useful. * Resource Allocation o Each task in the system has a priority. All resources in the system are allocated on the basis of this priority, primiarily CPU time and memory. Tasks at the same priority are allocated resources on the basis of first-in, first-out. o A task must be in core to execute. Note, this includes aborting. o The entire purpose of the task loading logic is to bring the highest priority task out of memory into memory. Because the partition wait queue is priority ordered, the logic nevers looks beyond the first task in the partition wait queue, even if the task cannot currently be brought into memory. o The task loading logic checkpoints tasks if there is not enough free memory to load the highest priority task which is out-of-memory. The checkpointing logic searches for the first task in the partition which is lower in priority and would leave a large enough hole. o Round-robin scheduling only effects CPU-time allocation. Therefore, the algorithm only operates on tasks in memory and at the same priority. For such tasks, each one will be given a time-slice to execute in. Note, if a higher priority task uses all the available CPU time, nothing will be available for other tasks to round-robin schedule with. There is no priority-promotion associated with round-robin scheduling. 53 Crash Dump Analysis Workbook CRASH DETECTIVE o Disk swapping only effects memory allocation. The algorithm varies the priority with which a task competes for memory, nothing else. * RSX-11M Task Scheduling o Unless a task is at priority 255, its execution may be interrupted at any point in time and the context of the system switched to another task. o Similarly, the exceution of a program will never be interrupted by a program of lower priority, no matter how important the low priority programs execution is. o The only exception to the above is when a user task switches to kernal state. Note, after the switch, the task is no longer a task but part of the executive. o If your program does something to cause a higher-priority program to execute, you will not execute the next instruction before it executes. o If your program does something to cause a lower-priority program to execute, it will not begin to execute until your task does something to put it in a wait state or exits. 54 APPENDIX A CONCATENATED EXECUTIVE ASSEMBLY One of the most useful listings to have for crash analysis is a concatenated listing of the executive. This is a listing of all RSX-11M executive modules and when done correctly, provides a listing which is an exact image of the executive. Also, by concatenating and assembling the entire executive, a cross-reference of all symbols can be obtained. The steps for producing a concatenated executive listing are very straightforward. The basic principles are as follows: 1. Copy all executive modules loaded in your system into one file. Copy the modules in the order they are shown loaded by the executive map. 2. Edit the resulting file. Change all .TITLE statements to .SBTTL statements and comment out all .END statements except the last one. Also, place a .DSABL LSB statement at the end of each executive module. This will prevent local symbols from carrying over between modules. 3. Assmble the resulting file and request a cref for the listing. Use LB:[1,1]EXEMC/ML and the RSXMC.MAC file as prefix files. The following pages list the command and source files used at Monsanto to automate this process. The following files are used: 1. STEP0.CMD This is the master command file. It executes STEP1.TEC to produce a PIP command file from the executive task build file, executes the resulting file (RSXPIP.CMD) to copy the executive sources into one file, executes STEP2.TEC to edit the concatentated file for assembly, and finally, assembles the concatentated executive. 2. STEP1.TEC This is a TECO macro which inputs RSXBLD.CMD and outputs RSXPIP.CMD. The output file is a command file which copies the individual executive sources into one file, RSX11M.MAC. A-1 CONCATENATED EXECUTIVE ASSEMBLY 3. STEP2.TEC This is a TECO macro which edits RSX11M.MAC to change it into a format suitable for assembly. 4. MASTER.MAC This file is used as the first file in RSX11M.MAC. It sets the correct title and defines the executive macros so the various executive symbols appear in the listing. 5. C5TA.MAC This is a dummy module for the C5TA routine from SYSLIB.OLB. It is used to properly space the addresses so the resulting listing is an exact image of the executive. See STEP0.CMD for further details. Note, the assembly produces two errors. This is because Digital has used the same symboL (L.LGTH) for two different data structures. All the files shown on the previous pages will be on the RSX/IAS SIG tape in [346,101]. For the TECO macros, a dollar sign ($) is an escape. A-2 CONCATENATED EXECUTIVE ASSEMBLY STEP0.CMD A.1 STEP0.CMD .ENABLE SUBSTITUTION .SETS UIC ; ; Build and Assemble Concantenated Executive. ; ; This command file creates and assembles a concantenated RSX-11M ; executive. The command file requires the following files to be ; present in SY0:'UIC'. ; ; STEP1.TEC Phase 1 Teco command file ; STEP2.TEC Phase 2 Teco command file ; MACRO.MAC Initial concantenated source ; C5TA.MAC Fake C5TA source module ; ; In addition, the following files from the system generation must ; be present in SY0:'UIC'. ; ; RSXBLD.CMD Task Build command file ; RSXMC.MAC Configuration prefix file ; SYSTB.MAC Device table source file ; ; Finally, psuedo device IN: must be assigned to the disk containing ; the executive sources. The sources are assumed to be in [11,10]. ; The executive library file is assumed to be in LB:[1,1]EXEMC.MLB. ; Also, the tasks TEC, PIP, MAC, and CRF must be installed. If all ; is correct, answer the next question 'YES'. Otherwise, the command ; file will pause and allow you complete the necessary setup. ; .ASK FLAG CONTINUE WITH FILE .IFF FLAG .PAUSE ; ; Create PIP command file from RSXBLD.CMD and copy executive. ; TEC @STEP1.TEC @RSXPIP.CMD ; ; Format RSX11M.MAC into correct form. ; TEC @STEP2.TEC ; ; Assemble executive, getting list and cref. ; MAC ,RSX11M/-SP/CR=LB0:[1,1]EXEMC/ML,SY0:'UIC'RSXMC/PA:1,RSX11M ; ; Waiting on CREF to finish. ; .WAIT CRF... ; ; All done. ; A-3 CONCATENATED EXECUTIVE ASSEMBLY STEP1.TEC A.2 STEP1.TEC !---------------------------------------------------------------! ! Concantentated RSX-11M Executive - Step 1 Macro ! ! ! ! This macro inputs the RSXBLD.CMD file and produces a ! ! PIP command file to append the necessary sources into ! ! one file. ! !---------------------------------------------------------------! !---------------------------------------------------------------! ! Open input and output files. ! !---------------------------------------------------------------! ERRSXBLD.CMD$ HK Y EWRSXPIP.CMD$ !---------------------------------------------------------------! ! Strip garbage from RSXBLD.CMD. ! !---------------------------------------------------------------! K S,[1,1]EXELIB/LB/SS$ -18D L .,ZK !---------------------------------------------------------------! ! Strip library names from RSXBLD.CMD. ! !---------------------------------------------------------------! 0J !---------------------------------------------------------------! ! Convert remaining names to one/line. ! !---------------------------------------------------------------! 0J !---------------------------------------------------------------! ! Format module names into correct PIP commands. ! !---------------------------------------------------------------! 0J !---------------------------------------------------------------! ! Process special cases of files, output, and exit. ! !---------------------------------------------------------------! 0JI PIP RSX11M.MAC/ME=SY0:MACRO.MAC PIP RSX11M.MAC/AP=SY0:RSXMC.MAC $0J SC5TA$ 0L FSIN0:[11,10]$SY0:$0J SSYSTB$ 0L FSIN0:[11,10]$SY0:$EX$$ A-4 CONCATENATED EXECUTIVE ASSEMBLY STEP2.TEC A.3 STEP2.TEC !---------------------------------------------------------------! ! Concantentated RSX-11M Executive - Step 2 Macro ! ! ! ! This macro inputs the RSX11M.MAC file and produces a ! ! file with .TITLE's and .END's changed. ! !---------------------------------------------------------------! !---------------------------------------------------------------! ! Open input and output files. ! !---------------------------------------------------------------! EBRSX11M.MAC$ HK Y !---------------------------------------------------------------! ! Change RSXMC to function correctly. ! !---------------------------------------------------------------! NS$$YDF$ 0KK FS.TITLE$.SBTTL$ NS$$YDF$ 0KK !---------------------------------------------------------------! ! Change .TITLE, .END pairs. ! !---------------------------------------------------------------! !---------------------------------------------------------------! ! Insert final .END and exit. ! !---------------------------------------------------------------! .END $INITL $EX$$ A-5 CONCATENATED EXECUTIVE ASSEMBLY MASTER.MAC A.4 MASTER.MAC .TITLE RSX11M .SBTTL RSX11M ; ; PREFIX FILE FOR CONCANTENATED RSX-11M ASSEMBLY. ; ; THIS FILE DECLARES THE MACROS USED TO DEFINE EXECUTIVE ; TABLE STRUCTURES AND BITS. THIS IS DONE TO GET AS MANY ; NON-GLOBAL SYMBOLS AS POSSIBLE. ; .MCALL IOERR$ IOERR$ .MCALL FILIO$ FILIO$ .MCALL ABODF$ ABODF$ .MCALL CLKDF$ CLKDF$ .MCALL DCBDF$ DCBDF$ .MCALL EMBDF$ EMBDF$ .MCALL HDRDF$ HDRDF$ .MCALL HWDDF$ HWDDF$ .MCALL ITBDF$ ITBDF$ .MCALL PCBDF$ PCBDF$ ,,SYSDEF .MCALL PKTDF$ PKTDF$ .MCALL SCBDF$ SCBDF$ .MCALL TCBDF$ TCBDF$ .MCALL UCBDF$ UCBDF$ .PAGE A-6 CONCATENATED EXECUTIVE ASSEMBLY C5TA.MAC A.5 C5TA.MAC .TITLE C5TA .IDENT /02/ ; ; FAKE C5TA, USED TO CORRECT SPACE FILL EXECUTIVE. ; $C5TA:: ;REF. LABEL .BLKB 110 ;SIZE OF MODULE .END A-7 APPENDIX B CRASH MANAGMENT COMMAND FILE The following is a command file that will read a crash dump from a crash device (MM: in this case), name it, and generate the initial listing. A copy of this file is on the SIG tape. It is named CRASHREAD.CMD. B-1 CRASH MANAGMENT COMMAND FILE .; Command file to read crash dumps, name according to the .; date and crash, and get initial CDA listing using the .; options /ACT/HDR/PCB. .; .; The name is the form NAMEMMDDX, where NAME is the system .; name, MM is the month, DD is the day, and X is the crash .; of the day (A for the first, B for the second, etc.) .; SET /UIC=[1,17] .ENABLE SUBSTITUTION .SETS $NAME "XXXX" .; .; Get date and parse out month and day. .; .SETS $DATE .PARSE $DATE "--" $DD MM YR .IF MM ="JAN" .SETS $MM "01" .IF MM ="FEB" .SETS $MM "02" .IF MM ="MAR" .SETS $MM "03" .IF MM ="APR" .SETS $MM "04" .IF MM ="MAY" .SETS $MM "05" .IF MM ="JUN" .SETS $MM "06" .IF MM ="JUL" .SETS $MM "07" .IF MM ="AUG" .SETS $MM "08" .IF MM ="SEP" .SETS $MM "09" .IF MM ="OCT" .SETS $MM "10" .IF MM ="NOV" .SETS $MM "11" .IF MM ="DEC" .SETS $MM "12" .; .; Loop and find which crash sequence number to use. .; .SETN $POS 0 .SETS ALBET "ABCDEFGHIJKLMNOPQRSTUVWXYZ" .100: .INC $POS .SETS $X ALBET[$POS:$POS] .SETS $FILE $NAME+$MM+$DD+$X .TESTFILE '$FILE'.CDA .IF = 1 .GOTO 100 .; .; Install necessary tasks, load driver, and get dump. .; .IFNINS ...LOA INS $LOA .IFNINS ...UNL INS $UNL .IFNINS ...CDA INS $CDA .IFNLOA MM: LOA MM:/HIGH/PAR=GEN .SETS F $FILE CDA 'F'/-SP,'F'/MEMSIZ:''.=[1,54]/STB,MM:/PCB/ACT/HDR .; .; Clean-up from command file. .; UNL MM: REM CDA B-2 APPENDIX C CDA AND RELATED PATCHES This section has patches used at Monsanto to correct errors in the executive crash dump routine and CDA itself. In this section are the following files: o LOWCR.COR This file patches the jump to $CRASH to correct jump to $CRALT. This prevents the top two words on the stack from being popped off and used as the PS and PC of the trap address. o CRASH.COR This file patches CRASH for a variety of problems. It also includes at patch to correctly get the user stack pointer and save location 4. o CDA.CMD This file applies the patches to CDA. o CDACLQ.PAT This file patches CDA to report the correct time for the clock queue dump. o LUDMP.PAT This file patches CDA to not print garbage for non-Files-11 window block, like DECNET. o TDUMP.PAT This file patches CDA to correctly output the pre-AST status bits. C-1 CDA AND RELATED PATCHES LOWCR.COR C.1 LOWCR.COR LOWCR.MAC/AU:72./-BF=LOWCR.DMC \ -2,2 .IDENT /09A/ -11,11 ; VERSION 09A -27 ; ; MSH089 -- PRESERVE ENTIRE STACK DURING FORCED CRASH % -80,,/;MSH089/ .IF DF C$$RSH JMP $CRALT ;JMP TO CRASH ROUTINE .IFF -81,,/;MSH089/ .ENDC / C-2 CDA AND RELATED PATCHES CRASH.COR C.2 CRASH.COR CRASH.MAC/AU:72./-BF=CRASH.DMC \ -2,2 .IDENT /04.03G/ -25,25 ; VERSION 4.03A -43 ; MSH039 -- DON'T RELY ON NXM TRAPS TO STOP RL11 ; MEMORY DUMPING ON Q-BUS MACHINE ; ; MSH057 -- PREVENT TK06 ROUTINE FROM CORRUPTING THE ; DISK BY A NXM TRAP ; ; MSH058 -- DO NOT ATTEMPT TO CLEAR R-ONLY REGISTERS ; ; MSH059 -- FIX TS11 BUGS ; ; MSH101 -- GET USER MODE SP ; ; MSH113 -- GET UMR#1 FOR TS11 MEMORY MAPPING ; ; MAP003 -- SAVE LOCATION 4 ; % -64,,/;MAP003/ $CRTR4::.WORD 0 ;TRAP 04 VALUE -184,,/;MAP003/ MOV @#4,$CRTR4 ;SAVE TRAP 04 LOCATION -256,,/;MSH101/ .IF DF M$$MGE MOV #PMODE!PR7,PS ;;;LOCK OUT INTERRUPTS AND SET ;;;PREVIOUS MODE=USER .IFF -257,,/;MSH101/ .ENDC -303,,/;MAP003/ .IF DF M$$WRD MOV $CRAR5,24(SP) ;;;RESET CORRECT APR5 VALUE .ENDC -623,632,/;MSH057/ C-3 CDA AND RELATED PATCHES CRASH.COR .IFTF ;M$$EXT .IF DF M$$MGE MOV #140000,R5 ;;;SET TO MAP THROUGH APR6 CLR @#KISAR6 ;;;POINT TO FIRST BYTE OF 1K SEGMENT .IFF ;M$$MGE CLR R5 ;;;R5 TRACKS THE DUMP PROCESS .ENDC ;M$$MGE .IFT ;M$$EXT 50$: CLR 4(R0) ;;;START AT BEGINNING OF UNIBUS MAP .IFF ;M$$EXT CLR 4(R0) ;;;START OF BEGINNING OF MEMORY 50$: .IFTF ;M$$EXT MOV #-2000,2(R0) ;;;WRITE 1K WORDS PER TRANSFER -636,649,/;MSH057/ BMI 80$ ;;;IF MI ERROR .IFT ;M$$EXT ADD #4000,@#UBMPR ;;;POINT TO NEXT 1K WORD BOUNDARY ADC @#UBMPR+2 ;;;DON'T FORGET THE CARRY ADD #40,@#KISAR6 ;;;ADJUST DUMP TRACKING POINTER CMP #170000,@#KISAR6;;;HAVE WE HIT THE I/O PAGE? .IFF ;M$$EXT .IF DF M$$MGE ADD #40,@#KISAR6 ;;;ADJUST DUMP TRACKING POINTER CMP #7600,@#KISAR6 ;;;HAVE WE HIT THE I/O PAGE? .IFF ;M$$MGE ADD #4000,R5 ;;;ADJUST DUMP TRACKING POINTER CMP #160000,R5 ;;;HAVE WE HIT THE I/O PAGE? .ENDC ;M$$MGE .ENDC ;M$$EXT BEQ $CRCMP ;;;IF EQ YES, DUMP IS DONE TST (R5) ;;;DOES FIRST WORD OF NEXT TRANSFER? C-4 CDA AND RELATED PATCHES CRASH.COR BCC 50$ ;;;IF CC YES BR $CRCMP ;;;IF CS NO, DUMP IS DONE 80$: -670,,/;MSH039/ .IFF .IF DF M$$MGE MOV #124.*4,-(SP) ;;;DUMP MAXIMUM 124.K WORDS .IFF MOV #28.*4,-(SP) ;;;DUMP MAXIMUM 28.K WORDS .ENDC -681,681,/;MSH039/ BMI WERRX ;;;IF MINUS I/O ERROR -688,688,/;MSH039/ BMI WERRX ;;;IF MINUS I/O ERROR -715,715,/;MSH039/ BMI WERRX ;;;IF MINUS I/O ERROR -723,,/;MSH039/ DEC (SP) ;;;DECREMENT MAXIMUM BLOCK DUMP BLE 72$ ;;;IF EQ, DUMP IS DONE -750,750,/;MSH039/ BEQ WERRX ;;;IF EQ, I/O ERROR 72$: TST (SP)+ ;;;CLEAN STACK BR $CRCMP ;;;DUMP DONE WERRX: TST (SP)+ ;;;CLEAN STACK -879,879,/;MSH058/ TST 2(R0) ;;;RESET RBUF -969,975,/;MSH059/ 100$: MOV #<1$+12>,R5 ;;;WE NOW COMPUTE ADDRESS OF COMMAND BIC #3,R5 ;;;BUFFER. (NEEDS DOUBLE WORD BOUND) MOV #8.,-(R5) ;;;LENGTH OF COMMAND PACKET ADDRESS CLR -(R5) ;;;UPPER 2 BITS OF COMMAND PACKET MOV #2$,-(R5) ;;;LOW ORDER 16 BITS MOV #100004,-(R5) ;;;WANT TO WRITE CHARACTERISTICS MOV R5,R4 ;;;COPY POINTER TO COMMAND PACKET ;;;R4=R5 IS FLAG THAT TS11 IS ;;;BEING INITIALIZED (SEE 180$) -978,978,/;MSH059/ -980,980,/;MSH059/ MOV #142010,(R5) ;;;REWIND AND CLEAR VOLUME CHECK -982,982,/;MSH059/ -984,984,/;MSH113/ .IF DF M$$EXT MOV #20000,(R5)+ ;;;POINT BUFFER TO SECOND UMR C-5 CDA AND RELATED PATCHES CRASH.COR .IFF CLR (R5)+ ;;;START AT LOCATION 0 .ENDC -986,986,/;MSH059/ MOV #512.,(R5) ;;;NUMBER OF BYTES IN A RECORD -992,993,/;MSH113/ CLR @#UBMPR+4 ;;;INITIALIZE UMR TO ADDRESS 0 CLR @#UBMPR+6 ;;; -994,994,/;MSH059/ -997,998,/;MSH059/ MOV #<1920./4>,R3 ;;;MAX NUMBER OF 4K WORD BLOCKS 40$: MOV #<1024.*4*2/512.>,R2;;;MAX NUMBER OF 512 BYTE REC/BLK -1002,1002,/;MSH059/ MOV #<124.*4>,R2 ;;;MAX NUMBER OF 4K WORD BLOCKS -1006,1006,/;MSH059/ 50$: MOV #9.,R5 ;;;RETRY COUNT+1 CALL 200$ ;;;ISSUE WRITE AND WAIT -1015,1017,/;MSH113/ ADD #<1024.*4*2>,@#UBMPR+4;;;BUMP ADDRESS OF UMR BY ADC @#UBMPR+6 ;;; 4K WORDS MOV #20000,2(R4) ;;;REINITIALIZE POINTER WITHIN 4K ;;; WINDOW TO START OF UMR 1 -1019,1029,/;MSH059/ BNE 40$ ;;;IF NE BLOCK LIMIT NOT REACHED .IFTF ; ; NOTE THAT THE FOLLOWING BRANCH IS NEVER TAKEN IF 180$ IS FALLEN ; INTO (R5 IS NEVER EQUAL TO R4, BECAUSE R5 IS A RETRY COUNT AND ; R4 IS AN ADDRESS, UNLESS 180$ IS BRANCHED TO FROM BELOW). ; 180$: CMP R4,R5 ;;;IS TS11 BEING INITIALIZED BEQ 280$ ;;;IE EQ YES, ERROR EXIT MOV #100011,(R4) ;;;WANT TO FORMAT (WRITE TAPE MARK) MOV R4,(R1) ;;;ISSUE COMMAND 190$: TSTB (R0) ;;;SUBSYSTEM READY? BPL 190$ ;;;IF PL NO BR $CRCMP ;;;SUCCESSFUL TERMINATION 200$: ;;;REF LABEL .IFT MOV R3,-(SP) ;;;SAVE BLOCK COUNTER .IFTF 210$: MOV R4,(R1) ;;;ISSUE COMMAND -1032,1032,/;MSH059/ MOV (R0),R3 ;;;GET STATUS C-6 CDA AND RELATED PATCHES CRASH.COR -1033,,/;MSH059/ .IFT MOV (SP)+,R3 ;;;RESTORE BLOCK COUNTER .ENDC BIC #1000,(R4) ;;;CLEAR WRITE DATA RETRY BIT -1037,1056,/;MSH059/ BNE 180$ ;;;IS NE YES BIT #4000,R3 ;;;NONEXISTANT MEMORY BNE 180$ ;;;IF NE YES BIC #^C<16>,R3 ;;;ISOLATE TERMINATION CODE CMP #12,R3 ;;;RECOVERABLE ERROR (TAPE NOT MOVE)? BEQ 270$ ;;;IF EQ YES CMP #10,R3 ;;;RECOVERABLE ERROR (TAPE MOVE ONE)? BNE 280$ ;;;IS NE NO, I/O ERROR BIS #1000,(R4) ;;;CHANGE COMMAND TO SPACE REVERSE, ;;; ERASE, WRITE DATA 270$: DEC R5 ;;;EXHAUSTED RETRY COUNT? BNE 210$ ;;;IF NE NO 280$: TST (SP)+ ;;;DISCARD RETURN ADDRESS / C-7 CDA AND RELATED PATCHES CDA.CMD C.3 CDA.CMD ; ; APPLY CDA PATCHES - REFERENCE TO SOFTWARE DISPATCH OR SPR. ; ; CDACLQ MONSANTO 013522 017371 ; PAT CDACLQ .OBJ=CDACLQ .DOB/CS:013522,CDACLQ .POB/CS:017371 ; ; LUDMP SPR 11-29693 006500 022302 ; PAT LUDMP .OBJ=LUDMP .DOB/CS:006500,LUDMP .POB/CS:022302 ; ; TDUMP MONSANTO 073153 012554 ; PAT TDUMP .OBJ=TDUMP .DOB/CS:073154,TDUMP .POB/CS:012554 C-8 CDA AND RELATED PATCHES CDACLQ.PAT C.4 CDACLQ.PAT .TITLE CDACLQ ; ; MODIFICATION: ; ; 2.04A -- PRINT TIME CORRECTLY (MONSANTO PATCH) ; .IDENT /2.04A/ .PSECT .BLK. = . . = .BLK.+1030 CALL PAT1 ;CALL FIRST PATCH NOP ; NOP ; . = .BLK.+1136 CALL PAT2 ;CALL SECOND PATCH .PSECT PAT PAT1: MOV R2,-(SP) ;SAVE R2 MOV $TKPS,R3 ;GET ADDRESS OF TICKS TRAP 0 ;GET TICS PER SECOND MOV R2,R0 ; MOVE TO R0 MOV (SP)+,R2 ;RESTORE R2 RETURN PAT2: CALL $DDIV ;GET NUMBER OF HOURS MOV R0,R4 ;REMANINDER IS MINUTES RETURN .END C-9 CDA AND RELATED PATCHES LUDMP.COR C.5 LUDMP.COR .TITLE LUDMP ; ; MODIFICATIONS: ; ; 0104A -- CHECK FOR FILES-11 DEVICE BEFORE ACCESSING FCB ; .IDENT /0104A/ .PSECT .BLK. = . . = .BLK.+4 NOWIND: . = .BLK.+14 UCBADR: . = .BLK.+1036 CALL PAT1 ;CALL PATCH 1 BCS 10$ ; IF CS, DONE WITH LUN . = .BLK.+1250 10$: . = .BLK. .PSECT PAT1 PAT1: MOV #NOWIND,R1 ;ASSUME NO WINDOW MOV R2,R4 ;GET WINDOW ADDRESS MOV UCBADR,R5 ;GET UCB ADDRESS BEQ 10$ ; IF EQ, IT IS UNASSIGNED 5$: MOV R5,R3 ;COPY UCB ADDRESS ADD #2,R3 ;POINT TO REDIRECT POINTER TRAP 0 ;GET IT CMP R2,R5 ;END OF REDIRECT CHAIN? BEQ 7$ ; IF EQ - YES MOV R2,R5 ;GET NEXT UCB ADDRESS IN CHAIN BR 5$ ; AND LOOP 7$: MOV R5,UCBADR ;SAVE UCB ADDRESS MOV R5,R3 ;COPY UCB ADDRESS ADD #10,R3 ;POINT TO DEVICE CHAR. TRAP 0 ;GET IT BIC #007727,R2 ;ISOLATE DESIRED BITS CMP #140010,R2 ;IS DEVICE NOT FILES-11 BNE 10$ ;IF NE, YES, DONE WITH LUN MOV R5,R3 ;COPY UCB ADDRESS ADD #5,R3 ;POINT TO STATUS BYTE C-10 CDA AND RELATED PATCHES LUDMP.COR TRAP 0 ;GET IT BITB #140,R2 ;IS DEV NOT MOUNTED OR FOREIGN BNE 10$ ; IF NE, YES, DONE WITH LUN CLC ;SET FILES-11 FLAG BR 20$ ; 10$: SEC ;SET NON FILES-11 FLAG 20$: RETURN ; .END C-11 CDA AND RELATED PATCHES TDUMP.PAT C.6 TDUMP.PAT .TITLE TDUMP ; ; MODIFICATION: ; ; 0115A -- OUTPUT PRE-AST STATUS CORRECTLY (MONSANTO PATCH) ; .IDENT /0115A/ .PSECT .BLK. = . . = .BLK.+176 .RAD50 /STP/ . = .BLK.+202 .RAD50 /SPN/ . = .BLK.+206 .RAD50 /WFR/ .WORD 0 . = .BLK.+4414 CALL .GTSTS ;CALL CONVERSION (RAD50) .END C-12 APPENDIX D RSX-11M DATA STRUCTURES D-1 APPENDIX D DATA STRUCTURES This sections is a reference guide to the RSX-11M data structures. The section includes information on the system database (SYSCM), executive pool structures, Files-11, task images, FCS, and DECNET (phase II). Each data structure is diagramed and all defined symbolics are listed. Also, there is a brief verbal description of the major function of the structure, how and when the structure is created and destroyed, and the major method used to address and link the structure. Finally, there are list of all references from the structure to others and all refernces in other structures to this type of structure. D-1 DATA STRUCTURES SYSCM D.1 SYSCM The module SYSCM is the RSX-11M executive data base. Included in it are all of the listheads for the major executive data structures, the time-of-day and date fields, and executive status words. The following diagram show the format of SYSCM for a mapped system with all conditionals set on. Macro: none CDA Switch: /SYS Size: variable $CMBEG |===============================| 00 | Current Task Header | $HEADR |-------------------------------| 02 | Cur Task Pri | 0 | $CURPR |-------------------------------| 04 | | $COMEF |--- Global Event Flags ---| 06 | | |-------------------------------| 10 | System Baselevel | $SYSID |--- ---| 12 | (ASCII) | |-------------------------------| 14 | Pointer to TKTN TCB | $TKNPT |-------------------------------| 16 | Pointer to Shuffler TCB | $SHFPT |-------------------------------| 20 | Address of Clock Count Reg. | $CKCNT |-------------------------------| 22 | Address of Clock CSR Reg. | $CKCSR |-------------------------------| 24 | Clock Load Count | $CLLDC |-------------------------------| 26 | System UIC (/SYSUIC) | $SYUIC |-------------------------------| 30 | 0 | |-------------------------------| 32 | Top of Executive | $EXSIZ |-------------------------------| 34 | Power Recovery Request Flag | $PWRFL |-------------------------------| 36 | Task Waiting for SIG Event | $SIGFL |-------------------------------| (continued on next page) D-2 DATA STRUCTURES SYSCM SYSCM (continued) |-------------------------------| 40 | LCB Listhead | $LOGHD |-------------------------------| 42 | MCR Command Buffer Listhead | $MCRCB |-------------------------------| 44 | Lock Word | $LSTLK |-------------------------------| 46 | Pool Allocation Constant (3) | |-------------------------------| 50 | First Free Pool Node | $CRAVL |-------------------------------| 52 | 0 | |-------------------------------| 54 | Active Task Listhead | $ACTHD |-------------------------------| 56 | Absolute Time Counter | $ABTIM |-------------------------------| 60 | Current Task TCB | $TKTCB |-------------------------------| 62 | Schedule Request TCB | $RQSCH |-------------------------------| 64 | Stack Depth | $STKDP |-------------------------------| 66 | DCB Listhead | $DEVHD |-------------------------------| 70 | Pointer to MCR TCB | $MCRPT M$$CLI >>>>>>>>>|-------------------------------| v 72 | | v |--- ---| v 74 | | v |--- MCR Prompt String ---| v 76 | (ASCIZ) | v |--- ---| v 100 | | >>>>>>>>>>>>>>|-------------------------------| 102 | Pointer to Error Logger TCB | $ERRPT |-------------------------------| 104 | Checkpoint File PCB Listhead | $CFLPT |-------------------------------| 106 | Clock Fork Block Link | |-------------------------------| 110 | Clock Fork Block PC | |-------------------------------| 112 | Clock Ticks Count | $INTCT |-------------------------------| (continued on next page) D-3 DATA STRUCTURES SYSCM SYSCM (continued) |-------------------------------| 114 | | $FRKHF |--- Fork Queue Listhead ---| 116 | | |-------------------------------| 120 | Feature Test Masks | $FMASK |-------------------------------| 122 | Parity Address Vector Table | $PARPT |-------------------------------| 124 | Clock Queue Listhead | $CLKHD |-------------------------------| 126 | CO: Output UCB | $COPT |-------------------------------| 130 | PCB Listhead | $PARHD |-------------------------------| 132 | Pointer to LDR... TCB | $LDRPT |-------------------------------| 134 | TCB Listhead | $TSKHD |-------------------------------| 136 | Group Global Event Flags List | $GGEF |-------------------------------| 140 | Idle Patterm Flag/Count | $IDLCT $IDLFL |-------------------------------| 142 | Idle Pattern | $IDLPT |-------------------------------| 144 | FEB | MAR | $DYPMN |--- | ---| 146 | APR | MAY | |--- | ---| 150 | JUN | JUL | |--- Days/Month ---| 152 | AUG | SEP | |--- | ---| 154 | OCT | NOV | |--- | ---| 156 | DEC | JAN | |-------------------------------| (continued on next page) D-4 DATA STRUCTURES SYSCM SYSCM (continued) |-------------------------------| 160 | 1 | $BTMSK |--- ---| 162 | 2 | |--- ---| 164 | 4 | |--- ---| 166 | 10 | |--- ---| 170 | 20 | |--- ---| 172 | 40 | |--- ---| 174 | 100 | |--- ---| 176 | 200 | |--- ---| 200 | 400 | |--- ---| 202 | 1000 | |--- ---| 204 | 2000 | |--- ---| 206 | 4000 | |--- ---| 210 | 10000 | |--- ---| 212 | 20000 | |--- ---| 214 | 40000 | |--- ---| 216 | 100000 | E$$DVC >>>>>>>>>|-------------------------------| v 220 | | $ERRHD v |--- EMB Listhead ---| v 222 | | v |-------------------------------| v 224 | Limit on Resident Data | $ERRLM v |-------------------------------| v 226 | Error Sequence Number | $ERRSQ v |-------------------------------| v 230 | Pointer to Error File Block | $ERRSV v |-------------------------------| v 232 | Size of Resident EMB's | $ERRSZ v |-------------------------------| v 234 | Device I/O Active Bitmap | $IOABM >>>>>>>>>>>>>>|-------------------------------| (continued on next page) D-5 DATA STRUCTURES SYSCM SYSCM (continued) |-------------------------------| 236 | Size of Memory (32W blocks) | $SYSIZ |-------------------------------| 240 | (high byte) | Disk Unit # | | ----------------| 242 | LBN of Saved Image | |-------------------------------| 244 | Load Device Name (ASCII) | |-------------------------------| 246 | Size of Load Image (32W) | |-------------------------------| 250 | Years/Universe | |-------------------------------| 252 | Months/Year | |-------------------------------| 254 | Days/Month | |-------------------------------| 256 | Hours/Day | |-------------------------------| 260 | Minutes/Hour | |-------------------------------| 262 | Seconds/Minute | |-------------------------------| 264 | Ticks/Second | $TKPS |-------------------------------| 266 | Year of Universe | |-------------------------------| 270 | Month of Year | |-------------------------------| 272 | Day of Month | |-------------------------------| 274 | Hour of Day | |-------------------------------| 276 | Minute of Hour | |-------------------------------| 300 | Second of Minute | |-------------------------------| 302 | Tick of Second | $TTNS Q$$OPT >>>>>>>>>|-------------------------------| v 304 | Pointer to Free I/O Packets | $PKAVL v |-------------------------------| v 306 | Max # | Current # | $PKNUM $PKMAX >>>>>>>>>>>>>>|-------------------------------| (continued on next page) D-6 DATA STRUCTURES SYSCM SYSCM (continued) E$$XPR >>>>>>>>>|-------------------------------| v 310 | Maximum Extend Size | $MXEXT M$$EXT >>>>>>>>>|-------------------------------| v 312 | Mapping Assignment Listhead | $UMRHD v |-------------------------------| v 314 | Address of First Assigned UMR | v |-------------------------------| v 316 | # Statically Allocated UMR's | v |-------------------------------| v 320 | | $UMRWT v |--- UMR Wait Queue Listhead ---| v 322 | | T$$CPW >>>>>>>>>|-------------------------------| v 324 | Temp Storage for $GSPKT | $TEMP2 P$$OFF >>>>>>>>>|-------------------------------| v 326 | | $TEMP0 v |--- Temp Storage for Spawn ---| v 330 | | $TEMP1 >>>>>>>>>>>>>>|-------------------------------| 332 | Temp Storage of DIC | $DICSV |-------------------------------| 334 | Mounted Device Listhead | $MOULS |-------------------------------| 346 | | Context Dis. | $CXDBL |===============================| 350 $CMFIN D-7 DATA STRUCTURES TCB D.2 TCB The TCB (Task Control Block) is the primary task data structure. TCB's are always located in system pool. They are created by INS and destroyed when a task is removed. Also, TCB's are created by MCR when using the RUN $filename command. The TCB's are chained together using the T.TCBL word. The chain header is $TSKHD which is located in SYSCM. Also, the currently active tasks are threaded together using the T.ACTL offset. This chain header is $ACTHD in SYSCM. TCB References: o (T.CPCB) Checkpoint PCB o (T.CPCB) Interrupt transfer blocks (connect-to-interrupt) o (T.RCVL) Send/Receive messages queued to task o (T.RCVL) I/O packets queued to ACP's o (T.ASTL) AST control clocks queued to task o (T.UCB ) UCB of TI: terminal o (T.TCBL) TCB of next installed task o (T.LDV ) UCB of load device o (T.PCB ) PCB of task partition o (T.ACTL) TCB of next active task o (T.SAST) Specified AST control block list o (T.ATT ) Attachment descriptors for task o (T.RRFL) Receive-By-Reference messages queued to task o (T.OCBH) OCB chain for this task References to TCB's o ($TKNPT) TKTN TCB address o ($SHFPT) Shuffler TCB address o ($ACTHD) First TCB in active task list o ($TKTCB) Current active TCB o ($RQSCH) TCB requesting scheduling o ($MCRPT) MCR TCB address o ($ERRPT) Error Logger TCB address o ($TSKHD) First TCB in installed task list o (O.PTCB) OCB, parent task TCB o (P.TCB ) PCB, owner task TCB o (A.TCB ) Attachment descriptor, attached task TCB o (C.TCB ) Clock queue, TCB of task to request is for o (I.TCB ) I/O packet, issueing task TCB o (X.TCB ) ITB, owning task TCB o (U.ACP ) UCB, ACP TCB address D-8 DATA STRUCTURES TCB TCB Macro: TCBDF$ CDA Switch: /ACT /STD Size: 100 bytes (32 words) w/PLAS, OCB 72 bytes (28 words) w/PLAS only 56 bytes (23 words) no options |===============================| 00 | Utility Link Word | T.LNK |-------------------------------| 02 | I/O Count | Task Priority | T.PRI T.IOC |-------------------------------| 04 | Checkpoint PCB/ITB Listhead | T.CPCB |-------------------------------| 06 | | T.NAM |--- Task Name (RAD50) ---| 10 | | |-------------------------------| 12 | | T.RCVL |--- Receive Queue Listhead ---| 14 | | |-------------------------------| 16 | | T.ASTL |--- AST Queue Listhead ---| 20 | | |-------------------------------| 22 | | T.EFLG |--- Local Event Flags ---| 24 | | |-------------------------------| 26 | TI: UCB Address | T.UCB |-------------------------------| 30 | Link to Next Installed Task | T.TCBL |-------------------------------| 32 | Status (Blocking Bits) | T.STAT |-------------------------------| 34 | Status (Status Bits) | T.ST2 |-------------------------------| 36 | Status (Attribute Bits) | T.ST3 |-------------------------------| 40 | (High Byte) | Default Pri. | T.DPRI D.LBN | ----------------| 42 | Block Number of Load Image | |-------------------------------| 44 | Load Device UCB Address | T.LDV |-------------------------------| 46 | PCB Address | T.PCB |-------------------------------| 50 | Maximum Task Image Size | T.MXSZ |-------------------------------| continued on next page D-9 DATA STRUCTURES TCB TCB (continued) |-------------------------------| 52 | Link to Next Active Task | T.ACTL |-------------------------------| 54 | Specified AST Listhead | T.SAST P$$LAS >>>>>>>>>|-------------------------------| v 56 | Attachment Descriptor | T.ATT v |--- ---| v 60 | Listhead | v |-------------------------------| v 62 | Partition Offset to Task | T.OFF v |-------------------------------| v 64 | SREF Count | | T.SRCT v |-------------------------------| v 66 | Receive-by-Reference | T.RRFL v |--- ---| v 70 | Listhead | P$$OFF >>>>>>>>>|-------------------------------| v 72 | Offspring Control Block | T.OCBH v |--- ---| v 74 | Listhead | v |-------------------------------| v 76 | Outstanding Offspring Count | T.RDCT >>>>>>>>>>>>>>|===============================| 100 T.LGTH T.STS Bit Masks TS.EXE 100000 Task not in execution (1=yes) TS.RDN 40000 I/O rundown in progress (1=yes) TS.MSG 20000 Abort message being output (1=yes) TS.NRP 10000 Task mapped to nonresident partition (1=yes) TS.RUN 4000 Task running on another processor (1=yes) TS.OUT 400 Task is out of memory (1=yes) TS.CKP 200 Task is checkpointed (1=yes) TS.CKR 100 Task is request to be checkpointed (1=yes) D-10 DATA STRUCTURES TCB T.ST2 Bit Masks T2.AST 100000 AST in progress (1=yes) T2.DST 40000 AST recognition disabled (1=yes) T2.CHK 20000 Task is not checkpointable (1=yes) T2.CKD 10000 Checkpointing disabled (1=yes) T2.SEF 4000 Task stopped for event flags (1=yes) T2.FXD 2000 Task fixed in memory (1=yes) T2.TIO 1000 Task is engaged in terminal I/O (1=yes) T2.CAF 400 Dynamic checkpoint allocation failed (1=yes) T2.HLT 200 Task is being halted (exiting) (1=yes) T2.ABO 100 Task is marked for abort (1=yes) 40 Saved T2.STP during AST T2.STP 20 Task stopped (1=yes) 10 Saved T2.SPN during AST T2.SPN 4 Task suspended (1=yes) 2 Saved T2.WFR during AST T2.WFR 1 Task is in waitfor state (1=yes) T.ST3 Bit Masks T3.ACP 100000 Task is an ACP (/AC) (1=yes) T3.PMD 40000 Dump task with PMD on abort (0=yes) T3.REM 20000 Remove task on exit (1=yes) T3.PRV 10000 Task is privileged (/PR) (1=yes) T3.MCR 4000 Task requested as external MCR function (1=yes) T3.SLV 2000 Task is a slave task (/SL) (1=yes) T3.CLI 1000 Task is a command line interpreter (1=yes) T3.RST 400 Task is restricted (1=yes) T3.NSD 200 Task does not allow send data (/-SE) (1=yes) T3.CAL 100 Task has checkpoint space in task image (1=yes) T3.ROV 40 Task has resident overlays (1=yes) T3.NET 20 Network protocol level D-11 DATA STRUCTURES OCB D.3 OCB OCB's (Offspring Control Blocks) are used for task spawning. An OCB is created whenever a parent spawns or connects to a child task. The OCB's are destroyed whenever the parent or the child task exits. OCB's are link to the spawned (child) task and not the parent. All OCB's for a task are linked together using the O.LNK word. The listhead pointer is in the spawned task TCB at T.OCBH. OCB References: o (O.LNK ) Next OCB for the task o (O.MCRL) MCR command line (from spawn directive) o (O.PTCB) Parent task TCB References to OCB's: o (T.OCBH) TCB, listhead for OCB chain Macro: PKTDF$ CDA Switch: none Size: 34 bytes (14 words) |===============================| 00 | OCB Link Word | O.LNK |-------------------------------| 02 | MCR Command Line Address | O.MCRL |-------------------------------| 04 | Parent Task TCB Address | O.PTCB |-------------------------------| 06 | Exit AST Address | O.AST |-------------------------------| 10 | Exit Event Flag Number | O.EFN |-------------------------------| 12 | Exit Block Virtual Address | O.ESB |-------------------------------| 14 | | O.STAT |--- ---| 16 | | |--- ---| 20 | | |--- ---| 22 | | |--- Exit Status Buffer ---| 24 | | |--- ---| 26 | | |--- ---| 30 | | |--- ---| 32 | | |===============================| 34 O.LGTH D-12 DATA STRUCTURES AST CONTROL BLOCK D.4 AST CONTROL BLOCK AST Control Blocks are used to declare AST's to a task. The control blocks are always preallocated and come from the system pool. For the specified AST's (Receive AST, Receive-By-Reference, FPP AST, and Powerfail), one AST control block is allocated and linked to the task through the T.SAST offset in the TCB. For other AST's, the executive reuses the associated data structure as the AST Control Block. For QIO AST's, this is the I/O Packet. Similarly, mark time AST's use the clock queue entry and spawned task AST's use the OCB. Finally, terminal I/O uses a special structure from the driver pool for unsolicited character AST's. AST's which are pending for a task are queued together. The listhead is T.ASTL in the TCB. The specified AST's are queued together through the T.SAST offset in the TCB. Note, these are not pending. AST Control Blocks do not reference other data structures. They are linked together using the first word. The A.CBL word determines the type and length of the AST Control Block. This word is coded as follows: o If A.CBL = 0, the AST Control Block is to be deallocated by the dequeue subroutine pointed to A.DQSR and mapped via the APR5 value in A.KSR5. This is current only used by the full-duplex terminal driver for unsolicited character AST's. o If the low byte of A.CBL is 0 and the high byte is non-zero, then the AST is a speciable AST. The high byte is the type code and the AST Control Block as a length of C.LGTH (clock queue). AS.FPA 1 FPP AST AS.RCA 2 Receive AST AS.RRA 3 Receive-by-Reference AST AS.PFA 4 Powerfail AST o If the high byte of A.CBL is 0 and the low byte is positive, then the low byte is the size of the AST Control Block. o If the high byte of A.CBL is 0 and the low byte is 200, the AST Control Block is for buffered I/O completion and has a length of I.LGTH. o If the high byte of A.CBL is 0 and the low byte is 300, the AST Control Block is an OCB and has a length of O.LGTH. D-13 DATA STRUCTURES AST CONTROL BLOCK AST Control Block Macro: PKTDF$ CDA Switch: /ACT Size: variable (see A.CBL) |===============================| -4 | Subroutine APR5 Bias | A.KSR5 |-------------------------------| -2 | Dequeue Subroutine Address | A.DQSR |-------------------------------| 00 | Link to Next AST Block | |-------------------------------| 02 | AST Control Block Length/Type | A.CBL |-------------------------------| 04 | # of Bytes for Task Stack | A.BYT |-------------------------------| 06 | AST Trap Address | A.AST |-------------------------------| 10 | # of AST Parameters | A.NPR |-------------------------------| 12 | First AST Parameter | A.PRM |-------------------------------| 14 . . . (Rest of Block) . . D-14 DATA STRUCTURES SEND/RECEIVE PACKET D.5 SEND/RECEIVE PACKET Send/Receive Packets are used to send messages between tasks. They are created in system pool when a SEND$ directive is issued and destroyed when the receiving task exits or receives them. Send/Receive Packets are linked together thought word 0 and to the receiving task at T.RCVL in the TCB. Macro: none CDA Switch: /ACT Size: 44 bytes (18 words) |===============================| 00 | Link to Next S/R Packet | |-------------------------------| 02 | | |--- Sender Task Name ---| 04 | | |-------------------------------| 06 | | |--- ---| 10 | | |--- ---| 12 | | |--- ---| 14 | | |--- ---| 16 | | |--- ---| 20 | | |--- ---| 22 | Send Data Message | |--- ---| 24 | | |--- ---| 26 | | |--- ---| 30 | | |--- ---| 32 | | |--- ---| 34 | | |--- ---| 36 | | |-------------------------------| 40 | Sender TI: UCB Address | |-------------------------------| 42 | Sender Current UIC | |===============================| 44 I.LGTH D-15 DATA STRUCTURES RECEIVE-BY-REFERENCE PACKET D.6 RECEIVE-BY-REFERENCE PACKET Receive-by-reference packets are used to send messages between tasks. They are created in system pool when a SREF$ directive is issued and destroyed when the receiving task exits or receives them. Receive-by-reference packets are linked together thought word 0 and to the receiving task at T.RRFL in the TCB. Macro: none CDA Switch: /ACT Size: 44 bytes (18 words) |===============================| 00 | Link to Next R-by-R Packet | |-------------------------------| 02 | TCB Address/0 if no EFN | |-------------------------------| 04 | EFN Mask/Sender Task Name | |-------------------------------| 06 | EFN Address/Sender Task Name | |-------------------------------| 10 | Region Attachment Descriptor | |-------------------------------| 12 | Region Offset | |-------------------------------| 14 | Region Size | |-------------------------------| 16 | Access Status | |-------------------------------| 20 | | |--- ---| 22 | | |--- ---| 24 | | |--- ---| 26 | | |--- Optional Data Message ---| 30 | | |--- ---| 32 | | |--- ---| 34 | | |--- ---| 36 | | |-------------------------------| 40 | | |-------------------------------| 42 | | |===============================| 44 I.LGTH D-16 DATA STRUCTURES GROUP GLOBAL EVENT FLAGS D.7 GROUP GLOBAL EVENT FLAGS Group global event flags are an extension to the event flags that allow each UIC group to have global event flags (65-96). The is one control block for each UIC group. The control blocks are created and dstroyed using directives. The group global event flags are linked together using offset G.LNK. The listhead pointer is $GGEF in module SYSCM. They do not reference any other structures. Macro: PKTDF$ CDA Switch: none Size: 12 bytes (5 words) |===============================| 00 | Link to Next Block | G.LNK |-------------------------------| 02 | Status | Group Number | G.GRP G.STAT |-------------------------------| 04 | Access Count | G.CNT |-------------------------------| 06 | | G.EFLG |--- Event Flags ---| 10 | | |===============================| 12 D-17 DATA STRUCTURES TASK HEADER D.8 TASK HEADER Task headers hold the initial and current context of a task. Task Headers are always located in system pool and are created whenever a task is loaded into memory. The task headers are destroyed whenever the task exits or is checkpointed. Task headers are not linked together. The address of the task header for the task current executing in a partition is stored offset P.PCB of the PCB. Task Header References: o (H.PFVA) Powerfail AST Control Block o (H.FPVA) FPP AST Control Block o (H.RCVA) Receive AST Control Block o (H.FCS ) FCS impure area o (H.FORT) Fortran impure area o (H.OVLY) Overlay impure area o (H.VEXT) Work area extension vector o UCB address of assigned devices o Window blocks o (W.BATT) Attachment decsriptors References to Task Headers: o ($HEADR) Current task header o (P.HDR ) PCB, current task header D-18 DATA STRUCTURES TASK HEADER Task Header Macro: TCBDF$ CDA Switch: /HDR Size: Variable (see H.HDLN) |===============================| 00 | Current Stack Pointer | H.CSP |-------------------------------| 02 | Header Length (bytes) | H.HDLN |-------------------------------| 04 | Event Flag Mask Word | H.EFLM |--- ---| 06 | Event Flag Mask Address | |-------------------------------| 10 | Current Task UIC | H.CUIC |-------------------------------| 12 | Default Task UIC | H.DUIC |-------------------------------| 14 | Initial PS | H.IPS |-------------------------------| 16 | Initial PC | H.IPC |-------------------------------| 20 | Initial SP | H.ISP |-------------------------------| 22 | Debugging SST Vector Address | H.ODVA |-------------------------------| 24 | Debugging SST Vector Length | H.ODVL |-------------------------------| 26 | Task SST Vector Address | H.TKVA |-------------------------------| 30 | Task SST Vector Length | H.TKVL |-------------------------------| 32 | Powerfail AST Control Block | H.PFVA |-------------------------------| 34 | FPP AST Control Block | H.FPVA |-------------------------------| 36 | Receive AST Control Block | H.RCVA |-------------------------------| 40 | Event Flag Save Address | H.EFSV |-------------------------------| 42 | Pointer to FPP/EAE Save Area | H.FPSA |-------------------------------| 44 | Pointer to Start of Windows | H.WND |-------------------------------| 46 | Task Directive Status ($DSW) | H.DSW |-------------------------------| 50 | FCS Impure Area Pointer | H.FCS |-------------------------------| continued on next page D-19 DATA STRUCTURES TASK HEADER Task Header (continued) |-------------------------------| 52 | Fortran OTS Impure Pointer | H.FORT |-------------------------------| 54 | Overlay Impure Area Pointer | H.OVLY |-------------------------------| 56 | Work Area Extension Pointer | H.VEXT |-------------------------------| 60 | Mailbox LUN | Swapping Pri. | H.SPRI H.NML |-------------------------------| 62 | Rec/Ref AST Control Block | H.RRVA |-------------------------------| 64 | | |-------------------------------| 66 | | |-------------------------------| 70 | | |-------------------------------| 72 | Pointer to Header Guard Word | H.GARD |-------------------------------| 74 | Number of LUN's | H.NLUN |-------------------------------| 76 | LUN 1 UCB Address | H.LUN |-------------------------------| 100 | LUN 1 Window Block |L| |-------------------------------| . . . (Lun Table) . . continued on next page D-20 DATA STRUCTURES TASK HEADER Task Header (continued) |-------------------------------| | Number of Window Blocks | |-------------------------------| | PCB Address | W.BPCB |-------------------------------| | Low Virtual Address Limit | W.BLVR |-------------------------------| | Hish Virtual Address Limit | W.BHVR |-------------------------------| | Attachment Descriptor Address | W.BATT |-------------------------------| | Size of Window (32W Blocks) | W.BSIZ |-------------------------------| | Physical Memory Offset (32W) | W.BOFF |-------------------------------| | Number PDR's | First PDR | W.BFPD W.BNPD |-------------------------------| | Contents of Last PDR | W.BLPD |-------------------------------| . W.LGTH . . (Window Blocks) . . |-------------------------------| | Current PS | |-------------------------------| | Current PC | |-------------------------------| | Current R5 | |-------------------------------| | Current R4 | |-------------------------------| | Current R3 | |-------------------------------| | Current R2 | |-------------------------------| | Current R1 | |-------------------------------| | Current R0 | |-------------------------------| | Header Guard Word | |===============================| D-21 DATA STRUCTURES PCB D.9 PCB PCB's (Partition Control Blocks) are the main RSX-11M data structure for defining memory. The is one PCB for every entity loaded into memory (except for the executive). Empty space in a partition is indicated by the gap between two PCB's. PCB's are created in many areas, for example, by MCR when defining partitions or by the executive when loading a task into a system partition. All main PCB's are linked together using the P.LNK offset in the PCB. The chain listhead is $PARHD in module SYSCM. Subpartition PCB's are chained together using the P.SUB offset. The chain header is P.SUB in the main partition PCB. PCB References: o (P.LNK ) Next main partition PCB o (P.SUB ) Next subpartition PCB o (P.MAIN) Main partition PCB for this subpartition o (P.WAIT) TCB's waiting for load into partition o (P.TCB ) TCB of task currently loaded in partition o (P.HDR ) Task Header of task currently loaded in partition o (P.ATT ) Attachment Descriptors for task attach to partition References to PCB's o ($PARHD) PCB chain listhead o (T.PCB ) Task PCB address o (A.PCB ) Attachment descriptor, PCB of owning task o (D.PCB ) DCB, device driver PCB D-22 DATA STRUCTURES PCB PCB Macro: PCBDF$ CDA Switch: /PAR Size: 42 bytes (17 words) w/ PLAS 34 bytes (14 words) w/o PLAS |===============================| 00 | Link to Next PCB | P.LNK |-------------------------------| 02 | I/O Count | Priority | P.PRI P.IOC |-------------------------------| 04 | | P.NAM |--- Partition Name (RAD50) ---| 06 | | |-------------------------------| 10 | Pointer to Next Subpartition | P.SUB |-------------------------------| 12 | Pointer to Main Partition PCB | P.MAIN |-------------------------------| 14 | Starting Physical Address | P.REL |-------------------------------| 16 | Size of Partition (32W) | P.SIZE |-------------------------------| 20 | Partition Wait Queue Listhead | P.WAIT |-------------------------------| 22 | Partition Swap Size | P.SWSZ |-------------------------------| 24 | Partition Busy Flags | P.BUSY |-------------------------------| 26 | TCB Address of Owner Task | P.TCB |-------------------------------| 30 | Partition Status Flags | P.STAT |-------------------------------| 32 | Address of Task Header | P.HDR P$$LAS >>>>>>>>>|-------------------------------| v 34 | Protection Word | P.PRO v |-------------------------------| v 36 | Attachment Descriptor | P.ATT v |--- ---| v 40 | Listhead | >>>>>>>>>>>>>>|===============================| 42 P.LGTH D-23 DATA STRUCTURES PCB P.STAT Masks PS.OUT 100000 Partition is out of memory (1=yes) PS.CKP 40000 Partition checkpoint in progress (1=yes) PS.CKR 20000 Partition checkpoint requested (1=yes) PS.CHK 10000 Partition is not checkpointable (1=yes) PS.FXD 4000 Partition is fixed (1=yes) PS.PER 2000 Parity error in partition (1=yes) PS.LIO 1000 Partition marked by SHF for long I/O (1=yes) PS.NSF 400 Partition is non shuffleable (1=yes) PS.COM 200 Library or common block (1=yes) PS.PIC 100 Position independent library or common (1=yes) PS.SYS 40 System-controlled partition (1=yes) PS.DRV 20 Device Driver loaded in partition (1=yes) PS.DEL 10 Delete partition when not attached (1=yes) PS.APR 7 Starting APR number D-24 DATA STRUCTURES ATTACHMENT DESCRIPTOR D.10 ATTACHMENT DESCRIPTOR Attachment descriptors are used to map partitions and the tasks which are attached to them. In particular, attachment descriptors map dynamic regions and task which reference them using the PLAS directives. Attachment descriptors are linked with two separate threads. The first is all attachment descriptors for the partition. This thread uses offset A.PCBL and the listhead is P.ATT in the PCB. The second is all attachment descriptors for a task. This thread uses offset A.TCBL and the listhead is T.ATT in the PCB. Attachment Descriptor References: o (A.PCBL) Next attachment descriptor in the PCB chain o (A.TCB ) TCB address of owning task o (A.TCBL) Next attachment descriptor in the TCB chain o (A.PCB ) PCB address of owning task References to Attachment Descriptors: o (T.ATT ) TCB, first attachment descriptor for task o Receive-by-reference, attachment descriptor for region o (W.BATT) Task header, window block attachment descriptor o (P.ATT ) PCB, first attachment descriptor for partition Macro: PCBDF$ CDA Switch: /PAR Size: 14 bytes (6 words) |===============================| 00 | PCB Attachment Thread Word | A.PCBL |-------------------------------| 02 | I/O Count | Priority | A.PRI A.IOC |-------------------------------| 04 | TCB Address of Attached Task | A.TCB |-------------------------------| 06 | TCB Attachment Thread Word | A.TCBL |-------------------------------| 10 | Mapping Count | Status | A.STAT A.MPCT |-------------------------------| 12 | PCB Address of Attached Task | A.PCB |===============================| 14 A.LGTH A.STAT Masks AS.DEL 10 Task has deleted access (1=yes) AS.EXT 4 Task has extend access (1=yes) AS.WRT 2 Task has write access (1=yes) AS.RED 1 Task has read access (1=yes) D-25 DATA STRUCTURES CLOCK QUEUE D.11 CLOCK QUEUE The Clock Queue is used for all time-related events. The queue entries take a variety of formats, depending on the type of entry: mark-time, single-shot scheduling request, periodic scheduling request, or internal system request. All Clock Queue entries are threaded together using the C.LNK offset. The listhead is $CLKHD in module SYSCM. The entries are ordered by the time they come due. Clock Queue References: o (C.LNK ) Next Clock Queue entry o (C.TCB ) TCB address References to Clock Queue: o ($CLKHD) Clock Queue listhead D-26 DATA STRUCTURES CLOCK QUEUE Clock Queue (Mark Time) Macro: CLKDF$ CDA Switch: /CLQ Size: 20 bytes (8 words) |===============================| 00 | Clock Queue Link Word | C.LNK |-------------------------------| 02 | Event Flag | Type (0) | C.RQT C.EFN |-------------------------------| 04 | TCB Address | C.TCB |-------------------------------| 06 | Absolute Time Request | C.TIM |--- ---| 10 | Becomes Due | |-------------------------------| 12 | Mark Time AST Address | C.AST |-------------------------------| 14 | Event Flag Mask Word | C.SRC |-------------------------------| 16 | Event Flag Mask Address | C.DST |===============================| 20 C.LGTH Clock Queue (Single-Shot Scheduling) Macro: CLKDF$ CDA Switch: /CLQ Size: 20 bytes (8 words) |===============================| 00 | Clock Queue Link Word | C.LNK |-------------------------------| 02 | | Type (4) | C.RQT C.EFN |-------------------------------| 04 | TCB Address | C.TCB |-------------------------------| 06 | Absolute Time Request | C.TIM |--- ---| 10 | Becomes Due | |-------------------------------| 12 | | |-------------------------------| 14 | | |-------------------------------| 16 | Scheduling UIC | C.UIC |===============================| 20 C.LGTH D-27 DATA STRUCTURES CLOCK QUEUE Clock Queue (Periodic Scheduling Request) Macro: CLKDF$ CDA Switch: /CLQ Size: 20 bytes (8 words) |===============================| 00 | Clock Queue Link Word | C.LNK |-------------------------------| 02 | | Type (2) | C.RQT C.EFN |-------------------------------| 04 | TCB Address | C.TCB |-------------------------------| 06 | Absolute Time Request | C.TIM |--- ---| 10 | Becomes Due | |-------------------------------| 12 | | C.RSI |--- Reschedule Interval ---| 14 | | |-------------------------------| 16 | Scheduling UIC | C.UIC |===============================| 20 C.LGTH Clock Queue (Internal) Macro: CLKDF$ CDA Switch: /CLQ Size: 20 bytes (8 words) |===============================| 00 | Clock Queue Link Word | C.LNK |-------------------------------| 02 | | Type (6/8) | C.RQT C.EFN |-------------------------------| 04 | TCB Address | C.TCB |-------------------------------| 06 | Absolute Time Request | C.TIM |--- ---| 10 | Becomes Due | |-------------------------------| 12 | Subroutine Address | C.SUB |-------------------------------| 14 | APR5 Relocation Base | C.AR5 |-------------------------------| 16 | | |===============================| 20 C.LGTH D-28 DATA STRUCTURES I/O PACKET D.12 I/O PACKET I/O packets are used to move the context of an I/O request from the executive to device drivers and ACP's. An I/O packet is created in the system pool whenever a task issues a QIO or QIOW directive and is destroyed when the I/O request is finished. I/O packets are threaded together using the I.LNK offset. Packets are queued to devices using the S.LHD offset of the SCB. Packets are queued to ACP's using the T.RCVL offset of the ACP TCB. I/O Packet References: o (I.LNK ) Next I/O Packet in queue o (I.TCB ) TCB of issueing task o (I.LN2 ) Second LUN word in task header o (I.UCB ) UCB address of device References to I/O Packets: o (T.RCVL) TCB, Pointer to first I/O packet in ACP queue o (S.LHD ) SCB, Pointer to first I/O packet in device queue o (S.PKT ) SCB, current I/O packet D-29 DATA STRUCTURES I/O PACKET I/O Packet Macro: PKTDF$ CDA Switch: /DEV Size: 44 bytes (18 words) |===============================| 00 | Link to Next I/O Packet | I.LNK |-------------------------------| 02 | Event Flag | Priority | I.PRI I.EFN |-------------------------------| 04 | TCB Address of Issueing Task | I.TCB |-------------------------------| 06 | Pointer to Second Lun Word | I.LN2 |-------------------------------| 10 | UCB Address | I.UCB |-------------------------------| 12 | I/O Function Code | I.FCN |-------------------------------| 14 | I/O Status Virtual Address | I.IOSB |-------------------------------| 16 | I/O Status Relocation Bias | |-------------------------------| 20 | I/O Status Relocation Offset | |-------------------------------| 22 | AST Service Virtual Address | I.AST |-------------------------------| 24 | | I.PRM |--- ---| 26 | | |--- ---| 30 | | |--- ---| 32 | | |--- I/O Parameters ---| 34 | | |--- ---| 36 | | |--- ---| 40 | | |--- ---| 42 | | |===============================| 44 I.LGTH D-30 DATA STRUCTURES LCB D.13 LCB LCB's (Logical Device Assignment Control Block) are used to map logical device names to physical device names. LCB's are located in system pool and are manipulated by the ASN command. LCB's are threaded together using the offset L.LNK. The list header is $LOGHD in module SYSCM. LCB References: o (L.LNK ) Next LCB in chain o (L.UCB ) TI: UCB o (L.ASG ) Phyical device UCB References to LCB's: o ($LOGHD) LCB chain lisheader Macro: LCBDF$ CDA Switch: none Size: 12 bytes (5 words) |===============================| 00 | Link to Next LCB | L.LNK |-------------------------------| 02 | Logical Device Name (ASCII) | L.NAM |-------------------------------| 04 | Global Flag | Logical Unit | L.UNIT L.TYPE |-------------------------------| 06 | TI: UCB Address | L.UCB |-------------------------------| 10 | Physical Device UCB | L.ASG |===============================| 12 L.LGTH D-31 DATA STRUCTURES ITB D.14 ITB ITB's (Interrupt Transfer Blocks) are used to map an interrupt to a loadable driver or connected task. The system uses three types of ITB's: single controller, multiple controller, and connect-to-interrupt. The first two are created by LOA when a loadable device driver is loaded. The last is used by the executive to service the connect-to-interrupt feature. Only connect-to-interrupt ITB's are threaded together using offset X.LNK. The listhead for all ITB's belonging to a task is T.CPCB in the task TCB. ITB (Single Controller) Macro: none CDA Switch: none Size: 34 bytes (14 words) |===============================| 00 | | |--- JSR R5,@#INTSV ---| 02 | | |-------------------------------| 04 | Device Priority | |-------------------------------| 06 | | |--- MOV @#APR5,-(SP) ---| 10 | | |-------------------------------| 12 | | |--- ---| 14 | MOV #mapping,@#APR5 | |--- ---| 16 | | |-------------------------------| 20 | | |--- JSR PC,@#driver entry ---| 22 | | |-------------------------------| 24 | | |--- MOV (SP)+,@#APR5 ---| 26 | | |-------------------------------| 30 | RTS PC | |-------------------------------| 32 | Unused | |===============================| 34 D-32 DATA STRUCTURES ITB ITB (Multiple Controller) Macro: none CDA Switch: none Size: 54 bytes (22 words) |===============================| 00 | | |--- ---| 02 | MOVB @#PS,TEMP | |--- ---| 04 | | |-------------------------------| 06 | | |--- JSR R5,@#INTSV ---| 10 | | |-------------------------------| 12 | Device Priority | |-------------------------------| 14 | | |--- MOV TEMP,R4 ---| 16 | | |-------------------------------| 20 | | |--- BIC #177760,R4 ---| 22 | | |-------------------------------| 24 | ASL R4 | |-------------------------------| 26 | | |--- MOV @#APR5,-(SP) ---| 30 | | |-------------------------------| 32 | | |--- ---| 34 | MOV #mapping,@#APR5 | |--- ---| 36 | | |-------------------------------| 40 | | |--- JSR PC,@#driver entry ---| 42 | | |-------------------------------| 44 | | |--- MOV (SP)+,@#APR5 ---| 46 | | |-------------------------------| 50 | RTS PC | |-------------------------------| 52 | TEMP: | |===============================| 54 D-33 DATA STRUCTURES ITB ITB (Connect-to-Interrupt) Macro: ITBDF$ CDA Switch: none Size: 50 bytes (20 words) |===============================| 00 | Link to Next ITB | X.LNK |-------------------------------| 02 | | X.JSR |--- JSR R5,@#INTSC ---| 04 | | |-------------------------------| 06 | | PSW | X.PSW |-------------------------------| 10 | ISR Entry Point | X.ISR |-------------------------------| 12 | Fork Thread Word | X.FORK |-------------------------------| 14 | Fork PC | |-------------------------------| 16 | Fork R5 | |-------------------------------| 20 | Fork R4 | |-------------------------------| 22 | Relocation Base for APR5 | X.REL |-------------------------------| 24 | Enable/Disable Entry Point | X.DSI |-------------------------------| 26 | TCB of Owning Task | X.TCB |-------------------------------| 30 | AST Dequeue Subroutine | |-------------------------------| 32 | AST Queue Thread Word | X.AST |-------------------------------| 34 | AST Control Word | |-------------------------------| 36 | # of Bytes for Task Stack | |-------------------------------| 40 | AST Trap Address | |-------------------------------| 42 | # of AST Parameters | |-------------------------------| 44 | Vector Address | X.VEC |-------------------------------| 46 | Saved Vector PC | X.VPC |===============================| 50 X.LEN D-34 DATA STRUCTURES DCB D.15 DCB DCB's (Device Control Block) are used to define generic devices. The DCB's are always found in executive space, either SYSTB for resident drivers or system pool for loadable drivers with loadable databases. DCB's are chained together using the D.LNK offset. The listhead pointer is $DEVHD in module SYSCM. DCB References: o (D.LNK ) Next DCB in device chain o (D.UCB ) First UCB of device o (D.DSP ) Device driver dispatch table o (D.PCB ) Device driver PCB address Refereences to DCB's o ($DEVHD) Pointer to first DCB in device chain o (U.DCB ) UCB, pointer to DCB for UCB D-35 DATA STRUCTURES DCB DCB Macro: DCBDF$ CDA Switch: /DEV Size: 34 (14 words) |===============================| 00 | Link to Next DCB | D.LNK |-------------------------------| 02 | First UCB Address | D.UCB |-------------------------------| 04 | Device Name | D.NAM |-------------------------------| 06 | High Unit # | Low Unit # | D.UNIT |-------------------------------| 10 | Length of an UCB | D.UCBL |-------------------------------| 12 | Driver Dispatch Table Address | D.DSP |-------------------------------| 14 | Legal Function Mask (0-15) | D.MSK |-------------------------------| 16 | Control Function Mask (0-15) | |-------------------------------| 20 | NOP'ed Function Mask (0-15) | |-------------------------------| 22 | ACP Function Mask (0-15) | |-------------------------------| 24 | Legal Function Mask (16-31) | |-------------------------------| 26 | Control Function Mask (16-31) | |-------------------------------| 30 | NOP'ed Function Mask (16-31) | |-------------------------------| 32 | ACP Function Mask (16-31) | L$$DRV>>>>>>>>>>|-------------------------------| v 34 | Driver PCB Address | D.PCB >>>>>>>>>>>>>>|===============================| D-36 DATA STRUCTURES UCB D.16 UCB UCB's (Unit Control Block) are the major device-related data structure. The UCB holds all information related to a device unit, there is one UCB for each separate unit. The UCB's belonging to a particular device (DCB) are contigious in memory. The offset D.UCB in the DCB points to the first UCB. UCB References: o (U.CLI ) TCB of CLI o (U.OWN ) UCB of owning TI: o (U.DCB ) DCB of corresponding device o (U.RED ) UCB or redirected device o (U.SCB ) SCB of corresponding device controller References to UCB's: o ($COPT ) UCB address of CO: device o (T.UCB ) TCB, task TI: UCB address o (T.LDV ) TCB, task load device UCB address o S/R message, sending task TI: UCB address o Task header, UCB address of assigned devices o (I.UCB ) I/O packet, UCB address of destination device o (L.ASG ) LCB, UCB address of physical device o (D.UCB ) DCB, address of first UCB o Mounted Volume, TI: UCB address o Mounted Volume, disk UCB address o (V.UCB ) MTAACP VCB, magtape UCB address D-37 DATA STRUCTURES UCB UCB (standard) Macro: UCBDF$ CDA Switch: /DEV Size: variable, see D.UCBL M$$MUP >>>>>>>>>|===============================| v -2 | UCB Address of Owner TT: | U.OWN >>>>>>>>>>>>>>|-------------------------------| 00 | DCB Address | U.DCB |-------------------------------| 02 | Redirect UCB Address | U.RED |-------------------------------| 04 | Unit Status | Control Flags | U.CTL U.STS |-------------------------------| 06 | Unit Status | Unit Number | U.UNIT U.ST2 |-------------------------------| 10 | Characteristics Word #1 | U.CW1 |-------------------------------| 12 | Characteristics Word #2 | U.CW2 |-------------------------------| 14 | Characteristics Word #3 | U.CW3 |-------------------------------| 16 | Characteristics Word #4 | U.CW4 |-------------------------------| 20 | SCB Address | U.SCB |-------------------------------| 22 | TCB of Attached Task | U.ATT |-------------------------------| 24 | | U.BUF |--- Buffer Address ---| 26 | | |-------------------------------| 30 | Byte Count | U.CNT |===============================| U.CTL Masks UC.ALG 200 Byte alignment allowed (0=yes) UC.NPR 100 Device is NPR device (1=yes) UC.QUE 40 Call driver before queueing (1=yes) UC.PWF 20 Call driver always at powerfail (1=yes) UC.ATT 10 Call driver always at attach/detach (1=yes) UC.KIL 4 Call driver always at I/O kill (1=yes) UC.LGH 3 Transfer length mask D-38 DATA STRUCTURES UCB U.STS Masks US.BSY 200 Unit is busy (1=yes) US.MNT 100 Unit is mounted (0=yes) US.FOR 40 Unit is mounted as foreign (1=yes) US.MDM 20 Unit is marked for dismount (1=yes) US.PWF 10 Powerfail occured (1=yes) 4 Device specific 2 Device specific 1 Device specific Card reader specific status bits US.MDE 2 Unit is in 029 translation mode (1=yes) US.ABO 1 Unit is marked for abort if not ready (1=yes) Files-11 specific status bits US.WCK 10 Write check enabled (1=yes) US.SPU 2 Unit is spinning up (1=yes) US.VV 1 Volume valid is set (1=yes) KMC-11-LP specific status bits US.KPF 1 KMC-11 powerfail interlock Full-duplex terminal driver specific status bits US.CRW 4 Unit is waiting for carrier (1=yes) US.DSB 2 Unit is disabled (1=yes) US.OIU 1 Output interrupt is unexpected (1=yes) Half-dupluex terminal driver specific status bits US.DSB 10 Unit is disabled (1=yes) US.CRW 4 Unit is waiting for carrier (1=yes) US.ECH 2 Unit has no echo in progress (1=yes) US.OUT 1 Unit is expecting output interrupt (1=yes) LPS11 driver specific status bits US.FRK 2 Fork in progress (1=yes) US.SHR 1 Shareable function in progress (1=yes) Magtape driver specific status bits US.LAB 4 Unit has labeled tape on it (1=yes) US.BSP 2 Internal backspace in progress (1=yes) D-39 DATA STRUCTURES UCB U.ST2 Masks US.UMD 10 Unit attached for diagnostics (1=yes) US.PUB 4 Unit is public device (1=yes) US.RED 2 Unit is redirectable (0=yes) US.OFL 1 Unit is offline (1=yes) U.CW1 Masks DV.MNT 100000 Device is mountable (1=yes) DV.F11 40000 Device is mountable as Files-11 (1=yes) DV.COM 20000 Device is mountable as communications (1=yes) DV.PSE 10000 Pseudo device (1=yes) DV.OSP 4000 Output spooled device (1=yes) DV.ISP 2000 Input spooled device (1=yes) DV.SWL 1000 Unit is software write-locked (1=yes) DV.MBC 400 Unit is on Massbus controller (1=yes) DV.UMD 200 User-mode dianostics supported (1=yes) DV.MXD 100 Mixed-mode Massbus device (1=yes) DV.SQD 40 Sequential device (1=yes) DV.SDI 20 Single-directory device (1=yes) DV.DIR 10 Directory device (1=yes) DV.TTY 4 Terminal-like device (1=yes) DV.CCL 2 Carriage control device (1=yes) DV.REC 1 Record oriented device (1=yes) D-40 DATA STRUCTURES UCB UCB (mountable) Macro: UCBDF$ CDA Switch: /DEV Size: variable (36 as shown) M$$MUP >>>>>>>>>|===============================| v -2 | UCB Address of Owner TT: | U.OWN >>>>>>>>>>>>>>|-------------------------------| 00 | DCB Address | U.DCB |-------------------------------| 02 | Redirect UCB Address | U.RED |-------------------------------| 04 | Unit Status | Control Flags | U.CTL U.STS |-------------------------------| 06 | Unit Status | Unit Number | U.UNIT U.ST2 |-------------------------------| 10 | Characteristics Word #1 | U.CW1 |-------------------------------| 12 | Characteristics Word #2 | U.CW2 |-------------------------------| 14 | Characteristics Word #3 | U.CW3 |-------------------------------| 16 | Characteristics Word #4 | U.CW4 |-------------------------------| 20 | SCB Address | U.SCB |-------------------------------| 22 | TCB of Attached Task | U.ATT |-------------------------------| 24 | | U.BUF |--- Buffer Address ---| 26 | | |-------------------------------| 30 | Byte Count | U.CNT |-------------------------------| 32 | Address of ACP TCB | U.ACP |-------------------------------| 34 | Address of ACP VCB | U.VCB |===============================| D-41 DATA STRUCTURES UCB UCB (terminals) Macro: UCBDF$ CDA Switch: /DEV Size: variable (64 as shown) C$$CLI >>>>>>>>>|===============================| v -6 | Address of CLI TCB | U.CLI M$$MUP >>>>>>>>>|-------------------------------| v -4 | Login UIC | U.LUIC v |-------------------------------| v -2 | UCB Address of Owner TT: | U.OWN >>>>>>>>>>>>>>|-------------------------------| 00 | DCB Address | U.DCB |-------------------------------| 02 | Redirect UCB Address | U.RED |-------------------------------| 04 | Unit Status | Control Flags | U.CTL U.STS |-------------------------------| 06 | Unit Status | Unit Number | U.UNIT U.ST2 |-------------------------------| 10 | Characteristics Word #1 | U.CW1 |-------------------------------| 12 | Characteristics Word #2 | U.CW2 |-------------------------------| 14 | Characteristics Word #3 | U.CW3 |-------------------------------| 16 | Characteristics Word #4 | U.CW4 |-------------------------------| 20 | SCB Address | U.SCB |-------------------------------| 22 | TCB of Attached Task | U.ATT |-------------------------------| 24 | | U.BUF |--- Buffer Address ---| 26 | | |-------------------------------| 30 | Byte Count | U.CNT |-------------------------------| continued on next page D-42 DATA STRUCTURES UCB UCB (terminals) continued |-------------------------------| 32 | Pointer to UCB extension | U.TUX |-------------------------------| 34 | | U.TSTA |--- ---| 36 | Terminal Status Words | |--- ---| 40 | | |-------------------------------| 42 | Type-ahead Status and Pointer | U.TTAB |-------------------------------| 44 | Fork Request | Lines/Page | U.TLPP U.TFRQ |-------------------------------| 46 | Fork List Link Word | U.TFLK |-------------------------------| 50 | Current V-Pos | Current H-Pos | U.TCHP U.TCVP |-------------------------------| 52 | Terminal UIC | U.UIC |-------------------------------| 54 | Modem Timer | Terminal Type | U.TTYP U.TMTI |-------------------------------| 56 | Controller Type | U.CYTP |===============================| U.CW2 Masks (Terminals) U2.DH1 100000 Unit is a multiplexor (1=yes) U2.DJ1 40000 Unit is a DJ11 (1=yes) U2.RMT 20000 Unit is remote (1=yes) U2.HFF 10000 Unit handles hardware formfeeds (1=yes) U2.NEC 4000 Do not echo solicited input (1=yes) U2.CRT 2000 Unit is a CRT (1=yes) U2.ESC 1000 Unit generates escape sequences (1=yes) U2.LOG 400 User logged onto terminal (0=yes) U2.SLV 200 Unit is slaved terminal (1=yes) U2.DZ1 100 Unit is a DZ11 (1=yes) U2.HLF 40 Unit is in hold-screen mode (1=yes) U2.AT. 20 MCR command AT. is being processed (1=yes) U2.PRV 10 Unit is privileged terminal (1=yes) U2.L3S 4 Unit is a LA30S terminal (1=yes) U2.VT5 2 Unit is a VT05B terminal (1=yes) U2.LWC 1 Lower case to upper case conversion (1=yes) D-43 DATA STRUCTURES UCB U.TSTA+0 Masks S1.IBF 100000 Buffered input in progress (1=yes) S1.USE 20000 Unsolicited input in progress (1=yes) S1.CTS 10000 Output stopped by control-S (1=yes) S1.DSI 4000 Input processing disabled (1=yes) S1.DEC 2000 Defer echo of character in U.TECB (1=yes) S1.DPR 1000 Defer processing of character in U.TECB (1=yes) S1.BEL 400 Bell pending (1=yes) S1.IBY 200 Input busy (1=yes) S1.OBT 100 Output busy (1=yes) S1.CTO 40 Output stopped by control-O (1=yes) S1.RNE 20 Echo suppressed (1=yes) S1.RAL 10 Read-all in progress (1=yes) S1.ESC 4 Escape sequence in progress (1=yes) S1.RUN 2 Rubout sequence in progress (1=yes) S1.RST 1 Read/special terminators in progress (1=yes) U.TSTA+2 Masks S2.FDX 100000 Line is in full-duplex mode (1=yes) S2.FLF 40000 Force linefeed before next echo (1=yes) S2.HFF 20000 Hardware formfeed present (1=yes) S2.HHT 10000 Hardware horizontal tab present (1=yes) S2.VFL 4000 Vertical fill requirement (1=yes) S2.HFL 3400 Horizontal fill requirement (1=yes) S2.IRQ 200 Input request in queue (1=yes) S2.ORQ 100 Output request in queue (1=yes) S2.SRQ 40 Special request in queue (1=yes) S2.BRQ 20 Break-through-write request in queue (1=yes) S2.CR 10 Trailing CR required on output (1=yes) S2.WRB 4 Low bit in S2.WRA pattern (1=yes) S2.WRA 2 Context for wrap-around (1=yes) S2.ACR 1 Wrap-around (auto CR/LF) required (1=yes) U.TSTA+4 Masks S3.PCU 100000 Position cursor (1=yes) S3.DAO 40000 Last character has data overrun error (1=yes) S3.BCC 20000 Last character has framing error (1=yes) S3.VER 10000 Last character has parity error (1=yes) S3.WAL 4000 Terminal is in write-pass-all mode (1=yes) S3.RCU 400 Restore cursor (1=yes) S3.8BC 200 Pass 8 bits on input (1=yes) S3.TAB 100 Type-ahead buffer allocation requested (1=yes) S3.WES 40 Task wants escape sequences (1=yes) S3.RAL 10 Terminal is in read-pass-all mode (1=yes) D-44 DATA STRUCTURES SCB D.17 SCB SCB's (Status Control Blocks) are the controlling structure for a device controller. It contains pointers to the device and the I/O queue listhead. SCB's have no common link. Each UCB points to a SCB, however, if a controller has multiple units, multiple UCB's will point to one SCB. SCB References: o (S.BMSV) EMB pointer o (S.LHD ) I/O packet queue listhead o (S.PKT ) Current I/O packet References to SCB's o (U.SCB ) UCB, address of associated SCB D-45 DATA STRUCTURES SCB SCB Macro: SCBDF$ CDA Switch: /DEV Size: Normally 26 - add 6 bytes for error handling and 14 for 22-bit NPR devices E$$DVC >>>>>>>>>|===============================| v -6 | Offset t/reg | No. Registers | S.RCNT S.ROFF v |-------------------------------| v -4 | Pointer to EMB | S.BMSV v |-------------------------------| v -2 | Device I/O Active Bit Mask | S.BMSK >>>>>>>>>>>>>>|-------------------------------| 00 | | S.LHD |--- I/O Queue Listhead ---| 02 | | |-------------------------------| 04 | Vector/4 | Dev. Priority | S.PRI S.PRI |-------------------------------| 06 | Initial TMO | Current TMO | S.CTM S.ITM |-------------------------------| 10 | Cont. Status | Cont. Index | S.STS S.CON |-------------------------------| 12 | Address of Device Status Reg. | S.CSR |-------------------------------| 14 | Address of Current I/O Packet | S.PKT |-------------------------------| 16 | Fork PC | S.FRK |-------------------------------| 20 | Fork R5 | |-------------------------------| 22 | Fork R4 | L$$DRV>>>>>>>>>>|-------------------------------| v 24 | Fork Driver Relocation Base | M$$EXT>>>>>>>>>>|-------------------------------| v 26 | | S.MPR v |--- ---| v 30 | | v |--- ---| v 32 | Additional Storage for | v |--- ---| v 34 | 22-bit NPR Devices | v |--- ---| v 36 | | v |--- ---| v 40 | | >>>>>>>>>>>>>>|===============================| 42 D-46 DATA STRUCTURES MAPPING ASSIGNMENT BLOCK D.18 MAPPING ASSIGNMENT BLOCK Mapping Assignment Blocks are used on extended memory machines (11/70, 11/44) to map UMR's to physical addresses. The blocks come from system pool. Mapping Assignment Blocks are threaded together using the M.LNK offset. The list header is $UMRHD in module SYSCM. Macro: SCBDF$ CDA Switch: none Size: 14 bytes (6 words) |===============================| 00 | Link Word | M.LNK |-------------------------------| 02 | Address of First Assigned UMR | M.UMRA |-------------------------------| 04 | Number of UMR's Assigned * 4 | M.UMRN |-------------------------------| 06 | Low 16 Bits Mapped by 1st UMR | M.UMVL |-------------------------------| 10 | (High 6 Bits) | High 2 Bits | M.UMVH M.BFVH | ----------------| 12 | 22-Bit Physical Address | M.BFVL |===============================| 14 M.LGTH D-47 DATA STRUCTURES MOUNTED VOLUME LIST D.19 MOUNTED VOLUME LIST The Mounted Volume List is used to determine which terminals own (have mounted) a disk volume. The entries are taken from system pool by MOU and returned by DMO when the volume is dismounted. The list entries are chained together using the M.MXT offset. The list header is $MOULS in module SYSCM. Mounted Volume References: o (Offset 0) Next list entry o (Offset 4) Disk UCB o (Offset 6) Terminal UCB References to Mounted Volumes: o ($MOULS) List header Macro: none CDA Switch: none Size: 10 bytes (4 words) |===============================| 00 | Pointer to Next Entry | |-------------------------------| 02 | 4001 | |-------------------------------| 04 | Disk UCB | |-------------------------------| 06 | Owning Terminal UCB | |===============================| 10 D-48 DATA STRUCTURES F11ACP VCB D.20 F11ACP VCB The F11ACP VCB (Volume Control Block) holds all information related to a mounted Files-11 disk. The system creates the VCB is pool whenever a volume is first mounted and destroys it when the volume is finally dismounted. VCB's are not chained together. The pointer to the VCB for a particular disk is stored in offset U.VCB of the disk UCB. F11ACP VCB References: o (V.IFWI) Index file window block o (V.FCB ) FCB chain References to F11ACP VCB's: o (U.VCB ) UCB, address of VCB for mounted device Macro: F11DF$ CDA Switch: /DEV Size: 62 bytes (25 words) |===============================| 00 | Transaction Count | V.TRCT |-------------------------------| 02 | Index File Window Address | V.IFWI |-------------------------------| 04 | | V.FCB |--- FCB Listhead ---| 06 | | |-------------------------------| 10 | Index BM Size | (high byte) | V.IBLB V.IBSZ |---------------- | 12 | Index Bit Map 1st Block # | |-------------------------------| 14 | Maximum Number of Files | V.FMAX |-------------------------------| 16 | Cluster Size | Window Size | V.WISZ V.SBCL |-------------------------------| 20 | Storage Bit Map Size (Blocks) | V.SBSZ |-------------------------------| 22 | Extend Size | (high byte) | V.SBLB V.FIEX |---------------- | 24 | Storage Bit Map 1st Block # | |-------------------------------| 26 | Volume Owner's UIC | V.VOWN |-------------------------------| 30 | Volume Protection | V.VPRO |-------------------------------| continued on next page D-49 DATA STRUCTURES F11ACP VCB F11ACP VCB (continued) |-------------------------------| 32 | Volume Characteristics | V.VCHA |-------------------------------| 34 | Volume Def. File Protection | V.FPRO |-------------------------------| 36 | Volume File Sequence Number | V.VFSQ |-------------------------------| 40 | # LRU Slots | (high byte) | V.FRBK V.LRUC |---------------- | 42 | Number of Free Blocks | |-------------------------------| 44 | | V.LABL |--- ---| 46 | | |--- ---| 50 | | |--- Volume Name (ASCII) ---| 52 | | |--- ---| 54 | | |--- ---| 56 | | |-------------------------------| 60 | Free BM Block | Status | V.STAT V.FFNU |===============================| 62 V.LGTH V.STAT Masks VC.HLK 10 Hardware lock the volume on dismount VC.SLK 4 Software lock the volume on dismount VC.BMW 2 Storage bitmap is write accessed VC.IFW 1 Index file is write accessed D-50 DATA STRUCTURES F11ACP WINDOW D.21 F11ACP WINDOW F11ACP Windows are used to map virtual blocks in a file to logical (physical) disk blocks. The windows are maintained by F11ACP and are created in system pool whenever a file is opened and destroyed when the file is closed. The windows are not threaded together. There is one window block for each open file. The address of the window is stored in the second LUN word of the associated LUN table entry in the task header. F11ACP Window References: o (W.FCB ) FCB address of file o (W.LKL ) Lock list for file References to F11ACP Windows: o Task header, second lun word o (L.WI1 ) Lock list, address of window block D-51 DATA STRUCTURES F11ACP WINDOW F11ACP Window (2/4 Format) Macro: F11DF$ CDA Switch: none Size: variable |===============================| 00 | Access Flags | # Entries | W.CTL |-------------------------------| 02 | Size of PTR's | (high byte) | W.VBN W.SIZE |---------------- | 04 | First VBN Mapped by Window | |-------------------------------| 06 | FCB Address | W.FCB |-------------------------------| 10 | Address of Lock Block List | W.LKL |-------------------------------| 12 | # of Blocks Mapped by PTR | W.RTRV |-------------------------------| 14 | | |--- LBN Block Number ---| 16 | | |-------------------------------| . . . More Pointer Triples . . W.CTL Masks WI.BPS 100000 Bypass interlock (1=yes) WI.EXL 40000 Manual unlock desired (1=yes) WI.PND 20000 Window turn pending (1=yes) WI.DLK 10000 Deaccess lock enabled (1=yes) WI.LCK 4000 Lock against shared access (1=yes) WI.EXT 2000 Extend allowed (1=yes) WI.WRV 1000 Write virtual block allowed (1=yes) WI.RDV 400 Read virtual block allowed (1=yes) D-52 DATA STRUCTURES LOCK BLOCK LIST D.22 LOCK BLOCK LIST The Lock Block List are data structures used to provide multiple writers to the same file (RMS record locking). The structures provide a means for a task to lock a block(s) for its exclusive use over a period of time. All locked blocks for a file are threaded together using offset L.LNK. The list header is located in offset F.LKL of the FCB. Also, each window block associated with the file points to the lock block list using offset W.LKL. Lock Block References: o (L.LNK ) Next list entry o (L.WI1 ) Window block of current lock owner References to Lock Blocks: o (W.LKL ) Window block, start of lock list for file o (F.LKL ) FCB, start of lock list for file Macro: F11DF$ CDA Switch: none Size: 10 bytes (4 words) |===============================| 00 | Link to Next Lock Block | L.LNK |-------------------------------| 02 | Address of Window Block | L.WI1 |-------------------------------| 04 | # Blocks Lock | (high byte) | L.VB1 L.CNT |---------------- | 06 | Starting VBN Number | |-------------------------------| 10 L.LGTH D-53 DATA STRUCTURES FCB D.23 FCB FCB's (File Control Blocks) contain information about currently open files. The FCB's are maintained by F11ACP and are first allocated using its internal pool and then overflow into the system pool. All FCB's for files on a volume are linked together using the F.LINK word. The list header is V.FCB of the VCB. FCB References: o (F.LINK) Link to next FCB in chain o (F.LKL ) Lock block list for file References to FCB's o (V.FCB ) F11ACP VCB, FCB list header D-54 DATA STRUCTURES FCB FCB Macro: F11DF$ CDA Switch: /HDR Size: 52 bytes (43 words) |===============================| 00 | FCB Chain Pointer | F.LINK |-------------------------------| 02 | File Number | F.FNUM |-------------------------------| 04 | Sequence Number | F.FSEQ |-------------------------------| 06 | Segment # | | F.FSQN |-------------------------------| 10 | File Owner UIC | F.FOWN |-------------------------------| 12 | File Protection | F.FPRO |-------------------------------| 14 | System Chars. | User Chars. | F.UCHA F.SCHA |-------------------------------| 16 | | F.HDLB |--- File Header LBN ---| 20 | | |-------------------------------| 22 | LBN of Virtual Block 1 | F.LBN |--- ---| 24 | If Contiguous, Zero if Not | |-------------------------------| 26 | | F.SIZE |--- Size of File in Blocks ---| 30 | | |-------------------------------| 32 | # Locks | # Accesses | F.NACS F.NLCK |-------------------------------| 34 | Status | # Writers | F.NWAC/F.STAT |-------------------------------| 36 | Directory EOF Block Number | F.DREF |-------------------------------| 40 | 1st Word of Directory Name | F.DRNM |-------------------------------| 42 | Address of Extension FCB | F.FEXT |-------------------------------| 44 | | F.FVBN |--- Starting VBN for FCB ---| 46 | | |-------------------------------| 50 | Lock Block Listhead | F.LKL |===============================| 52 F.LGTH D-55 DATA STRUCTURES MTAACP VCB D.24 MTAACP VCB The MTAACP VCB (Volume Control Block) holds all information related to a mounted magtape. The system creates the VCB in pool whenever a magtape is mounted and destroys it when the magtape is dismounted. The VCB's are chain together using the V.NXT offset. The chain header is U.VCB in the magtape UCB. Macro: MTADF$ CDA Switch: /HDR Size: 110 bytes (36 words) |===============================| 00 | Transaction Count | V.TCNT |-------------------------------| 02 | Pointer to Next VCB | V.NXT |-------------------------------| 04 | Pointer to Mounted List | V.MVL |-------------------------------| 06 | Pointer to Unmounted List | V.UVL |-------------------------------| 10 | TCB Address of Accessing Task | V.ATL |-------------------------------| 12 | UCB Address | V.UCB |-------------------------------| 14 | Mount Mode | Current Vol # | V.RVOL V.MOU |-------------------------------| 16 | Tape Characteristics | V.TCHR |-------------------------------| 20 | Current File Sequence # | V.SEQN |-------------------------------| 22 | Current File Section # | V.SECN |-------------------------------| 24 | # TM's to Next HDR1 | V.TPOS |-------------------------------| 26 | TMO Counter | Process Stat. | V.PSTA V.TIMO |-------------------------------| 30 | | V.STS |--- ---| 32 | Command Execution Status | |--- ---| 34 | | |-------------------------------| 36 | Spare Word | V.SPAR |-------------------------------| (continued on next page) D-56 DATA STRUCTURES MTAACP VCB MTAACP VCB (continued) |-------------------------------| 40 | Block Length | V.BLKI |-------------------------------| 42 | Record Length | V.RECL |-------------------------------| 44 | | V.FNAM |--- ---| 46 | File Name | |--- ---| 50 | | |-------------------------------| 52 | File Type | V.FTYP |-------------------------------| 54 | File Version | V.FVER |-------------------------------| 56 | | V.CDAT |--- Creation Date ---| 60 | | |-------------------------------| 62 | | V.EDAT |--- Expriation Date ---| 64 | | |-------------------------------| 66 | Block Count | V.BLKC |--- ---| 70 | for File Section | |-------------------------------| 72 | CC Attr. | Record Type | V.RTYP V.FATT |-------------------------------| 74 | | V.WIND |--- ---| 76 | | |--- ---| 100 | | |--- Null Window ---| 102 | | |--- ---| 104 | | |--- ---| 106 | | |===============================| 110 S.VSCB D-57 DATA STRUCTURES EMB D.25 EMB EMB's (Error Message Blocks) are created by the executive whenever an error is logged. The EMB's are created in pool and queued to the error logger (ERL...) using the $ERRHD in module SYSCM. The system supports different types of EMB's for various error conditions. EMB (Nonsense Interrupt) Macro: EMBDF$ CDA Switch: /SYS Size: 22 bytes (9 words) |===============================| 00 | Size of EMB in (bytes) | E.SIZE |-------------------------------| 02 | Error Subcode | Error Code | E.CODE E.SCDE |-------------------------------| 04 | | E.TIME |--- ---| 06 | Time of Error | |--- ---| 10 | | |-------------------------------| 12 | Sequence Number | E.SEQ |-------------------------------| 14 | Saved I/O Bitmap | E.ABM |-------------------------------| 16 | # Interrupts | ID of Vector | E.VCTR E.LOST |-------------------------------| 20 | PS before Interrupt | E.OPS |-------------------------------| 22 | PC before Interrupt | E.OPC |===============================| D-58 DATA STRUCTURES EMB EMB (Device Error) Macro: EMBDF$ CDA Switch: /SYS Size: variable (54 + device registers) |===============================| 00 | Size of EMB in (bytes) | E.SIZE |-------------------------------| 02 | Error Subcode | Error Code | E.CODE E.SCDE |-------------------------------| 04 | | E.TIME |--- ---| 06 | Time of Error | |--- ---| 10 | | |-------------------------------| 12 | Sequence Number | E.SEQ |-------------------------------| 14 | Saved I/O Bitmap | E.ABM |-------------------------------| 16 | Retry Count | E.RTRY |-------------------------------| 20 | I/O Count | Task Priority | E.IOC |-------------------------------| 22 | | E.TASK |--- Task Name (RAD50) ---| 24 | | |-------------------------------| 26 | Partition Address | E.PAR |-------------------------------| 30 | Task UIC | E.UIC |-------------------------------| 32 | QIO Function Code | E.FCN |-------------------------------| 34 | | E.PRM |--- ---| 36 | | |--- ---| 40 | | |--- ---| 42 | QIO Parameters | |--- ---| 44 | | |--- ---| 46 | | |--- ---| 50 | | |-------------------------------| 52 | | # Dev. Regs. | E.RCNT |-------------------------------| 54 / Device Registers / E.REGS /===============================/ D-59 DATA STRUCTURES EMB EMB (Driver Load/Unload) Macro: EMBDF$ CDA Switch: /SYS Size: 32 bytes (13 words) |===============================| 00 | Size of EMB in (bytes) | E.SIZE |-------------------------------| 02 | Error Subcode | Error Code | E.CODE E.SCDE |-------------------------------| 04 | | E.TIME |--- ---| 06 | Time of Error | |--- ---| 10 | | |-------------------------------| 12 | Sequence Number | E.SEQ |-------------------------------| 14 | Saved I/O Bitmap | E.ABM |-------------------------------| 16 | | |-------------------------------| 20 | | |-------------------------------| 22 | | |-------------------------------| 24 | | |-------------------------------| 26 | Load/Unload Code | E.WHY |-------------------------------| 30 | Device Name (ASCII) | E.NAME |===============================| D-60 DATA STRUCTURES INDEX FILE FORMAT D.26 INDEX FILE FORMAT VBN |===============================| | | 1 | Bootstrap Block | | | |-------------------------------| | | 2 | Home Block | | | |-------------------------------| | | 3 | | | | |--- ---| | Index File Bit Map | | "n" size in | | Home Block (first word) | |--- ---| | | | | | | |-------------------------------| 3+n+0 | Index File Header | | INDEXF.SYS | | (1,1) | |-------------------------------| 3+n+1 | Bit Map File Header | | BITMAP.SYS | | (2,2) | |-------------------------------| 3+n+2 | Bad Block File Header | | BADBLK.SYS | | (3,3) | |-------------------------------| 3+n+3 | Master File Directory Header | | 000000.DIR | | (4,4) | |-------------------------------| 3+n+4 | Checkpoint File Header | | CORIMG.SYS | | (5,5) | |-------------------------------| | | 3+n+5 | User File Header #1 | | (6,x) | |-------------------------------| . . D-61 DATA STRUCTURES HOME BLOCK D.27 HOME BLOCK Macro: HMBOF$ Size: 1000 bytes (256 words) |===============================| 00 | Index File Bitmap Size | H.IBSZ |-------------------------------| 02 | Location of Index | H.IBLB |--- ---| 04 | Bit Map | |-------------------------------| 06 | Maximum # of Files Allowed | H.FMAX |-------------------------------| 10 | Storage Bit-Map Cluster Size | H.SBCL |-------------------------------| 12 | Disk-Device Type | H.DVTY |-------------------------------| 14 | Structure Level | H.VLEV |-------------------------------| 16 / / H.VNAM / Volume Name (ASCII) / / / |-------------------------------| 32 | | |--- Reserved ---| 34 | | |-------------------------------| 36 | Volume Owner's UIC | H.VOWN |-------------------------------| 40 | Volume Protection Code | H.VPRO |-------------------------------| 42 | Volume Characteristics | H.VCHA |-------------------------------| 44 | Default File Protection | H.DFPR |-------------------------------| (continued on next page) D-62 DATA STRUCTURES HOME BLOCK Home Block (continued) |-------------------------------| 46 | | |--- ---| 50 | Reserved | |--- ---| 52 | | |-------------------------------| 54 | # Extend Blk. | # RTV Ptrs. | H.WISZ H.FIEX |-------------------------------| 56 | | # LRU Entries | H.LRUC | ----------------| 60 | | |--- ---| 62 | | |--- ---| 64 | Reserved | |--- ---| 66 | | |--- ---| 70 | | |-------------------------------| 72 | Checksum of words 00-70 | H.CHK1 |-------------------------------| 74 / / H.VDAT / Creation Date and Time / / / /-------------------------------/ 112 / / / Volume-Header Label / / (not used) / /-------------------------------/ 256 / / / System Specific Information / / (not used) / /-------------------------------/ 400 / / / Relative Volume Table / / (not used) / |-------------------------------| 776 | Checksum of words 000-774 | H.CK2 |===============================| 1000 D-63 DATA STRUCTURES FILE HEADER D.28 FILE HEADER Macro: HDFOF$ Size: 1000 bytes (256 words) |===============================| 00 | 56 | 27 | H.IDOF H.MPOF |-------------------------------| 02 | File ID Number | H.FNUM |-------------------------------| 04 | File Sequence Number | H.FSEQ |-------------------------------| 06 | Structure/System Level | H.FLEV |-------------------------------| 10 | File Owner UIC | H.FOWN |-------------------------------| 12 | File Protection | H.FPRO |-------------------------------| 14 | System Chars. | User Chars. | H.UCHA H.SCHA |-------------------------------| 16 / / H.UFAT / User File Attributes / / (For FCS, 1st 7 words of FDB) / / / |-------------------------------| 56 | | I.FNAM |--- ---| 60 | Filename (RAD50) | |--- ---| 62 | | |-------------------------------| 64 | Filetype (RAD50) | I.FTYP |-------------------------------| 66 | Version Number | I.FVER |-------------------------------| 70 | Revision Number | I.RVNO |-------------------------------| (continued on next page) D-64 DATA STRUCTURES FILE HEADER File Header (continued) |-------------------------------| 72 | | I.RCDT |--- ---| 74 | Revision Date | |--- ---| 76 | | |--- ----------------| 100 | | | I.RVTI |---------------- ---| 102 | | |--- Revision Time ---| 104 | | |--- ----------------| 106 | | | I.CRDT |---------------- ---| 110 | | |--- ---| 112 | Creation Date | |--- ---| 114 | | |-------------------------------| 116 | | I.CRTI |--- ---| 120 | Creation Time | |--- ---| 122 | | |-------------------------------| 124 | | I.EXDT |--- ---| 126 | Expiration Date | |--- ---| 130 | | |---------------- ---| 132 | | | |-------------------------------| 134 | | Ext. Seg. # | M.ESQN |-------------------------------| 136 | Extension File ID # | M.ERVN |-------------------------------| 140 | Extension File Sequence # | M.EFNU |-------------------------------| 142 | RTV Size - Always 1,3 Format | M.CTSZ M.LNSZ |-------------------------------| 144 | Max # RTV's | # RTV's | M.USE M.MAX |-------------------------------| 146 / / M.RTRV / Retrieval Pointers / / (in 1,3 format) / / / |-------------------------------| D-65 DATA STRUCTURES FILE HEADER 776 | Checksum of Words 000-774 | H.CKSM |===============================| 1000 D-66 DATA STRUCTURES DIRECTORY ENTRY D.29 DIRECTORY ENTRY Macro: none Size: 20 bytes (8 words/32 block) |===============================| 00 | File ID Number | |-------------------------------| 02 | File Sequence Number | |-------------------------------| 04 | 0 | |-------------------------------| 06 | | |--- ---| 10 | Filename (RAD50) | |--- ---| 12 | | |-------------------------------| 14 | Filetype (RAD50) | |-------------------------------| 16 | Version Number | |===============================| 20 D-67 DATA STRUCTURES FDB D.30 FDB Macro: FDOF$L, FCSBT$ Size: 102 bytes (33 words) |===============================| 00 | Record Attr. | Record Type | F.RTYP F.RATT |-------------------------------| 02 | Record Size | F.RSIZ |-------------------------------| 04 | | F.HIBK |--- Highest VBN Allocated ---| 06 | | |-------------------------------| 10 | | F.EFBK |--- EOF Block Number ---| 12 | | |-------------------------------| 14 | First Free Byte in EOF Block | F.FFBY |-------------------------------| 16 | Device Chars | Record Access | F.RACC F.RCTL |-------------------------------| 20 | Block I/O Buffer Descriptor | F.BKDS/F.NRBD |--- or ---| 22 | User-record Buffer Descriptor | |-------------------------------| 24 | Block I/O Status & AST Addr. | F.BKST/F.NRBD |--- or | 26 | Next-record Buffer Descriptor | |-------------------------------| 30 | Buffer Size/Next Record Addr. | F.OVBS/F.NREC |-------------------------------| 32 | End-of-block Value | F.EOBB |-------------------------------| 34 | Create Quantity & Statistics | F.CNTG/F.RCNM |--- or ---| 36 | Record Number | F.STBK |-------------------------------| 40 | Extend Quantity | F.ALOC |-------------------------------| 42 | File Access | LUN Number | F.LUN F.FACC |-------------------------------| 44 | Dataset Descriptor Pointer | F.DSPT |-------------------------------| 46 | Default Filename Block Addr. | F.DFNB |-------------------------------| 50 | Bookkeeping | EFN | F.BKEF F.BKP1 |-------------------------------| (continued on next page) D-68 DATA STRUCTURES FDB FDB (continued) |-------------------------------| 52 | Error Word | F.ERR |-------------------------------| 54 | Buffer Count | Mul. Buf. No. | F.MBCT F.MBC1 |-------------------------------| 56 | Reserved | Mul. Buf. Bit | F.MBFG F.BGBC |-------------------------------| 60 | Device Buffer Size | F.VBSZ |-------------------------------| 62 | Block Buffer Size | F.BBSZ |-------------------------------| 64 | | F.BKVB/F.VBN |--- VBN Number ---| 66 | | |-------------------------------| 70 | Block Buffer Descriptor | F.BDB |-------------------------------| 72 | Spooling Device | F.SPDV |-------------------------------| 74 | Reserved | Spooling Unit | F.SPUN F.CHR |-------------------------------| 76 | Control Bits | F.ACTL |-------------------------------| 100 | Sequence Number | F.SEQN |===============================| 102 Start of FNB F.FNB D-69 DATA STRUCTURES FNB D.31 FNB Macro: NBOF$L, FCSBT$ Size: 36 bytes (15 words) |===============================| 00 | | N.FID |--- ---| 02 | File-ID | |--- ---| 04 | | |-------------------------------| 06 | | N.FNAM |--- ---| 10 | Filename | |--- ---| 12 | | |-------------------------------| 14 | File Type | N.FTYP |-------------------------------| 16 | Version | N.FVER |-------------------------------| 20 | Status | N.STAT |-------------------------------| 22 | Next File | N.NEXT |-------------------------------| 24 | | N.DID |--- ---| 26 | Directory ID | |--- ---| 30 | | |-------------------------------| 32 | Device Name | N.DVNM |-------------------------------| 34 | Unit Number | N.UNIT |===============================| 36 D-70 DATA STRUCTURES DSD D.32 DSD Macro: FDSOF$ Size: 14 bytes (6 words) |===============================| 00 | Device String Length | N.DEVD |-------------------------------| 02 | Device String Address | |-------------------------------| 04 | Directory String Length | N.DIRD |-------------------------------| 06 | Directory String Address | |-------------------------------| 10 | Filename String Length | N.FNMD |-------------------------------| 12 | Filename String Address | |===============================| 14 D-71 DATA STRUCTURES $$FSR1 D.33 $$FSR1 Macro: BDOFF$ Size: variable |===============================| 00 | | |--- I/O Status Block ---| 02 | | |-------------------------------| 04 | | B.VBN |--- Virtual Block Number ---| 06 | | |-------------------------------| 10 | Address of Next Buffer | B.NXBD |-------------------------------| 12 | Buffer Status | Empty | B.BFST |-------------------------------| 14 | Empty | |-------------------------------| 16 / Start of I/O Buffer / S.BFHD / . / / . / / . / D-72 DATA STRUCTURES $$FSR2 D.34 $$FSR2 Macro: $FSROF Size: 104 bytes (34 words) |===============================| 00 | | |--- Allocation Listhead ---| 02 | | |-------------------------------| 04 | First Address in FSR1 | A.BFSR |-------------------------------| 06 | Last Address in FSR1 | A.EFSR |-------------------------------| 10 | File Owner UIC | A.OWUI |-------------------------------| 12 | Default File Protection | A.FIPR |-------------------------------| 14 / / A.DPB / Scratch Area and QIO DPB / / / |-------------------------------| 44 | | A.IOST |--- Scratch I/O Status Area ---| 46 | | |-------------------------------| 50 / / A.DFDR / Default Directory Information / / / |-------------------------------| 100 | Default Buffer Count | A.DFBC |-------------------------------| 102 | Default Task UIC | A.DFUI |===============================| 104 D-73 APPENDIX E EXAMPLE CRASHES Included on the SIG tape in the crash analysis area are a number of files named CRAxxx.MAC. These are the sources for programs which you can run to crash your system and generate example crashes. CRAASMALL.CMD is a template command file to assemble all of these. CRABLDALL.CMD is a template command file to build all of them. These have all been tested and all crashed the system on which they were run. These programs are intended for use by a knowledgeable person for educational purposes; the authors take no responsibility for what happens when your system crashes. E.1 CRAYZO This program causes a stack limit violation by pushing onto the kernel stack until the crash occurs. E.2 SST CRASHES - CRAT04, CRAILI, CRABPT, CRASEG These programs cause executive SST crashes. This provides examples of the SST crashes discussed in Basic Crash Analysis. Interpreting these crashes should be straight-forward after reading the Basic Crash Analysis chapter. E.3 CRATRP AND CRAEMT These programs crash the system via a TRAP and an EMT at system state, respectively. These are more examples for Basic Crash Analysis. E.4 CRAOSP This is the crash caused when the kernel stack pointer becomes odd. This is a Fatal Stack Error. The stack pointer is repositioned to 4, and the PS and PC are pushed onto the stack. The processor traps through 4, and jumps to $CRASH because of a stack limit violation. The key to understanding this crash E-1 EXAMPLE CRASHES CRAOSP is to note that the kernel stack pointer on the CDA output is 4, and to then examine low core. E.5 ODD VECTOR CRASHES There are two types of odd vector crashes. If the odd vector is location 4 or the IOT vector, then a repeating pattern occurs on the kernel stack. This occurs because the attempt to handle the trap results in another trap of the same type. In the case of odd location 4, this happens entirely within the PDP-11 hardware. In the case of the IOT vector, this depends on the fact that the IOT is used in RSX to crash the system. The second type of odd vector crash occurs if some other trap vector or interrupt vector is odd. The fatal aspect here is that there is one more PS, PC combination on the stack than the executive knows about. The crash occurs when the executive tries to clean up after the second trap. A general rule is that if the stack has a repeating pattern, or if the stack seems hopelessly confused prior to the crash, examine low core for corrupted vectors. E.5.1 CRAOD4 This is the crash caused when location 4 is odd, and an odd address trap occurs. When the processor tries to fetch the new PC, another odd address trap occurs, causing a repeating pattern on the stack down to the yellow zone limit. When the yellow zone limit is reached, the processor alternates between odd address traps and stack limit violation traps. The push onto the stack occurs before the PC is incremented, so the PC's pushed by the two traps differ by two. When the red zone is reached, the stack pointer is reset to 4, the PS and PC are pushed on the stack, and the processor halts. Note that the exact appearence of the stack in the yellow zone may vary depending on the priority of different CPU errors in your CPU model. E.5.2 CRAIOS And CRAIOU These are examples of the crashes which occur when the IOT vector is odd. CRAIOS is an IOT at system state; CRAIOU is an IOT at user state. Both have a 13 word repeating pattern on the kernel stack. The crash routine is eventually reached through the stack limit violation code. E-2 EXAMPLE CRASHES ODD VECTOR CRASHES E.5.3 CRAEVO This crash occurs if the EMT vector is odd. The EMT pushes the task PS and PC onto the stack. After the EMT, the processor is in mode [current,previous] = [kernel,user]. The fact that the vector address is odd causes an odd address trap. Now the mode is [kernel,kernel]. The executive only knows about one trap, and now proceeds to handle the odd address trap as though it occurred at user state. If the current task has no SST vectors, then the executive cleans the stack and jumps to the routine $ABCTK (abort current task). The RETURN at the end of that routine is intended to take us back to $DIRSV in this case. However, the stack contents are shifted by two words because of the extra trap. The result is that the executive tries to return to the location in kernel space which corresponds to the value of R1 before the original trap. If R1 is odd, as in this example, an odd address trap occurs and the system crashes right away. (Note that R1 is odd when CRAEVO begins execution, with contents of 12621 - CRA in RAD-50.) If R1 is even, the results are unpredictable, but bound to be bad. If the current task does have SST vectors, the results are less predictable. Normally the SST parameters would be pushed onto the task stack, along with the PS and PC from the SST. This just isn't going to work out in this case. A similar crash can occur if an interrupt vector or miscellaneous trap vector is odd. Again the key to this crash is not to grind out what happened to the stack, but to check the vectors in low core. E-3