The following are the names and descriptions of the component conditions:

failed

The component failed testing.

ok

The component is operational.

unknown

The component has not been tested.

The following is the name and description of the receptacle state for components:

connected

The component is connected to the board slot.

The following are the names and descriptions of the occupant states for components:

configured

The component is available for use by the Solaris operating environment.

unconfigured

The component is not available for use by the Solaris operating environment.

The following are the names and descriptions of the board conditions.

failed

The board failed testing.

ok

The board is operational.

unknown

The board has not been tested.

unusable

The board slot is unusable.

Inserting a board changes the receptacle state from empty to disconnected. Removing a board changes the receptacle state from disconnected to empty.

Caution: Removing a board that is in the connected state or that is powered on and in the disconnected state crashes the operating system and can result in permanent damage to the system.

The following are the names and descriptions of the receptacle states for boards:

connected

The board is powered on and connected to the system bus. You can view the components on a board only after it is in the connected state.

disconnected

The board is disconnected from the system bus. A board can be in the disconnected state without being powered off. However, a board must be powered off and in the disconnected state before you remove it from the slot.

empty

A board is not present.

The occupant state of a disconnected board is always unconfigured. The following table contains the names and descriptions of the occupant states for boards:

configured

At least one component on the board is configured.

unconfigured

All of the components on the board are unconfigured.

Platforms based on dynamic system domains (DSDs, referred to as domains in this document) divide the slots in the chassis into electrically isolated hardware partitions (that is, DSDs). Platforms that are not based on DSDs assign all slots to the system permanently.

A slot can be empty or populated, and it can be assigned or available to any number of domains. The number of slots available to a given domain is controlled by an available component list (ACL) that is maintained on the system controller. The ACL is not the access control list provided by the Solaris operating environment.

A slot is visible to a domain only if the slot is in the domain's ACL and if it is not assigned to another domain. An unassigned slot is visible to all domains that have the slot in their ACL. After a slot has been assigned to a domain, the slot is no longer visible to any other domain.

A slot that is visible to a domain, but not assigned, must first be assigned to the domain before any other state changing commands are applied. The assign can be done explicitly using -x assign or implicitly as part of a connect. A slot must be unassigned from a domain before it can be used by another domain. The unassign is always explicit, either directly using -x unassign or as an option to disconnect using -o unassign.

Functions that change the state of a board slot or a component on the board can be issued concurrently against any attachment point. Only one state changing operation is permitted at a given time. A Y in the Busy field in the state changing information indicates an operation is in progress.

The following list contains the functions that change the state:

• configure
• unconfigure
• connect
• disconnect

Commands that change the availability of a board can be issued concurrently against any attachment point. Only one availability change operation is permitted at a given time. These functions also change the information string in the cfgadm -l output. A Y in the Busy field indicates that an operation is in progress.

The following list contains the functions that change the availability:

• assign
• unassign

Functions that change the condition of a board slot or a component on the board can be issued concurrently against any attachment point. Only one condition change operation is permitted at a given time. These functions also change the information string in the cfgadm -l output. A Y in the Busy field indicates an operation is in progress.

The following list contains the functions that change the condition:

• poweron
• poweroff
• test

This section contains a description of the unconfigure process, and illustrates the states of source and target boards at different stages during the process of moving permanent memory.

In the following code examples, the permanent memory on board 0 must be moved to another board in the domain. Thus, board 0 is the source, and board 1 is the target.

A status change operation cannot be initiated on a board while it is marked as busy. For brevity, the CPU information has been removed from the code examples.

The process is started with the following command:

# cfgadm -c unconfigure -y SB0::memory &

First, the memory on board 1 in the same address range as the permanent memory on board 0 must be deleted. During this phase, the source board, the target board, and the memory attachment points are marked as busy. You can display the status with the following command:

# cfgadm -a -s cols=ap_id:type:r_state:o_state:busy SB0 SB1

Ap_Id         Type      Receptacle     Occupant       Busy
SB0           CPU       connected      configured     y
SB0::memory   memory    connected      configured     y
SB1           CPU       connected      configured     y
SB1::memory   memory    connected      configured     y
 

After the memory has been deleted on board 1, it is marked as unconfigured. The memory on board 0 remains configured, but it is still marked as busy, as in the following example.

Ap_Id         Type      Receptacle     Occupant       Busy
SB0           CPU       connected      configured     y 
SB0::memory   memory    connected      configured     y 
SB1           CPU       connected      configured     y 
SB1::memory   memory    connected      unconfigured   n 
  

The memory from board 0 is then copied to board 1. After it has been copied, the occupant state for the memory is switched. The memory on board 0 becomes unconfigured, and the memory on board 1 becomes configured. At this point in the process, only board 0 remains busy, as in the following example.

Ap_Id         Type      Receptacle     Occupant       Busy
SB0           CPU       connected      configured     y 
SB0::memory   memory    connected      unconfigured   n 
SB1           CPU       connected      configured     n 
SB1::memory   memory    connected      configured     n 
  

After the entire process has been completed, the memory on board 0 remains unconfigured, and the attachment points are not busy, as in the following example.

