The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Поиск:  Каталог документации | unixware

UnixWare Frequently Asked Questions (Autoconfiguration)

Answers to questions frequently asked about SCO's UnixWare product
Archive-name: unix-faq/unixware/autoconfig
Posting-Frequency: monthly
Last-modified: May 12, 1996
Version: 2.02

UnixWare╝ Frequently Asked Questions List (Autoconfiguration)

For more information about the files which compose the total UnixWare
FAQ, see the "FAQ Overview" file posted regularly on the Internet newsgroup
comp.unix.unixware.misc.

INTRODUCTION

The purpose of this document is to give answer frequently asked questions
on the hardware configuration, the new administration tools, and common
tasks using the autoconfiguration feature in UnixWare 2.

Its maintainer is Rob Dinoff (rdinoff@novell.com).  Suggestions and
contributions welcome.

This document and the other FAQ files may be found on the world wide web at
http://www.freebird.org/faq/

This document may also be obtained by anonymous ftp from the freebird
archive at

   * ftp.freebird.org:/unixware/freebird/hints/FAQ/autoconfig
   * ftp1.freebird.org:/pub/mirror/freebird/hints/FAQ/autoconfig
   * ftp2.freebird.org:/pub/unixware/freebird/hints/FAQ/autoconfig

Small print: This file is Copyright 1996 freebird.org. Permission is granted
for copying for non-commercial use. Many proper names of companies and
software mentioned in these files are trademarks of their respective owners.
All views are those of the individual contributors and not of their
employers.

This article is posted monthly around the middle of the month.

----------------------------------------------------------------------------

TABLE OF CONTENTS

Section 1: Overview of Autoconfiguration

A1) What is the Autoconfiguration feature?
A2) What does Autoconfiguration mean to me?
A3) What are the new Administration tools provided as part
    of autoconfiguration?
A4) How do I invoke the DCU ?

Section 2: Administration using the DCU

2.1 ISA Board Specific Administration

A5) How do I Change the IRQ, IOADDRs, MEMADDRs, or DMA?
A6) How do I Add an ISA board?
A7) How do I Delete an ISA board?
A8) How do I Add an internal modem?
A9) How do I Add a dual serial board?
A10) How do I Add a parallel port board?

2.2 General Administration Section

A11) How do I Bind a driver to a specific CPU (MP systems only)?
A12) How do I Change the UNIT parameter?
A13) How do I Disable a board?
A14) How do I Enable a previously disabled board?

2.3 Special Case Administration Section

A15) How do I Determine Board ID's?
A16) How do I Determine resmgr keys?
A17) How do I Change the Boot HBA ?
A18) How do I Move a board?

Section 3. Trouble Shooting.

A19) Trouble Shooting Problems during Installation.
A20) Trouble Shooting Problems on an Installed System.

Section 4. Acknowledgements.

RELATED INFORMATION:

For additional information on the autoconfiguration feature, see
the following related documents:

    o Installation Handbook.
    o System Owner Handbook: Chapter 6.
    o Device Driver Programming Guide: Chapter 3.
    o Device Driver Reference Manual

----------------------------------------------------------------------------

Section 1: Overview of Autoconfiguration

Subject: A1) What is the Autoconfiguration feature?

The autoconfiguration feature in UnixWare 2 incorporates several
new kernel modules, changes to device driver initialization,
and introduces several new administration tools.  From an
administrator's perspective, the primary impact of autoconfiguration
is related to how configuration changes are made, and if and when
kernel rebuilds are needed.

