Figure 14-1 The major hardware components of a typical system
Information on installing and configuring these components
is provided in later chapters. See:
The CHWP include:
New and updated drivers for current and previous SCO OpenServer releases
can be downloaded from the SCO Software Library:
ftp://ftp.sco.com/pub/drivers/
Because today's computer hardware market changes rapidly,
we recommend that you consult these web pages regularly.
In particular, we recommend that you verify support for your
devices before installing or upgrading drivers or operating
system products.
Supported architecture
Except where otherwise noted, the hardware information
in this book applies to the
PC bus architectures supported by SCO:
Industry Standard Architecture (ISA),
Extended Industry Standard Architecture (EISA),
Micro Channel Architecture (MCA), and
Peripheral Component Interconnect (PCI).
SCO OpenServer systems support a limited number of
Personal Computer Memory Card Interface Association
(PCMCIA) cards but do not currently support
the complete PCMCIA subsystem.
In addition to the specific devices mentioned here, there are many
others which require additional vendor supplied
software. These are available from, and supported by, independent
hardware vendors. Call your reseller or sales representative and ask
for the latest SCO Hardware Compatibility Handbook or the SCO Directory.
These are also available online from the SCO World Wide Web
homepage and can be accessed with a suitable browser.
The URL (Uniform Resource Locator) is:
http://www.sco.com/chwp
General compatibility issues
If your computer is listed as a supported machine in the
SCO list of compatible hardware it should run SCO OpenServer systems. However, if you are
adding additional hardware such as host, video, or
network adapters you may require new or updated device
drivers.
New and updated drivers are supplied with each SCO OpenServer
release; see SCO OpenServer Features and Limitations for details about devices supported
in this release. See also
``Accessing the SCO Compatible Hardware Web Pages''
for more information about device support on SCO platforms.
The hardware described in this book has been tested with SCO OpenServer systems. However, because the manufacturers of compatible machines or add-on peripherals may change configuration, functionality, or firmware at any time, no guarantee is implied.
To determine whether hardware components are compatible with your machine, you must know the processor (for example, 386, 486 or Pentium(TM)) and the bus architecture (ISA, EISA, MCA and PCI) that it uses. You should also be aware of the type of disk controller in your system.
Some computers arrive with the hard disk only partially formatted. If you have such a machine, use the correct low-level or hard format procedure as described in the manual for your hard disk controller before installing an SCO OpenServer system. This does not apply to most SCSI or IDE hard disk drives.
We recommended that you install the operating system without any additional or unnecessary hardware installed on the system and with any switch settings at their factory defaults. Hardware configuration conflicts can make installation of an SCO OpenServer system difficult or impossible.
If you have added any boards, make sure that all switches or software-controlled settings are set as recommended in the manufacturer's hardware manual for that board. Some computers require specific switches or software-controlled settings to run SCO OpenServer systems. If your computer does not run the SCO OpenServer system with the settings as shipped, contact your computer hardware representative for the proper settings.
Typical device interrupts
One of the most common causes of problems both during and
after installation is a device interrupt conflict.
Make sure device interrupts do not
conflict and do not use the reserved interrupts indicated in
Table 14-1
or your system will probably fail to boot.
Table 14-1 Typical device interrupts
--------------------------------------------------------------------- Interrupt Octal Device --------------------------------------------------------------------- 0∗ 0 Clock 1∗ 1 Console 2 2 Networks, tapes and others 3 3 Serial COM2 4 4 Serial COM1 5 5 Alternate parallel port (lp2) 6∗ 6 Floppy disk 7 7 Main parallel port (lp0 or lp1) 9∗ 11 Chain from IRQ2 10 12 11∗ 13 SCSI host adapter 0 12 14 SCSI host adapter 1 13∗ 15 FPU 14∗ 16 ST506/ESDI/IDE controller 0 15 17 ST506/EDSI/IDE controller 1
* Do not attempt to use these interrupts for any other purpose.
Configuring devices with bootstrings
You should read
``Using bootstrings''
if any of these conditions are true:
Boot: prompt displayed at system
startup. Normally this process is transparent to the
operator because when you press <Enter> at the Boot:
prompt, the system uses a pre-defined bootstring such as
hd(40)unix specified by DEFBOOTSTR in
/etc/default/boot.
There are special bootstrings that permit you to define device configurations that override system defaults (without relinking the kernel). For example, you might be using a tape drive at a non-standard address or the system might not be recognizing your host adapter correctly. In a similar way, new device drivers that are not supplied with SCO OpenServer systems can be installed from a floppy disk using the link bootstring.
To define or redefine a device at boot time:
Make certain the bootstring parameters you use match your hardware configuration. Additional bootstrings are documented in the boot(HW) manual page.
Boot:
prompt. If you are performing an installation, note that
this is the only time the Boot: prompt appears;
you are not given the opportunity to reboot during the
installation unless you are installing from tape.
Now enter the necessary bootstrings separated by spaces.
For example:
defbootstr Stp=wdha(1,1,0)
defbootstr is not shown in the following examples, but remember that it should be included on the boot line. The system then boots according to the information you provided. If you entered the bootstring incorrectly, an error message is displayed.
For additional information on the boot process and bootstrings,
see the
boot(HW),
boot(F),
bootstring(HW),
link(HW),
and
mem(HW)
manual pages.
Advanced Power Management bootstrings
If you need to configure, control, or query the operating
system's power management facilities after it has booted,
you should use the Power Management control shell,
pwrsh(ADM).
See
``Configuring Power Management''.
Access to your system's BIOS-APM at boot time by boot(HW) is controlled by the apm.cmd= bootstring. When boot runs, it executes any apm.cmd= lines found in /etc/default/boot (see the boot(F) manual page); these define the default APM handling. Any stand-alone apm.cmd= commands issued at the boot prompt override these settings. Alternatively, apm.cmd= may be specified as an argument to most stand-alone commands.
The following bootstring arguments can be used to configure APM if it is accessible:
A status error does not stop APM being used; in that case,
the apm.warn= and apm.boot= conditions are not
tested.
The default apm.boot test is:
ac.online | charge.high | charge.low | (!charge.unknown & % >= 15)which permits the boot process to proceed if AC mains power is being used or the batteries have sufficient charge (greater than or equal to 15%).
The default apm.warn test is:
!ac.online & (charge.low | charge.critical | (!charge.unknown & % <= 25))which issues a warning if AC mains power is not being used and the BIOS-APM reports that the charge in the batteries is low (less than or equal to 25%).
These tests should work on systems where the APM firmware can deduce the approximate status of the battery without knowing the percentage charge remaining.
On some machines, the APM firmware does not know the condition of the battery. It may then report no charge remaining (% = 0 is true) rather than admitting that the charge is unknown (charge.unknown is true). Consequently, either of the above test conditions may always be true when such machines are using batteries rather than AC power.
To try to overcome this problem, the apm.warn test could be changed to:
!ac.online & !battery.unknown & (charge.critical | % <= 25)However, this may not work on all such machines.
Different manufacturers interpret different percentages of remaining charge or approximate battery status as being ``high'', ``low'', or ``critical''. These interpretations may have been designed to be used with proprietary software, and so may be misleading. They may not produce satisfactory results if they are used as indicators of the battery's charge state. Checking the percentage of remaining charge should be more satisfactory, but is not possible on all machines.
The kernel can only use APM if it supports a 32-bit Protected Mode interface. If such an interface is available, one of the following bootstrings can be used:
The ct bootstring has the general format:
ct=controller(base,irq,dma)
where:
Boot: hd(40)unix ct=wangtek(0x338,5,1)
When you invoke the tape bootstring manually, you must
specify hd(40)unix or fd(64)unix, not
just unix. The tape bootstring is not checked
until the driver is initialized. If the configuration
information supplied in the bootstring appears to be
invalid (for example, the controller named in the
bootstring is not supported), then a warning message is
printed, and the tape driver ignores the bootstring and
uses the default configuration.
The syntax for SCSI bootstrings is:
periph=adapter(hanum,[bus,]id,lun)
where:
For example, to define a SCSI tape device connected
to the first Future Domain adapter at id 4, lun 0, use the
following bootstring:
Stp=fdha(0,4,0)
SCSI host adapter bootstrings
The adapter bootstring overrides the kernel's
default configuration for a given host adapter. It has the
following syntax:
adapter=driver(base, int, dma)
where:
If the kernel fails to recognize, or incorrectly
identifies, your SCSI adapter at boot time, you
can use the adapter bootstring to define it. For
example, if you have an Adaptec 1522 board installed and
the system fails to recognize it as configured, you would
use a bootstring similar:
adapter=spad(0x340,11,0)
Root hard disk bootstrings
The hd bootstring overrides the default search
sequence used by the hd driver to determine
the root disk. The syntax of the bootstring is:
hd=driver
where driver is the disk driver prefix.
Valid driver prefixes are:
To boot from a Compaq IDA drive, you would use the bootstring hd=ida0.
You should add this bootstring to the definition of
DEFBOOTSTR in the file /etc/default/boot so
that the system uses the correct root disk configuration when it boots.
Disabling drivers with bootstrings
Sometimes the system may detect a device that is not
actually present. You can use the disable
bootstring to disable the driver. The syntax of the
bootstring is:
disable=driver[,driver ... ]
For example, if you wanted to disable the dpt driver and boot from another device on the system, you would use the bootstring disable=dpt.
If you are having trouble installing SCO OpenServer due to errors with specific drivers, you can disable these drivers with the disable bootstring. Provided that these drivers are not required to install the system, use the following:
To disable machine architecture checking, type:
boot: defbootstr mcheck.disable
To prevent the retrieval of information about hardware on the PCI bus,
type:
boot: defbootstr pci.bios32
To prevent scanning the SCSI bus for additional hard drives, type:
boot: defbootstr scsi.noscan
To prevent scanning the ATAPI interface on the IDE bus for
additional hard drives, type:
boot: defbootstr wd.noscan
Specifying the location of an EIDE (IDE) CD-ROM
The srom bootstring allows you to specify the location of a
CD-ROM on the EDIE (IDE) bus:
srom=wd(<IDE Controller>, <Master/Slave>, <LUN>, <BUS>)
The valid options for any of the above arguments are "1" or "0".
For example, to specify a CD-ROM that is on the secondary
IDE controller that is set to master, type:
srom=wd(1,0,0,0)
If the CD-ROM is the only device on the IDE interface, it must be set to master.
Memory bootstrings
The mem bootstring enables you to discover how much
memory boot thinks your system has, and to
reconfigure this if necessary. To find out how much memory
boot thinks your system has, enter
mem=/p.
To define your system as having 12MB of memory starting at 1MB in addition to its 640KB base memory, enter mem=1m+12m or, alternatively, mem=1m-13m You can use this to limit the memory size of your machine artificially -- for example, to test the performance of an application on a machine with a smaller amount of memory. You can only allocate memory as pages aligned on 4KB boundaries.
Memory above 16MB is not addressable by DMA for those peripheral controllers that only support 24-bit addressing. To mark memory above 16MB on a 24MB machine as non-DMAable, enter mem=1m-16m,16m+8m/n.
For more information about the mem bootstring, see the
mem(HW)
manual page.
cache bootstring
Both 486 and Pentium processors have an internal on-chip cache and an
optional external cache. boot can control the cache behaviour
with the cache bootstring. The following options are
available:
There are two ways to install BTLD disks on your system:
Boot:
prompt; it cannot be executed once the kernel has loaded.
Invoke link by typing link at the
Boot: prompt and pressing <Enter>, or by using
the link= bootstring argument.
If you invoke link directly, it prompts for the names of the packages to load:
What packages do you need linked into the system,
or q to quit?: pkg1 pkg2
The link command ignores any link= bootstring arguments.
Alternatively, you can use a link= bootstring argument
which has the syntax:
link="pkg1 pkg2 ..."
where pkg1, pkg2 and so on are the names of BTLD packages to be linked into the loaded system kernel.
If the package names do not include the name of the device from which to read the BTLDs, you can define the device using the bltd (or btlddev) bootstring. The default device is usually the same as the one from which the boot program was loaded.
After the kernel loads but before it runs, link prompts you to insert the appropriate floppy disk for each BTLD package you specified.
You may now be prompted to enter any tuneable parameters and hardware-dependent parameters such as the interrupt vector (IRQ), DMA channel, and base I/O address. If any conflicts occur (for example, if the interrupt vector that the boot-loaded driver wants to use is already occupied by another driver), boot explains the problem, lists the possible resolutions, and prompts you to choose.
If any errors occur while the BTLDs are being
extracted, you must reboot the system. Insert the N00
(installation boot) floppy, and enter restart at
the Boot: prompt to restart the installation or
upgrade from the beginning.
Adding BTLDs after initial installation
To add BTLD drivers after installation:
In the Hardware/Kernel Manager, select a driver to configure from the list, then click on the Configure Driver button. Follow the prompts. For more information, see ``About device driver configuration''.
Once you configure the driver, click on the Relink Kernel button; click on Relink to confirm. See ``Relinking the kernel'' for more information. To activate the new kernel once it is relinked, reboot your system using the System Shutdown Manager or the shutdown(ADM) command.
You can also use the Hardware/Kernel Manager to tune the kernel parameters. To do this, click on the Tune Parameters button. See ``Configuration tools'' in the Performance Guide.
See also:
Figure 14-2 The main Hardware/Kernel Manager screen
About device driver configuration
Use the
Hardware/Kernel Manager
to configure device drivers into the kernel.
For a detailed description of driver configuration by device type, see:
See also:
It is also possible to relink the kernel by hand. You might do this when, for example when you have added several different drivers to the system and chosen not to relink as part of the mkdev process, or you have installed BTLDs using installpkg(ADM). In order to relink the kernel you must be logged in as root, and the Link Kit must be installed on your system.
To relink the kernel by hand:
The linking process will now begin. The speed with which the kernel relinks depends on a number of factors; the process can take several minutes on slower machines.
Once the kernel has been rebuilt you will see the following message:
The UNIX kernel has been rebuilt.Enter ``y'' if you want this to be the boot kernel.Do you want this kernel to boot by default?
The system now backs up the old kernel by moving the current /unix file to /unix.old, then asks whether you also want the kernel environment rebuilt. This will make any necessary changes to the /etc/inittab and device node files. Enter ``y'' to rebuild the kernel environment.
The system will respond with a message that the kernel has been successfully linked and installed and that you must now reboot the system for any changes to take effect.
On laptops, the power management facilities usually provide a report on the battery charge level, permitting you to shut down the machine before the batteries are completely discharged. Some systems may be able to turn off hard disks or monitors after a period of inactivity, or by explicit command.
If your system has the required APM hardware, and
this was recognized and enabled by
boot(HW)
at boot time, see
``Advanced Power Management bootstrings''.
The Power Management daemon,
pwrd(ADM),
runs to handle system events notified by the
BIOS-APM firmware, such as low power. Possible
events are defined in the file
/etc/pwr/sys/events, the format is defined on the
pwrevents(F)
manual page. An action is defined for each event that
allows the system to respond appropriately. Possible
actions are defined in the file
/etc/pwr/sys/actions, the format for which is
defined on the
pwraction(F)
manual page. You can find the scripts invoked by the
action file in the directory
/etc/pwr/lib. An example is battery
which shuts the system down if the power is low. Edit the
actions file and scripts to tailor the response
of your system to the various power events. However,
events are pre-defined in the BIOS; you cannot
configure the thresholds at which they occur yourself.
Configuring APM using pwrsh
As an alternative to configuring the pwrd daemon,
you can use the
pwrsh(ADM)
command to configure, control, or query the power management
facilities of your system after it has booted.
Typically, you would run pwrsh regularly as a
crontab(C)
entry for root to check the charge status of the
batteries and take appropriate action if necessary.
To prevent interaction with pwrd, change the command
(cmd) associated with the appropriate event's action
to ``exit 0''.
See
``Checking battery status regularly''
for an example of how to do this.
pwrsh can read commands from the command line (using
the -c option) from a specified file, from the
standard input, or interactively. If you run pwrsh
interactively, use the ? or help command
for information about other commands. Enter
quit or <Ctrl>D to leave
pwrsh.
You can use the status command to
obtain the boot-time, previous, or current power status of the
machine's AC supply and batteries:
/etc/pwr/bin/pwrsh -c "status -b -AB # print boot-time power status"
/etc/pwr/bin/pwrsh -c "status -n -AB # print previous power status"
/etc/pwr/bin/pwrsh -c "status -AB # print current power status"
You can also specify a power test condition to the
status command in the style of
hasapm(ADM)
-- see also the description for the apm.boot
and apm.warn in
``Advanced Power Management bootstrings''.
pwrsh exits with a value determined by the last command
executed. When a test is used with the status command,
this is the result of the test:
[ /etc/pwr/bin/pwrsh -c "status -s \
!ac.online & (!charge.low | !charge.critical | \
(!charge.unknown & % <= 25))" ] \
&& echo "No AC power and battery charge is low!"
You can use the state command to turn the system or peripheral devices on (Ready) or Off, make them Idle but automatically ready for use, or Freeze them to conserve data.
For example, the following command idles the entire system if
battery power is low and the AC supply is not being used:
[ /etc/pwr/bin/pwrsh -c "status -s \
!ac.online & ( charge.low | charge.critical )" ] \
&& /etc/pwr/bin/pwrsh -c "state -i all"
The following command freezes the video screen and keyboard and
idles the hard and floppy disks:
/etc/pwr/bin/pwrsh -c "state -f display \
state -i storage"
The following crontab entry for root calls the executable file /usr/local/bin/check_batts every 15 minutes:
15 * * * * /usr/local/bin/check_batts 2>&1 | mail rootThe check_batts script checks the charge status of the batteries. If the batteries are low, it warns all users and shuts down the system:
:
[ /etc/pwr/bin/pwrsh -c "status -s !ac.online &
( charge.low | charge.critical )" ]
/etc/shutdown -y -i0 -g00:05 -f "No AC power and battery charge is low!
System will shut down in 5 minutes - log off now!"
You should also disable pwrd's handling of low battery
charge. To do this, edit the entry for the
``apm/batteries-are-low''
(classname/event) entry in
/etc/pwr/sys/actions. Change the entry to read:
system/lowbattery-1:apm/batteries-are-low::exit 0then shut down and reboot the system.