03/27/85 test_cpu Syntax as a command: test_cpu {-control_args} Function: checks the CPU hardware for problems that have existed on the processors. By running various tests invoked by this command, you can determine whether the given CPU has had specific problems fixed. This command is usually used with the set_proc_required command if the system being tested has multiple CPUs configured. If one of the test scripts fails and the successful execution of that test is dependent upon installation of a particular FCO, the FCO number is displayed in the error message. Control arguments: -brief, -bf inhibits the printing of the test number and name, prior to the execution of a test. -cycle COUNT repeats each test for COUNT times, then proceeds on to the next test. -exclude LIST, -excl LIST excludes tests specified in the LIST, where LIST can be either a valid test number or a name. -exclude TEST_LIST, -excl TEST_LIST excludes the tests identified by TEST_LIST, where TEST_LIST is either a set of test names or numbers, from the tests that are run. -from TEST NUMBER/NAME, -fm TEST NUMBER/NAME starts testing from the test identified by TEST NUMBER or NAME. The default is to start testing from test 1. -help displays a brief usage statement. This control argument should not be used with any other control argument. -history_regs, -hregs displays history registers when a test fails. The default is not to display them. -long, -lg displays machine conditions and history registers after a fault has occured. The default is not to display them. -machine_conditions, -mc displays machine conditions when a test fails. The default is not to display them. -repeat COUNT, -rpt COUNT repeats an entire sequence of tests for COUNT times. The default is to run the test set one time. -select TEST_LIST, -sel TEST_LIST executes only those tests specified by TEST_LIST, where TEST_LIST is either a set of test names or numbers from the tests that are run. The tests are described briefly below. To find out the exact details of each test, see the test_cpu program. The default is to run all tests. The command line: test_cpu -select cmpc tmir -repeat 5 -count 2 executes the "cmpc" test twice, then the "tmlr" test twice. The sequence is repeated five times. -stop_on_failure, -sof stops testing when a test failure occurs and returns to a new Multics command level. The default is to continue testing with the next test. -test_names lists valid test names and the associated test numbers known to test_cpu. This control argument should not be used with any other control argument. -to TEST NUMBER/NAME stops testing after the test identified by TEST NUMBER or NAME. The default is to run all tests. List of requests for diagnostic tests: mlrstern checks a failure in which the fill character is placed as the first character on a page. This test causes a MME1 fault if the hardware fails. tmlr tries several MLR instructions, in several working combinations, across a page boundary. Messages are printed for any failures. csl_oob checks a particular use of a CSL instruction where the first descriptor is 0. This test causes an out_of_bounds fault if the hardware fails, and a MME1 fault if it succeeds. mvn checks the use of an MVN instruction that moves a number to a shorter number. The first two characters are dropped when the hardware fails. mvn_of1 checks the use of MVN to move the number 0. An overflow indicates that the hardware failed. tct checks a particular TCT use. The test causes an op_not_complete if the hardware fails, and a MME1 fault if it succeeds. sreg checks the use of an SREG instruction that occurs as the last instruction in a page. The test causes an op_not_complete if the hardware fails, and a MME1 fault if it succeeds. csl_onc checks a particular CSL use. The test causes an op_not_complete if the hardware fails, and a MME1 fault if it succeeds. test_sc2 checks the use of the SC modifier interacting with page faults. A MME1 fault occurs if the hardware fails. test_ci checks the use of the CI modifier interacting with page faults. A MME1 fault occurs if the hardware fails. rpd_test checks a particular use of the RPD instruction as it interacts with the hardware. A MME1 fault occurs if the hardware fails. mlr_test checks the use of the MLR instruction across a bounds fault boundary. The bounds fault is followed by a segment fault and a page fault. A MME1 fault occurs if the hardware fails. cls_test checks the CSL instruction across a bound fault boundary. A MME1 fault occurs if the hardware fails. cmpc checks the CMPC instruction in a way that fails if a timer runout or connect fault occurs in midexecution when the hardware is failing. A MME1 fault occurs if the hardware fails. bad_fill checks the success of moving or comparing fill characters in the first two words of a page. Failure is indicated by a miscompare and a message to the user. mpy_ofl multiplies -2**35 by itself and checks for an overflow fault (which indicates failure). test_xed checks a particular indexed XED usage that fails if the first executed instruction is an APU-type instruction. Failure is indicated by a miscompare and a message to the user. cmpc7 checks a CMPC failure when both strings begin seven words from a page boundary and run into the next page. A MME1 fault occurs if the hardware fails. extra_fill checks the MLR instruction to see if extra fill characters are placed after a string when the string crosses a page boundary. A MME1 fault occurs if the hardware fails. test_cmpc_fill checks the fill mechanism of the CMPC instruction near a page boundary. A MME1 fault occurs if the hardware fails. acv_restart checks that machine conditions can successfully be restarted after an access violation fault that is caused by a reference to data via an EIS (MLR) instruction. Failure is indicated by successive no_write_permission conditions. scm_tally checks to see if the SCM instruction works with the tally runout indicator set correctly. The test calls a small alm program that uses an SCM instruction. Because the hardware fails erratically, the test is run 10 times to get a (limited) statistical sampling. Failure is indicated by a message to the user indicating the number of times the SCM instruction failed. mvt_ascii_to_bcd checks nine to six (ASCII to BCD) conversion using the MVT instruction. A large ASCII data segment is generated. Then a BCD segment is generated using non-EIS conversion. Three segments are then converted from ASCII to BCD using the MVT instruction, and these segments are compared to the known good BCD segment. If any compare errors are detected, the contents of both segments are dumped in octal at the failing location. mvt_bcd_to_ascii checks six to nine (BCD to ASCII) conversion using the method described for the mvt_nine_to_six test above. If any compare errors are detected, the contents of both segments are dumped in octal at the failing location. mvt_nine_to_four checks 9-bit to 4-bit (decimal to packed decimal) conversion using the MVT instruction. A large segment of data, containing 9-bit characters of values 0 to 15 in a rotating pattern, is generated. Then a second segment is generated, converting the 9-bit characters into 4-bit characters using non-EIS conversion techniques. The 9-bit data segment is then converted to three 4-bit data segments using the MVT instruction and compared to the known good 4-bit data. If any discrepancies are found, the contents of both segments are dumped in octal at the failing location. mvt_four_to_nine checks 4-bit to 9-bit (packed decimal to decimal) conversion using the method described for the mvt_nine_to_four test above. If any compare errors are found, the contents of both segments are dumped in octal at the failing location. mvt_ascii_to_ebcdic checks nine to nine (ASCII to EBCDIC) character conversion using the method described for the mvt_nine_to_four test above. If any discrepancies are found, the contents of both segments are dumped at the failing location. mvt_ebcdic_to_ascii checks nine to nine (EBCDIC to ASCII) character conversion using the method described for the mvt_nine_to_four test above. If any discrepancies are found, the contents of both segments are dumped in octal at the failing location. ci_mod_case_2 checks character indirect modification with two tally words and two data character strings, each located at a page boundary. An LDA instruction is executed on one tally word, CI mod, and a CMPA is executed with a second tally word, CI mod. Both tally words point to a character string that should be equal. If the zero indicator does not come on as a result of the CMPA, a MME1 fault is taken, indicating that the hardware failed. acv_restart_csl validates that machine conditions can be successfully restarted after an access violation fault that is caused by a reference to data via an EIS (CSL) instruction. Failure is indicated by successive no_write_permission conditions. cmpn_tst checks that numeric data moved with an MVN instruction can be successfully compared with a CMPN instruction. Failure is indicated by a MME1 fault. itp_mod checks that an EPP2,* to a word pair that contains an ITP modifier with a bit offset actually loads PR2 with the correct information. A MME1 fault indicates failure. mvnoosb checks the prepage logic of the CPU for EIS numeric instructions. Failure is indicated by a MME1 fault. cmpb_with_sixbit_offset checks the CMPB instruction with a six bit offset. A MME1 fault indicates that the hardware failed. cmpb_with_rotate checks the CMPB instruction with a rotating pattern. A MME1 fault indicates that the hardware failed. cmpc_pgbnd compares a 38-character data string against a zero-length string, for a CMPC instruction that is located at seg|1767. Either an out_of_bounds condition or a MME1 fault indicates that the hardware failed. csl_pgflt checks that a CSL instruction does not get a no_write_perm condition if it causes a page fault on the target string and the source string is read-only. scm_pgflt tests a problem with the SCM instruction whereby the target operand takes a page fault and the resulting comparison is not made. Failure is indicated by a message to the user indicating the number of miscompares. scd_con_flt tests a failure with the SCD instruction that fails when interrupted by a connect fault. Failure is indicated by displaying the number of times the SCD failed. xed_dirflt_even tests the ability of the CPU to perform an XED, located on an even word location, of a pair of instructions located on a page boundary. Failure is indicated by an IPR fault. xed_dirflt_odd tests the ability of the CPU to perform an XED, located on an odd word location, of a pair of instructions located on a page boundary. Failure is indicated by an IPR fault. cmpc_adj_len tests the ability of the processor to perform a CMPC instruction which takes a fault on D2 and D2 has residue, indicated by the MIF flag. The test fails when the level count on D2 is not adjusted correctly on the SPL. Failure is indicated by an IPR fault. cmpc_zero_ind tests the ability of the processor to correctly restore the zero indicator after returning from a page fault on D2 after a match has occurred utilizing the CMPC instruction. Failure is indicated by an IPR fault. scm_tro tests the ability of the processor to find the correct character using a SCM instruction. The tally runout indicator should not be set. Failure is indicated by an IPR fault. rpt_test_odd checks that a RPT instruction in an odd location does not fail after a page fault on a STZ instruction, after crossing a page boundary. Failure is indicated by an IPR fault. rpt_test_even checks that a RPT instruction in an even location does not fail after a page fault on a STZ instruction, after crossing a page boundary. Failure is indicated by an IPR fault. scd_oob_tst tests the conditions when D3 resides in a different segment than D1 or D2. Also tests the conditions if there is no match or if the scan ends a few words from the end of a 64K seg. A seg fault is taken on the seg described by D3. cmpb_onc checks the CPU for cmpb to complete correctly. An op_not_complete fault will occur on a failure. cmpc_a checks the CPU to insure that the indicators are set correctly. An illegal_opcode indicates an error. cmpc_b same as cmpc_a except the data and addresses are changed. sreg_no_write checks that the TRS is used (not the PSR) if a sreq instruction is executed two locations from a page boundary. tnz checks for the conditonal transfer at a page boundary. An illegal_opcode indicates an error. Notes: All the tests run by test_cpu are contained in the segment >system_library_tools>bound_cpu_tests_. This segment has an added name of cpu_tests_. To display the machine condition trace of a test, use the mc_trace command with the test_cpu command. ----------------------------------------------------------- Historical Background This edition of the Multics software materials and documentation is provided and donated to Massachusetts Institute of Technology by Group BULL including BULL HN Information Systems Inc. as a contribution to computer science knowledge. This donation is made also to give evidence of the common contributions of Massachusetts Institute of Technology, Bell Laboratories, General Electric, Honeywell Information Systems Inc., Honeywell BULL Inc., Groupe BULL and BULL HN Information Systems Inc. to the development of this operating system. Multics development was initiated by Massachusetts Institute of Technology Project MAC (1963-1970), renamed the MIT Laboratory for Computer Science and Artificial Intelligence in the mid 1970s, under the leadership of Professor Fernando Jose Corbato. Users consider that Multics provided the best software architecture for managing computer hardware properly and for executing programs. Many subsequent operating systems incorporated Multics principles. Multics was distributed in 1975 to 2000 by Group Bull in Europe , and in the U.S. by Bull HN Information Systems Inc., as successor in interest by change in name only to Honeywell Bull Inc. and Honeywell Information Systems Inc. . ----------------------------------------------------------- Permission to use, copy, modify, and distribute these programs and their documentation for any purpose and without fee is hereby granted,provided that the below copyright notice and historical background appear in all copies and that both the copyright notice and historical background and this permission notice appear in supporting documentation, and that the names of MIT, HIS, BULL or BULL HN not be used in advertising or publicity pertaining to distribution of the programs without specific prior written permission. Copyright 1972 by Massachusetts Institute of Technology and Honeywell Information Systems Inc. Copyright 2006 by BULL HN Information Systems Inc. Copyright 2006 by Bull SAS All Rights Reserved