In UnixWare 1.x, the configuration parameters for an expansion
board are input by the user when installing the driver package
and were stored in /etc/conf/sdevice.d/* files.  When the
kernel was built using idbuild(1M), these configuration parameters
were built into the resulting kernel.  If the administrator
needed to change any of these parameters they had to edit these
sdevice files, rebuild the kernel, and reboot the system.

In UnixWare 2, on EISA, MCA and PCI systems, the configuration
parameters are read from Non-Volatile RAM (NVRAM).  Only ISA
cards still require the user to enter this information.  The
/etc/conf/sdevice.d/* (see System(4)) files still accurately
reflect the configuration parameters, but they are no longer
used to configure the drivers.  The configuration parameters
are stored in /stand/resmgr, a binary file used to initialize
a new kernel module, the resource manager.  Drivers then query
the resource manager for their configuration parameters.

For EISA, MCA and PCI systems, hardware configuration changes
are made using the Hardware Configuration Utility that came
with the system and are then picked up automatically by UnixWare.
For ISA cards, administrators change configuration parameters by
changing the values within the resource manager.  The new
administration tools discussed in a following section are used to
make these changes, and then synchronize these changes with
/stand/resmgr and the /etc/conf/sdevice.d/* files.  Rebuilding
the kernel is rarely required.

Subject: A2) What does Autoconfiguration mean to me?

Autoconfiguration means different things to different people, to some
it applies to every aspect of the hardware, main memory, display device,
expansion boards, modems, etc.  In UnixWare 2.0, Autoconfiguration
applies to bus expansion boards and the software that supports them.
Let's clarify what we mean by "bus expansion boards and the software
that supports them".

Bus expansion boards are cards that plug into slots within your
computer.  Examples include networking cards, SCSI host bus adapters
and modem cards.  Expansion boards are designed to provide access to
different kinds of "devices".  We use the term "devices" loosely; in
the case of SCSI host bus adapters, devices are just that, hard disks,
cd-roms, tape drives, etc.  In the case of networking and modem cards,
"devices" refer to "the computer network" and "the telephone network"
respectively.

Hardware boards by themselves are useless without supporting software.
The software modules supporting these boards are generally called
"device drivers".  In order for the device driver to provide access to
the expansion board, both the device driver and hardware must be
"in-sync" with respect to the board's configuration parameters.  When we
talk about "configuration parameters" we mean interrupt vector (IRQ),
memory address range, I/O address range, direct memory access (DMA)
channel, etc.

Two important definitions:

Autodetection: this is the ability to automatically determine information
about the hardware, how much memory's installed, the bus type, disk
capacity, presence of expansion boards, etc.  In the case of expansion
boards, autodetection can range from simply identifying that a specific
brand of ethernet card is installed (i.e XYZ Brand), or better yet,
identifying the specific card installed (i.e. XYZ Ethernet 16), to the
ability to glean some or possibly all configuration parameters relevant
to the board's operation.

Autoconfiguration: this is the ability to automatically configure the
system so the hardware is accessible.  There are two parts to
autoconfiguration, configuring the software and configuring the
hardware.  The simplest case here would be to simply accept the
configuration parameters from the user, check for conflicts and then "do
whatever's required" with the information to produce a running system.
Obviously this functionality falls far short of most people's
expectation regarding autoconfiguration, although in some cases (ISA
boards in an ISA bus) that is the best we are able to provide.  The next
level of functionality would be to configure the software dynamically
based on information gleaned during autodetection without asking the user
for configuration parameters.  The ideal case would be to automatically
change hardware settings and/or software configuration such that no
action whatsoever from the user was required.

For UnixWare 2.O, the Autoconfiguration Feature supports autodetecting
the boards and their configuration parameters (if and when possible) and
using these configuration parameters to autoconfigure the device
drivers.  We do NOT currently support autoconfiguring the hardware
itself.

It would be nice if autoconfiguration in UnixWare 2.0 would address all
aspects of hardware configuration, however it is not a panacea.  It is
important that you understand what autoconfiguration will NOT provide.

Autoconfiguration for UnixWare 2.0 does not provide the following:

    o Automatic resolution of ISA expansion board configuration conflicts.

Most ISA boards are configured via dip switches and jumpers.  If you
do not configure these boards correctly before they are installed, the
only solution will be for you to re-configure the boards to remove any
conflicts.  You will also have to enter the correct configuration
parameters when prompted.  Autoconfiguration does provide functionality
to help identify which boards and configuration parameters are conflicting,
The DCU will allow you to change the software configuration parameters
in the event wrong information was inadvertently input during package
installation.

When you invoke the DCU you will get a warning message about which
boards and configuration parameters are conflicting, you can then go modify
the parameters to the appropriate values.  See section 2.1 for more
on modifying the IRQ, IOADDRs, MEMADDRs, or DMA.

   o Configuring hardware attached to ports (i.e serial, parallel, PS/2)

The DCU configures hardware controllers, not devices attached to them.
The tools to configure these types of hardware devices should already be
available.  For example, to configure the mouse use mouseadmin(1).

   o Replacing one expansion board with another and expecting the system
     to reboot into the same operational state.

A simple example would be to replace your networking board.  Unless you
replace your old board with the exact same board, or another board
supported by the same driver, your networking will not be working when
you reboot.  Any time you exchange boards, you will need to install the
appropriate software to support the new board.  Even if the correct
software was installed, other "network specific" software configuration
is required.  Autoconfiguration does NOT provide the additional software
configuration; the necessary tools are provided in the network package.

   o For those expansion boards that support hardware configuration via
     non-volatile RAM (NVRAM), UnixWare 2 does not assign configuration
     parameters to boards by writing NVRAM.

This functionality is already provided by the hardware vendors with their
Hardware Configuration Utility.

Subject: A3) What are the new Administration tools provided as part
              of autoconfiguration?

    Several new administration tools were introduced in UnixWare 2
    to support the Autoconfiguration feature.

    o /sbin/dcu(1M): the Device Configuration Utility (DCU) is the
      primary interface into the Autoconfiguration system.  The DCU
      provides the ability to map hardware instances to device drivers,
      detect parallel and serial ports, view or edit the current
      configuration, and detect hardware conflicts that would
      subsequently cause idbuild(1M) failures.  It also provides a way
      to modify the configuration, should a board be added, removed or
      configured.  In the case of EISA/MCA/PCI machines, most of the
      configuration can be determined automatically.

      However, the DCU is not intended to be the primary method for
      configuration.  It is assumed that on these machines, the hardware
      will be properly configured via the Hardware Configuration Utility
      that is provided with the machine.  If a board needs to be
      reconfigured, it will be necessary to rerun the Hardware Configuration
      Utility and UnixWare 2, will attempt to automatically incorporate the
      change.  Basically, UnixWare 2, will read information from NVRAM but
      will not write information out to NVRAM.

      In addition, the DCU is not intended as the mechanism for installing
      drivers.  Drivers will continue to be provided as packages that
      can be installed via the standard packaging utilities.

    o /sbin/resmgr(1M): the resmgr command provides a raw interface
      into the resource manager kernel module.  It can be used to
      make unrestricted changes to the in-core database.  If at all
      possible, use the DCU to make configuration changes.  This tool
      should be used cautiously; it provides unrestricted/un-validated
      access to the resource manager's database.

    o /etc/conf/bin/idconfupdate(1M): this command is primarily
      used to synchronize the resource manager's in-core database with
      /stand/resmgr and the /etc/conf/sdevice.d/* files.  The DCU
      command automatically calls this to synchronize up everything unless
      you opt to cancel your changes when you exit.  The resmgr command
      does NOT synchronize anything.  If you make changes to the in-core
      resource manager database, AND you want these changes to be
      permanent, you need to call idconfupdate to synchronize up all the
      files.

      See the manual pages for a complete description of these commands.

Subject: A4) How do I invoke the DCU?

As you use/read this document, many of the instructions start
with "Invoke the DCU."  The DCU can be invoked several ways.
During installation, "Invoking the DCU" is very specific, it
can be invoked once and only once, if you miss your opportunity,
the only alternative is to restart the installation.  During
Installation, after you choose your keyboard type, you'll have
the opportunity to install HBA floppies (if required) once you
are done installing one or more HBA's, you will be given the choice
of either continuing the installation, or "Enter the DCU", with the
default being to continue.  To invoke the DCU, hit the <DOWN ARROW>
key and then hit <RETURN> or <ENTER>.

If you need to invoke DCU on a running system, there are three ways:

   1.  From the Desktop, select Admin_tools, then open
       Hardware_setup.

   2.  From the Desktop, open an terminal window, su(1M) to root,
       and then type dcu.

   3.  Log in at the "Console Login:" prompt as root, and
       type dcu.

       Note: you have to be root to execute the DCU or know the root
       password if using Hardware_setup.

Section 2: Administration using the DCU

This section is broken up into three parts:

    o ISA Board Specific Administration

    o General Administration

    o Special Case Administration

2.1 ISA Board Specific Administration

Subject: A5) How do I Change the IRQ, IOADDRs, MEMADDRs, or DMA?

This only applies to ISA boards. The entries for EISA, MCA
and PCI are read-only, you need to use the Hardware
Configuration utility that came with the system to make changes
on those systems.

   1.  Invoke the DCU.

   2.  Select "Hardware Device Configuration" and hit <ENTER>.

   3.  Move the cursor to the line for the entry you want
       change.

   4.  Mover the cursor to the field you want to change and
       enter the new value.

   5.  Hit F10 to exit form.

   6.  Hit F10 again to return to main menu.

   7.  Select "Apply Changes & Exit DCU"

Subject: A6) How do I Add an ISA board?

   1.  If the driver supporting the board you want to add is
       NOT installed, install it using pkgadd(1M).

   2.  Invoke the DCU.

   3.  Select "Software Device Drivers" and hit <ENTER>.

   4.  Select the category of driver you want or "All" for a
       list of all the drivers available.

   5.  Page Up/Down to the driver that supports the new ISA board.

   6.  Use the <SPACEBAR> to select the driver.

   7.  Hit F5 to create a new instance.

   8.  Enter all the correct configuration information for
       the board.

   9.  Hit F10 to create the new entry.

  10.  Hit <ENTER> to return to the "Software Drivers" menu.

  11.  Select "Return to the DCU Main Menu"

  12.  Select "Apply Changes & Exit DCU"

Subject: A7) How do I Delete an ISA board?

   1.  Invoke the DCU.

   2.  Select "Hardware Device Configuration" and hit <ENTER>

   3.  Move the cursor to the line for the entry you want to delete.

   4.  Mover the cursor to the first field and change the "Y"
       to "N".

   5.  Hit F10 again to return to main menu.

   6.  Select "Apply Changes & Exit DCU"

Subject: A8) How do I Add an internal modem?

To add an internal modem, follow the instructions in the
section "Add an ISA board" and create a new entry for the asyc
driver (Communications Card Driver).

Subject: A9) How to I add a dual serial board?

To add a dual serial board, follow the instructions in the
section "Add an ISA board" and create two new entries for the asyc driver.

Subject: A10) How do I Add a parallel port board?

To add a  parallel port, follow the instructions in the section
"Add an ISA board" and create a new entry for the mfpd driver.

2.2 General Administration Section

Subject: A11)  How do I Bind a driver to a specific CPU (MP systems only)?

   1.  Invoke the DCU.

   2.  Select "Hardware Device Configuration" and hit <ENTER>

   3.  Move the cursor to the line for the entry you want to
       bind to a specific CPU.

   4.  Hit F7 to edit the advanced parameters

   5.  Change the BindCPU value to the CPU you want to bind
       the driver to.

   6.  Hit F10 to exit form.

   7.  Hit F10 again to return to main menu.

   8.  Select "Apply Changes & Exit DCU"

Subject: A12) How do I Change the UNIT parameter?

   1.  Invoke the DCU.

   2.  Select "Hardware Device Configuration" and hit <ENTER>

   3.  Move the cursor to the line for the entry you want to change.

   4.  Hit F7 to edit the advanced parameters.

   5.  Change the  UNIT field to the value you want.

   6.  Hit F10 to exit form.

   7.  Hit F10 again to return to main menu.

   8.  Select "Apply Changes & Exit DCU"

Subject: A13) How do I Disable a board?

   1.  Invoke the DCU.

   2.  Select "Hardware Device Configuration" and hit <ENTER>

   3.  Move the cursor to the line for the entry you want to disable.

   4.  If you plan to re-enable the board later, make note of
       the current Device Name.

   5.  Mover the cursor to the Device Name field and enter "unused".

   6.  Hit F10 to exit form.

   7.  Hit F10 again to return to main menu.

   8.  Select "Apply Changes & Exit DCU"

Subject: A14) How do I Enable a previously disabled board?

   1.  Invoke the DCU.

   2.  Select "Hardware Device Configuration" and hit <ENTER>.

   3.  Move the cursor to the line for the entry you want re-enable.

   4.  Mover the cursor to the Device Name and enter the name
       of the driver.  If needed, hit F2 for choices.

   5.  Hit F10 to exit form.

   6.  Hit F10 again to return to main menu.

   7.  Select "Apply Changes & Exit DCU".

2.3 Special Case Administration Section

This section covers scenarios that should rarely be
encountered.  From a hardware perspective, independent of
UnixWare, changing boot HBA's is NOT guaranteed to work, but
if you are willing to try, this might/should work.

Just to be safe, you should save a copy of the current kernel
and resmgr file before you start.

    cp /stand/unix /stand/unix.good
    cp /stand/resmgr /stand/resmgr.good

If the following instructions do not work, you need to go back to the
old board, or reinstall from scratch with the new board.   If
you want to go back to the old board, restore your original
board using the same configuration parameters, then from the
interactive boot(1M) set RESMGR=resmgr.good and KERNEL=unix.good.

If these instructions do work, it is important that you
recreate your Emergency Recovery Diskette (emergency_disk(1M) or from
the desktop) with the new configuration.

Subject: A15) How do I Determine Board ID's?

Some of the instructions in the following sections require
changing the BRDID parameter in the resource manager database.
The new board id you will need is different depending on the
bus type.

       EISA: the board id is a 7 character string (e.g. "CPQ6100").

       MCA: the board id is EXACTLY a 4-digit hex number of the form
            "0x1234".  Use 0's to  pad to four digits if needed,
            "0x0123" is correct, "0x123" is wrong.

       PCI: the board id is an 8-digit hex number of the form
            "0x12345678".  Do NOT pad a PCI board id with 0's.

       ISA: these cards have no board id.

It is not always easy to determine the board id for a given
board.  In the case of EISA boards, the documentation that came
with the board may or may not clearly indicate the board id.
For MCA and PCI, the board id is something we have defined for
UnixWare and it will not be clearly documented in the materials
that came with the board.  A good place to start is
the Drvmap(4) file for the driver that supports the new board.
The Drvmap files are located in /etc/conf/drvmap.d/*.  If the
new board is not listed in the Drvmap file, shutdown the
system, insert the new board, but DO NOT remove the current
board and DO NOT attach the boot device to the new board.   On
an EISA or MCA system you will need to run the Hardware
Configuration Utility.  Then reboot, login, and run /sbin/resmgr
from  the shell.  The new board should be the last line and it
should include the board id you need to complete the steps
below.

Subject: A16) How do I Determine resmgr keys?

Some of the steps below require knowing the resource manager key
for a specific entry.  To determine the key you need, run the the
resmgr(1M) command.  The key is the first column of the output.

2 fd 1 4 2 6 3f0 3f7 - - 2 - - - - 1
KEY=2

Subject: A17) How do I Change the Boot HBA?

If you are replacing an ISA HBA with an ISA HBA:

   1.  Make sure the new board is using the exact same
       configuration parameters as the current board, or use the DCU
       to update the resmgr entry for the current board to reflect
       the settings of the new board.  If you use the DCU to update
       the existing resmgr entry, you MUST do it before you shutdown
       and swap boards.

   2.  If the new HBA requires a different driver, make sure
       the new driver is installed, or install it using pkgadd(1M).
       Then:

       o If you had to use pkgadd to install the new driver, a new default
         entry may have been added to the resource manager.  This entry
         must be removed before you continue.  Run resmgr to check if a
         default entry was added (it will be the last line of output).  If
         so, delete this entry using "resmgr -r -k new_key".

       o Execute "resmgr -k key -p MODNAME -v modname"
         where key is the key corresponding to the current ISA entry
         and modname is the driver that supports the new board.

       o Run /etc/conf/bin/idconfupdate to synchronize up this
         change with /stand/resmgr and the sdevice file.

       o Add $static to /etc/conf/sdevice.d/modname and
         change the second field from "N" to "Y" if needed.

       o Execute /etc/conf/bin/idbuild -B to rebuild the kernel.

   3.  Shutdown your system.

   4.  Swap the boards.

   5.  Reboot the system.

If you are replacing a non-ISA (EISA or PCI) with an ISA HBA:

   1.  Update the parameters of the current resmgr entry for the
       non-ISA board to match the new ISA board:

       resmgr -k key -p IRQ -v irq

       resmgr -k key -p IOADDR -v "sioaddr eioaddr"
       resmgr -k key -p MEMADDR -v "smemaddr ememaddr"
       resmgr -k key -p DMA -v dma

       Where:  key is the key for the current non-ISA board,
               irq is the irq for the ISA board,
               sioaadr and eioaddr are the start i/o address and
               end i/o address for the ISA board,
               smemaddr and ememaddr are the start memory address and
               end memory address for the ISA board,
               dma is the DMA channel for the ISA board.

   2.  Execute "resmgr -k key -p BRDBUSTYPE -v 1" to change
       the bus type, where key is the key corresponding to the
       current non-ISA entry.

   3.  Use the resmgr command to delete some non-ISA specific
       params:

       resmgr -k key -p BRDID -v "" resmgr -k key -p SLOT -v ""
       resmgr -k key -p CA_DEVCONFIG,n -v ""

   4.  If the new board is supported by the same driver,
       execute:  resmgr -k key -p ITYPE -v 1.

   5.  Run /etc/conf/bin/idconfupdate to synchronize up these
       changes with /stand/resmgr and the sdevice files.

   6.  If  the new  HBA requires a different driver, make sure
       the new driver is installed, or install it using pkgadd(1M).
       Then:

       o If you had to use pkgadd to install the new driver, a new
         default entry may have been added to the resource manager.
         This entry must be removed before you continue.  Run resmgr(1M)
         to check if a default entry was added (it will be the last line
         of output).  If so, delete this entry using
         resmgr -r -k new_key

       o Execute "resmgr -k key -p MODNAME -v modname"
         where key is the key corresponding to the current non-ISA
         entry and modname is the driver that supports the new board.

       o Add $static to /etc/conf/sdevice.d/modname and
         change the second field from "N" to "Y" if needed.

       o Execute "resmgr -k key -p ITYPE -v itype" where
         itype is the fifth field of the last line in the sdevice file.

       o Execute /etc/conf/bin/idbuild -B to rebuild your kernel.

   7.  Shutdown the system.

   8.  Remove the non-ISA board.

   9.  Run the Hardware Configuration Utility if needed.

  10.  Insert the new ISA board and attach SCSI devices.

  11.  Reboot your system.

If you are replacing an ISA HBA with an non-ISA HBA (EISA or PCI):

   1.  Shutdown your system.

   2.  Install the non-ISA board, but do NOT remove the current board
       and do NOT move your boot disk.

       Note: if the ISA boot controller is controlling the floppy,
       you need to disable the floppy controller on the non-ISA board.
       This may require changing a jumper or dip switch,
       or it may require the Hardware Configuration Utility.

   3.  Run the Hardware Configuration Utility if needed, to
       configure your new board.

       Note: the ROM BIOS address of the new boot controller must be
       set to a value that does not conflict with any HBAs in the
       system, AND must be less than any secondary HBA controllers that
       exist in the machine.  Otherwise, when the original boot
       controller is removed, the BIOS will try to boot from the
       secondary controller, instead of the new boot controller.

   4.  Reboot the system.

   5.  Login and execute the following:

       resmgr -k key -p BOOTHBA -v 1 resmgr -k key -p UNIT -v 0
       resmgr -r -k different_key

       Where key is the key corresponding to the new non-ISA entry and
       different_key is the key corresponding to the current ISA entry.

   6.  Run /etc/conf/bin/idconfupdate to synchronize up these
       changes with /stand/resmgr and the sdevice files.

   7.  If the new HBA requires a different driver, make sure the
       new driver is installed, or install it using pkgadd(1M).  Then:

       o If you had to use pkgadd to install the new driver, a new default
         entry may have been added to the resource manager.  This entry
         must be removed before you continue.  Run resmgr to check if a
         default entry was added (it will be the last line of output).
         If so, delete this entry using "resmgr -r -k new key".

       o Execute "resmgr -k key -p MODNAME -v modname"
         where key is the key corresponding to the new non-ISA entry
         and modname is the driver that supports the new board.

       o Add $static to /etc/conf/sdevice.d/modname and change the
         second field from "N" to "Y" if needed.

       o Execute /etc/conf/bin/idbuild -B to rebuild your kernel.

   8.  Shutdown your system again.

   9.  Remove the old ISA HBA.

  10.  Insert the SCSI cable into the new board.

       If you disabled the floppy controller on the new board in
       step 2 above, you need to re-enable it now.

  11.  Reboot the system.

For the following cases, use these instructions:

     EISA <=> EISA
     EISA <=> PCI
     PCI <=> PCI
     PCI <=> MCA
     MCA <=> MCA

   1.  Execute "resmgr -k key -p BRDID -v brdid" where key is
       the key of the current HBA, and brdid is the board id for the
       new board.

   2.  If the new  board is a different bus type, execute
       "resmgr -k  key -p BRDBUSTYPE -v bustype" where bustype is  a
       numeric value representing the bus type of the new board.

       EISA   2
       PCI    4
       MCA    32

   3.  Run /etc/conf/bin/idconfupdate to synchronize up this
       change with /stand/resmgr and the sdevice files.

   4.  If the new HBA requires a different driver, make sure the
       new driver is installed, or install it using pkgadd.  Then:

       o If you had to use pkgadd to install the new driver,
         a new default entry may have been added to the resource manager.
         This entry must be removed before you continue.  Run resmgr to
         check if a default entry was added (it will be the last line of
         output).  If so, delete this entry using resmgr -r -k new key.

       o Execute "resmgr -k key -p MODNAME -v modname"
         where key is the key corresponding to the current ISA entry
         and modname is the driver that supports the new board.

       o Run /etc/conf/bin/idconfupdate to sync up this
         change with /stand/resmgr and the sdevice file.

       o Add $static to /etc/conf/sdevice.d/modname and
         change the second field from "N" to "Y" if needed.

       o Execute /etc/conf/bin/idbuild -B to rebuild your kernel.

   5.  Shutdown the system.

   6.  Swap the boards (use same slot to be safe).

   7.  Reboot the system.

Subject: A18) How do I Move a board?

   1.  Shutdown the system.

   2.  Move the board.

   3.  Reboot.

Section 3. Trouble Shooting.

Subject: A19) Trouble Shooting Problems during Installation

There are many different types of problems you could encounter
during  installation.  Most of these problems are covered in the
Trouble Shooting section of the Installation Handbook and you
are directed there for solutions to those problems.

One problem not covered in the Installation Handbook involves
problems loading HBA drivers.  On some platforms, attempting to
load a driver for a board that is not installed on your system
can mess-up your system and cause the installation  to fail.
If this happens, you have to disable loading of that particular
driver during installation.

   1.  Invoke the DCU.

   2.  Select "Software Device Drivers".

   3.  Select "Host Bus Adapters".

   4.  Page Up/Down until you find the driver that is causing
       you problems.  If you are not sure which driver is causing the
       trouble, try switching vt's with <alt><sysreq> H and look for
       the driver name in the error messages.  To switch back to the
       desktop <alt><sysreq> <F1>

   5.  De-select the driver using the <SPACEBAR>

   6.  Hit <ENTER> to exit menu.

   7.  Select "Return to DCU Main Menu".

   8.  Select "Apply Changes & Exit DCU".

Subject: A20) Trouble Shooting Problems on an Installed System

Problems are more likely to be encountered when boards are
added, rather than when they are removed.  The exception to
this is the removal of an ISA board.  If you remove an ISA
board, you must use the DCU to free-up the configuration
parameters for the board.  (See the section "Delete an ISA
Board" earlier in this document.)

The first step to trouble shooting is to understand the true
nature of the problem.  Here are some questions to ask:

   1.  What type of board are you having trouble with ?

       ISA cards must be added using the DCU and the configuration
       parameters you specify must match the settings on the board.

       EISA, MCA and PCI boards should automatically be detected by
       UnixWare.  To verify this, run the DCU, select "Hardware Device
       Configuration", and verify the new board was found.

       If a new entry is not there, run the hardware configuration
       floppy that came with the system to verify it can find the new
       board.  If it detects the board, save the configuration
       information, and reboot the system.  If it fails to find the
       board also, try pulling the board, and reinserting it and
       rerunning the Hardware Configuration Utility again.

   2.  Was the driver correctly assigned to the board?

       1.  Invoke the DCU.

       2.  Select "Hardware Device Configuration".

       3.  Check the "Device Name" field for the new entry.  If the
           entry  is UNKNOWN, then no driver was assigned to the board.

       4.  If the entry is UNKNOWN or incorrect, move the cursor to
           the Device Name field and hit F2 for a list of drivers to
           choose from.

       5.  Select the driver for the new board and hit <RETURN>.

       6.  Hit F10 to return to the main menu.

       7.  Select "Apply Changes & Exit DCU"

       8.  Reboot your system.

       One reason a driver might not be correctly  assigned to a board
       is if the driver's drvmap(4) file does not contain the board id of
       the new board.  See section 2.3.1 for more on board ids.

   3.  Is the driver that supports the board installed?

       Run pkginfo(1) to list the packages that are installed on the
       system and verify the required driver is installed.

----------------------------------------------------------------------------

Section 4. Acknowledgements.

I would like to thank Les Temple for writing this FAQ.  Also
Andrew Josey, Dave Ballman, Dean Flamberg and Evan Leibovitch for
providing comments and suggestions.

--
Andrew Josey, To email remove #nospam from From: line.
Disclaimer: Any views expressed are not those of my employer, either past, 
present or future.



Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру