RD51/52/53 Survival Tips
From Computer History Wiki
An interesting memo written by a field service staff member in 1986:
RD51/52/53 Survival Tips ( or, why is such a small disk causing me so much trouble ) James B. Frazier MSD-CSSE First, a few terms you need to know. There are some differences in this implementation of DSA/MSCP. DSA==> Digital Storage Architecture MSCP==> Mass Storage Control Protocol DSDF==> Digital Standard Disk Format BBR ==> Bad Block Replacement The process used to make the disk appear error free. FACT==> FActory Control Table Where the disk manufacturer writes bad spot info. This info was found with very sensitive testing during manufacture. Written in a non DSDF format. Accessible only to the RQDXn controller. FCT==> Format Control Table Where the RQDXn controller stores bad block info. This info is a combination of the FACT and bad blocks found during format. Written in DSDF format. Accessible only to RQDXn controller. RCT==> Replacement and Caching Table Where the BBR and Revector process stores/finds which RBN replaces a given LBN. Accessible to Host and controller. LBN==> Logical Block Number Where programs and data are stored. Accessible to host and RQDXn. RBN==> Replacement Block Number A block used to replace a LBN that is bad. UIT==> Unit Information Table Where the RQDX3 stores/reads the disk geometry table. When should you format a disk: When should a disk be formatted? Well... a new disk probably has the wrong format on it and obviously needs to be formatted. An existing disk that has been corrupted because of a bad controller, bad cable or bad environment (AC line noise etc.) will need formatting. An existing disk that the user says has a bad block and his program won’t work, or one or more files can’t be accessed, may not need formatting. The first thing to do is check the system error log. All of the operating systems can log the MSCP Status/Event code in the system error log. If that code includes an octal 10 or hex 8, you have found a forced error. The remedy is to replace the file(s) from a backup set, or repair/recreate said file(s). What has happened is that the RQDXn BBR process replaced an LBN with a RBN but couldn’t read the original data safely. The best guess data was written in the RBN with an error flag that forces a Status/Event code of octal 10, hex 8, a "Forced Error". The block in question is no longer bad. The data is. bad. As soon as the file is replaced, and/or this block is written over, the forced error disappears. Now if your customer is reporting lots of problems with bad blocks, the first item should be to check the integrity of the hardware and cables. There is a known problem with the 20 pin and 34 pin connectors that plug into the RD5x, some plugs have exposed conductors extending out from the side, this can short against the skid plate and cause lots and lots of problems. Until the stockrooms can be purged, your only recourse is to inspect all cables and tape them as necessary. Next check the rev levels of all the hardware, RQDX1 controllers should have V9.4 roms. RQDX2 controllers should have V10.0E roms. The RQDX3 has only one version of ucode, so far. [No longer true, see ...] If you upgrade a uPDP23+ RQDX1 from V8.0 to V9.4, or install an RQDX2, check the KDF11-B boot roms, they MUST be at least V.9, part no. 23-183E4 & 23-184E4. V.9 roms are no longer available, so if you need new roms order V1.0, part no. 23-380E4 & 23-381E4, order by using part no. KDF11-B3. Be very aware that an RD5x system reacts differently than a RLO2 system to poor environments. Electrical disturbances, AC line noise, etc., cause retries on an RLO2, on an RD5x the RQDXn starts doing lots of BBR and will eventually fill up the RCT. At this point the RD5x is unusable. If you suspect AC line noise, arrange to loan a DEC CVC to your customer. If that helps, sell him one. ESD can also hurt you, there are many ways to alleviate this problem. Check with district support. During maintenance, always use a anti-static kit. It may be that the RD5x in question was improperly formatted, and the FACT was not used, or the data from the manufacturers sticker was not entered. How to properly format RD5x disks: Once the decision is made to format a disk, backup the data if at all possible! Something you need to know and remember, THE RD51 DOES NOT HAVE A FACT! This is important to know when answering diagnostic setup questions to format the RD51 disk. At this writing we have shipped three different controllers, RQDX1/2/3, with six separate levels of ucode. When you run a formatter diagnostic, it calls to a format program inside the controller’s ucode. This explains why one diagnostic prints slightly different text on the system console when run at several sites. Every rev level of ucode has some subtle changes, including the text used during the format process. For uPDP systems with RQDX1/2 controllers, use ZRQBC1. When the formatter starts you should answer NO to the change HW question unless the RQDX1/2 is not at the standard address. ALWAYS ANSWER NO TO THE CHANGE SW QUESTION !!!!!!!!!!!!!! ALWAYS ANSWER NO TO THE CHANGE SW QUESTION !!!!!!!!!!!!!! The change SW is only useful for APT. Don’t use it in the field. In the case of an RD51, the only safe course is to answer NO to the question "Use existing bad block information <N>:". And YES to the question "Use downline load <N>:", and supply the head, cylinder, and byte offset info from the sticker on the drive. Also answer YES to the question "Continue if bad block information is not accessible <N>:". If there is no sticker on the drive, then say no to the downline load question. In the case of the RD52/53 you should answer YES to the question "Use existing bad block information <N>:", and NO to the "Continue if bad block info is not accessible <N>:" question. If this fails, because it claims it can’t read bad block info, retry and answer NO to the question "Use existing bad block information <N>:". And YES to the question "Use down line load <N>:, and enter the info from the sticker on drive. Say yes to "Continue.." this time. For uPDP systems with RQDX3 controllers and RD51/52/53 drives use ZRQCB2. ALWAYS SAY YES TO CHANGE HW ALWAYS SAY YES TO USE AUTOFORMAT. For uVAXI systems with RQDX1/2 controllers and RD51/52/53 drives, use EHXRQ and the directions for uPDP. The questions are identical. RQDX3s are not supported. [But they do work!] In the case of uVAXII, ALWAYS ANSWER YES TO THE QUESTION "USE AUTOFORMAT MODE". If you don’t have MDM V1.08 or better, get it. Someone in the branch/district is on automatic distribution and should be sharing with all. Drive vs Controller compatibility: The RQDX2 is an RQDX1 with some ECOs and larger RAMs etc. So all of the RQDX1/2 ucode versions can be viewed as a linear progression. 23-188E5-00 & 23-189E5-00 ==> V10.0E RQDX2 Will handle RX50,RD51/52/53 23-178E5-00 & 23-179E5-00 ==> V10.0D RQDX2 Will handle RX50,RD51/52/53 23-172E5-00 & 23-173E5-00 ==> VO9.4E RQDX1 Will handle RX50,RD51/52 23-042E5-00 & 23-043E5-00 ==> VO9.0 RQDX1 Will handle RX50,RD51/52 93-264E4-00 & 23-265E4-00 ==> VO8.0 RQDX1 Will handle RX50,RD51 23-238E4-00 & 23-239E4-00 ==> VO7.0 RQDX1 Will handle RX50,RD51 Now, if by changing the controller, or the proms, you change the ucode revision level up, the new ucode will restructure the RCT/FCT tables on the connected disks to it’s satisfaction. If the ucode revision level is to a lower level, the older ucode won’t understand the disk structure, and the disk(s) will have to be formatted. The ucode is only upwards compatible, not downwards. If you replace an RQDX1/2 with an RQDX3, you MUST reformat the disk. RQDX1/2 controllers have the disk geometry stored in roms. RQDX3 controllers write the disk geometry on the disk during format, (in the UIT) and then read it off the disk after every power up sequence or controller init sequence. If an RQDX3 tries to bring an RD5x drive online and can’t read the UIT, it assumes that the drive is an RD51. The solution is to reformat. If an RQDX2 is configured with 3 RD5x drives and no RX50, the 3rd RD5x (drive 2) has the removable bit set. When a sniffer boot sees this it will try to boot drive 2 first instead of drive 0. How you can help: MSD-CSSE is working on identifying problem scenarios associated with this subsystem. You can help us by reporting specific syndromes/symptoms that you see being repeated at multiple customer sites. Please send as much detail as possible, include exact drive and controller type, firmware rev level, CPU type and rev level, boot rom rev level, box type, operating system etc. Send reports to me at: James B. Frazier MS: ZKO2-1/N42 or on the ENET: PULSAR:: FRAZIER