hwmgr_ops(8)hwmgr_ops(8)NAMEhwmgr_ops - Hardware management commands for performing operations on
components
SYNOPSIS
/sbin/hwmgr command [subsystem] [parameters]
SUMMARY OF HWMGR OPERATIONAL COMMANDS
Operational commands are characterized by a subsystem identifier after
the command name. The current subsystems are: component, scsi and
name.
Some of the hwmgr operational commands are available for more than one
subsystem. Use the subsystem most closely associated with the type of
operation you want to perform, depending on the parameter information
that you obtained using the view or show command options.
Some commands require you to specify a subsystem name. However, if you
specify the identity of a hardware component, then you do not need to
specify a subsystem name. The hwmgr command is able to determine the
correct subsystem on which to operate, based on the component identi‐
fier.
The command options are organized by task application, defined in the
COMMAND OPTIONS section. The command options, the subsystems on which
they operate, and the nature of the operation are listed in the follow‐
ing table:
────────────────────────────────────────────────────────────────────
Option Subsystem Purpose
────────────────────────────────────────────────────────────────────
add name Database management
delete component, name, scsi Database management
edit name, scsi Database management
locate component Hardware configuration
offline component, name OLAR
online component, name OLAR
power component, name OLAR
redirect scsi Hardware configuration
refresh component, scsi Database management
reload name Driver configuration
remove name Database management
scan component, name, scsi Hardware configuration
status component Hardware configuration
unconfigure component, name Hardware configuration
unindict component OLAR
unload name Driver configuration
────────────────────────────────────────────────────────────────────
COMMAND OPTIONS
The following sections describe the options and parameters for each
command set. The commands are organized according to typical usage,
with the more frequently used operations first: Hardware Configuration
- Commands that you use to manipulate your hardware configuration. You
use these operations after you have modified your hardware configura‐
tion and you want the modifications to be implemented. Online Addition
and Replacement (OLAR) - Commands that you perform to maintain maximum
system uptime and performance, such as adding additional CPUs. See the
Managing Online Addition and Removal manual and olar_intro(5) for more
information. Database Management - Commands that you use to modify the
hardware databases. The operating system uses these databases to store
information about the hardware components. Driver Configuration - Com‐
mands that you use to configure the drivers that control hardware com‐
ponents.
Hardware Configuration
Use these commands to examine or manipulate your hardware configura‐
tion. For example, use these commands when replacing a failed SCSI
disk or adding a tape drive. Associated procedures for these operations
are provided in the Hardware Management manual.
─────────────────────────────────────────────────────────
Command Option Supported Subsystem
─────────────────────────────────────────────────────────
locate component
redirect scsi
scan component, name, scsi
status component
unconfigure component, name
─────────────────────────────────────────────────────────
Finds a hardware component. The locate operation is designed to help
you find the physical location of a component in the system. How this
is actually implemented depends on the hardware that you want to find.
If the locate operation is directed to a SCSI disk component, the disk
attempts to flash its activity light (if available). You can specify
the following additional options with the locate option: Specifies the
hardware identifier (HWID), which is an integer such as 34. Specifies
a duration of N seconds for the light to flash. The default is 30 sec‐
onds and a value of zero causes no signal.
If there is much I/O activity on the disks, it might be diffi‐
cult to see which disk light is flashing. You might want to tem‐
porarily suspend I/O to the disks before using the locate
option. Assigns the device special file names, cluster dev_t
values, local dev_t values, SCSI device ID (did), and hardware
ID (HWID) of one hardware component to another. Use this com‐
mand to transfer the system identity from one component to
another, equivalent component. You might use this option when a
disk fails and you want to replace it with a new disk.
You must specify a SCSI device ID (did) for each of the follow‐
ing options. You can obtain these identifiers by using the
hwmgr show scsi command: The source component. The system iden‐
tity of this component will be transferred to the target device.
The target component. This device receives its new identity from
the source device. Scans the system for new hardware components
and, if a new component is found, configures it. If you do not
specify any arguments, the operation scans all hardware on the
system. The scan component option is asynchronous. When you
issue the command it completes immediately, although the scan
can still be active in the kernel.
To test for completion of a scan, use the Event Manager (EVM)
evmwatch and evmshow commands to monitor for an event with the
following event name: sys.unix.hw.scan_completed. For example:
# evmwatch -f '[name sys.unix.hw.scan_completed]' | evmshow A
hardware scan has just completed.
Alternatively, use the graphical EVM Viewer interface to monitor
completion of the scan. (See EVM(5) for an introduction to
EVM.)
You can specify the following additional options with the scan
option: Specifies the hardware component identifier (HWID) for
the device on which on which to perform the scan operation.
Specifies the hardware category, such as disk or tape, on which
to perform the scan operation. See the -get category command
option, which displays a list of category names. Performs a
recursive scan downward in the system topology. If this option
is not specified, the scan operation will not scan recursively
to hardware components below the starting component, unless
recursion occurs as part of the normal scanning process for the
component. A bus, for example, is scanned recursively (because
that is how the scan code for a bus is written). A scan of a
platform is not normally recursive. Specifies the host name of
a specific cluster member on which you want to start the opera‐
tion. Specifies that the scan operation is performed on every
cluster member. Scans the specified component for new hardware.
The scan name option is asynchronous. When you issue the com‐
mand it completes immediately, although the scan can still be
active in the kernel. To test for completion of a scan, use the
Event Manager (EVM) evmwatch and evmshow commands to monitor for
an event with the following event name: sys.unix.hw.scan_com‐
pleted. For example:
# evmwatch -f '[name sys.unix.hw.scan_completed]' | evmshow A
hardware scan has just completed.
Alternatively, use the graphical EVM Viewer interface to monitor
completion of the scan. (See EVM(5) for an introduction to
EVM.) Specifies the name of the hardware to scan. This is a
required parameter. Specifies the host name of a specific clus‐
ter member on which you want to perform the operation. Speci‐
fies that the scan operation is performed on every cluster mem‐
ber. Scans SCSI hardware for new devices. When you add new
SCSI hardware (such as disks) to the system, use the scan scsi
option to find the new hardware. If you do not specify any argu‐
ments, the command scans all SCSI buses on the system.
The scan scsi option is asynchronous but, unlike the scan compo‐
nent and scan name options, you cannot test for completion of
the scan by watching for the “A hardware scan has just com‐
pleted” EVM event. When a scan detects changes to the SCSI con‐
figuration (such as when a newly added device is found) hardware
change and registration EVM events are posted. Use the graphical
EVM Viewer interface to monitor these events when it is neces‐
sary to know that a scan is complete. (See EVM(5) for an intro‐
duction to EVM.)
Note
When you reconfigure RAID arrays the new block zero might happen
to be the same block as the previous block zero. This can lead
to problems caused by applications that see the disklabel as
valid even though it might extend beyond the end of the disk.
After a scan, the system recognizes the new unit(s) as dskNN.
Before using the disk, run the following command to zero any
inappropriate label:
# disklabel -z dskNN
This is recommended if you construct a new unit on a RAID array
or if you move one or more disks comprising a unit on a raid
array to connect them directly to a host bus adapter.
Next, run the disklabel command to create a new default label
(or apply a preconfigured label from a proto file): as follows:
# disklabel -rwn dskNN # disklabel -Rr dskNN PROTOFILE
You can specify the following additional options with the scan
scsi command. Use the hwmgr show scsi command to find appropri‐
ate values for the options. Specifies the SCSI bus on which you
want to perform the scan operation. The value is an integer,
such as 0 (zero). This integer is part of the component name for
the SCSI bus, such as scsi0. Use the hwmgr view hierarchy com‐
mand to determine a bus number. Specifies the SCSI target on
which you want to perform the scan operation. The value is an
integer, such as 5. This integer is part of the path to the com‐
ponent, such as 0/5/0 (bus/target/lun). Use the hwmgr show scsi
command to determine the target number. Specifies the SCSI log‐
ical unit number on which you want to perform the scan opera‐
tion. The value is an integer, such as 0 (zero). This integer is
part of the path to the component, such as 0/5/0 (bus/tar‐
get/lun). Use the hwmgr show scsi command option to determine
the lun value. Specifies the host name of a specific cluster
member on which you want to perform the operation. Displays the
status of all components or a specified component. See Managing
Online Addition and Removal (OLAR) manual, olar_config(4), and
olar_intro(5) for more information on the use of status informa‐
tion during OLAR procedures.
The following options are available: Shows the status of the
component specified by the hardware component identifier. Spec‐
ifies the host name of a specific cluster member on which you
want to perform the operation. Specifies that you want to
select components for display according to their status as fol‐
lows: -good - Displays only those components that have a status
of good. In the output from the status command option, the sta‐
tus displayed is null (no content) when a component is good.
-ngood - Displays only those components that have a status other
than good. Specifies that you want to display components
according to their warning status as follows: -warning - Dis‐
plays only those components that have a status of warning.
-nwarning - Displays only those components that have a status
other than warning. Specifies that you want to display compo‐
nents according to their critical status as follows: -critical -
Displays only those components that have a status of critical.
-ncritical - Displays only those components that have a status
other than critical. Specifies that you want to display compo‐
nents according to their inactive status as follows: -active -
Displays only those components that have a status of active.
-ninactive - Displays only those components that have a status
other than active. This status currently applies only to CPUs
managed using Capacity on Demand (COD).
The output from the status command option provides you with the
following information: The hardware identifier (HWID) of the
component. Use the hardware identifier with other hwmgr command
options (such as show component -id). You might need this
information to identify a particular component. The name of the
host from which the status information was retrieved. Specifies
four possible conditions that describe the status of the compo‐
nent: Null - If there is no entry in the field, the component
is good. Inactive - The component is inactive and cannot be
used by the operating system. Warning - Warns you that a compo‐
nent is not in an optimal state but might return automatically
to an optimal state.
For example, when you take a CPU off line by using the offline
nosave command option, its status changes to a warning state. It
is only a warning status because this CPU is otherwise func‐
tional, and will automatically become online and available after
you reboot the system. Critical - Warns you that a component is
not in an optimal state and cannot return automatically to an
optimal state. You must intervene to bring the component back to
an optimal state (online and available).
The status categories do not necessarily imply that a hardware
component has failed. They only indicate the present state of a
component, which might depend on other hwmgr command options
that you used. Specifies whether a component is online or off‐
line. Refer to the offline component command option described
in hwmgr_ops(8) for a description of these states. Specifies
the following possible states of the component: Unknown - The
system is unable to determine the state of the component. Use
other hwmgr command options and diagnostic tools to determine
its state. Available - The component is fully functional and
ready for use although it might not be currently online.
Unavailable - The component is unavailable. Broken - The compo‐
nent has failed. Limited - The component has limited availabil‐
ity. Testing - The component is under test. Off - The compo‐
nent is powered off. Specifies the indictment status of the
component, meaning that an error analysis tool has marked the
component as suspect and potentially failing. The component
might need replacement.
The value of the INDICT LEVEL field can be as follows: (Null) -
The component is not indicted. Low - There is a low probabil‐
ity that this component is at fault. Medium - There is a
medium probability that this component is at fault. High -
There is a high probability that this component is at fault.
The component name. Unconfigures a hardware component. Uncon‐
figuring a hardware component removes the registration of a com‐
ponent with the running kernel. It does not remove the copmpo‐
nent's persistence information from the databases.
The following options are available: Specifies the name of the
hardware persistence entry to delete when you want to perform
the operation on the name subsystem.
The -entry option and the -id option are mutually exclusive.
Unconfigures database entries that have the specified hardware
component identifier. Use this option when you want to perform
the operation on the component subsystem.
The -id option and the -entry option are mutually exclusive.
Performs a recursive operation downward in the system topology.
If this flag is not specified, the operation does not recurse to
hardware components below the starting component.
You can use this option only when you specify the -id option.
Performs the operation on the specified cluster member.
Online Addition and Replacement (OLAR)
The following commands enable you to add or replace components without
shutting down the system. The commands enable you to maximize system
uptime and improve performance. For example, you can add a CPU or
replacing a failed CPU while the system us up. Procedures for the hot-
swap operations associated with these commands are included in the Man‐
aging Online Addition and Removal manual, olar_config(4), and
olar_intro(5).
─────────────────────────────────────
Command Option Supported Subsystem
─────────────────────────────────────
offline component, name
online component, name
power component, name
unindict component
─────────────────────────────────────
Specifies that you want to take the specified component offline. You
can specify either a component name, or its hardware identifier (HWID).
Identifies the hardware identifier (HWID) of the target component.
Specify an integer, such as 52. You can obtain the HWID of a device by
using the view hierarchy command option.
The -id option and the -name option are mutually exclusive.
If the component is a CPU and there are processes bound to the
CPU, a warning message is displayed similar to the following:
hwmgr: Active processes are bound to CPU1. Use -verbose for
further
information.
Repeat the command, using the -verbose option to obtain details
of the bound processes. See RESTRICTIONS for more information.
Identifies the name of the target component. Specify a name,
such as CPU2. You can obtain the component name by using the
view hierarchy command option, as described in hwmgr_view(8).
The -name option and the -id option are mutually exclusive.
Specifies that you do not want the offline status to persist
across a reboot. When the system reboots, the device is back
online. Specifies that you want to force the component into the
offline state. You might need to use this option if processes
are bound to the CPU by commands such as runon. Specifies that
you want to discover and display any impact caused by your off
ine request. You can then manipulate the component with other
commands before you take it offline. Specifies that you want to
bring a component online. The options are as follows: Identifies
the hardware identifier (HWID) of the target component. Specify
an integer, such as 52. You can obtain the HWID of a device by
using the view hierarchy command option.
The -id option and the -name option are mutually exclusive.
If the component is a CPU and there are processes bound to the
CPU, a warning message is displayed similar to the following:
hwmgr: Active processes are bound to CPU1. Use -verbose for
further
information.
Repeat the command, using the -verbose option to obtain details
of the bound processes. See RESTRICTIONS for more information.
Identifies the name of the target component. Specify a name,
such as CPU2. You can obtain the component name by using the
view hierarchy command option, as described in hwmgr_view(8).
The -name option and the -id option are mutually exclusive.
Applies power to or removes power from a component. This option
works for both the name and the component subsystems and the
alternative syntaxes are as follows: hwmgr power [on|off] [com‐
ponent] -id hardware-component-id hwmgr power [on|off] [name]
-name hardware-name
The command options are as follows: Changes the power state of
the component. Identifies the hardware identifier (HWID) of the
target component. Specify an integer, such as 52. You can
obtain the HWID of a device by using the view hierarchy command
option.
The -id option and the -name option are mutually exclusive.
If the component is a CPU and there are processes bound to the
CPU, a warning message is displayed similar to the following:
hwmgr: Active processes are bound to CPU1. Use -verbose for
further
information.
Repeat the command, using the -verbose option to obtain details
of the bound processes. See RESTRICTIONS for more information.
Identifies the name of the target component. Specify a name,
such as CPU2. You can obtain the component name by using the
view hierarchy command option, as described in hwmgr_view(8).
The -name option and the -id option are mutually exclusive.
Clears a component indictment.
You can verify the indictment status of a component using the
status component command option.
Although indictment is automatic and determined by using the
Compaq Analyze error analysis tool, you can optionally examine
the indictment status and choose to unindict a component. Typi‐
cally, an indictment is removed only after a problem is thor‐
oughly analyzed and corrective action (such as replacing a com‐
ponent) is taken. Refer to the Managing Online Addition and
Removal manual, olar_config(4), and olar_intro(5) for more
information.
Identifies the hardware identifier (HWID) of the target compo‐
nent. Specify an integer, such as 52. You can obtain the HWID
of a device by using the view hierarchy command option.
The -id option and the -name option are mutually exclusive.
If the component is a CPU and there are processes bound to the
CPU, a warning message is displayed similar to the following:
hwmgr: Active processes are bound to CPU1. Use -verbose for
further
information.
Repeat the command, using the -verbose option to obtain details
of the bound processes. See RESTRICTIONS for more information.
Identifies the host name of the cluster member to which the
indicted component is connected.
Database Management
Use these commands to modify the hardware databases that the operating
system uses to store component information. Supported buses and con‐
trollers are recognized on system startup and are automatically config‐
ured into the system. If you want to add an unrecognized component,
such as a prototype in development, you might need to use the add name
option to add the device to the name subsystem.
─────────────────────────────────────────────────────
Command Option Supported Subsystem
─────────────────────────────────────────────────────
add name
delete component, name, scsi
edit name, scsi
refresh component, scsi
remove name
─────────────────────────────────────────────────────
Adds a bus, controller or device entry to the name database. The fol‐
lowing options are available: Specifies the base persistence name the
persistence entry. For example, scsi is the base persistence name for
a SCSI adapter. Specifies the persistence number to be associated with
this hardware component. For example, the first SCSI bus is 0, making
the persistence entry for the bus scsi0. Specifies the type for a
hardware persistence entry. Specifies the persistence name of the par‐
ent bus or controller, at which location the new entry will persist.
For example, a SCSI bus might persist under parent bus tza. Specifies
the instance number of the parent bus or controller of the hardware
component. For example, the instance number for a SCSI bus persisting
on a parent tza bus might be instance 0, for tza0. Specifies the slot
number occupied by this hardware component. For example, a SCSI bus
might persist at slot 2 of the tza0 bus (tza0 slot 2).
To add other (generic) types of entries to the name subsystem,
the following additional options are available: Specifies the
type for a hardware persistence entry. Specifies a key used to
identify the persistence entry. Specifies the host name of a
specific cluster member on which you want to perform the opera‐
tion. Enables you to modify the name database by changing the
hardware persistence of a bus, controller, or device. You must
specify a hardware name using the -entry option.
The following options are available: Specifies the name of the
hardware persistence entry to edit. Specifies a changed parent
name for this persistence entry. Specifies a changed parent
instance number for this persistence entry. Specifies a changed
slot number for this persistence entry. Specifies the host name
of a specific cluster member on which you want to perform the
operation.
To edit a generic persistence entry, use the following command
syntax: hwmgr edit name -entry hardware-name -key string-value
[-member cluster-member-name]
The following options are available for generic entries: Speci‐
fies the generic name for the hardware persistence entry to
edit. This option is mandatory. Specifies a new value for the
key for this persistence entry. Specifies the host name of a
specific cluster member on which you want to perform the opera‐
tion. Use this option to delete the specified component from
all members of the cluster and delete all device special files
that are associated with the specified component.
When performing a delete operation you must specify an identi‐
fier for the component that you want to delete. You can obtain
the identifier for a specific component by using the various
show or view command options. Valid identifiers are as follows:
A hardware identifier (HWID) A SCSI Device ID (did) A component
name
When you delete a hardware component, the request is always a
cluster-wide operation. The system can no longer access the
deleted component during the current boot session. However, if
deleted components remain connected to the system during a
reboot, they are automatically renamed and reconfigured in the
order they are discovered. Discovery occurs during the boot
sequence, when the system probes the hardware.
The delete command options are as follows: Specifies the SCSI
device identifier. Specifies the name of the hardware. Speci‐
fies the hardware identifier (HWID). Specifies the host name of
a specific cluster member on which you want to initiate the
operation.
The -member option is not supported if you specify the -did
option. Enables you to assign a unique name to a SCSI device
that does not have a cluster-unique name. You must specify a
SCSI Device ID (did).
If a SCSI device does not provide a unique name, it is seen as a
different device for each path from which it is accessed and you
cannot add it to a shared SCSI bus. Use the edit scsi command at
every location from which the device is seen, assigning the same
name each time. The SCSI subsystem assigns this name to the SCSI
device, enabling the device to be seen as the same device from
all access paths used. The device will also receive a new device
special file.
The following options are available: Specifies the SCSI device
identifier. You can obtain this identifier by using the hwmgr
show scsi command. This option is mandatory Specifies a unique
user-defined identifier for the device. Specifies the host name
of a specific cluster member on which you want to perform the
operation. Deletes all hardware components that are not cur‐
rently registered. Use this command only if the system or clus‐
ter is set up in an optimal configuration and you want to remove
obsolete hardware entries from all databases. This command
removes all components that are not registered with hardware
management at the time that you perform the operation.
For example, if you make many hardware configuration changes,
particularly by removing and replacing hardware there will be
many unused entries in the hardware databases. Such unused
entries aere not shown if you examine your configuration by
using the view devices and view hierarchy, options. Only the
show component command displays the unused database entries as
follows:
8: cymro ----- none Unconfigured-device-(<NULL>)-at-
pci1slot7
Use the refresh component command to remove entries for compo‐
nents that will never be returned to the system.
The following option is available: Specifies the host name of a
specific cluster member on which you want to start the opera‐
tion. Deletes stale paths to SCSI devices, except for any stale
path that is the first path to a SCSI device. The number of
stale paths can increase the boot time for large configurations
because the SCSI subsystem attempts to probe each path.
Other than because of infrequent component failures, such stale
paths can occur if you move storage to different adapters or if
you remove or replace adapters. However, if you have inexplica‐
bly large numbers of stale paths on your system, it might indi‐
cate a configuration problem and you should consult your techni‐
cal support representative before using the refresh option.
The following options are available: Specifies that you want to
perform the operation on all SCSI devices. Specifies a particu‐
lar SCSI bus on which to perform the operation. Specifies a
particular device, using the device identifier, on which the
operation is to be performed. Specifies the host name of a spe‐
cific cluster member on which you want to perform the operation.
Removes a hardware persistence entry from the database but does
not affect any hardware component currently using the name. This
option affects only the persistence of the name across reboots.
The following options are available: Specifies the name of the
hardware persistence to be removed. Specify ALL to remove all
entries. Specifies the host name of a specific cluster member
on which you want to perform the operation.
Driver Configuration
You use these commands to configure drivers used by hardware compo‐
nents.
─────────────────────────────────────
Command Option Supported Subsystem
─────────────────────────────────────
reload name
unload name
─────────────────────────────────────
Performs a driver unload followed by a load. (See the unload option.)
The following options are available: Specifies the driver to
reload. Specifies that the kernel configuration routine is not
called when the driver is reloaded. Specifies the host name of
a specific cluster member on which you want to perform the oper‐
ation.
Unloads a module (usually a driver) from memory. The following
options are available: Specifies the name of the driver that is
to be unloaded from memory. For example, tu, the driver name
for the tulip network interface card. Specifies the host name
of a specific cluster member on which you want to perform the
operation.
DESCRIPTION
The commands described in this reference page are a subset of the com‐
mand options available from the hwmgr utility. Refer to hwmgr(8) for
more information.
Use the hwmgr operational commands to perform operations on hardware
components. You use the information obtained from other hwmgr commands
to obtain the appropriate operational command parameters, such as
device identifiers. Refer to the following reference pages for informa‐
tion on related commands: hwmgr_show(8) - Commands that enable you to
display information from the hardware device databases. hwmgr_view(8)
- Commands that enable you to display information about the status of
the system and its hardware devices, such as whether a particular disk
has a valid I/O path. hwmgr_get(8) - Commands that enable you to
obtain (get) or configure (set) device and component attributes.
See the Hardware Management manual for more information about compo‐
nents, device special files, and a definitive list of the supported
device names. This manual provides further examples of hwmgr command
usage and common procedures.
You can run some hwmgr commands directly from the SysMan Menu. You can
also monitor many properties and attributes of components by using the
SysMan Station GUI. See the System Administration manual for informa‐
tion about these interfaces.
RESTRICTIONS
The following notes and restrictions apply:
Currently the locate component -id command is implemented only for some
SCSI disks, using the disk activity indicator light (LED). The indica‐
tor lights on some SCSI devices glow dimly when using this command, and
it might not be possible to distinguish the locator signal from current
I/O. You might need to quiesce I/O to see the flashing LED.
When working on a cluster, if you do not specify an optional member
name the operation defaults to the local member. (Some command options
require that you specify a member name.)
The -verbose option displays only the following types of binding: RAD
binding, in systems that support resource affinity domains. Processes
bound to a CPU when you use the runon command.
ERRORS
The command returns an int with an errorno from <errno.h> header file.
EXAMPLES
These examples have been reformatted for ease of reference. The actual
formatted output from commands might be slightly different. For exam‐
ples of the command options specific to hot-swap of CPUs, refer to the
Managing Online Addition and Removal manual. The following command
causes the activity light on component HWID 66 to flash for one minute:
# /sbin/hwmgr locate component -id 66 -time 60
Obtain the HWID by using the following command options:
# /sbin/hwmgr show scsi -type disk
66: 2 cymro disk none 0 1 dsk16
[0/3/0] The following command shows the status of all system
components. Only partial output is included here:
# /sbin/hwmgr status comp
STATUS ACCESS INDICT HWID: HOSTNAME
SUMMARY STATE STATE LEVEL NAME
----------------------------------------------------------------------
1: cymro online available AlphaServer 800
5/500
2: cymro online available CPU0
3: cymro online available unknown
4: cymro online available kevm
The following example shows how you can use the redirect option
to replace a failed device (did=3). This command assumes that:
You used the show scsi (or other) option to obtain the device
identifier (did) for the failed device. The replacement device
is installed according to the directions in the Owner's Manual.
You used the scan scsi option to probe for the replacement
device. You used the show scsi option to obtain the device
identifier (did) for the replacement device and found it to be
53. # /sbin/hwmgr redirect scsi -src 3 -dest 53 The following
example shows how you check the indictment status of a device,
in this case a CPU, and change it if necessary. See the Managing
Online Addition and Removal manual for information on the
indictment procedure.
In this case, the Event Manager notified you that Compaq Analyze
indicted a CPU. The SysMan Station displays a critical event
icon (a red circle with a slash): Use the following command to
show which devices are not in an optimum state:
# /sbin/hwmgr status component -ngood
STATUS ACCESS INDICT HWID:
HOSTNAME SUMMARY STATE STATE LEVEL NAME
--------------------------------------------------------------
50: ghent99 critical offline available medium CPU2
A component is shown as indicted. Use the following command to
obtain the indictment attributes:
# /sbin/hwmgr get attr -id 50 -a indicted_probability / -a
indicted_urgency indicted_probability = 10 indicted_urgency = 5
Use the following command to change the indicted status of a
device:
# /sbin/hwmgr unindict -id 50 hwmgr: Unindict operation was
successful Use the following command to verify the change of
status:
# /sbin/hwmgr get attr -id 50 | grep indict indicted = 0
indicted_probability = (null) indicted_urgency = (null)
Changing the indictment status automatically resets the value of
the indicted_probability and indicted_urgency attributes. The
following command attempts to offline a CPU to which processes
are bound by the runon command:
# /sbin/hwmgr -offline -id 3 hwmgr: Active processes are bound
to CPU1. Use -verbose for further information.
Use the following command to display more information about the
bound processes:
# /sbin/hwmgr -offline -id 3 -verbose Warning active processes
are bound to CPU1.
Taking this CPU offline will suspend active processes until
the CPU is placed back online.
For your system, a snapshot of the processes which could be
affected includes:
PID CPU USER COMMAND
1256 1 root hwmgr
1187 1 root []
1186 1 root sh
hwmgr: Please use the -force switch if you wish to offline a
CPU with bound processes.
If you decide that the processes can be safely terminated, you
can choose to force the CPU offline as follows: # /sbin/hwmgr
-offline -id 3 -force
hwmgr: CPU1 is now offline
If you bring the CPU back online, the suspended processes will
restart. The following example shows how to apply power to a
named CPU: # /sbin/hwmgr -power on -name CPU2
FILES
Refer to hwmgr(8) for a list of data files.
SEE ALSO
Commands: dop(8), dsfmgr(8), hwmgr_view(8), hwmgr_get(8),
hwmgr_show(8), sysman(8), sysman_station(8)
Files: olar_config(4), processor_sets(4)
Misc: olar_intro(5)
Hardware Management, Managing Online Addition and Removal, System
Administration
hwmgr_ops(8)