Ap_Id         Type      Receptacle     Occupant       Busy
SB0           CPU       connected      configured     n 
SB0::memory   memory    connected      unconfigured   n 
SB1           CPU       connected      configured     n 
SB1::memory   memory    connected      configured     n 
  

The permanent memory has been moved, and the memory on board 0 has been unconfigured. At this point, you can initiate a new state changing operation on either board.

You can specify platform-specific options that follow the options interpreted by the system board plugin. All platform-specific options must be preceded by the platform keyword. The following example contains the general format of a command with platform-specific options:

command -o sbd_options,platform=platform_options

# cfgadm -a -s "select=class(sbd)"

Ap_Id         Type      Receptacle     Occupant       Condition
SB0           CPU       connected      configured     ok
SB0::cpu0     cpu       connected      configured     ok
SB0::memory   memory    connected      configured     ok
IO1           HPCI      connected      configured     ok
IO1::pci0     io        connected      configured     ok
IO1::pci1     io        connected      configured     ok
SB2           CPU       disconnected   unconfigured   failed
SB3           CPU       disconnected   unconfigured   unusable
SB4           unknown   empty          unconfigured   unknown

This example demonstrates the mapping of the following conditions:

• The board in Slot 2 failed testing.
• Slot 3 is unusable; thus, you cannot hot plug a board into that slot.

In the following example, the memory sizes are displayed in Kbytes.

# cfgadm -c unconfigure -y SB0::memory &
# cfgadm -l -s noheadings,cols=info -o parsable SB0::memory SB1::memory

address=0x0 size=2097152 permanent=752592 target=SB1::memory 
     deleted=1273680 remaining=823472
address=0x1000000 size=2097152 source=SB0::memory

The following shell script can be used to monitor the progress of a memory delete operation.

# cfgadm -c unconfigure -y SB0::memory &
# watch_memdel SB0

#!/bin/sh
# This is the watch_memdel script.

if [ -z "$1" ]; then
        printf "usage:  %s board_id\n" `basename $0`
        exit 1
fi

board_id=$1

cfgadm_info='cfgadm -s noheadings,cols=info -o parsable'

eval `$cfgadm_info $board_id::memory`

if [ -z "$remaining" ]; then
        echo no memory delete in progress involving $board_id
        exit 0
fi

echo deleting target $target

while true
do
        eval `$cfgadm_info $board_id::memory`

        if [ -n "$remaining" -a "$remaining" -ne 0 ]
        then
                echo $deleted KBytes deleted, $remaining KBytes remaining
                remaining=
        else
                echo memory delete is done
                exit 0
        fi
        sleep 1
done
exit 0

The following syntax is used to refer to Platform Notes attachment points on the Sun Enterprise 10000 system:

board::component

where board refers to the system board; and component refers to the individual component. System boards can range from SB0 (zero) to SB15. A maximum of sixteen system boards are available.

The DR 3.0 model running on a Sun Enterprise 10000 domain supports a limited subset of the functionality provided by the cfgadm_sbd plugin. The only supported operation is to view the status of attachment points in the domain. This corresponds to the -l option and all of its associated options.

Attempting to perform any other operation from the domain will result in an error that states that the operation is not supported. All operations to add or remove a system board must be initiated from the System Service Processor.

The following syntax is used to refer to attachment points on the Sun Fire 15K system:

board::component

where board refers to the system board or I/O board; and component refers to the individual component.

Depending on the system's configuration, system boards can range from SB0 (zero) through SB17, and I/O boards can range from IO0 (IO zero) through IO17. (A maximum of eighteen system and I/O boards are available).

The -t and -x options behave differently on the Sun Fire 15K platform. The following list describes their behavior:

-t

The system controller uses a CPU to test system boards by running LPOST, sequenced by the hpost command. To test I/O boards, the driver starts the testing in response to the -t option, and the test runs automatically without user intervention. The driver unconfigures a CPU and a stretch of contiguous physical memory. Then, it sends a command to the system controller to test the board. The system controller uses the CPU and memory to test the I/O board from inside of a transaction/error cage.

-x assign | unassign

In the Sun Fire 15K system administration model, the platform administrator controls the platform hardware through the use of an available component list for each domain. This information is maintained on the system controller. Only the platform administrator can modify the available component list for a domain.

The domain administrator is only allowed to assign or unassign a board if it is in the available component list for that domain. The platform administrator does not have this restriction, and can assign or unassign a board even if it is not in the available component list for a domain.

The following are the names and descriptions of the component types:

cpu

CPU

io

I/O device

memory

Memory

Note: An operation on a memory component affects all of the memory components on the board.

References to attachment points are slightly different on Sun Fire 6800, 4810, 4800, and 3800 systems than on the Sun Fire 15K system. The following syntax is used to refer to attachment points on Sun Fire systems other than the Sun Fire 15K:

N#.board::component

where N# refers to the node; board refers to the system board or I/O board; and component refers to the individual component.

Depending on the system's configuration, system boards can range from SB0 through SB5, and I/O boards can range from IB6 through IB9. (A maximum of six system and four I/O boards are available).

The following are the names and descriptions of the component types:

cpu

CPU

pci

I/O device

memory

Memory

Note: An operation on a memory component affects all of the memory components on the board.