AT&T 3B2 Frequently Asked Questions
AT&T 3B2 Frequently Asked QuestionsThis article contains the answers to many Frequently Asked Questions (FAQ) often posed to the net. It is posted because the same questions pop up time after time. This will hopefully help out by not having these questions posted over and over, and help new users know what questions there are to ask in the first place! 8^)
This article includes answers to the following questions. Much of the information included in this article is also compatible with the 3B15 series of WE32000 series based computers.
This FAQ originally constructed and maintained by Gregory Gulik, now administered by the 3B2-kind-of-guy, Stephen Friedl (steve@unixwiz.net). Unofficially updated by Robert Martel (bob@wolf.csuohio.edu).
As of mid-2001, Steve Friedl still provides limited support for 3B2 users and will try to help you if you're in a jam. Visit http://www.unixwiz.net/3b2.html for more information.
If you are going to be at all serious about the 3B2, and especially if you are relying on yourself for maintenance, the first thing you want to do is obtain the AT&T 3B2 Computer Maintenance Manual.
A check on 9 July 1997 with AT&T and Lucent Technologies revealed the the 3B2 Computer Maintenance Manual is no longer available. I've left the following information intact so that readers would know what the contents of the manual were.
It contains diagrams of all 3B2 computers up to the 3B2/600, parts lists, breakdown procedures, troubleshooting information, and sources of additional documentation.
In addition, it contains the "3B2 Computer Maintenance Utilities" diskette called "idtools" (formerly known as "devtools"). This floppy is bootable, and once running, the following options are available:
While some of these options are also available from UNIX, all the utilities here can be run on a machine with a damaged (or missing) hard disk, often allowing the drive to be repaired that is otherwise unbootable.
This manual and disk can not be ordered from the AT&T Customer Information Center in Indianapolis, IN. It had select code 305-395, and last sold for $130. The AT&T CuIC can be reached at:
(800) 432-6600 Continental US
(317) 322-6556 elsewhere
The CuiC takes phone orders with a credit card, and with a purchase order for qualifying companies.
Copyright 1989 by Owens-Laing Publications.
Title: Disk Expansion on the 3B2
Author: Stephen Friedl (steve@unixwiz.net)
Issue: 3B Journal, 4Q 1989
[Edited by Gregory Gulik]
[ conventions are: *bold* and _italics_ ]
The 3B2/400 family (/300, /310 and /400) computers use standard MFM disk drives, and it is possible to add or replace these drives yourself -- in this article we show you how to do this.
The 3B2/500 and larger machines all have SCSI (Small Computer Systems Interface) disk drives, so these instructions do not apply to them. For the duration of this article, "3B2" means the 3B2/400 and below, and in the case where there are differences among these included models we will mention them.
Before doing any drive replacement, you must obtain the 3B2 Computer Maintenance Reference Manual from AT&T. This document contains quite a bit of useful information about your 3B2 hardware, and it is helpful in its own right. What makes it so special is the "idtools" diskette that comes with it. This floppy disk contains numerous utilities that will help you diagnose and troubleshoot your computer, as well as the disk formatting tools we need for our expansion project.
This is a fairly technical topic, and it relies on substantial knowledge of UNIX system administration. Those steps directly related to the formatting operation are covered here, but others such as backup and restore from tape, disk space allocation, and rebooting the machine are prerequisite knowledge. AT&T's sysadm documentation covers a great deal of it, but if these things are new to you, perhaps you're not ready to give this a go just yet.
Please keep in mind that if this is not done correctly (especially the backups), you could lost most or all of your computer's data in a very short time. You must have at least one full, verified backup of all filesystems, with two backups being safer. In addition, it is a good idea to try this during an off time when you can afford to be down for while if things don't go so well.
Finally, we have tried to present this information as accurately and clearly as we can, but we cannot guarantee that there are no bugs. Check everything, verify steps with the manual, and ask a local wizard if you get stuck. Of course, you undertake this procedure at your own risk.
There are many drives on the market that are satisfactory, and we present some guidelines here for selecting one. We have our favorites, but most available ST-506 drives can be used in the 3B2. Note that these are suggestions only, not endorsements or guarantees of compatibility.
The first restriction is that the idtools software will not format more than 1024 cylinders in a single drive, and a drive with more will simply have the excess cylinders ignored. This is an unfortunate but unavoidable waste of disk space, giving us a practical limit of about 135Mbyte. (15 heads x 1024 cyls x 18 blks/track x 512 bytes/block).
Most of the drives found in the original 3B2 are made by Control Data (or their subsidiary, Imprimis), and these Wren II drives are of excellent quality, and they represent a very safe route. These drives are available with formatted capacities of 30 and 72 megabytes, and they have an average access time of about 28 msec. Other brands known to work include Maxtor, Miniscribe, Priam, Micropolis and others. Some of these drives have more than 1024 cylinders which allows them to be used, but at less than their advertised capacity.
Each drive in the 3B2 is formatted with a disk type, which is a small number that identifies the drive to the machine. The disk type indexes into a table of drive information, and this table is part of the /dgn/edt_data file. This file is used to fill the Equipped Device Table, a list of currently-available hardware devices maintained by the firmware. Part of this list, the subdevice table, describes the possible hard disk drives.
Now that the formatting tools have arrived and a drive has been obtained, we are ready to do the installation. It is at this point that a full backup of the entire system is in order and to review the relevant portions of the Maintenance Manual.
After backing up the current drives, shut down the machine, turn off the power, and remove the power plug. Open the case, note the current configuration of the drive cables, and remove them along with the power connectors.
Select "drive 0" on the drive select jumpers, insert/enable the terminating resistor, and place the drive back in the cage. Connect drive zero's data cable (the thin ribbon cable), the last connector on the wide control cable, and the power cable to the rear of the drive. Pay particular attention to pin one orientation, and insure that all connections are snug.
At this point you are ready to turn on the machine. Plug in the 3B2 power cable and turn the switch to "ON". The console should show a SELF CHECK, followed shortly by
FW ERROR 1-02: DISK SANITY FAILURE EXECUTION HALTED SYSTEM FAILURE: CONSULT YOUR SYSTEM ADMINISTRATION UTILITIES GUIDE
This ominous message is actually expected, and it just means that the disk drive is not formatted yet. At this point, type your current firmware password (usually "mcp") followed by RETURN, and you will be presented with the normal firmware menu.
At this point you should boot "/idtools" from the floppy drive (load device 0, FD5). Once booted, idtools displays an informational message and asks that RETURN be hit.
Note that this entire process is covered in Appendix B of the Maintenance Reference Manual, and we strongly recommend that you review sections
Hard Disk Formatter (B-8), Defect Table Builder (B-33), and Writing Sanity Track (B-47)
plus the introduction before continuing.
At the first menu, "formhard" should be entered. It will ask which disk should be formatted, and the proper response is zero in most cases. If you are doing this procedure on a machine with two drives installed, be very careful when answering this question.
Next, you are asked for drive configuration information. You must enter the drive type (from a previous section) plus the drive dimensions, and the following table summarizes several models we know about. If your drive is not shown, consult your vendor documentation for this information.
Drive type drv id cyls trk/cyl sec/trk byte/cyl abbrev --------------- ------ ---- ------- ------- -------- ------ Wren II 30MB 3 697 5 18 512 HD30 Wren II 72MB 5 925 9 18 512 HD72 Fujitsu M2243AS 8 754 11 18 512 HD72C Micropolis 1325 5 1024 8 18 512 HD72 Maxtor 1140 4* 918= 15 18 512 HD120 Maxtor 1190 11 1224+ 15 18 512 HD135 Miniscribe XXXX 4* Priam XXXX
* selected by user
+ can only use 1024 cylinders on this drive
= can usually be formatted out to 1024 cylinders, even though it is
actually capable of 1224 cylinders, like the 1190.
Note that "tracks/cylinder" means "heads", and the sectors/track and bytes/cylinder values the same for all drives. The drive ID is shown as 4 for high-capacity drives, and it assumes that this number was inserted into the Equipped Device Table subdevice listing.
In the following examples, user responses are in bold, and the drive shown is a Maxtor 1140. Note that the default entries shown may vary from machine to machine.
Format which disk [ 0 or 1 ] (0)? 0 Drive id: 3- ? 4 Number of cylinders: 687 - ? 918 Numbers tracks/cyl: 5 - ? 15 Number sectors/track: 18 - ? 18 Number bytes/sector: 512 - ? 512
Once these values have been entered, idtools shows where it will place various housekeeping areas on the disk, almost all stored on the first two cylinders. You need not concern yourself with the specific values printed.
The bad block listing (with various alternate names, such as "Flag Track Log") is usually found on a sticker on top of the drive. To simplify data entry, it is a good idea to photocopy this sticker while it is on the drive, because later the drive might not be in such a comfortable reading position (especially if it is in a drive cage).
The first prompt in this section asks if the backup defect table should be modified. A formatted drive normally has two copies of the defect table on disk in case one is lost, but a blank drive has no such table. Answering "yes" to this question means that the data you enter here is stored in both places.
To enter the defects, enter "new" when asked, then "bc" for the type of defect byte count. Then, for each bad sector, enter the cylinder number, the head number, and the byte count, all separated by spaces. This "byte count" field is often shown on the disk label as "BFIND" (bytes from index) or "BCAI" (byte count after index), and it is distinct from the sector number. Most entries have a block length of one, but if the label shows more than this then it must be the fourth field on the line.
An entry of "q" terminates the input, and displays the entire list of blocks entered. It is vital that this list be checked completely, and edits made if necessary. An entry of just a RETURN accepts the current list and moves onto the next prompt.
Format entire disk - type 1 Format single track - type 2 Format from selected track to end - type 3 Select type of format [1, 2, or 3] (1) ?
Entering "1" followed by RETURN starts the formatting process, and when it completes it starts a verify pass where all blocks on the disk are examined for errors. This operation can take some time on a large drive, and idtools shows its progress with a message displayed every five cylinders formatted.
After the format and verify, idtools writes the "sanity track" with the "fixdisk" program. The sanity track contains a special data pattern that validates the drive to the 3B2, and it takes just a moment and requires no input from you.
With the conclusion of the fixdisk operation the drive is formatted. You can remove the idtools floppy and power the machine down.
The machine should now be put back together and the original drives reinstalled. It is important that all drive selects and terminating resistors be installed properly, following the rules mentioned previously.
The first drive in the machine has the lowest drive select jumper (usually position zero) and connected to the zero data cable (usually the bottom drive). The second drive in the machine has the next drive select (usually position one) and the other data cable, and the control cable connects them both. The drive that is at the physical end of the control cable must have the terminating resistor.
Disk drives installed into an XM expansion module have special rules on termination, and these are documented and diagrammed on pages 6-23 and 6-24 of the Maintenance Reference Manual.
The easiest case is adding a second drive to a machine that previously had only one. After installing the new unit, boot /unix from the hard drive and enter single-user mode (this is much easier if you have edited /etc/inittab).
With the /usr partition mounted, run the "sysadm" command, and at each successive menu, enter "diskmgmt", "harddisk", and "partitioning" in turn. This enters the partitioning operation and it should prompt you for the relevant information. We do not discuss strategies for allocating filesystem resources, as this is covered in the AT&T system administrative documentation.
Once the drive is partitioned, the added filesystems (say, /usr2 and /usr3) may be used immediately.
All other cases involve replacing existing drives, and it most expedient to use the full restore procedure for this. A full backup is absolutely required here for this operation, and it should be verified once it is made.
Boot the "Essential Utilities - Disk 1" floppy and select the "Full Restore" operation. This procedure includes a partitioning step that allows you to allocate your new disk resources. Follow the instructions shown on the screen.
After the core set of floppies -- five or six disks -- you can interrupt this process, boot /unix from the hard disk, and restore all of your backups. You may have to install the Cartridge Tape Utilities if your backups are stored on that medium.
WARNING: This "full restore" operation destroys all data on all hard disks during the partitioning, and you _must_ have a full set of reliable, verified backups before considering this step, and two full sets of backups would not be a bad idea. If these backups are not done properly, all data on the disks will be LOST. Please be very careful when doing this, as mistakes can be costly.
Some early models of the 3B2/300 do not permit a 72MB hard drive to be added to the system board. The recognizing signs for this restriction are documented in the Maintenance Reference Manual on page 7-21, and 3B2/300 owners should consult this information before starting this project.
While the documentation does not mention the reason for this restriction, we speculate that any drive with more than eight heads cannot be used in these older machines.
These are the steps I used to add a second swap partition to my 3B2/400. Why add a second swap area? By default, the SVR3.1 system disks (the version I use) make one swap area of 10196 blocks on the first hard disk (/dev/rdsk/c1d0s1). While this 5Mb area seems plenty for most uses, I managed to exhaust it. It was time to RTFM. While the manual gives you the confidence to say that you can increase the number of swap partitions, it doesn't clearly tell you exactly how to go about doing that. What follows are the steps you can follow to add another swap partition to your system.
Are you adding this swap space "just to balance the load"? If so, forget it. The effect is negligible and clearly not worth the effort. I have been unsuccessful in conclusively proving whether or not SVR3.1 does perform balanced allocation of the swap space. It seems to knock a huge chunk off the first partition before it even touches the second one. I would not think of doing this unless you have SVR3.1 or SVR3.2. Earlier versions do not have the advanced swap handling functions, and may not even allow you to do this. Upgrade time. The only reason to add another swap partition is if you have a valid reason to do so (i.e. you have exhausted your present swap space). Remember that swap cannot be used for anything else, you take space away from your mountable filesystems when you add swap space.
Please keep in mind that this is your system, and these steps can easily wipe out all your data files. Take adequate care to back up your data. Make sure your backups work before you start any of this.
IT IS STRONGLY RECOMMENDED THAT YOU HAVE A PAPER COPY OF THESE DIRECTIONS IN FRONT OF YOU AS YOU PERFORM THIS TASK.
BACK UP THE SYSTEM! I cannot stress this enough. If you have a tape drive, use that in preference over the floppy drive. Back up the /, /usr, and /usr2 partitions. While it is not mandatory, it's also a good idea to back up everything else just in case catastrophe strikes. Expect the worst and hope for the best.
Reload the Foundation floppies and select a custom partition setup. Pick the sizes you want for the new swap partitions. Since you are adding a second swap partition, it is up to you if you wish to add to (or keep) the original 5Mb swap partition. It is mandatory that you keep some swap space on the first disk. There is no rule that says the 2 partitions must be equal in size. Finish the full restore.
For Your Information: the sizes of the partitions are dependent on the number of blocks per cylinder group. That means, you can specify size in units of (18 * number of heads). If you specify a number that is not a round figure, the machine will round it for you. RECORD THIS NUMBER!!! This new partition will be named /usrX (where X is a positive integer) and there will be a filesystem made upon it. Do not worry.
Bring up unix, log in as root, and bring the machine to runlevel 1. When the machine is in single-user mode, make sure that all disk partitions are unmounted (except for the root partition!)
Make a temporary file with the existing partition data:
# prtvtoc /dev/rdsk/c1d1s6 > /tmp/disk.data
Edit the disk.data file. Make the following changes: change the tag field from 0 to 3 (from 'user' to 'swap') change the flags from 00 to 01 (unmountable partition) delete all the initial comments (lines with initial *'s) Double check this file to make sure you got it right
Save this data back to the hard disk. If you choose to chicken out, do it BEFORE THIS STEP:
# fmthard -s /tmp/disk.data /dev/rdsk/c1d1s6
Edit /etc/fstab to remove the reference to the now defunct filesystem. You don't have to do anything else to the actual partition to remove the filesystem - the system will page over the superblock and inode lists by itself.
Use /etc/swap to tell the system that the partition is ready for paging/swapping. The best way to do this is to make the system add this partition each time it boots. Create a file called /etc/rc2.d/S00SETSWAP. Link it to the file /etc/init.d/S00SETSWAP. In this file, add the following line:
/etc/swap -a /dev/dsk/c1d1sYY 0 XXXXX
In this case, the Y's in the disk name should be set to the disk partition that the new swap space is to be located on. Usually, this is partition 8 (if you specified the swap space as the first partition on the disk before /usr). The 0 (zero) signifies that swap activity is to start at the 0th block of the partition - the start. Replace the XXXXX with the number of blocks available in the partition. This is the number you recorded in Step 1 above.
Reboot and pray. If it all went well, the machine will come up in multi-user mode. Once again, log in as root and bring the machine down to single-user state. Make sure that the system is actually using the new partition with the
# /etc/swap -l
command. You should see the original swap partition (/dev/dsk/c1d0s1) as well as your new partition listed.
If your machine did not boot for some bizarre reason, reload the system again (go to step 1), making sure that you do everything correctly.
Restore your data. If you backed up on floppy, just restore them in order and reboot. If you backed up on a CTC tape drive, you must install the Cartridge Tape Utilities disk, reboot, recover your data, and reboot one last time. IF you didn't back up your data, then you're SOL.
A note to those with XDC and SCSI drives - the maneuvers you have just completed only messed up the data on the 2 internal disk drives. Any data on your 3rd (and higher) drives should remain untouched.
There is another way to do this whole thing without reloading the entire OS. It involves having a boot floppy with prtvtoc, fmthard, swap, and a few other files on it. You would have to make this before hand (explained in a different question). In this instance, you would only alter the partitions on the disk you added the new partition to. This, however, would force you to re-create and restore filesystems on the partition(s) you borrowed space from. For my time and money, it was easier (and less error-prone) to add the swap partition by reloading the Foundation disks. True Blue Gurus (TM) can experiment with the second method.
Comments and criticisms welcome.
Jeffrey L. Bromberger ------- System Manager ------- Tramway Unix Systems
jeffrey@squid.tram.com Anywhere!{van-bc,limbic,icus}!tram!jeffrey
From: aj4640@dean1.usma.edu Robertson John MAJ at US Military Academy, West Point, N
[Read the P.S. at the end of this message before attempting to ftp these files.]
The X11 R4 distribution tape contains sources to run clients on a 3b1. Several of us have hacked those sources to enable clients to run on a 3b2.
I wish I could offer the source patches directly but for various reasons, I can't. However, 3b2 users are more than welcome to have the clients, the libraries, the include files, and the pre-processor. This will get X-windows up on your 3b2 without the xdaemon stuff (as long as you have the Wollongong networking stuff.) With this stuff, you'll have a pile of ready-to-run clients as well as the tools needed to compile your own X11 applications.
In addition to the default X11 R4 clients, bin.tar.Z also has a running copy of tgif, xdvi, xmahjongg [you'll need to do the fonts for your server. UTSL!], and lots of other neat stuff.
The lib.tar.Z contains libX11.a, libXt.a, etc. In addition, the app-defaults for all the clients in bin.tar.Z are also here.
include.tar.Z has all the include files. You'll need these if you want to compile your own stuff.
cpp.tar.Z is a compiled version of the X11 distribution preprocessor. In this version, you'll need to define the symbol 3b2 before invocation. It will not gag on the big header files that many X applications use.
The files can be obtained via anonymous ftp from euler.math.usma.edu. They are in pub/3b2. Other than unpacking and installing the clients and lib stuff in the usual places, no other special work should be needed.
I cannot offer any support for this stuff. Take it, hack it, and have fun. Even more, give the clients away to other suffering 3b2 users. It has made our 3b2's substantially easier to use.
Jack
P.S. The X11R4 clients for the 3B2 have been moved to Bradley University on erratic.bradley.edu in pub/3B2_X. If that system is down, you may want to also try ds3.bradley.edu, also in pub/3B2_X.
From: geoff@ugc.uucp (Geoff Coleman)
[This item covers adding a third party SCSI drive to a 3B2 only as additional partitions to the ones on the internal MFM disks. Another item in this FAQ discusses uses a SCSI disk for the root and swap partitions as that is a considerably more involved procedure.]
The hardware installation is relatively simple. The SCSI address of the disk must be set via jumpers. If the disk being added is the first outside disk for the 3B2 then the you must use an "AT&T SCSI Connect Kit".
After the disk has been physically attached the machine should be restarted. If the disk is one that is unknown to the 3B2 a message will appear on the console that there is an unknown scsi device "make" "model". The make and model information is important.
Once the 3b2 is rebooted login as root and cd to /etc/scsi. At this point you should run ./edittbl -l to list all of the SCSI devices known to the system. Then insert a new entry into the device table with the .edittbl -i command. The first entry is the make and must be padded with spaces to 8 characters. The second entry is the model and must be padded to 16 characters with spaces. The number of lu's is one unless it is a bridge controller.
At this point you should reboot the machine and there should be no unknown device error message on bootup.
Once the system has been rebooted login as root and change the run level to single user mode and remount /usr if need be.
At this point you need to cd to /usr/lib/scsi and edit the file tc.index. Add an entry for the new disk in the same manner as the other entries in this file. Make sure that the model number starts in column 9 and is padded out to 16 characters, if you receive an unable to open script file message on formatting the problem is most likely in this entry.
At this point you can run the format program from either sysadm or the command line. After the format has finished reboot the system and the disk should be listed as a formatted disk.
The EPORTS board can easily handle 38.4K baud on an otherwise unloaded system, provided Hardware Flow Control is enabled. The hard part is keeping HFC enabled. Several solutions to this problem exist, but one that seems to work is (1) to have a daemon set HFC on open lines periodically, and (2) have uugetty enable HFC on all logins.
Some people have found the 1.2 version of the EPORTS driver to be buggy, and that 1.3 allows for significantly higher throughput.
Elliot Dierksen submitted two solutions to this problem. Each one addresses the problem in two different ways. The first one enables HFC when a user logs in a HFC capable serial port. The second one is a daemon spawned by init(1) that periodically enables HFC on specified serial lines.
From: elliot@oau.org (Elliot B Dierksen)
Step 1: copy uugetty to some new name (I used epuugetty). Use some sort of binary editor to change the exec of '/bin/login' to '/bin/ephfc'.
Step 2: compile ephfc. Here it is!
I have had no problems with this at all, but your mileage may vary. No promises implied or intended. Even with cron entries to set HFC, I still have problems on occasion with dial outs. Inbound calls work great.
I hope you all find this useful!
I made some more changes to sethfc. Somebody didn't like my system where init respawned it every 60 seconds. Actually, I didn't like it much since it was making my wtmp file HUGE! I made sethfc2 able to take multiple tty arguments and added a daemon mode. Here is the inittab line:
hfc:234:respawn:/etc/sethfc2 -C -E tty21 tty31 tty34 # Set Hardware Flow Control
And here is the program (comments welcomed):
From: v.hoang@att.com
It means more files being opened than the limit you've set for the system. Edit /etc/master.d/kernel and bump up the values of NFILE, NINODE & NS5INODE (or something close to that), then cd /boot, mkboot -k KERNEL, touch /etc/system then reboot the system.
From: rdc30@nmrdc1.nmrdc.nnmc.navy.mil (LCDR Michael E. Dobson) Subject: Anonymous ftp with WIN/TCP 3.0.x YES!!
Contrary to the documentation for WIN/TCP 3.0.{0,1}, it is possible to set up anonymous ftp. The Bugs: note in the documentation about it not being fully implemented in this release seems to be just a documentation omission. I saw the method to use on a US military 3B2 Users Group mailing list. The missing parts are the creation of a dev directory in the root of the ftp account directory with null and tcp devices created with mknod, and the inclusion of the services file in the etc subdir along with group and passwd files. You of course need ls & pwd in bin and a pub tree. Below is the output of ls -lR in my ftp root as well as the passwd in ~ftp/etc/passwd. Try it out and see.
total 5 drwxr-xr-x 2 root other 64 Jan 23 11:12 bin drwxr-xr-x 2 root other 64 Jan 23 11:09 dev drwxr-xr-x 2 root other 80 Jan 23 11:13 etc drwxr-xr-x 2 ftp sys 240 Jan 23 11:16 pub drwxr-xr-x 2 root other 64 Aug 28 20:01 shlib /usr3/ftp/bin: total 111 ---x--x--x 1 root other 35678 Jan 23 11:11 ls ---x--x--x 1 root other 19551 Jan 23 11:11 pwd /usr3/ftp/dev: total 0 crw-rw-rw- 1 root sys 63, 43 Aug 28 19:57 circ crw-rw-rw- 1 root sys 49, 2 Jan 23 11:09 null crw-rw-rw- 1 root sys 63, 38 Jan 23 11:09 tcp crw-rw-rw- 1 root sys 63, 36 Aug 28 19:56 udp /usr3/ftp/etc: total 4 -r--r--r-- 1 root other 336 Jan 23 11:12 group -r--r--r-- 1 root other 56 Jan 23 11:13 passwd -r--r--r-- 1 root other 884 Jan 23 11:12 services /usr3/ftp/pub: total 0 /usr2/ftp/shlib: total 211 -r-xr-xr-x 1 root other 66626 Aug 28 20:01 libc_s -r-xr-xr-x 1 root other 39859 Aug 28 20:01 libnsl_s Contents of ~/ftp/etc/passwd: ftp:x:13:1:Anonymous FTP Account:/usr3/ftp:/usr/bin/ftp -- Mike Dobson, Sys Admin for | Internet: rdc30@nmrdc1.nmrdc.nnmc.navy.mil nmrdc1.nmrdc.nnmc.navy.mil | UUCP: ...uunet!mimsy!nmrdc1!rdc30 AT&T 3B2/600G Sys V R 3.2.2 | BITNET: dobson@usuhsb or nrd0mxd@vmnmdsc WIN/TCP for 3B2 | MCI-Mail: 377-2719 or 0003772719@mcimail.com
A special note from Steven M. Kilby >skilby@ucqais.cba.uc.edu<&
Setting up an anonymous FTP login for the 3B2/400 differs slightly from the instructions in the FAQ. The FAQ instructions will work on 600's or 1000's. The only changes are in the directory setup.
[As other people found the original anonymous FTP setup did not work at all without Steven M. Kilby's changes, I modified the directory structure above to reflect Steve's changes. -greg]
From: Kevin Darcy >kevin@cfctech.cfc.com<
Also, you should probably make people aware that the exact minor numbers for all clone devices will vary from system to system, and to only use the ones displayed as a guide. For instance, my dev entries for circ, tcp & udp are
crw-rw-rw- 1 root other 63, 66 Sep 10 1991 /dev/circ crw-rw-rw- 1 root other 63, 56 Sep 10 1991 /dev/tcp crw-rw-rw- 1 root other 63, 58 Sep 10 1991 /dev/udp
which is somewhat different than what's shown above (cfctech's major numbers are higher than most folks', because we have run StarLAN, Datakit & WIN/TCP all simultaneously on the machine, in addition to everything on the release tape, and, at one point, even loaded X Windows on the box (!)).
The following are some 3B2 ftp sites that I know of and what they contain:
little.nhlink.net (204.89.239.98)
bioforge.biology.lsa.umich.edu (141.211.76.204) - (Unable to log in.)
contents of little.nhlink.net, ames.arc.nasa.gov, and additional DMD/Layers software
erratic.bradley.edu (136.176.5.253) - GONE
old gcc
stasi.bradley.edu (136.176.5.121) - GONE
lpr/lpd
ames.arc.nasa.gov (128.102.18.3) - GONE
Kyoto-Lisp, Pascal, Sendmail, citadel-bbs
(I checked all these sites on 08 September 1998. If there are any I've missed or have been added since, please let me know)
NB: the procedures described here require substantial knowledge of UNIX and entail a significant risk of causing loss of data. The obvious disclaimers apply here, so use at your own risk. Please be careful.
This document is an introduction to operating your 3B from a standalone /unix. Even with inoperable hard drives, it is possible to insert the boot floppy (Essential Utilities Disk 1), say some magic words, and receive a # prompt. At this point you can do major surgery on the failing machine, often recovering a drive previously thought to be lost.
Our style is informal and we'll use lots of examples to illustrate the points at hand. We have been using standalone shells for quite some time and have learned a great deal; we hope to pass this information on to you. Please read this document carefully before trying the methods described here, and if possible have a wizard around when giving it a go. This can be dangerous business: as has been said before, it is a time where experience and informed courage count for much.
Throughout this document, sample usage sessions will be shown indented, with user input in bold. To make it easier to distinguish between a multiuser UNIX shell and a standalone one, we will show multiuser UNIX's root prompt as ## and the standalone prompt as #.
This cannot be emphasized enough. Your boot floppies are the key to your machine, and without them the machine is down.
The most compelling reason for a standalone shell is when the primary drive has gone down and must be recovered. While working from a standalone /unix is slow and tedious, it can often save an entire hard disk with minimal data loss.
We have also used this standalone shell to repair a corrupt /etc/inittab, to fix /etc/passwd, to restore a /bin/login that had been removed, and to install new bootstraps on the hard drive. With a standalone boot disk in hand, a host of possibilities presents itself.
Before booting this floppy, take some time to explore its contents, as the disk has a filesystem on it that can be mounted and perused. To do this, insert a COPY of the Essential Utilities Floppy 1 (from now on, "the boot floppy") into the drive with a write-protect tab. Now,
## mount /dev/dsk/c0d0s5 /install -r
Because boot floppies vary from release to release, it would be most helpful to simply get a listing of the contents of your particular boot floppy.
Once finished, the floppy must be unmounted:
## cd /
## umount /dev/dsk/c0d0s5
"Open Sesame"
To give standalone a try, first shut the machine down to firmware mode. Assuming the machine is now in firmware mode, put a copy of the boot disk into the drive. Note that some versions of the operating system (Sys V Release 2, at least) require that the boot floppy be write-enabled (i.e., no write-protect tab); it is this requirement that mandates multiple backups of the boot floppy. UNIX will be updating the disk while it runs -- the superblock, access times, etc. -- and if the machine crashes at the wrong time it simply will not boot again without an fsck. Be careful.
Type in your firmware password and boot /unix from the floppy drive (Option 0, named `FD5') instead of the hard drive (Option 1, named `HD30' or `HD72'). It can take several minutes for UNIX to boot, but when it does, the familiar menu will be displayed:
1) Full Restore
2) Partial Restore
3) Dual-Disk Upgrade
4) Release Upgrade
Selection? [1, 2, 3, 4, quit, help]
At this point, type the phrase
magic mode
The system recognizes this special option and responds:
Poof!
Selection? [1, 2, 3, 4, quit, help, shell, copy]
Notice the new options? Now type shell, then RETURN, and you will be greeted with the familiar # prompt. You are now running a standalone shell on the floppy.
A few reminders here: a floppy filesystem is not able to hold much data, and many common utilities are unavailable. When dealing with the standalone shell, one must learn alternatives to these utilities. For example, echo * can replace ls(1), and cat > file can serve as a poor replacement to ed(1). One must become remarkably resourceful when working in an environment as restricted as this. We will see later how we can enhance this confined environment with additional tools.
The floppy's /dev directory contains a host of entries, some of them referring to partitions on the hard drive. While a particular partition may have several names, we generally use the following devices to refer to the hard disk:
Partition What it is (on the hard disk)
----------- -----------------------------
/dev/idsk00 / filesystem
/dev/idsk01 swap area
/dev/idsk02 /usr filesystem
/dev/idsk06 the entire disk
/dev/idsk07 boot partition
/dev/idsk08 optional filesystem (/u or /usr2)
To gain access to the primary hard drive, partitions of interest are mounted onto directories on the floppy. The device names are selected from the table in the previous section.
Before mounting a partition, we recommend running the filesystem check fsck(1m) first. The mount command will fail if the the superblock is not in order -- this is often the case after a crash. In addition, it gives a convenient verification of the device status and the the filesystem's name and volume.
# /etc/fsck /dev/idsk00
While some errors are to be expected while checking the root partition, a total failure is a very serious error. Our experience defines "total failure" as an indication by fsck that it cannot find any possible traces of a filesystem. In particular, "CAN NOT READ: BLK 1" is one of the more ominous messages we have seen.
Once fsck grants the filesystem a clean bill of health, it is ready to be mounted. Rather than take up space for a handful of common commands, AT&T has rolled several of them into one: fsys. It is undocumented and appears to only be used on the boot floppy. Some versions of the boot disk do contain the mount and umount programs and those can be used instead of fsys.
Fsys takes a handful of options, not all of which are interesting to us in standalone mode. Used in the install scripts for a handful of filesystem-related duties, we will use it simply as a replacement for mount(1m) and umount(1m). To mount the hard disk's root filesystem onto the floppy's /install directory, do:
# fsys -m /install /dev/idsk00
Fsys will complain on an error, and this brings us to a serious bug in this program: if either the mount directory or the partition's device name are invalid for any reason, the error message will always point to the partition device name. This can be, to put it lightly, "misleading"
With the hard drive's root filesystem mounted on /install, it is now fully part of the standard directory tree. While the floppy has no editor or many of the helpful tools, the root partition does, and these can be exploited. When beginning an extended standalone session on the primary drive, we have found it helpful to extend the shell's search path:
# PATH=/install/bin:/install/etc:$PATH ; export PATH
Now the familiar ls, ed, (but not vi) and many other commands are available. Since they will be loaded from the hard drive, execution is much faster.
As an example, assume that the root password has been forgotten and the machine is basically closed. The solution suggested by AT&T's documentation (in the System Administration Utilities Guide) is to do a partial restore. The difficulty with this approach is that many important system files -- /etc/passwd, /etc/inittab, /etc/gettydefs, and others -- are overwritten in the process. Even with a full backup, this can be an unpleasant undertaking.
An alternate approach will use the standalone shell. The general strategy is to mount the hard drive, edit the password file, and boot multiuser UNIX. The full procedure is:
(boot standalone /unix)
# fsck /dev/idsk00
# fsys -m /install /dev/idsk00
# /install/bin/ed /install/etc/passwd
(edit the file in the standard way)
w
q
# fsys -u /dev/idsk00
At this point, the root drive is now unmounted and the system may be rebooted. Normally you can just type exit at the shell prompt and you will be returned to the monitor and asked what program to boot. If that doesn't work on your version, try:
# sync
# sync
# /etc/uadmin 2 2
Uadmin(1m) is documented in the manual (you must also refer to the uadmin(2) manual page) -- the above does a normal return to the monitor (i.e., firmware). WARNING: uadmin(1m) is available from full UNIX as well but is very dangerous. Use it with extreme caution and only if you really know what uadmin does.
================== WARNING ================
Only do this on backup copies of the disks,
NEVER to the main Essential Utilities Disk.
================== WARNING =================
The Essential Utilities Disk 1 contains many files needed by the automatic restore/upgrade procedures, but for standalone work, many are not needed. After working with these disk for some time, we were able to narrow down what is helpful to have on the disk and what is not. The following procedure (run from multiuser mode, signified by the ## prompt) will convert an Essential Utilities disk to a standalone boot disk.
(from hard disk UNIX)
## fsck /dev/dsk/c0d0s5
## mount /dev/dsk/c0d0s5 /install
## cd /install/inst/bin
## mv fsys pdinfo swap ttyset ../../bin
## cd /install
## /bin/rm -rf inst
## cp /bin/ed /install/bin
## cp /etc/fsdb /install/etc
## cat > /install/inittab
is:s:initdefault:
sh:s:respawn:/bin/sh < /dev/console > /dev/console 2>&1
^D
## cd /
## umount /dev/dsk/c0d0s5
While there may be other files on this floppy that are not needed, we have operated on the principle of least customization. It has been our experience that keeping the procedure simple allows it to be done on-the-fly (say, at a customer site) and minimizes the exploration required when a new operating system disk is released.
In addition, it is not wise to pack the disk too tightly. The editor requires adequate space under /tmp, so an almost-full disk precludes editing all but the smallest files; this applies whether the file being edited resides on the hard drive or the floppy.
Once this is done, the new disk will come up in standalone mode without the need for magic mode. In addition ed(1) and fsdb(1m) are available. The other tools mentioned (pdinfo, swap, ttyset) are helpful but not required by the basic procedures.
It has been our experience that any version (SVR2, SVR3) of boot disk can be used with any version of hard disk UNIX without difficulty for doing simple operations such a performing filesystem checks or editing /etc/passwd. For more complex operations, such as repartitioning the hard drive or restoring the bootstraps, higher version compatibility is required.
It should be apparent that knowledge of these standalone methods is tremendously powerful. In addition to being able to rescue a floundering machine, an unrestricted path to root has been provided as well. While all the standard rules about physical security of the computer apply here, an additional step may be taken to thwart a would-be interloper.
The responsible system administrator of a machine in a hostile environment will generally change the computer's firmware password. This magic word is required before the monitor on the 3B2 motherboard will boot from a floppy, and lack of this password prevents a malicious user from simply pulling the power plug to enter firmware mode.
In addition to changing the firmware password, the floppy key floppy should itself be secured. When the computer is restarted with this disk in the drive, it will clear the non-volatile RAM (NVRAM) and restore the default parameters. Because the firmware password is included in these "default parameters", this disk should be kept out of non-trusted hands.
We solicit bug reports, comments, and suggestions on this document. Please direct them to:
Stephen J. Friedl Software Consultant Orange County, California USA steve@unixwiz.net
The 3B Journal was put out sporadically by Owens-Laing Publications for several years in the late 1980s, and I used to be the technical editor. The magazine dealt with the 3B1 and 3B2 platforms, and the content varied from very markety-oriented to quite technical (the latter usually written by me).
The publisher never seemed to get a handle on the business end of running a magazine, and I've heard nothing past the fourth quarter, 1989 issue. The current phones are disconnected, and I have NO information on subscriptions or anything like that.
-- Stephen Friedl steve@unixwiz.net 3/12/1992
[I'm putting this together mostly from memory and from discussions with other people. Please feel free to make corrections.]
Some corrections/additions provided by Andrew D. Hay >adh@petrel.att.com<, Paul S. Sawyer >paul@unhtel.unh.edu<, Mike Crom >crom@vogon.att.com<, David Beneman >..!uunet!tacoma!dcb<, Paul Rak >pjr@emo.com<, Kevin Darcy >kevin@cfctech.cfc.com<
3B2/300 Processor: WE32000, 8 MHz almost 1 MIPS Memory: Supports a maximum of 4 MB of RAM using two half height 2 MB memory cards. Slots: 4 standard slots. Features: MFM disk controller on motherboard 1 internal full-height drive bay 1 720 K floppy drive 3B2/310 Processor: WE32100, 10MHz (supports optional MAU) 1.1 MIPS Memory: Supports a maximum of 4 MB of RAM using two half height 2 MB memory cards. Slots: 4 standard slots. Features: MFM disk controller on motherboard 1 internal full-height drive bay 1 720 K floppy drive 3B2/400 Processor: WE32100, 10MHz (supports optional MAU) 1.1 MIPS Memory: Supports a maximum of 4 MB of RAM using either two half height or full height 2 MB memory cards. Slots: 12 standard slots. Features: MFM disk controller on motherboard 2 internal full-height drive bays 1 720 K floppy drive 1 23 MB cartridge tape drive 3B2/400S Same as 3B2/400 but with a SCSI controller. 3B2/500 Processor: WE32100, 18MHz 2.1 MIPS 2.6 MIPS w/VCache 4.0 MIPS w/PE Memory: 2 - 4MB cards max Slots: 7 I/O + 4 system (MEM0, MEM1, Vcache, BUB0) There is also BUB1, but it is listed as unusable without the 22MHz upgrade. Features: SCSI disks Up to 1 additional PE 3B2/522 Processor: WE32200, 22MHz 5.0 MIPS Memory: 2 - 16MB cards max Slots: 7 I/O + 4 system (MEM0, MEM1, Vcache, BUB0, BUB1) Features: SCSI disks Field upgraded 3B2/500 to same processor as 3B2/700 Up to 1 additional PE 3B2/600 (aka 3B2/1000-60) Processor: WE32100, 18MHz 2.6 MIPS 4.0 MIPS w/PE Memory: 4 - 4MB cards max Slots: 12 I/O + 12 system Features: SCSI disks 120MB SCSI tape Up to 3 additional PEs 3B2/700, 3B2/622 (aka 3B2/1000-70) Processor: WE32200, 22MHz 4KB PCache 5.0 MIPS 7.5 MIPS w/1 PE 8.5 MIPS w/2 PEs 9.0 MIPS w/3 PEs Memory: 4 - 16MB cards max Slots: 12 I/O + 12 system Features: SCSI disks 120MB SCSI tape Up to 3 PEs The 3B2/622 is a field upgrade for the 3B2/600 3B2/1000, 3B2/600G (aka 3B2/1000-80) Processor: WE32200, 24MHz 9 MIPS 16 MIPS w/3 MPEs Memory: 4 - 16MB cards max Slots: 12 I/O + 12 system Features: SCSI disks Up to 3 MPEs 3B2/1050 R3 Processor: MIPS R3000A, 33MHz Memory: 16MB - 32MB Slots: 7 - One slot used by SCSI HA Card Features: 320/525 MB SCSI Tape Drive 600 MB Internal Disk Drive 1 720 KB Floppy Drive Up to 36 GB external SCSI disk space Up to 50 Serial Connections (298 with FXM) 3B2/1100 R3 Processor: MIPS R3000A, 33MHz Memory: 32MB - 64MB Slots: 11 - One slot used by SCSI HA Card Features: 320/525 MB SCSI Tape Drive 2 600 MB Internal Disk Drives 1 720 KB Floppy Drive Up to 50 GB external SCSI disk space Up to 82 Serial Connections (330 with FXM) 3B15 Processor: WE32100 (standard MAU) (14MHz WE 32100) 1.6 MIPS 2.2 MIPS with co-processor Memory: 2 MB / 16 MB Slots: Features: Standard 9-Track tape drive Uses 8 inch SCSI drives NOTE: Not all 3B15s have SCSI. Some models were converted from 3B5s and have 8 inch FSD drives (maximum 8, 160 MB or 340 MB). Then there are the Lark II drives. The non-SCSI tape bus can take 1-4 drives. The 3B5 becomes a 3B15 by a change of 2 (??) boards, and most importantly, a new name sticker! 3B4000 Processor: WE32100 from 3B15 as control processor 1 to 6 3B2/600's as attached processors Memory: Slots: Features: Supports tons of SCSI disk
Name Device Code Description ---- ------ ----------- SBD 0x0001 System motherboard NI 0x0002 10base5 ethernet card SW Name Function ------- -------- NI TCP/IP NAU StarLAN 10 PORTS 0x0003 Ports card. 4 serial, 1 parallel. (includes HPP) CTC 0x0005 Cartridge tape controller. 23 MB NAU 0x0006 Network access unit. 1 MB STARLAN SPSC 0x0045 X.25 adapter SCSI 0x0100 SCSI host adapter AIC 0x0101 Alarm interface circuit EPORTS 0x0102 Extended ports. 8 serial ports ISC 0x0201 Intelligent serial controller SW Name Function ------- -------- SNABSC 3270 Emulation,RJE (old) (Bisync/SNA) SI 3270 Emulation,RJE,LU6.2 (Bisync/SNA) X25 X.25 Communication XDC 0x0204 External disk controller for 2 more MFM drives FXM 0x0215 Fiber eXpansion Module DKIT 0x0308 "Datakit" fiber-optic card (connect to datakit/ISN switch) MAU 0xFD00 Math accelerator unit VCACHE 0xFE00 Extended memory cache (3B2/600 and higher, exc. 3B2/1000-80) MPB 0xFF00 Multiprocessor board (3B2/600 and higher, exc. 3B2/1000-80) MPB 0xFF01 Multiprocessor board (3B2/1000-80 only)
John L. Wehle ported GCC to the WE32000 series processor, and it first appeared in release 2.2 of GCC.
To build the GCC 2.3.3 release on the 3B2, download the latest GCC distribution and allocate at least 40 MB of disk space to do the build. Follow the directions in the INSTALL file. The following are some notes that will make the install go smoother.
If you are already using GCC 2.2.2, use that and follow the directions as listed in the INSTALL file. It's by far the easiest way to go. Here is a summary:
$ configure --target=3b2 $ make LANGUAGES=c CC=/usr/local/bin/gcc $ make stage1 LANGUAGES=c CC=/usr/local/bin/gcc $ make LANGUAGES=c CC=stage1/xgcc CFLAGS="-Bstage1/ -g" [continue with the common directions below]
If you don't have a previous version of GCC available and will be using the AT&T supplied compiler, there some special thing you're going to have to do. First of all, older versions of /lib/cpp are not capable of processing one of the source files. I recommend building the distribution until the GNU cpp is done. Then, temporarily replace your /lib/cpp with the GNU version, and add the following flag to CFLAGS in the Makefile:
CFLAGS = -U__STDC__
When stage1 is complete, you could remove the -U__STDC__ flag and restore your original cpp.
Basically, the steps are as follows:
$ configure --target=3b2 $ make LANGUAGES=c [Building cccp.c will probably fail. Fix the cpp as described above] $ make LANGUAGES=c $ make stage1 LANGUAGES=c $ make LANGUAGES=c CC=stage1/xgcc CFLAGS="-Bstage1/ -g"
[It is important to note that due to a bug in the AT&T compiler, the optimizer doesn't get compiled correctly at this point.]
The following are the common directions for old GCC users and AT&T compiler users.
$ make stage2 $ make CC=stage2/xgcc CFLAGS="-Bstage2/ -g -O"
[Some people still have problems with the optimizer at this point. If you do, just do not use the -O flag when compiling GCC. The symptom you will experience that tells you the -O flag should be removed is the compilation of cccp.c will take a VERY long time. Kill the compile and restart without the -O.]
$ make stage3 $ make CC=stage3/gcc CFLAGS="-Bstage3/ -g -O"
To optionally verify everything built correctly:
$ for file in *.o; do > tail +10c $file > foo1 > tail +10c stage3/$file > foo2 > cmp foo1 foo2 || echo $file > done
Then, to install the distribution:
$ make CC=stage3/gcc CFLAGS="-Bstage3/ -g -O" install
Good luck!
[These notes are a combination of my own experiences with building the GCC compiler on a 3B2/400 and discussions with John Wehle, the author of the port.]
The GCC binaries available on several anonymous FTP sites will not work with certain version of the standard C compiler. It appears to be some sort of linker problem. I may have a fix for it. Contact me via E-mail if you fall into this category.
Speaking of linker problems, GCC 2.2.2 will not work all that well with the standard C shared library -lc_s. The workaround for this is to compile your program with GCC, but the link will fail. When it does, use something like the following to do the link stage:
$ cc -O -L/usr/local/lib/gcc-lib/we32k-att-sysv/2.2.2 program.o \ -o program -lgcc -lc_s
This way, you will not only get fast binaries, but small ones as well. This problem has been corrected in 2.3.2 (Thanks Stallman!)
You may need to raise your ULIMIT to compile the g++ compiler as the executable is larger than 1 MB.
The full error message resembles the following:
FW ERROR 1-01: NVRAM SANITY FAILURE
DEFAULT VALUES ASSUMED
IF REPEATED, CHECK THE BATTERY
The 3B2 stores information such as the time of day clock and machine name in non-volatile memory. The memory is backed up by a Lithium battery, that does die after a few years. The battery is normally located in the right side of the case, near the cards, and connected to the motherboard under the card in slot 2. Replacing the battery almost always requires the complete removal of the card cage. Replacement batteries can be found at some electronics stores. I won't list exact specifications because I have seen 3 different types of batteries so far, and there may be more. Your best bet is to just buy another batter with the exact same voltage and modify the connector to fit.
Rumor has it that there was one written by Wollongong, but AT&T purchased exclusive marketing rights to WIN TCP/IP for the 3B2, but chose NOT to include SLIP. There is the NOS (KA9Q) package that supposedly provides SLIP capabilities, but I have not tried it and don't know if it'll run on a 3B2.
Timothy Goodin (tgoodin@apex.net) has made a start of porting a slip package to the 3B2/400 running SVR3.2 and Wollongong "Enhanced" TCP/IP. This is NOT a working package but a start. The work thus far can be found on little.nhlink.netin the /pub/att/slip directory. Tim invites anyone interested in the project to lend a hand. See the README file for details.
From: Steven M. Kilby (skilby@ucqais.cba.uc.edu)
The rexecd released with WIN TCP for the 3B2 has the following bug. This bug has been verified on a 400 with TCP 3.0.1 and 3.2. When executing a command using the rexecd daemon, the gid of the user is set and left at root. This is very apparent when executing a command that creates a shell, such as XTerm. The only available solutions at present are to rewrite the daemon yourself, or.... not run it. The problem has been reported to CERT.
The person to contact about 3B2 software is Kristine Schneider [708-979-1017]. I called her and obtained the following information about NFS:
Latest Versions: 1.3 Requires: System V Rel 3.2.1 or 3.2.3, WIN/TCP 3.2 or higher Product Code: C274-0NB3-000 List Price: $1295.00
This package is for the WE versions of the 3B2. NFS comes bundled with SVR4 for RISC-based 3B2's. TCP/IP on the other hand, does not and has to be purchased separately.
Watch for a bug in the install shell script.
The connectors 3B2's use are called RJ-45. They are 8 conductor telephone like connectors, and lucky for us, are pretty standard. You can either buy the cables and connectors from AT&T for an arm and a leg, or elsewhere. I don't know about the cables, since I've never bought them from anyone but AT&T, but I have made my own RS-232 connectors with excellent results.
The following is an excellent description of the RJ-45 port on the 3B2:
From: rthomas@hakatac.almanac.bc.ca (Robert N Thomas)
Looking into the 8 pin modular RJ-45 jack you'll see that pin 1 should be on the right.
Diagram of what you should see when looking at an 8 PIN modular jack connector.
+----------+
| 87654321 |
| |
+--+ +--+
| |
+----+
Ok, not all 3B2 8 pin modular jack connectors are created "EQUAL". These beasties are used for running StarLan 1MBit, EPORTS cards, PORTS cards, as well as for running ETHERNET 10MBits as well
The pin outs for the two modular jack cables on the back of the 3B2, as well as for the PORTS card should be as follows:
PIN Lead Direction Explanation
===== ========== ============= ========================
1 PROT GRD Ground
2 reserved Not Connected
3 TXD0 Out Transmit Data
4 DTR0 Out Data Terminal Ready
5 RXD0 In Receive Data
6 DCD0 In Data Carrier Detect
7 SIG GRD Signal Ground
8 reserved Not Connected
The 2 modular jacks on the back of your machine should be labeled console and contty. If your talking about a PORTS card, here is what one looks like:
Centronics connector
for Parallel Printer
|
\|/
+------------+ +----+ +----+ +----+ +----+
\ / | | | | | | | |
\________/ +-__-+ +-__-+ +-__-+ +-__-+
^ ^ ^ ^
The above 4 RJ45 connectors are for
plugging serial terminals into your 3B2.
The EPORTS card is card that has 8 RJ45 connectors (8 pin modular jacks) on it. This card is where you would want to plug a high speed modem onto your system, because the above connectors DO NOT SUPPORT HARDWARE FLOW CONTROL. The PIN OUTS for the EPORTS card are as follows:
PIN Lead Direction Explanation
===== ========== ============= ========================
1 PROT GRD --- Ground
2 CTS In Clear to Send
3 TXD0 Out Transmit Data
4 DTR0 Out Data Terminal Ready
5 RXD0 In Receive Data
6 DCD0 In Data Carrier Detect
7 SIG GRD --- Signal Ground
8 RTS Out Request to send
Most 3B2 systems need to do the following to enable hardware flow control. Otherwise the 3B2 will ignore RTS & CTS. Also see the FAQ item about handing high speed modems on EPORTS cards for more detailed information.
epstty hfc <-- XON/XOFF flow control must be disabled before you do this. The stty command is one way to disable XON/XOFF. Line DISCIPLINES are another way to do this. See etc/gettydefs file.
When the 3B2 is active on the port (waiting for someone to logon to the port or whatever.), DTR is active. When the 3B2 wishes to DISCONNECT (ie, too many wrong passwords, or the user logs off the port), it will lower DTR momentarily. If you are trying to get a modem to work, you might want the modem to DISCONNECT the user when DTR is dropped..
When the DCD is set inactive, the 3B2 will assume that the user has either turned off the terminal, or dropped carrier. If this occurs, the user is logged off the system, and background tasks are aborted. If DCD is inactive, be aware that NONE of the standard AT&T provided utilities are capable of sending anything to the device. There is a way to get around this in the more recent releases of the 3B2's OS. See your admin documentation for details.
Otherwise, in the case of a MODEM, when the user drops carrier, you want the modem to "momentarily" lower this DCD0 just long enough for the 3B2 to realize that the user has dropped carrier. The modem should then Re-ENABLE DCD0, so that the 3B2 will be able to send data to the modem. {needed for cu, and outbound UUCP to work correctly in older releases of the OS}
Most semi-decent modems are capable of handling DCD and DTR in a 3B2 friendly manner. I have done this with PEP's, USR HST's, and MicroComm 9600 AX modems, without incident.
From: pen@cbnewsf.cb.att.com (paul.e.nepermann)
Here are the pinouts for the connectors from the 8 pin modular to the 25 pin adapters.
8 pin modular to 25 pin RS232C Terminal/Printer 8 pin modular to 25 pin RS232C ACU Modem | Terminal/Printer | ACU Modem 8 pin side | 25 pin/male | 25 pin/female | 25 pin | | | 1 FG | FG 1 | FG 1 | FG 1 2 CTS (in) | RTS 4 | RTS 4 | CTS 5 3 TXD (out) | RXD 3 | RXD 3 | TXD 2 4 DTR (out) | DCD 8 | DCD 8 | DTR 20 5 RXD (in) | TXD 2 | RXD 2 | RXD 3 6 DCD (in) | DTR 20 | DTR 20 | DCD 8 | DSR 6 | | 7 SG | SG 7 | SG 7 | SG 7 8 RTS (out) | CTS 5 | CTS 5 | RTS 4
Don't worry about it, you're not missing anything. It's an almost completely dead hierarchy that used to be about 3B2's and 3B1's. Discussions about 3B2's have migrated to comp.sys.att, and discussions about 3B1's have migrated to comp.sys.3b1.
# cp /unix /oldunix # cd /etc/master.d
Edit your kernel parameters
# cd /boot # mkboot -k KERNEL # cd / # sysadm firmware
Once in firmware mode, have the 3B2 boot using /etc/system
Most software from the Free Software Foundation compiles and runs on 3B2s with little or no modification. The following are exceptions and their reasons. Please prove me wrong, I'd love to have some of this stuff on my 3B2 as well.
gdb - GNU Debugger No configuration files for WE32K processor. libg++ - C++ Libraries The g++ compiler produces invalid assembler code for one of the modules.
From: rthomas@hakatac.almanac.bc.ca (Robert N Thomas)
[This is intended for experienced 3B2 system administrators only. You can lose all the data on your system if a mistake is made. You should make a full system backup before you try this. Heck, make two just to be sure. Do this at your own risk!]
Well, I have managed to get a SCSI drive interfaced to my unix system. I thought that while this is all fresh in my mind, that I would type this document and make it available to the Net. I also am keeping a copy of it to aid me if I need to do this again. The EMAIL message by geoff describing the edittbl process was invaluable to me. But it still took 30 hours for me to get it to work. Hopefully the information here will make it easier for someone else trying to get this stuff to work.
I have a 3B2/400 computer system, with the following required hardware and software:
You need the SCSI host adaptor utilities, and disk controller utilities. If you don't have the SCSI card, and the software, don't bother trying it.
Here's what I did.
prtconf <-- Take down what SCSI addresses you currently have in use.
Look under SCSI at the ID: number.
Jumper your new hard disk to an unused SCSI ID: number (0-7) (don't forget about terminating resistors.)
I didn't do this and wasted a few hours because I managed to pick one of the few "used" address's. BTW, Address 0 is always used on a 3B2. SCSI host adaptor takes this address.
With finger on the CTRL-S or printscreen, watch the machine boot. As it comes up it will say something like:
unknown device "QUANTUM ELS170S 3.5" not configured (*void). (TC:0, ID:2)
{Gee, maybe I am installing a Quantum 170 on my 3b2 at address 2 eh??}
Write all this down, and ensure you got it right. The 3B2 usually tries to scroll it off right away for you, to be helpful :-}
logon as root.
cd /etc/scsi
./edittbl -l <-- The idea here is to view how SCSI disk entries are
formatted. I'll show you what I did here to get the
QUANTUM 170 up.
./edittbl -i <-- We want to insert a new entry.
Enter Vendor ID: QUANTUM
The vendor ID must be padded out to 8 characters. So add one
space on the end of quantum to pad it out to 8 characters.
Enter Product ID: ELS170S
The vendor id entered must be 16 characters. The "3.5" won't
fit in 16 characters, hence I simply added 9 spaces onto the
end until I had 16 characters.
AT&T Device Name: SD01
SD01 = disk drive
ST01 = tape drive
TC Driver type: 0x001
Enter Peripheral Device Type: 0x000 <-- Most cases. 1 = tape
0 = disk
Max lu supported: 0x001 <--- How many logical units, or if you like
subdevices are here. Usually 1.
The system then asks again what vendor ID again.
Enter Vendor ID: >CTRL-D< <--- CTRL-D to update and exit.
Interrupt to exit without save
cd to /usr/lib/scsi
Next, you want to edit the tc.index file. Add an entry for your hard disk similar to the others. Here's what I did for the Quantum.
QUANTUM ELS180S 3.09 sd00.0
Again, QUANTUM padded to 8 chars, ELS170S. Must be at least 16 chars long. In my case I went "over it".
sysadm reboot <--- Reboot machine.
Once machine is up,
sysadm single <--- Go to single user mode.
Rumor has it that formatting needs single user mode.
cd /usr/lib/scsi
./format -v /dev/xxxxxx <-- In my case /dev/rdsk/c1t6d0s6
<-- c1 = controller #1, t6 = scsi ID number
<-- d0 = disk 0, and s6 = partition number
sysadm partitioning <-- to add simple data partitions to the system
<-- and add them
or
In my case, since I wanted the SCSI disk to replace my existing boot disk, you can't use sysadm partitioning. Instead, you have to do it in a more manual mode. I could use a SLOW MFM drive for critical things like root, swap and /usr, or I could use a nice BRAND NEW SCSI drive for this, and use the MFM's for other less critical things.
To become a bit more familiar with how your disks are setup, you can try the below in safety. prtvtoc only displays the current settings.
prtvtoc /dev/dsk/c1d0s6 <-- Display partitions on my BOOTABLE CD WREN
70 Meg MFM hard disk. A standard one for most
3B2 systems.
prtvtoc /dev/dsk/c1d1s6 <-- This displays the second partition settings for
the second MFM hard disk on a 3B2.
If the above does not work, you may cat /etc/fstab and this will show you most of your disks. You could also check /etc/system for your root partitions name.
In my case, I decided to store these configurations in /etc/vtoc, since it makes sense to know what's in your partition tables. The manuals made mention of this vtoc directory. When I got there, this was an empty directory so I decided to populate it.
cd /etc/vtoc prtvtoc /dev/rdsk/c1d0s6 > c1d0s6.vtoc prtvtoc /dev/rdsk/c1d1s6 > c1d1s6.vtoc
Since we want to add partitions to the newly added SCSI disk, what I did is. Remember to select the correct device id for the disk your adding.
fmthard /dev/rdsk/c1t6d0s6
This will install an unparitioned vtoc (volume table of contents, or partition table if you prefer). This gave me some badly needed information about how many sectors are usable on the disk.
I then would recommend:
cd /etc/vtoc prtvtoc /dev/rdsk/c1t6d0s6 > c1t6d0s6.vtoc
Funny thing about prtvtoc. It's output can be read by the partitioning program to re-create your partitions!!! Nice touch don't you think.
I then went and edited this file's partition tables entries such that I would have 20 Meg root, 140 Meg /usr and 8 Megs of swap.
Here is what it looked like when I finished for my Quantum drive:
* /dev/rdsk/c1t6d0s6 partition map
*
* Dimensions:
* 512 bytes/sector
* 63 sectors/track
* 4 tracks/cylinder
* 252 sectors/cylinder
* 1325 cylinders
* 1323 accessible cylinders
*
* Flags:
* 1: unmountable
* 10: read-only
*
* First Sector Last
* Partition Tag Flags Sector Count Sector Mount Directory
0 2 00 100 40986 41085
1 3 01 41086 16384 57469
2 4 00 57470 275926 333395
6 0 01 0 333396 333395
7 0 01 0 100 99
Partition 0 is a root file system. Starting at sector 100, going to sector 41085, making a total of 41085 - 100 + 1 = 40986 sectors.
Partition 1 is my swap partition. I started this one at sector num 41086 to 57469, making a total of 57469 - 41086 +1 = 16384 sectors, or 8 Meg of swap (16384 * 512 bytes/sector = 8Meg). I also positioned this as close to the center of the drive as possible, to try and make it more accessible. I want speedy access to this area. Putting it at the beginning of the drives, means that when the 3B2 has to read a swapped process, its got to seek to the beginning of the drive. I save myself a bit of seek time.
Partition 2 is my /usr file system.
Partition 6 defines the total length of the drive.
Partition 7 defines the BOOT area of the drive. I selected the beginning of the drive. I suspect you could move it anywhere, but for me the beginning is good enough.
The TAGS also seem to define the type of partition, hence you should follow the TAG & FLAG examples shown above. If your just adding a data disk, let sysadm partition do the dirty work for you.
One observation is fmthard does not format a hard disk. I think a name like makevtoc would be a bit better choice of a name. Oh well, who said unix makes sense anyway!!!
Ok, now that the file is all edited just right, time to partition the disk:
fmthard -s /etc/c1t6d0s6.vtoc /dev/rdsk/c1t6d0s6
I would recommend doing a prtvtoc to ensure that you got everything right. prtvtoc will declare if you had any problems. EG: unused sectors and such.
Now that the disk is partitioned, it's time to make it a bootable disk. I tried to get newboot to work and couldn't. So I went and used dd to get the job done:
dd if=/dev/dsk/c1d0s7 of=/dev/dsk/c1t6d0s7
And POOF! Instant boot disk.
Next, we must use mkfs to create the file systems. Again, the /etc/vtoc directory contains most of the answers. In this case the number of sectors for each mountable partition.
mkfs /dev/dsk/c1t6d0s0 40986:5120 10 126 -b 1024 <-- makes root file sys
40986 = total number of sectors.
5120 = total number of inodes (total number of files you can create)
10 = gap. Floppy this should be 1, on my box 10. It's in the
manuals. Your system may be somewhat different for gap.
Since I have a 3B2/400 at 10MHz, 10 is good.
126 = Blocks per track. In the prtvtoc output it says 252 sectors
per cylinder. Since each sector is 512 bytes, and my block
size is 1024. You get 512/1024 * 252 to get 126 blocks per
cylinder.
1024 = I want a 1K/block file system. I sure could use 2K file
system software.
I got 5120 from a df -lt command. The current configuration AT&T provided for my root file system. Seems good enough for me.
mkfs /dev/dsk/c1t6d0s2 275926:40000 10 126 -b 1024 <-- makes my /usr file sys
I kinda trumped up my inodes here. It's always good to have enough Inodes, and a dam pain when you run out. I wanted to ensure I had enough. Adding more later means the destruction of all files on the file system and a restore from tape to recover.
mkfs to partition 1 (the swap area) is not very useful. Also mkfs to partition 6 in also not a smart idea.
Next it is time to label the file system. This is a job for the labelit command.
labelit /dev/dsk/c1t6d0s0 / labelit /dev/dsk/c1t6d0s2 /usr
mount each newly created file system(s). For me, I did the following:
cd / mkdir user mkdir root mount /dev/dsk/c1t6d0s0 /root mount /dev/dsk/c1t6d0s2 /user
OK, now that we have our file systems online, it's time to copy the files over to this new file system. Here's what I did:
cd / find . -mount -print | cpio -pvdlm /root
This copies all files on ONLY THE ROOT {/} FILE SYSTEM to the /root file system.
cd /usr find . -print | cpio -pvdlm /user
Copies all files on /usr as well as any other file systems below /usr to the /user file system. You could use the -mount option to limit this. In my case there are no other file systems, so who cares :-}.
OK, now all needed files are now on my SCSI drive. Only problem is I can't boot off the scsi's / file system.
cd /root/etc vi system
While you edit this file, you'll find a section all commented out. The default looks like:
* System device specifications * * NOTE: With VTOC, specifications are not required. * following is an example of what should go here * * ROOTDEV: /dev/idsk00 * PIPEDEV: /dev/idsk00 * SWAPDEV: /dev/swap 0 3528
I changed my /root/etc/system files entries to look like:
* System device specifications * * NOTE: With VTOC, specifications are not required. * following is an example of what should go here * ROOTDEV: /dev/dsk/c1t6d0s0 PIPEDEV: /dev/dsk/c1t6d0s0 SWAPDEV: /dev/dsk/c1t6d0s1 0 16384
I ran into a terrible problem, and could not get the SCSI drive to boot. The system would start booting off the SCSI, and then switch midstream to the MFM drives on me. This was horrible, and I could not find anything in the docs to help. Editing the /etc/system was the only way I could get it to work. If there is a better way, I would appreciate hearing about it.
Since the SCSI is the new root file system, you'll have to ensure that all mount point directories are re-created on your file system replacements. All file system mountpoints will be nonexistent on your new file systems.
mkdir /usr
Now you need to select which file systems you want mounted at boot time.
cd /etc vi fstab
In my case, the default file looked like:
/dev/dsk/c1d1s2 /usr /dev/dsk/c1d0s8 /usr2
I changed it to:
/dev/dsk/c1t6d0s2 /usr /dev/dsk/c1d0s8 /usr2
And remember to ensure the mount directories DO exist.
sysadm firmware
MCP is usually the Password for most dos based systems.
For the boot file name, type in /etc/system
For the load device, select SCSI
For the subdevice, select the SCSI disk.
The system will produce a warning about the devices. I don't know if I did all the correctly, but it seems to work. I tried to find the answer to my boot disk problem in the docs, but failed. I assume the warnings are caused by the 3B2's OS assuming the existence of only MFM drives.
If the machine boots, and your df -lt reports a SCSI root file system, and a SCSI /usr, then it worked.
Next you'll have to use sysadm autold to select the SCSI boot device.
Hope this helps, and may be kept available to help someone else get SCSI disks on their 3B2 as well.
Cheers.... ---- Robb ----
From: hak@alf.cooper.edu (Jeff Hakner)
After the system panics and gives you the SYSTEM FAILURE... message, type the firmware password. You'll need 6 formatted floppies. For program name, type sysdump. This is a firmware program, so it won't ask for a device.
Insert the first floppy, hit c, as per directions on screen. Continue for the remaining floppies. This process takes ~15 minutes.
After the dump is complete, (remove the floppy and) boot unix.
When the system is up, find a filesystem with at least 4MB free. Run ldsysdump filename, where filename is the name of the image file which will be created. Once again, feed it the 6 disks (in sequence) as prompted.
When this is done, filename will contain the core image of the crashed system. To analyze, use crash filename.
(Of course, if you don't know how to use crash.....)
From: morgan@engr.uky.edu (Wes Morgan)
Q: Why can I connect to some sites with telnet or ftp, but not others? Why do I get "Connection timed out" and "Host is unreachable" errors? What is the "TTL problem"? How can I fix it?
A: Some (or all!) of these problems can often be traced to one particular kernel parameter -- IP_TTL.
For those unfamiliar with TCP/IP standards, TTL stands for "time to live." Each TCP/IP packet has a finite lifetime, measured in "hops." Normally, each router or brouter along the transmission path is considered one hop. When the packet is first sent, it's time-to-live is set to the value of IP_TTL; as the packet travels through each router/brouter, this counter is decremented by one. If a packet's TTL is exhausted before it reaches its destination, an error message is returned and the packet is killed. This is often what actually happens behind those "Connection timed out" and "Host is unreachable" error messages.
[ Readers in search of more detailed information about TTL and other ] [ IP packet characteristics should read RFC 791, "Internet Protocol," ] [ which is available from many anonymous FTP sites. Ask archie about ] [ "rfc791.txt" ]
By default, WIN/TCP sets IP_TTL to 15 (0x0f); while this may be more than adequate for local networking, it is often far too small for systems participating in the larger Internet. (I have, however, seen a local network that had enough routers to deplete the default TTL on exclusively local traffic -- sheesh!)
Those who wish to modify the IP_TTL parameter will find it in: /etc/conf/pack.d/ip/space.c (WIN/TCP for System V/386) /etc/master.d/ip (WIN/TCP for 3b2 SVR3.2) Follow the normal procedures for modifying tunable parameters. REMEMBER -- ALWAYS MAKE A BACKUP COPY OF THE OLD KERNEL!
Q: I've been told to set IP_TTL to its maximum value, 255 (0xFF). Is a high TTL undesirable?
A: For normal operation, it's no big deal; it will cause your packets to bounce around locally a bit more than necessary, but that's a local decision.
However, the impact of a high TTL can be far more significant in long-range networking. During periods of network flakiness (which seem to be happening at an ever-increasing rate), a high TTL can cause the packet to bounce around far more than necessary. For instance, suppose that router A thinks that a router B should handle traffic for machine C; it will forward packets to router B, decrementing the TTL of each packet. If router B is confused, it might think that router A is supposed to handle traffic for machine C and fire the packet right back to router A. With a high TTL, you'll generate endless loops between these two routers; this, in turn, will slow down everyone else's traffic. [and, in some uncommon cases, crash the router; I did that once....8( ]
While I certainly agree that it's "someone else's job" to make sure that these situations don't occur, I think that we have an obligation to minimize our impact on those folks that provide our long-range connectivity.
I've found that setting IP_TTL to 64 (0x40) meets all our needs AND minimizes our impact on flaky networks. Please consider your needs when configuring; don't just set things to the maximum possible. After all, it's called "performance tuning," not "crank it up, man!"
By: Jeff Hakner, Cooper Union NYC
Draft 1.1, 13JUL1993
3B2/310 and /400 systems were delivered with a maximum CPU clock rate of 10 MHz. AT&T, at some point, released a chipset consisting of CPU, MMU, MAU and oscillator which ran at 14MHz. That chipset does not seem to be widely available any longer. Congruent Technologies, a big 3B2 VAR, is known to have a large number of the chips, but their asking price (as of late 1992) was $1000 !!! Considering that an entire V2 motherboard is going for $50 these days, that seems outrageous.
I heard from several sources that one could simply replace the oscillator and run the 10MHz chips up to about 14MHz, depending on the vintage of the motherboard and memory cards. The oscillator, a WE32102 in AT&T parlance, is made by McCoy. It is not a typical TTL clock oscillator which is housed in a 14-pin DIP and costs about $5. This is because the 3B2 CPU requires a bi-phase clock. McCoy said they had the faster parts, but they wanted $200!! I set out to do it myself.
Someone got me the pinout of the WE32102, and I noticed two unused pins. I put the thing on the bench, hooked it up to a scope, and experimented. It turns out that the WE32102 will accept and *external* clock at double frequency. This clock source overrides the internal x2 oscillator which is inside the WE32102 can. Therefore, one can easily (and cheaply!) vary the CPU clock speed by attaching the appropriate TTL clock oscillator, about $5.
The WE32102 is a 16-pin DIP. It is a wide DIP, not the narrow type normally found in a 16 count. The pinout is:
8: GND 16: VCC 3: Internal oscillator enable 5: External frequency source (x2) input 10: Clock, phase 1 12: Clock, phase 2 (90 degree delay) 14: x2 output
To perform the mod, all you need to do is:
For example, a 25MHz clock source will run the system at 12.5MHz. That's the only speed I've tried, and it seems to work fine. Your mileage may vary. In particular, this mod will not work with really old motherboards or memory cards, I'm told.
Early 3B2/300s and /310s ran at 8.2 MHz. These systems probably won't get much above 10 MHz. Very recent 3B2/400s and /310s (is that an oxymoron?) have 14MHz CPU/MMU/MAU chipsets installed. These systems may be able to go to 16MHz, but I don't know if the rest of the motherboard will handle it!
NFS Release 1.03.00 for the 3B2 has a serious bug in the installation script that causes it to fail with a syntax error from "expr" on the eighth disk if the kernel parameters found in /etc/master.d/kernel are not of the form:
v--------------- first column on the line
NPROC = 1234
^-^-------- *exactly* one space
While it's legal to use any (or no) whitespace as far as rebuilding the kernel is concerned, it seems that the installation procedure doesn't permit this (it's actually a very badly-written shell script). Be sure to check your file before installing this software.
AT&T may not, but Lucent Technologies does (for now).
I received a letter and parts price list from Lucent Technologies Enhanced Solutions Group late last summer. A number of parts were still available including a SCSI 4mm DAT tape drive as well as system boards. UNIX SVR3.2.3, SVR4.0.4 (for RISC 3B2s), TCP/IP WIN/3B 3.2 for SVR3.2.3 and TCP/IP WIN/3B 4.01.01 for SVR4 were also listed.
(dead links removed)
According to information received from Lucent Technologies on 9 July 1997 they still have a fair number of new and refurbished 3B2s as well as new components available. One would suspect that Lucent will not warehouse these items indefinetly. For more information contact Lucent Technologies at (800) 342-5251.
To get the latest copy of this FAQ, send a mail message to
mail-server@rtfm.mit.edu
The body of your mail should contain a command to the mail server.
To get all the parts of this FAQ (currently consisting of 2 parts),
place the following command in the body of your message:
send usenet/news.answers/3b2-faq/*
To request only one part, substitute the part number as in the
following example:
send usenet/news.answers/3b2-faq/part1
Please remember to leave the Subject: line blank to reduce the chance of confusing the server.
This page maintained by
Robert M. Martel,