Copyright 1996-1998 by James Mohr. All rights reserved. Used by permission of the author.
Be sure to visit Jim's great Linux Tutorial web site at https://www.linux-tutorial.info/
No one really expects your system to remain stagnant. As your company grows, your computer should be able to grow with it. You can add more memory or a new printer with little or no changes to the operating system itself. However, if you need to add something like a hard disk or CD-ROM drive, the operating system needs to be told about these changes. Therefore, you need some mechanism to be able to add new devices. This mechanism is the shell scripts in /usr/lib/mkdev, collectively referred to as the "mkdev scripts." (Pronounced "make-dev scripts")
Although their appearance has change between ODT and OpenServer, what they do functionally has changed little. OpenServer provides both a graphical and character based program to configure the hardware. This is the Hardware/Kernel Manager and is functionally the same as the sysadmsh in ODT. Despite the outward appearance it is basically the same as the mkdev scripts. In many cases, just like sysadmsh, the Hardware/Kernel Manager actually calls the mkdev scripts to configure the hardware. To make life easier, I will be referring to the mkdev scripts throughout this discussion. However, since the scripts are called from sysadmsh and the Hardware/Kernel Manager, the information still applies.
One thing I need to point out is that these scripts are not just to add devices. Originally this was the case, hence the name mkdev. However, as SCO UNIX grew, any addition to the system functionality was made through mkdev scripts. For example, when you run mkdev fd, you are not adding a floppy disk to your system, but rather you are giving the choice of creating a boot or root filesystem floppy or one with a UNIX filesystem on it. When you run mkdev mmdf, there is no MMDF device to be created. Instead, you are configuring MMDF.
However, this is not the only way that devices can get added to the system. Third Party drivers can do anything they want. Not that they should, they just can. Even if a driver is installed using custom, there is nothing that guarantees that this mechanism is used.
As with any device you add to your system, I need to remind you to have everything planned out before you start. Know what hardware exists on your machine and what settings each card has. Look at the documentation to see what settings are possible in case you need to change them. If you are adding a new device of a particular type, the odds are you are going to need to make some changes.
On a standard ODT system, there are two dozen different scripts. Therefore taking about each of them in details would probably take up this whole chapter, if not the whole book. Therefore, we are going to talk about the scripts in general and then get to some specifics about the more commonly used one as we address the issue that can crop up.
As I have said before and I will say a hundred time again, before you start to do anything, prepare yourself. Get everything together that will be needed prior to starting. Gather the manuals and diagrams, get your notebook out and have the settings of all the other cards in front of you. Also, before you start read both the Release Notes and the chapter on installing in the OpenServer Handbook.
Perhaps the most important thing to do before you run any mkdev script is to how the hardware is really configured. I need to emphasize the word really. Many customers have gotten arrogant with me, almost to the point of being angry because the insist that they hardware is set at the "defaults" and I insist that they check anyway.
Unfortunately for me, in most of the cases the devices are set at the default. However, confirming this takes less time then trying to get something installed for a couple of hours and only then finding out they are not at the default. Therefore, I would insist that the customer check before we continue. I did have one customer who made noises like he was checking and "confirmed" the fact that the device was at the default. After almost an hour of trying to get it to work, I asked him to change the settings to something other then the defaults, thinking maybe there was a conflict with some other device. Well, as you guessed, he didn't need to do anything to make things non-default, they were already there! Lesson learned: DON'T lie to tech support.
Another important part of the preparation is to understand what it is you are trying to accomplish. If you are having trouble with your modem where it works, but not correctly, then playing around with mkdev serial (which configures the serial port) is not what you want to do. If you are running into trouble getting Merge to work, the problem may lie elsewhere than the mkdev dos script (which adds support for DOS filesystems).
One thing I need to point out is that many of these scripts can be used to reconfigure existing devices as well as remove them. Therefore, don't just think of these as scripts to add devices.
There are a few sub-directories in /usr/lib/mkdev. Two of them, oaforms and oamenus provide the nice menuing capabilities of certain scripts such as mkdev lp and mkdev graphics. The other sub-directory, perms, contains permissions files similar to those in /etc/perms. These are accessed when the appropriate devices are added or reconfigured.
The exception is perms/HDLIST. This is because of the relatively complex nature of the hard disk minor numbering scheme for the hard disks. We'll get into this in a little more details when we cover the mkdev hd script.
It is a common misunderstanding that the mkdev scripts do not configure the devices. The configure the device drivers. This may appear like a subte difference, but is a very important one. If you were to be configuring the device, then you could set the interrupt, DMA and base address. Instead, you are configuring the software to expect the hardware has a certain configuration. If you run an mkdev script and tell it that a device has a certain interrupt, then you must make sure that the hardware in configured the same way.7
One of the most important things about installing hardware is knowing what you are doing. Now this may seem like an overly obvious thing to say, but there is a lot more to installing software than people think.
One of the most common problems I see is that cards are simply snapped into the bus slot with the expectation that whatever settings are made at the factory must be correct. This is true in many, if not most cases. Unless you have multiple boards of the same type (not necessarily the same manufacturer), you can usually get away with leaving the board at the default. However, what is the default?
Unless you are buying your hardware second hand, there ought to be some kind of documentation or manual that come with it. For some, like hard disks, this may only be a single sheet. Others, like my host adapter come with booklets of 50 pages or more. These not only give you the default settings, but tell you how to check as well as change the settings.
On ISA cards, settings are changed by either switches or jumpers. Switches, also called DIP-Switches come in several varieties. Piano switches, look just like piano keys and can be pressed down or popped up. Slide switches move back an forth to adjust the settings. In most cases the switches are labeled in one of three ways: on-off, 0-1 and closed-open. Do not assume that on, open or 1 means that a particular functionality is active. Sometimes 'on' means to turn on disabling the function. Always check the documentation to be sure.
Jumpers are clips that slide over pairs of metal posts to make an electrical connection. In most cases, the posts are fairly thin (about the size of a sewing needle) and usually come in rows of pin pairs. Since you need both posts to make a connection, it is okay to store unused jumpers by connecting them to just one of the posts. You change the setting by moving the jumper from one pair of pins to another.
The most common things that they configure are base address, IRQ and DMA. However, they sometimes are used to enable or disable certain functionality. For example, jumpers are often used to determine whether an IDE hard disk is the master or the slave.
The other three bus types, MCA, EISA, and PCI bus cards do not have DIP switches or jumpers. They normally come with some kind of configuration information provided on a diskette. Provided with the machine itself is a configuration program that reads the information from the diskettes and helps to ensure that there are no conflicts. Although hardware settings are configured through these programs, it is still possible in some cases to create conflicts yourself, but the configuration utility will warn you.
Sometimes the configuration utility is provided on a separate floppy. Usually this is a DOS floppy, but is not bootable. Therefore, you will need to first boot off a DOS floppy before you can configure the card. MCA machines have a bootable configuration disk that contains the configuration information for the hardware provided with the machine If this is the case, then this disk is as important as the SCO UNIX installation media. If this disk gets trashed, then there is no way you will even be able to add another piece of hardware, your kids will hate you and your co-workers will think you are a geek. On the other hard, you could get a copy from the manufacturer, but that's a hassle. The real problem is that some machines, like the IBM PS/2 series, recognize when you add a new card to the system and won't let you boot until you feed it the configuration disk.
In some cases, the configuration program is part of the hardware (BIOS) or resides in a normally inaccessible part of the hard disk. Check the machine documentation for details.
Knowing what kind of card you have is not only important to configure the card, but unless you know what kind of bus type you have, you may not be able to even stick it in the machine. This is because all of the different cards have a different size or shape. As you would guess, the slots on the motherboard they go into also have different sizes and shapes.
Hopefully, you knew what kind of card to buy before you bought it. However, it is often the case where an administrator will know what kind of slots are on the machine from reading the documentation, but never opened the case up so has no idea what the slots look like. If this is a pure ISA or MCA machine, then this is not a problem as none of the cards for any other bus will fit into one of these slots.
Problems arise when you have mixed bus types. For example, it is very common today to have PCI or VLB included with ISA or EISA. I have also seen MCA machines with PCI slots, as well as both PCI and VLB in addition to the primary bus (usually ISA or EISA). If you've gotten confused reading this, image what will happen when you try to install one of these cards.
More than likely you are using your SCO machine as a server. Therefore, the computer you bought probably has at least six slots in it. This can be more if you have a tower case or have PCI in addition to the primary bus. Due to their distinct size and shape, it is difficult to get cards into slots where they don't belong. Usually there is some mechanism (i.e. notches in the card) that prevent you from sticking them in the wrong slots.
On some motherboards you will find a PCI slot right next to an ISA or EISA slot. By "right next to" I mean that the seperation between the PCI slot and the other is much less than between slots of the same type. This is to prevent you from using both slots. Note that the PCI electronics are on the opposite side of the board from ISA and EISA. Therefore, it's impossible to fill one slot and then use the other.
When installing the expansion cards, you need to make sure that the computer is disconnected from all power supplies. The safest thing is to shutdown the system and then pull the plug from the wall socket. That way you ensure that no power is getting to the bus, even if it is turned off. Although the likelihood of you injuring yourself seriously is low, you have a greater chance of frying some component of your motherboard or expansion card.
Another suggestion is to ground yourself before touching any of the electronic components. You can do this by either touching a grounded metal object (other than the computer itself) or wearing a grounding strap. These usually come with a small instruction sheet telling where the best place to connect it is.
When I first started in SCO Support we had a machine that would reboot itself if someone so much as touched it who wasn't grounded. I have also cleared my CMOS a couple of times myself. Therefore, I can speak from experience when I say how important this is.
When you open the case you will see a row of bus card slots, lined up in parallel. Near the outside/back end of the slot, there is a backing plate that is probably attached to the computer frame by a single screw. Since in most cases, there is some connector, etc that sticks out of the slot, this plate will probably have to be removed. In addition, the card will have an attachment similar to the backing plate that is used to hold the card in place. I have seen cards that do not have any external connector, so you could insert them without first removing the backing plate. However, they are not secure as nothing is holding them in place.
This plate has a lip a the top with the hole for the screw. In order to get the orientation right for the screw hole, the card will probably be inserted correctly. (Provided it is in the right kind of slot) As you are inserting the card into the slot, make sure that is going in completely perpendicular to motherboard. That is, make sure that both ends are going into the slot evenly and that the card is not tilted. Be careful not to push to hard, but also keep in mind that the card must "snap" into place. Once the card is seated properly in the slot, you can make the necessary cable connection to the card.
After the cables are connected, your machine can be rebooted. Many people recommend first closing the computer's case before turning on the power switch. Experience has taught me to first reboot the machine and test the card first, before putting the case back on. If, on the other hand, you know you have done everything correctly, the go ahead and close things up.
SCO UNIX provides a couple of utilities that can be used to check what you have installed if you are running either EISA or MCA. If you have an EISA system, use the eisa(ADM) utility. The one drawback is that this can only show you what EISA cards you have installed. This is because ISA cards have no way of communicating with the bus the same way EISA can. If you have an MCA machine, you use the slot(ADM) command. Note that both of these commands can only view the configuration and not change it. To change it you need to run the appropriate configuration program.
Avoiding address, interrupt and DMA conflicts is often difficult. If your system consists solely of non-ISA cards, then it is easy to use the configuration utilities to do the work for you. However, the moment you add an ISA card, then you must look at the card specifically to see how it is configured and to avoid and conflicts yourself.
If you have ISA and PCI cards, you can use the PCI setup program to tell you which interrupts are in use by ISA bus cards. If you don't, then it is possible that there will be interrupt conflicts between ISA bus card and a PCI bus card, or even two ISA cards.
Unlike DOS, every expansion card that you add to an SCO system requires a driver. Many, such as those for IDE hard disks, are already configured in your system. Even if the driver for a new piece of hardware exists on your system, it may nor be linked into your kernel. Therefore, the piece of hardware it controls is inaccessible.
There isn't too much you can say about adding CPU's. There is no mkdev script to run. There are no jumpers to set on the CPU. In some newer machines, there is a level that pops out the old CPU and you pop in a new one. This is (as far as I have seen) only on 486 machine to allow you to add a Pentium. These are called Zero-Insertion-Force (ZIF) socket, since you use the lever is used to lock the CPU into place and it requires zero force to insert it.
One thing that needs to be considered is the speed of the CPU. You may want to increase the speed of the CPU, by simply buying a faster one. From SCO's perspective this is okay. You plug it in, and it can work with it. However, it might not be from the hardware's perspective. Motherboards are often sold with the same speed as the CPU. This is because they cannot handle faster speeds. Therefore, in many cases you cannot simple replace the CPU with a faster one.
In other cases, the motherboard is of higher quality and can handle even the fastest Pentium. However, if you only had a 50Mhz 486, then you might have to change jumpers to accommodate the slower CPU. Often these changes effect such things as the memory waits states. Here you need to check the motherboard documentation.
The day with probably come when you need to expand the RAM on your system. As more users are added and they do more work, the little RAM you have won't be enough. Once you have decided that you need more RAM, you still have most of your work ahead of you.
One of the key issues is the kind of RAM. In almost all newer machines, RAM comes in the form of SIMM modules. As I mentioned in chapter 12, these are about the size of a stick of chewing gun, with the chips mounted directly on the cards. These have almost entirely replaced the old RAM that was composed on individual chips.
There are two primary type of SIMMs. The somewhat larger is called a PS/2 SIMM as it was first used on PS/2 machines. This has 72 connectors on it and can be immediately distinguished by the small notch in the. The other kind is referred to as non-PS/2, normal, regular, etc. This has 30-pins and no notch. There is also a 32-pin SIMM. However, this is uncommon. I have never seen one, but was told of this by someone who works in the chip manufacturing business.
Two important aspects of RAM is the speed and whether or not it has parity. The speed of RAM is measured in nano-seconds(ns). Most RAM today is either 70 or 60ns, with a few machines still being sold with 80ns. The speed of RAM is a measure of how quickly you can read a particular memory location.
Although it is possible in many cases to mix RAM speeds, I advise against this. First, memory can only be accessed as quickly as the slowest chip. Therefore, you can nothing by adding faster RAM, and loose if you add slower RAM. I have also seen machines where mixing speeds actually causes problems. Since the difference between 80ns and 70ns is more than 10%, the delay waiting for the slower (80ns) RAM makes the system think that there is a problem. This usually results in kernel panics.
Another issue is the motherboard design. For example, on my machine, I have two banks of memory with four slots each. Because of the way the memory access logic is designed, I must fill a bank completely, otherwise, nothing in that bank with be recognized. On other machines, you can add single SIMMs. Check the documentation that came with the motherboard.
Another important issue is the fact that SCO UNIX uses only extended not expanded memory. Expanded memory dates back to the early days when the XT bus could only handle up to 1MB of RAM. In order to give programs access to more memory than the computer could handle, some memory board manufacturers came up with the concept of "bank switching". With bank switching, a 64K area between 640K and 1Mb is reserved and then portions above 1Mb are "switched" in to this reserved block as needed.
When the AT bus was developed, it could access more memory. However to make it compatible with older peripherals, the area between 640K to 1MB was left "unused". You often see this when SCO UNIX boots that it doesn't use that area. Memory beyond 1MB is known as extended memory.
Some machines have a hardware limitation on the maximum amount of memory that can be installed. Since I use 30-pin SIMMs, the largest available (as of this writing) is 4Mb. Because of this, I max out at 32 MB when I fill all eight of my slots. If you have 72-pin memory, there are larger modules, such as 8, 16 and even 64Mb. Again refer to you motherboard manual for details. Currently, OpenServer officially supports up to 512MB of main memory. However, I was told there is a machine at SCO running with 1Gb. I was also told that OpenServer should support up to 2Gb.
If you experience repeated panics with parity errors, consider replacing your memory. Because of the way memory is accessed you may have to remove or replace entire banks (like mine). I have also seen cases where mixing memory types and speeds can cause the panics. For example, if you have a machine that "allows" both 4MB and 1MB SIMMs, the demands that SCO puts on the machine may be too much and it panics. However, running the same configuration with Windows works fine. The panics may also be the result of improperly inserted SIMMs. That is, if the SIMM is loose, it may not make a good contact with the slot. If the machine gets jarred, the contact may be lost.
In some cases you can simply add the memory and the machine will recognize it (like mine). However, I have some machines where you have to set jumpers to enable each bank as you add memory. In other cases, where you have filled up all the slots on the motherboard, you can add a memory expansion card. If this is on a machine like a PS/2, it requires you to tell the system of the memory expansion card using the configuration disk.
If this is the first device you are adding to the host adapter, you need to configure that host adapter into the system. You will then be prompted for such information as IRQ and base address. If you have either a PCI or EISA machine, you won't be prompted for these values as these are configured into the CMOS by the appropriate configuration utility and they are then read by the driver at boot time.
If you are adding a second (or anything after that) host adapter you will have to disable the BIOS on it. Remember from our discussion on SCSI in the chapter on hardware, that the system will look for a bootable hard disk. If the BIOS on the second host adapter is enabled, the system may try to boot from this one. If it is the same model host adapter, then it will probably have to change the base address, IRQ and DMA, as well.
Remember that every device on the SCSI bus, including the host adapter itself, is identified by a SCSI ID. SCSI IDs range from 0-7 on standard SCSI and 0-15 on a Wide-SCSI bus. Regardless of what type, the host adapter is almost exclusively set to ID 7. It is this ID that is used to identify devices on the bus, not their location in relation to the host adapter.
Since there is no real need to have a SCSI host adapter configured unless something is attached, the only "official" way to add a host adapter to the system is to go through the procedures to add one of the attached devices. If the system recognizes that you do not have a configured host adapter, you will be prompted to add one.
If you are adding a device to an existing host adapter, then the driver for that host adapter is already linked into the kernel. (At least we hope so) You only need to make the kernel aware of the new device. Each device gets an entry in /etc/conf/cf.d/mscsi. This tells the system what host adapter type the device is attached to, what kind of device it is, which host adapter number it is attached to, the ID, LUN, and bus number for every device on every SCSI bus. The nice things about the installation is that you don't have to worry about editing the mscsi file yourself. All you have to do is supply the correct information and the installation programs will add this for you.
One change that was made in OpenServer was adding an extra column to mscsi. This is for SCSI host adapters that provide two channels. The new column in mscsi (the sixth one) is for the channel. If the device is on the second channel, this entry will be a 1. If the device is on the first channel or the adapter isn't support twin-channel, then this entry is 0. If the entry is missing, the system assumes it is 0.
When you run either the Hardware/Kernel Manager or one of the mkdev scripts, the first thing you are asked it what host adapter 'type'. Here you need to put in the internal name of the device driver. The default will be either an Adaptec 154x if this is the first one you are installing or the last host adapter you installed. If you don't know you can get a list of the available one either by looking in /etc/default/scsihas or entering 'h' when you are asked for the type (It says to do this on the screen).
Next, you are asked what host adapter number. Since you can only have two of any kind, you are given the choice of either 0 for the first or 1 for the second host adapter.Open Server also supports twin channel SCSI host adapters. You are, therefore, asked which channel the device is one. If you have a host adapter with only one channel, enter 0 as the channel.
Be careful here. Some host adapters label their channels A and B, rather than 0 and 1. Since both A and 0 come first, these are the same channel. That makes B and 1 the same channel. Although does seem logical, unless someone specifically tells you, you are still guessing.
You are next asked the ID of the device. Remember that the ID is not the position on the SCSI bus, but is something that you need to explictely set. Make sure that the ID you are inputting to the mkdev script is correct. Just like base addresses, IRQs and everything else, this has to match. The problem is that determing the ID is not always easy. Remember from our discussion on SCSI device in chapter 12. You might have jumpers or switches that can have several different labels. Unless you have used this model of device before, you will probably need to double-check the doc to be sure. (Checking the doc is always a good idea.)
The last question is the logical unit number (LUN) of the device. Currently, SCO doies not support any device that is set to something other than LUN 0. This is not to say that it won't work.. It's simply an issue of all devices that SCO supports directly have embedded controllers so they can only be set to LUN 0.
If the root disk is IDE, EIDE or ESDI, then you can add another disk of that type or add a SCSI disk. (assuming you have a SCSI host adapter) Keep in mind that the number of disks is limited by The MAX_DISK dynamic kernel parameter. If set to 0, the maximum number is dynamic.
Some host adapters, like the Adaptec AHA1510 do not have a BIOS. Therefore, you cannot install onto a disk connected to this adapter. This can be used only as a secondary adapter. There are dozens of host adapters supported by SCO, with more being added to each release. Each has certain characteristics that need to be addresses. If there are known problems with a specific host adapter it will be listed in the Release Notes or in the Open Server Handbook.
One of the most commonly used and often messed up scripts is the one to add hard disks to your system: mkdev hd. The reason that the mkdev script is so often messed up is that people are not prepared when they start. They do not know the current configuration on their system. As a result they often guess when running this script. What then happens is that the system flails and dies during the next reboot because it is looking for things that are not there.
Since the mkdev hd script is only called after the system itself is installed and you are adding a new disk, there is a better chance that you know what kind of disk. However, this is not always the case. I have talked with customers who are the software consultants and have technicians add the hardware. In some cases they don't even know what kind of hard disk they are installing.
If you have trouble figuring out what kind of hard disk you have, either refer to the documentation that came with the drive, call the vendor or re-read the section at the beginning of the book on hard disks.
The key thing to keep in mind is making sure how the disk is configured. Every drive should come with some kind of documentation. Either a detailed, multi-page manual as is the case with many SCSI drives, or a single sheet, a is common with IDE drives. This usually contains information about the default settings of the drive. Don't trust them. Check out the settings yourself to ensure they are correct before you stick the drive in the machine. It is easier to check beforehand than it is after your tried to install it and failed.
If it's an IDE drive, then one of the key issues is whether it is the master or slave. If you are adding a second drive to a system that only has one drive, then you are obviously adding the slave. If you already have two drives on the first IDE controller and this is the first one on the second controller. then it is the master.
Another key issue is making sure the cabling is right. In the section on hard disks earlier, I mentioned that the position on the cable is irrelevant for IDE drives; the jumpers determine which drive is which. A problem often crops up when connecting the cable to the drive itself.
Usually there is a small "key" on the connector on the cable which fits into a notch on the drive-side connector. If the "key" is missing or the drive-side connector is wide enough, it may be possible to fit the connectors together backwards. Fortunately, you don't have to resort to "trial and error" to figure out which is which. On one side of the cable, there will be a colored stripe (usually red). This is line 1 of the 40-line IDE cable. In fact, on almost all ribbon cables, line 1 is marked red.
On the drive side, things are a little more complicated. The IDE cable has 40 parallel lines, but the connectors (both on the cable and on the drive) are in two parallel rows. Usually the connector on the drive is either male (pins) or there is a small "card" sticking out that is similar to an expansion card. These alternate with the odd numbered lines on one side and the even numbered lines on the other.
On the drive near the connector, often on the circuit board itself will be some small numbers. These tell you which pin is which. Sometimes there will be a 1 and 2 on one end with 39 and 40 on the other. Other times there will be just a 1 and 39. (I have seen cases where there is just a 2 and 40).
SCSI drives may have jumpers to configure them, but they may also be configured in other ways such as with dials, dip switches, or piano switches. Like IDE drives, SCSI usually has one set of jumpers. This will be for the SCSI ID of the drive. In some cases there will be up to eight pairs of pins to indicate which SCSI ID. Others have three pins that operate in binary. (For more details on SCSI configuration, see the section on SCSI in the hardware chapter.)
Standard SCSI cable looks very similar to the IDE, except that the cable has 50 lines instead of just 40. However, the same issues with the key and slot, as well as the number applies. On the other hand, I can't remember seeing a SCSI device where the key and slot didn't match up correctly.
If you are not sure of how the drive is configured, check the documentation that came with your drive. If that can't be found, most hard disk manufacturers have fax services that will fax you installation information on any drive they have.
The first thing the mkdev hd script does is to check your root hard disk. This is important because you cannot have both a SCSI and IDE drive in your system and boot from the SCSI. Therefore, if you system only has SCSI drives and you run this script, you are only given the option to add another SCSI hard disk. (I talked about the reasons for this in the section on SCSI in the chapter on hardware)
Well, this is not entirely true. If you are running OpenServer 5.0, then you are given a menu option to add an IDE drive. You can start it and it will go through like it is trying to add the hard disk, but it eventually errors out. To me, this is a bug.
The mkdev hd script accesses the functions to determine the hard disk type through two another scripts: /usr/lib/sh/std_funcs and /usr/lib/mkdev/.hdfuncs. The script std_funcs contains several standard functions that provide interfaces for user input and output. This script contains some interesting functions, but unfortunately that is not the topic of this section. However, I would recommend looking at it as it not only because it has some useful functions, but uses some interesting tricks of the shell.
The other script, .hdfuncs, contains hard disk functions (what else?). This is where most of the actual work gets done when adding a hard disk. Should you be adding a SCSI hard disk, the .hdfuncs calls another script /usr/lib/mkdev/.scsi.
One of the first things the mkdev hd scripts does it to check for the architecture type. Actually this isn't quite true. The system simply asks "Am I MCA?" If not, it doesn't care if it's ISA or EISA, just that it's not MCA. This is very important as the drivers are very different between MCA and AT architectures. Whereas, ISA devices work fine in EISA machines.
Just after this, the system checks for the existence of the link kit. This is a very important step. Without the link kit, none of the necessary drivers are on the system and you won't be able to add anything. The nice thing is that if the system determines that the link kit is not installed, you are asked if you want to install it.
Next we get to see where one of our esoteric devices finally comes of use: /dev/string/cfg. The .hdfuncs script uses it to find out what the boot hard disk type is. This is because, as I mentioned before, you can't have both SCSI and non-SCSI and boot from the SCSI. If .hdfuncs finds that your boot hard disk is SCSI. It will only allow you to add another SCSI. If this is the case, it actually runs the .scsi script.
Here you are ask about the host adapter and how the drive is configured. This is where is become essential that you know your hardware configuration. The script makes some suggestion about what the values are based on what it can determine, however these are not always the correct values to input.
For example, one of the things it suggests is the prefix of the host adapter you are adding. It firsts checks /etc/conf/cf.d/mscsi and uses the last host adapter prefix it finds. This makes sense because if you are adding a SCSI device, then most likely it will be to the same host adapter as the last device added.
If there are no entries in mscsi, it looks for a boot device. This is also obtained through /dev/string/cfg. This makes sense because in most cases you are adding a SCSI device to an existing host adapter and there are no entries in mscsi, you probably want to add it to the boot host adapter.
This is a place where people run into problems. They simple don't know what to input there. They were given installation instructions for the hardware, but the hardware vendor may not provide instructions for UNIX. In most cases it is safe to take the default. However, be safe! Know what you have. The same also applies to the SCSI ID and LUN. If you don't know, don't guess. If you know you are adding a new host adapter, .scsi will prompt you for information about this host adapter to be able to configure it into the kernel.
Once the script decides that your input is a valid device one of two things will happen. If the hard disk is brand new and the system has never accessed it before, you will have to relink the kernel, reboot and run mkdev hd again before you can access the drive to make the partitions. The reason for this is that the first time you run mkdev hd, the kernel is configured to recognize the drive. It is not until you reboot that the system recognizes the drive and is able to access it. Only then can you partition the disk and make filesystems. Remember that the second time you run mkdev hd, you must use the exact same values.
The second time you run mkdev hd, you are brought into fdisk to partition the drive. The fdisk utility is used to create UNIX partitions. You can define up to four partitions, which can be no larger than 2TB (2 terabytes) or the maximum size of the disk, which ever is smaller. Keep in mind that filesystems are limited to smaller sizes, you may not be able to create a partition that is the full size of the disk, then create only a single filesystem. Also, if this disk was already use and the partition table is still valid, you could simple quite out of fdisk without changing any of the values.
I need to emphasize something here. On ODT, there must be at least one active UNIX partition for mkdev hd to work properly. For those of you with a little experience know that if there is only one partition, the system automatically makes it active. So if it's a new drive and you are using the entire disk for UNIX, there is no problem. Also, if you are adding a UNIX partition to a hard disk which already has a DOS partition, this is also no problem, as you can simply make the UNIX partition active.
However, what do you do if the entire disk is used for DOS and you want to be able to access it, let's say, through Merge? Ah, therein lies the rub. The .hdfuncs script will not allow you to continue if there is no active UNIX partition. Yes, you can quit out of the mkdev process, however, the system has trapped the interrupt key. If you quit, all the device node information is deleted and you are back to where you started. The solution to this is not really what we're here to talk about. You will either have to edit mkdev fd or add the nodes by hand. Fortunately, OpenServer allows you to add a DOS-only disk.
In the mkdev hd script, each of the device names has to be created as the hard disk is added. There a literally dozens of names that need to get created. For SCSI devices, these names are based on the order drives get installed and not necessarily the order they appear on the bus. Therefore the devices cannot be created in advance or put in a file like the other devices. These must be created when the script is run.
During this process a "seed" value is calculated, based on which the remaining minor numbers are calculated. This "seed" value is one of those multiples of 64 that are used for each hard disk. Remember from our discussion of major and minor numbers? The first hard disk has major numbers between 0-63, the second between 64-127, etc. The first number in the range (i.e. 0, 64, 128, or 192) is the lowest value that the minor number can be for any device on this hard disk. This is the "seed" value and is simply added to the minor number calculated for each device for the hard disks.
If there are already four hard disks on the system, then the seed number will be at least 256. Remember from our discussion of major and minor numbers. Each is stored in a single byte. Therefore, it is impossible to have minor number above 255, therefore you can't have more than four hard disks on a system, right?
Well, several years ago this was true. Four hard disks on a system was considered to be quite a lot. Therefore, it did not bother the "powers-that-be" too much that there was this limitation. As databases grew into the gigabyte range, four hard disk was no longer "a lot." Especially considering that a SCSI bus could handle six per host adapter, this limitation was becoming a bit annoying. Something had to be done to address this issue. That something was extended minor numbers.
Well, if you want to find out more about extended minor numbers, read the section on major and minor numbers. If you're already read the section, then you understand what we're taking about.
If the mkdev hd script has determined that the seed value is greater than 255, it gets a new major number that is then used for the extended minor numbers.
After completing fdisk, divvy is called, which is used to create divisions and filesystems on those divisions. By default one filesystem is create on the active partition that you just made. However, you are asked if you want to make any changes. Even if you don't want to make changes, it's a good idea to say that you do. This way you are brought into an interactive session of divvy and you can see if things look reasonable. I also find it useful to checks for typoes that I might have made when inputting the values. In addition, you can name the filesystem that's created. Otherwise you end up with some weird name. You then can exit divvy and the filesystem is created.
You need to be very careful here if this was disk that you had used before. For example, you updated the OS or had to reinstall after a system crash. Although you are brought into divvy, you don't have to change anything. However, there are probably no devices nodes for these filesystems, so you will probably at least have to name them. If you want to keep the data, don't create the filesystems. Creating the filesystem clears out the inode table, making your data inaccessible.
Although divvy is used to create the filesystem on the divisions, the mkdev hd process does not actually make the filesystem readily available. You do have the names of the device nodes as well as the name(s) of the filesystem(s). Therefore, every time you boot you could run the mount command by hand to add the filesystem(s). This is obnoxious, but you could do it.
A better alternative would be to have the system mount the filesystem(s) automatically. (Assuming this is what you wanted) This is done through another mkdev script mkdev fs.
This is one of the script where you are not actually "making" any devices. However, you are adding some functionality to your system. During the course of this script you are prompted for the device name of the filesystem (this is the name you input in divvy) and the name of the directory of where you want to mount the filesystem. By convention this is the same as the name of the filesystem, however there is nothing that prevents you from naming it something else.
At this point you see a message the says:
Reserving slots in lost+found directory ...
Here, the system is creating 62 files and removing them. Why? Think back to the discussion of filesystem in chapter 6.
Next, you are asked for the manner in which is should be mounted (never, always or prompt). The convention is to always mount it, which kind of makes sense. Why go through all that trouble to add a filesystem if you never want to access it? If there are conditions at your site where you might want to not mount it, then choose one of the other options.
Finally, you are asked whether users should be able to mount this filesystem. Be careful. If you say "yes", then every user has the power to do so. Although they may not have access to files underneath the mount point, anyone can still mount it. It is useful if you have a user whose sole function is to do backups, so having the ability to mount filesystems is very useful. However, if the user cannot read the file, it can't be backed-up. If you give them root authority to back everything up, then they don't need to be able to mount the filesystem as a user.
Another commonly used script is mkdev fd, for "make device floppy." Again, this is another case where no device is actually created. This script creates floppies that can be used in emergencies to boot your system.
You are prompted to input the type of floppy you want to use as well as whether you want to use either drive 0 or drive 1. If you are creating a filesystem floppy (the next prompt asks what kind of floppy you are creating), then there is no problem in using drive 1. However, if you are creating boot floppy, this must be drive 0. Also, you need to know the kind of floppy drive you have. If you chose the wrong kind (size or density), the script fails.
After you chose the floppy drive, you are given the choice of what kind of floppy you want to create. A filesystem floppy, is essential empty. It contains the filesystem structure that a filesystem on the hard disk does. However, since it is accessing a smaller space there are few inodes so the inode table is smaller. Like a newly created filesystem on the hard disk, this one is empty.
The other two type are usually created in pairs and as a pair are often referred to as a boot/root floppy set. A boot floppy is exactly what it sounds like. It contains the necessary information to boot and load the kernel. A root filesystem floppy contains a filesystem as well as the file necessary to get the system going into maintenance mode. In addition, it contains utilities that can be used to recovery from a crash and restore your data. To see what files are copied onto the floppy, take a look at /usr/lib/mkdev/perms/FD.
It is advisable, recommended, suggested, desirable, etc that you create a boot/root floppy set every time you add or delete drivers that effect either the hard disk or tape drive. These are the most important drivers and devices you have for crash recovery. When you system goes down and you can't access it through the boot/root floppy, then you only alternative is to reinstall.
Just like mkdev hd and mkdev fs come in pairs, so do mkdev cdrom and mkdev high-sierra. Just like the first pair, you do not absolutely need to add a high-sierra filesystem to be able to access the CD-ROM. If you remember from our discussion on the /dev directory there is such a thing as a cd-tape device. Since you are not actually mounting the device, there is no need to add a filesystem driver for it. Additionally, if you have a UNIX Filesystem CD, then the filesystem driver is already installed.
If you are adding a SCSI CD-ROM, then it must be attached to a supported host adapter to be able to use the configuration utilities. Although you may find a third party driver, you will once again run into the question of who is going to support it.
Open Server allows a maximum of 255 CD-ROM drivers per system. How many are possible on each host adapter is only limited by the host adapter itself. For example, you can only have 7 on a SCSI-1 host adapter, but 15 on a Wide-SCSI-2. If this is the first CD-ROM you are installing on the system, you are also prompted to add support for the High-Sierra filesystem. This is the format that DOS CD-ROMs use, so you must install the high-sierra filesystem if you want to access DOS CDs.
Generally, adding floptical drives is the same for any other SCSI device. You need to ensure that there are no conflicts and that the hardware settings match what you tell the system they are. Here, too, you are limited to the number of devices that the SCSI bus supports.
Although there is a wide range of hard disks that are support in either ODT or Open Server, the combinations that you can add are not that wide. Here I am not referring to either manufacturers of sizes, but rather the type of hard disk, such as IDE or SCSI. One problem is mixing SCSI and non-SCSI hard disks. Personal preference says not to. It is annoying. You are also limited by the fact that if you have already installed the system on a SCSI disk, then you cannot later add a non-SCSI disk.
The thing to note is that the high-sierra (also known as ISO-9660) is the same type as DOS and Windows use. Therefore, don't think that just because you added DOS functionality to your system, you will be able to access a "DOS" CD-ROM. The new Rockridge filesystem supported in OpenServer is an extension of the high-sierra filesystem in that is supports version numbers and long filenames.
There are two nice things about the mkdev cdrom script. First, it gives you the option of adding a standard CD-ROM or a cd-tape drive. Therefore, you can save a little space in your kernel if you need to by only adding what you need. The second nice thing is that if you are adding a standard CD-ROM, you are ask if you want to add the high-sierra filesystem. Now, there is a mkdev scrip to add the high-sierra, which mkdev cdrom calls. However, it's nice to have things done for us. Wouldn't you say?
Like hard disk, if you are adding a CD-ROM and there is not already a SCSI device on your system, the kernel will need to be configured for the host adapter. Also, if you are adding it to a second host adapter, you will need to configure that as well.
This section needs work!!
If you are a good little system administrator then you have already bought yourself a tape drive and have configured it into your system. Therefore, I don't need to talk about adding one. On the other hand, there may come a time when the tape drive you have is not sufficient for you needs and you have to add a new one. As you would guess, the script to do this is mkdev tape.
Before you begin to install the tape drive be sure to have read your tape drive hardware manual. This will often contain information about the physical installation of the device as well as configuration. Whenever, I think about installing tape drives, I think of the first SCSI tape drive I had. There were three jumpers to set the SCSI ID. It didn't make sense that you could only set it to ID 0, 1 or 2. Had I read the manual first, I would have known that this was the binary representation of the number.
As you expected, the values have to be correct for the device to work. You need to know the type of controller you have, the base address, IRQ and DMA. Note that for the DMA channel, you only have an option of 3 or 5 when running mkdev tape. If the tape drive you are adding has it's own controller card, then the base address, IRQ and DMA channel are configured on ISA machines with jumpers or switches. Non-ISA cards can probably be configured via the configuration utilities.
If you remember our discussion on device nodes, you know there are several different kinds of tape drives. A standard cartridge tape, also referred to as a QIC-02 is a about the size of a Betamax video tape. For the younger readers, this is a little smaller than a VHS tape. (Or twice the size of a music cassette) This kind of tape is installed using the Cartridge Tape Drive option. You can either configure this tape drive for auto-configuration or you can input the parameters yourself.
There are a couple of things that things that can go wrong when installing a QIC-02 tape drive. The most common is that it simply does not show up at boot. Instead of the standard configuration string, you get a NOTICE that says the tape controller was not found. This is usually the result of the base address configured in the mkdev script not matching the hardware. However, I had one customer who was having a terrible time configuring a QIC-02. He had removed it and reinstalled it several times, with no success. He was sure that the parameters were correct, because he had used the same tape drive in another machine. Normally, there is no problem with switching QIC-02 tape drives from one machine to another, provided you move the controller card and not just the tape drive. Needless to say, the tape drive work fine when he installed the card. (What he had done was to simply move the tape drive over to the new machine and plugged power into it.)
As with any piece of hardware, make sure the controller is seated properly. You may also have to try a different slot. Maybe the slot is bad. Maybe something else. The first machine that I got when I was in support that I could install UNIX on was a "hand-me-down." The longer you worked there, the more likely you were to get a newer machine. Conversely, the newbie got the hand-me-downs. The one I got, (datrat, as the previous owner had christened) was very sensitive. There was only one QIC-02 controller card in the department that work in my machine. It only worked with one tape drive and in only one slot. Other people could used any combination of drive, card and slot. Not me. One Drive. One Card. One Slot.
If the drive is recognized at boot, but hangs when you issue tape commands, makes sure that the DMA and IRQ are correct. Another possible problem is that the controller card is in the slot, but the drive is not connected to the controller. If the tape drive is external, then it probably has to be powered up at boot time to be recognized. An incorrect IRQ can also result in the message:
Cannot open /dev/rct0
Another possibility is that the device node as become corrupted. If it's a QIC-02, tape drive, the device node should look like this:
crw-rw-rw 1 root root 10, 0 Feb 14 12:00 rct0
If not, try removing then reinstalling the tape drive.
The second option is for a Mini-Cartridge. This option is used to install Irwin tape drives only. The tape for this kind of drive are about the size of a cigarette pack. The drives are hooked up to the floppy controller. Mini-tape drives may use the floppy disk drive controller. Some Irwins will have their own controller. Irwin mini tape drivers differ from others in that they are not configurable and therefore do not require you to enter any parameters when you are installing it. However, you must ensure that the tape drive is set to unit 1.
The third option in mkdev tape is for QIC-40/QIC-80 tape drives. The cartridges are the same size as for an Irwin. If you are installing a non-Irwin mini, there are a couple of things to be careful of. First, the installation mkdev script is the QIC-40/80 script, not the mini cartridge. This is for Irwins only. Although the tapes are physically the same, Irwin tape drives require a different driver.
You are prompted to select whether you are installing a QIC-40 or QIC-80 drive. Also you select whether to enable extended length tapes. Not all tape drives support this. Therefore, you must be sure that the drive can support it, before you enable extended length mode.
If either Irwin or QIC-40/80 tape drive is not recognized at boot-up, it display a message similar to when it can't find a QIC-02. This is due the standard problems of incorrect configuration.
It is possible to have two floppies and add a QIC-40/80, provided that the tape drive is configurable for soft select. On certain tape drives, the unit or drive number can be set by the driver. On Archive and Mountain drives this is called Soft Select mode. On Wangtek drives this is called Phantom select mode. In each case this set on the drive. Check the hardware doc to see if you drive can handle this. It is a good idea to set it, if you can, as it helps to limit the number of problems.
The fourth option is for a SCSI tape drive. There are five different type of SCSI tape drives you can add: Cartridge, Exabyte, 9-Track, DAT and Compaq SCSI. On OpenServer there is an Option for generic SCSI tape drives if you are not sure what kind you have. However, being the good little system administrator that you are, you do know, so you don't need to use this option.
As with any SCSI device you have to be sure of the configuration. You can have multiple SCSI tape drives on the system, provided they have unique SCSI IDs.
With a SCSI tape drive, you may end up with a message indicating there is no controller response. The obvious things to check are the same with any SCSI device, such as proper ID, cabling and SCSI termination. If you have more than on host adapter, make sure that you specified the correct one. Also, if you have OpenServer make sure that you have selected the correct bus if you host adapter is twin-channel.
Like cartridge tapes, external SCSI tape usually have to be turned on when the system boots. If the drive is internal, check to see that the drive initializes when you insert a tape. That is, it will probably make a few "whirring" noises. Also keep in mind that a SCSI tape may appear at boot, even though it is not configured correctly. The initialization routines at boot, do not check the hardware, but do print the configuration string. (Remember, this is done with the printcfg() routine)Therefore, you might see that the configuration strings shows a device that isn't even on the system, let alone configured correctly.
The one important thing about adding a tape drive is that the boot string can be modified to reflect this. You could rely on the kernel having the correct parameters, or you could pass this parameters to the kernel through the boot string. When adding a tape drive, you are given the chance to modify the bootstring. If improperly typed in, this can cause the system to panic when it's booting. So be careful of what you type in.
The default tape drive accessed by many utilities is /dev/rct0. If you install more than one tape drive, the mkdev script will prompt for which drive you want to be the default tape drive. The device node for this will then be linked to /dev/rct0. You can do this by hand or through the menu option in the mkdev tape script.
In earlier versions of SCO, parallel ports were configured by default on the system. When you installed, you had immediate access to the parallel ports. This was useful as most printers ran off the parallel port. However, things changed. The call load went up. Customer could no longer access their parallel port. This was not surprising as the parallel driver was no longer in the kernel on the N1.
The reason for this is simple: it wasn't needed. Well, it isn't all that simple without understanding the reason why the engineers went through the trouble of removing it. Why fix something that wasn't broken or why remove something that didn't bother anyone? You don't go get your appendix out just because you have nothing better to do that day. Or do you?
The same thing applied to the parallel driver. It wasn't needed, that's true, but it was taking up valuable space on the floppy. With all the SCSI drivers in the kernel, there's not much room for anything else. Therefore, some things had to go. One of those things was the parallel driver. As I mentioned, it just wasn't needed during the installation.
This changed caused a large number of calls during the first months after the product shipped. Many hours were spent walking people through the mkdev parallel script to add the parallel port. It isn't hard, but for the most part, customers would much rather have someone tell them how to do it rather than reading from a book. Besides, finding it in the installation guide isn't all that easy. (Assuming, of course, you don't look in the index or table of contents)
As I said, adding the parallel port is not all that difficult. When you run mkdev parallel you are given three choices for ports to add. If you are not sure how your parallel port is configured, I would suggest you add all three. When you reboot, the hardware screen will display the one you have and you can then remove the others.
On a new system, it is common to add the parallel port and then immediately add a printer. Or in many cases the reverse: you've added a printer and it won't work 'cause you haven't run mkdev parallel, yet.
The mkdev lp script is one of the shortest and for good reason: the script itself doesn't do much. Instead it calls /usr/lib/sysadm/lpsh. The lpsh program is one of the nice looking ones that uses the menus and so on in oamenus and oaforms. You can call this program yourself or even get to it through sysadmsh. Since I talked about adding printers in the section on printers, there really isn't much more I can say here.
Similar in function is mkdev serial, although as you suspect you use this to add serial ports instead of parallel ports. The real important issue is not to use this script when trying to add intelligent multiport cards such as those from Digiboard or Equinox. Both of these have there own drivers and installation routines. They will modify the kernel appropriately and add the device nodes. The mkdev serial script is only to add non-intelligent (also referred to as dumb, for the non-politically correct among us) serial ports.
By default, only the COM1 device is configured into the kernel, even if you have a COM2. This can be added later by running mkdev serial.
There are many manufacturers of non-intelligent serial cards. These cards do not have any special processor on them and are accessed using the standard sio driver. Because of the minor numbering scheme used for serial devices (see the section on the /dev directory) you can only add 8 non-intelligent serial ports, even though there is an option in mkdev serial to add a 16-port card.
Using the mkdev serial script, there are only two options for such cards. They represent the standard COM1 and COM2 ports. Depending on the number of ports you want to add, you will be given a number of manufactures to choose from. Although this does not represent all the ones available on the market, but it does cover quite a few. There is a way to add addition ones if you need to.
Let's first side step a minute and take a look at /etc/conf/sdevice.d/sio. It looks something like this:
sio Y 53 7 0 3 2f8 2ff 0 0
sio Y 26 7 0 4 3f8 3ff 0 0
In the section on the link kit, I went into details about the files in the sdevice.d directory. I said that column 3 represented the number of "units" of that type that were configured. While this is also true for the sdevice.d/sio file, there is a level of indirection we need to address.
If we look at the above example, (which I have not changed from what the system creates by default) we see the two line that represent COM1 and COM2. It seems rather ridiculous to think that there are 53 COM1 ports and 26 COM2 ports on the system.
In this case, these do not directly represent the number of ports but rather the offset into an array. This is the sio_sup_brds array in /etc/conf/pack.d/sio/space.c. If we look at the 54 line (remember we start counting a 0) we see the entry for the AT-IBM-COM2 device. Next, if we look at line 27, we see the entry for the AT-IBM-COM1 device. (For details for what each entry means, see the declaration of the board_t structure in <sys/sioconf.h>.)
If you want to add a new board to this list copy an existing entry and add it to the bottom of the array. I want to empathize that this ought to go at the bottom of the list because the entry in sdevice.d/sio is the relative position in the array, placing an entry before line 27 or line 54 throws things out of whack.
The next time you run mkdev serial, the entry you added with appear as one of the options. Provided you've input everything correctly.
The limit of eight serial ports is not because the system does not support it, but rather because there are few entries in pack.d/sio/space.c that support it. The few that exist all micro-channel devices and are only listed for COM2. This is because the minor numbers for COM2 start at 8. If a 16-port board were to be added to COM1, the minor numbers would overlap those for COM2.
One common question that support gets is why you can't have COM3 or COM4. Well, the official word is that you can't. The reason is that COM1 and COM3 share interrupts and COM2 and COM4 share interrupts and the SCO serial driver cannot support serial devices at the same interrupt. However, this is generally true on older boards, newer ones may allow you to configure both the base address and the interrupt.
If we go back to /etc/conf/pack.d/sio/space.c for a moment, we see that there actually are entries for COM3 and COM4. They can be configured like this:
I/O PORT ADDRESS
0x2F0 - 0x2F7
0x3E8 - 0x3EF
0x2E8 - 0x2EF
If your card can be configured to one of the configurations above, then you can simply run mkdev serial and select the proper COM port. If not, you can try to change the entry in the sio/space.c file to reflect your configuration. However, I cannot guarantee it. I have personal experience with using the three settings above, not with changing the sio/space.c file. However, based on the way the file is put together, it should work.
Part of the mkdev script asks you to select a baud rate which for devices attached to this port. This only means what default values will be used when creating the entries in /etc/inittab and the files in /etc/conf/init.d. Once completed, the mkdev will add the entries to the Terminal Control Database.
A common problem with serial cards is loss of characters. In certain circumstances, this can be corrected by increasing the NCLIST kernel parameter. If this does not correct the problem, then you may consider getting a either an intelligent serial card (one with its own processor) or one with a 16550 UART. This has a multiple character buffer, which decreases the number of characters lost.
In general, installing a serial terminal is the same whether it is connected to a standard COM port on an intelligent multi-port board. In either case, you obviously have to ensure that the driver for that port is linked into the kernel, otherwise the terminal will not be able to talk to the system.
By default, terminals are set up using 9600 baud, 8 data bits, 1 stop bit, no parity, full duplex, and XON/XOFF handshaking. If your terminal cannot handle these settings, then you can either change the line in inittab to reflect the appropriate gettydefs entry, or you can create your own gettydefs entry if none of these fit. See the section on starting your system or the gettydefs(F) man-page.
Pay attention to which pins are which on the terminal. You only need to worry about three: transmit, receive and signal ground. The serial port will be set up (probably) with pin 2 as transmit, 3 as receive and 7 and ground if you have a DB25 (25-pin) connector. If you have a DB9 (9-pin) connector pin 2 is receive, 3 is transmit and pin 5 is ground. Make sure that the cabling is set up so that transmit on one side goes to receive on the other and the two ground pins are connect. In some cases you need a crossed cable, when the pin numbering is the same on both sides (i.e. the same number of pins). If pins 2 and 3 are different, then you need a straight through cable.
You need to ensure that there is an entry for the terminal in both /etc/inittab and either /etc/conf/cf.d/init.base or a file in /etc/conf/init.d. If not in inittab, but in either of the other two locations, then potentially the serial port was added to the device driver files, but the kernel was never relink. Remember from our discussion on the kernel, when you do a relink, part of rebuilding the kernel environment is creating a new inittab file by catting the files in etc/conf/init.d onto the end of /etc/conf/cf.d/init.base. Not relinking would explain why the entry was not in inittab.
On the other hand, if it's not in either of the other files, but is in inittab¸ then probably someone added it to inittab by hand. This needs to be corrected by putting the entry in one of the other files. Otherwise, the next time you relink, the entry is gone.
If the entry is correct, you can enable it with the enable command. Like this:
The enable command changes the entry in inittab and either of the other locations from off to respawn. If the terminal is already enabled, you get a message saying so. It is the fact that there is a respawn in inittab that gives you the login prompt when the system starts and gives you a new one when you log out. For more details, see the section on starting and stopping the system and the inittab(F) man-page. When enabled, the corresponding entry might look like this:
Se1a:234:respawn:/etc/getty tty1a m
If the login prompt doesn't look right (i.e. garbage characters) then probably the gettydefs entry is incorrect. If you remember from our discussion of starting and stopping the system, this is the last entry on the line. In this case m. If the m entry in gettydefs does not match what the terminal is set for, you get incorrect behavior. See the gettydefs(F) man-page for more details.
If you don't see a login on the terminal, it's possible it was sent before the terminal was turned on. Therefore, the terminal cannot display it. If you press ENTER a couple of times an no login prompt appears, maybe it's not really enabled or there is a hardware problems. Disabled it and re-enabled it. You should also try simply sending the date to the file, with:
date > /dev/<tty_name>
If that still produces nothing¸ then you may have a hardware problem. If you have enabled the port, you can run:
to see if there is a getty or login running on that port. If not, there may be some serious software problems.
Often times the connector on the terminal is female. You can test the terminal if take a paper clip and put one end in hole 2 and the other end in hole three. By pressing keys on the keyboard, the data is going out the transmit line (pin 2 or 3, doesn't matter) and comes back in on the other pin. If nothing appears, first makes sure that the terminal is turned on (I've had my share of those calls). If it is turned on check the brightness (I've had enough of those, as well). If still nothing, the monitor is probably on vacation.
If you suspect the cable or serial port, you can try the terminal on a port that you know is working. Then switch parts one at a time, until you isolate the part that's broken.
Another script that really points elsewhere is mkdev graphics. In general, this does the same thing as when you configure the video card through the System®Hardware menu options in sysadmsh. In fact, the exact same program is called. This, too, has the same menuing functionality of lpsh.
In ODT, your video card and monitor were configured using mkdev graphics. As with other mkdev scripts, mkdev graphics still exists, but call the corresponding manager from scoadmin. In this case it is the Video Configuration Manager. The mkdev graphics script is based on the same functions as the sysadmsh so you have the same kind of windowing as with sysadmsh. The Video Configuration Manager is the same as the other configuration managers.
One important difference you encounter right away. In ODT you do not "Add" a video adapter, but rather "Update". In OpenServer, there is button "Add Adapter." This is a little confusing since when you get done, you are asked whether you want to replace the existing video card. To me this is a bug, or at least a very annoying feature. If I replace the adapter, I am not adding anything. I am either replacing or updating the adapter, but certainly not adding. At any rate, don't be confused when you run into this.
If you select "add adapter", then you are presented with a list of video cards. If you don't have a video card, but rather the video chips are built onto the motherboard, you should look for the chipset you have. If your card or chip set is not there, you should either select one that is closest, or contact SCO or the manufacturer. SCO might have included the driver in the newest copy of the Advanced Hardware Supplement (AHS). If all else fails, try the generic IBM VGA adapter. Although you may not get the resolution you want, selecting this card normally gets you running.
When you finally select one, you may find that your card had "special configuration information" if you select 'yes' to view it, you are brought into SCOHelp, which will give you more details about the card. If there is no additional information or you have finished reading the help file, you need to select the resolution and the monitor configuration. If you just click okay, you are reminded that you haven't configured the card completely and are asked to do so or click cancel.
Interestingly enough, if you have selected (highlighted) the video adapter and then click on Modify instead of Add, you are told that this action will remove the configured card (which is displayed) and that you can cancel on the next screen. The next screen is simply the Add Adapter screen, so you are at the same place.
CAUTION: If you are reconfiguring an existing graphics adapter that uses I/O addresses and a memory mapped window, please be sure to write down your current selections before you choose new ones. When you choose new settings, the current I/O addresses and memory mapped window are not saved. If you reconfigure an adapter, then later choose not to save the configuration, the previous settings for the grafinfo file are not restored.
When you select the option to modify the monitor, you are given the choice of changing the monitor itself (model, brand, etc), the resolution of the monitor or add a resolution. This allows you to have multiple resolutions for the same monitor. There is a list of monitors from which to choose from. Here again, find your or what that closely matches. If you don't find one, there are several listed that say "Other 15-inch" "Other 16-inch" etc. Find the size you have and select that type.
Next, click on Change resolution to modify the resolution of your monitor. Here you need to be careful. You might have a video card that supports a higher resolution than the monitor. Remember that any system is only as strong as its weakest link. If you try to push the monitor beyond it's limits, you could physically damage it. At best, you might end up with a crazy looking display. Therefore, select a resolution and scan rate that your monitor supports.
Think back to our discussion of video cards. Maybe your card supports a particular resolution "in principle". However, if you do not have enough RAM to support that resolution, then your video card really doesn't support it. Check the card documentation for how much memory is need for each resolution. Higher resolution on monitors may require setting the monitor to interlaced on non-interlaced mode. Again, check the hardware documentation.
New to OpenServer is the idea of having multiple resolutions. Here you can assign the console multiscreen function keys to different resolutions. The ability to configure the function keys is also new to OpenServer. If you want to use the monitor and resolution you chose for each console multi-screen, select "Assign all function keys". The time you would want to select a different monitor and resolution is when you have a second video card and monitor that have a different resolution. If you are configuring multiple cards and monitors, I suggest that you group the function keys somehow. For example, you could assign F1-F6 to one video card and F7-F12 to the other one.
The Video Configuration Manager does not configure the kernel like other driver, but instead gets its information from three ASCII files, stored in /usr/lib/grafinfo. The graphinfo files, contain the information for the graphicsi (video) cards. derives the configuration choices it provides from three sources: grafinfo (graphics card information) files, moninfo (monitor information) files, function key or device files. The grafinfo and moninfo files are ASCII text files that are located in subdirectories of the /usr/lib/grafinfo directory. These files describe the attributes of the graphics adapters and monitors that are supported by the Graphical Environment.
The grafinfo files use the name of the particular adapter they describe and an .xgi extension (for example, wonder.xgi); the moninfo files use the name of the particular monitor they describe and a .mon extension (for example, 8514.mon). The function key or devices files are text files that are located in the /usr/lib/vidconf/devices directory. These files contain the device driver names for all the programmed function keys on the console (<F1> through <F12>) as well as the device driver name for the console. The console driver is used when the system is running in single user mode.
New to OpenServer are "readme" files for many of the video drivers. In most cases, these can be displayed when running mkdev graphics.
The scripts mkdev ptty and mkdev streams usually are associated with either TCP/IP or X-Windows. Pseudo-ttys are virtual terminals, that do not have any physical counter-part. For example, if you connect to a remote machine via telnet, the shell needs to write it's output somewhere. That somewhere is the virtual, or pseudo-terminal you are using. When installing TCP/IP you are asked how many pseudo-ttys you want installed. If you input a value that later turns out to be too small, you can use the mkdev ptty script to add more.
Streams are configure in the system be default when you add either TCP/IP or X-Windows, and are a way to add modularity to drivers. Like mkdev dos, the mkdev streams script is like and on-off switch. Since streams is essential to X-Windows and TCP/IP removing them if either one is installed is not a good idea.
Next, we get to mkdev mouse. There are several different kinds of mice as you might remember from our discussion on the /dev directory. Although not possible in a DOS or Windows environment, it is possible under SCO to have multiple mice configured on your system.
In that discussion, I brought up the fact that there are three kinds of mice: bus mice, serial mice and keyboard mice. The most annoying to work with (at least in my mind and from and administrative point-of-view) are bus mice. These have their own cards that are plugged into slots in the machine. In order to configure them correctly, you have to ensure that the jumpers (or switches) match those that you tell the software. In addition, there is a problem just in the fact that they require these setting. Most of the one I have seen do not allow you to set IRQs higher than 9. Since the interrupts below that are already in short supply, taking one away for a bus mouse is annoying. My solution is a serial mouse.
Now a serial mouse does have the disadvantage of taking away a serial port. If you attach a modem to the other serial port, both of them are gone. Then, on the other hand, what else do you need the serial ports for. In order to connect to the system, serial mice will have either a DB9 or a DB25 connector. Some, like my Logitech Trackman have a DB9 on the end of the cable, but provides a DB9 to DB25 adapter.
Another nice thing about serial mice is that you don't have to connect them to a standard COM port. If you have a multiport board (intelligent on not), you can attach the mouse to any port on the multiport board. Be careful, however. You want to be sure that you attach the mouse to the non-modem control port (the lowercase letter, i.e. tty1a).
Keyboard mice are connect to a dedicated port at the back of your computer. They will usually have either a 6-pin or 9-pin mini-DIN connectors. More and more computer vendors are selling their systems with keyboard mouse plugs built-in. Often, the plug for the console keyboard is the exact same size as the one for the mouse. Needless to say, I got enough calls from customer when trying to install their OS, they couldn't even boot because of a keyboard error or something similar. (Now, ask yourself one question: "Is this really an operating system problem.")
Now, if you think back to the section on starting and stopping the system, the hardware check comes before the system tries to boot. Therefore it hasn't even looked at the installation floppy, so there is nothing the OS could have done to cause the problem. However, the customer, not knowing the phone number for the hardware manufacturer found SCO's quick enough and called us.
Unlike the other mouse types, installing a keyboard mouse without one on your system can cause some problems. It is known to happen that the keyboard will lock, if there is no keyboard mouse port on the machine. If this happens you will need to boot off an old kernel and remove the keyboard mouse driver.
During the installation process of either type of mouse, you are asked the devices to which you want to associate the mouse with. You could associate a mouse on COM1 with /dev/tty01-/dev/tty05 and the mouse on COM2 with /dev/tty06-/dev/tty10. This might be useful if you had two video cards in you system that split the console tty devices between them. There is also an option within the mkdev script to change the association of the mouse. Therefore, you can add a video card later and change the device association.
Keep in mind that if you don't have the mouse configured correctly, you will run into trouble when starting X. Sometimes you just can't log in, so you have to switch screen to get a character login. However, I have seen cases where you cannot even switch multi-screen. Therefore you might want to test the mouse before you use it.
There is relatively unknown program that not only allows you to test your, but allows you to use it with such things as sysadmsh and even vi! To start it in "vi mode", run the command like this:
usemouse -t vi -c vi <file_name>
I'd recommend choosing a file that already exists to see the behavior. You can also use the mouse with sysadmsh.This is one of the other modes that usemouse has. This is simply based on one of the configuration files in /usr/lib/mouse.
In vi, the mouse buttons should result in the follow actions:
The left button moves the cursor to the beginning of the file.
The middle button deletes the current character.
The right button moves the cursor to the end of the file.
To simulate the middle button on a two button mouse, press both of the other buttons at the same time. This is called "chording". You stop the usemouse utility simply by typing exit at the shell prompt. This is because usemouse starts a sub-shell when it is invoked.
If this does not produce the correct behavior, go through the normal "sanity checks" of ensuring the cabling is correct, jumper settings match (if applicable), the card is seated correctly (if it's a bus mouse) and is recognized at boot if a bus mouse and the serial is recognized if a serial mouse, and that the mouse is supported.
In the section on hardware, I mentioned that the resolution of the mouse effects how much it moves across the screen in proportion to how much you move it across the mouse pad. If you have a keyboard mouse, the resolution can be changed by editing /etc/conf/pack.d/kbmouse/space.c. The kbm_resolution parameter determines how many "clicks" (or reports or counts) are passed to the mouse driver for every millimeter you move the mouse. The relationship between kbm_resolution and the clicks per millimeter for a high-resolution mouse are:
For a low resolution mouse, the relationship looks like this:
If you change this parameter, you must relink the kernel and reboot, before the changes will take effect.
A common problem with mice is that they are sometime slow or "sluggish." That is, they do no appear to move or react as quickly as they should. This can be changed by modifying the kbm_poll, also in /etc/conf/pack.d/kbmouse/space.c. This parameter determines how often the mouse driver will poll the mouse. The greater the value the more often it will poll. If you decrease the value below 0xb0, the system might freeze. A good starting value is 0x400.
Here again, you must relink and reboot for the changes to take effect.
If you have a Compaq machine, there is one script that would be of special use to you. The mkdev ida script allows you to add an Intelligent Drive Array. This give you the ability to talk to several physical hard disks as one large one.
If you have a Corollary system, the mkdev eccd script allows you to add the memory error checking and correction (ECC) facility. The daemon associated with this device regular checks memory and is capable of detecting single bit and double bit errors. Single bit errors can be corrected, whereas a double bit error cause a panic. the ECC facility notifies the system of single bit errors and decreases the likelihood that they grow into double bit errors.
Two remaining scripts, 'mkdev vpixld' and 'mkdev dda' are used if you have VP/Ix on your system. If you don't know what VP/ix is don't worry you don't want to. Since I am not going to be talking about VP/ix at all, we are going to have to leave these alone.
There are two scripts that are linked together: shl and layers. They add shell layers to you system. Shell layers allow you to interact with more that one shell session from a single terminal. This is comparable to repeatedly typing sh to get sub-shells. The key difference is that with sub-shells, you can move only in one direction. Once you start a sub-shell, you do not have ready access to the parent shells. With shell layers, you have access to all shells.
This may sound like an interesting topic (which it is), however the low number of calls and the simplicity of the subject cause me skip this topic.
One of the more simpler scripts is mkdev dos. This is really nothing more than an on-off switch. This script is used to either add DOS support or remove it. Once it's added and you reboot, you will be able to mount DOS filesystems and access them like any UNIX filesystem. You do not need to have Merge installed to take advantage of this functionality. For more details, see the chapter on DOS and Windows compatibility.
Another script that adds functionality without adding devices is mkdev mmdf. The mkdev mmdf script allows you to configure SCO UNIX's standard mail system MMDF. There are quite a few configuration aspects to cover, which we covered in detail in the section on MMDF.
Next: System Monitoring
Copyright 1996-1998 by James Mohr. All rights reserved. Used by permission of the author.
Be sure to visit Jim's great Linux Tutorial web site at https://www.linux-tutorial.info/