Attaching a System Board

---

Note - This section gives a broad overview of the actions that occur when you execute DR Attach. For step-by-step instructions, see "To Attach a Board with Hostview" on page 3-4.

---

You can attach system boards that are present in the machine, powered on, and not part of an active domain (i.e., not being used by an operating system). These unattached boards may have been Hot Swapped into the system after the system was booted, blacklisted when the system was booted, or detached from another domain. See "Configuring the System for DR" on page 2-1 for a discussion of which board configurations can be attached.

---

Note - If the system board to be attached has been hot swapped into the system, the thermcal_config(1M) command should be run immediately after the board has been powered on.

---

Once you've selected an eligible board and a target domain, the DR Attach operation proceeds through two steps: Init Attach and Complete Attach.

Init Attach

During the Init Attach phase, DR diagnoses and configures the selected board, preparing it and its devices for attachment to the operating system. During this phase DR:

• Adds this board to the target domain's board list in the domain_config(4) file on the SSP
• Runs hpost -H on the board to configure it. hpost isolates the board on the Enterprise 10000 centerplane by placing it into a single-board hardware domain (see hpost(1M))
• Runs obp_helper -H which loads download_helper to the board, and takes the processors on the board out of reset mode allowing them to spin in download_helper
• Reconfigures the centerplane and board domain mask registers, placing this board in the target hardware domain

DR displays the output of these hpost(1M) and obp_helper(1M) operations, including the steps that succeeded and those that caused exceptions.

If hpost(1M) and obp_helper(1M) succeed, the board configuration is presented to the operating system. The devices are added to the operating system configuration but are not attached.

After the Init Attach phase is completed, the OBP board configuration may be displayed to confirm which devices are present on the board. You may then enter the Complete Detach phase to proceed or you may abort the operation.

If you abort the operation, DR removes the board configuration from the operating system data structures and removes the board from the domain_config(4) file (leaving the board in a state where it is not assigned to any domain). The board may then be removed from the system via Hot Swap, left in the system unattached, or attached at a later time.

Complete Attach

During the Complete Attach phase, DR attempts to complete the attach operation. If a problem occurs that prevents the attachment of any device on the board, the dr_daemon(1M) (described in the Solaris Reference Manual for

SMCC-Specific Software) logs that problem in the system message buffer. To determine which devices were successfully attached, display and check the system configuration for the board.

After a board is successfully attached, you have the option of reconfiguring the I/O devices as described in "Reconfiguration After a DR Operation" on page 2- 7. This operation may take several minutes to complete.

Attach Buttons

When you perform an attach operation using the Hostview GUI program (which transparently calls a separate executable, drview(1M)) the following buttons appear at various times during the attach process:

• Init Attach--Begins the attach operation (see "Init Attach" on page 3-2). Once the operation has completed successfully, the label on this button changes to complete.
• complete--Completes the attach operation (see "Complete Attach" on page 3-2).
• reconfig--Automatically reconfigures the device directories in the domain. You may want to run the reconfiguration operation after attaching a board (see "Reconfiguration After a DR Operation" on page 2-7).
• abort--Cancels the attach operation. This button is enabled after the Init Attach operation has successfully completed (see "Init Attach" on page 3- 2).
• dismiss--Terminates the step that is currently in progress, but leaves the board in its current state (Present, Init Attach, In Use). You can remove the DR attach window by choosing dismiss at any point during the attach operation. dismiss terminates any work being done on the SSP for the attach operation. For example, if hpost(1M) is running when you select dismiss, that hpost(1M) process is terminated. Note that dismiss does not terminate work being done on the host via RPC calls to the dr_daemon(1M). Once an RPC call is initiated, the host completes the RPC call regardless of whether the calling program is waiting for the RPC call to finish.

  The host dr_daemon(1M) keeps track of the progress of the attach

operation. Once the Init Attach operation completes successfully, it remembers this state. So you can dismiss the window, then return to the DR operation later and complete or abort the attach.

• help--Access online information regarding DR Attach operations.

· To Attach a Board with Hostview

---

Note - Before performing the following steps, be sure to read "Attaching a System Board" on page 3-1".

---

1. From Hostview, choose Configuration >> Board >> Attach. The following window is displayed.

Figure 3-1

2. Select the board that you want to attach in the main Hostview window (if that board is not already selected).

3. Click the top Select button in the window shown above. The Board and Source Domain fields are automatically filled in for you. (You can also manually edit those fields.) The source domain is the domain that the board currently belongs to. If the board is not a member of any domain, the source domain entry is no_domain.

4. In the main Hostview window, select the domain to which you want to attach the board.

   To do this, select any board that is currently a member of that domain.

5. Click the bottom Select button in the window shown above. The Target Domain field is automatically filled in for you. (You can also manually edit that field.)

6. Click Execute in the window shown above. If any errors occur, the error messages appear in the window shown above. Otherwise, the following window is displayed.

Figure 3-2

7. Click the Init Attach button.

   Clicking on the Init Attach button begins the first phase of the board attach process. When this phase is finished, the caption on the button changes to complete. Before you click the complete button, however, you may want to view the system information to verify that you want to proceed, as described in "Viewing System Information" on page 3-23.

   The Init Attach operation may take a few minutes to complete. Output from the hpost(1M) commands is directed to the Information pane of the window, as shown above in Figure 3-2.

   If the Init Attach fails, look for the cause in the output in the Information pane. Once you have determined the cause, you may want to choose Init Attach again.

   The window should now appear similar to that shown in Figure 3-3 on page 3-7, with the complete button enabled.

8. Select complete.

Figure 3-3

This operation may take a minute or so to complete. When it has successfully completed, DR displays the following message.

Board attachment completed successfully

The system board resources (processors, memory, and I/O devices) are now available to the operating system.

You may wish to view system information about the newly attached board using the buttons (CPU, Memory, Device, and so forth), as described in "Viewing System Information" on page 3-23.

---

Caution - Before choosing the reconfig option, be sure to read "Reconfiguration After a DR Operation" on page 2-7.

---

9. Select dismiss.

   The DR Attach operation is complete.

· To Attach a Board with dr(1M)

Before performing the following steps, see "Attaching a System Board" on page 3-1. The process of attaching a board is very similar whether you use Hostview or dr(1M). The basic concepts are not repeated in this section.

The dr(1M) shell was introduced in Chapter 1, "Introduction to DR". A quick reference guide is available in the dr(1M) application via the help command.

1. Execute the dr(1M) command in an SSP Window to bring up the dr(1M) prompt.

% dr dr>

2. Use drinit(1M) to establish communication with the dr_daemon(1M) on the desired target domain.

dr> drinit xf3 Checking environment... Establishing Control Board Server connection... Initializing SSP SNMP MIB... Establishing communication with DR daemon... xf3: System Status - Summary BOARD #: 0 1 2 5 6 8 9 10 11 13 physically present. BOARD #: 4 7 being used by the system. dr>

3. Begin the Init Attach operation for the designated board.

   In this example, board 6 is being attached to a domain called xf3.

dr> init_attach 6 Initiate attaching board 6 to domain xf3. Adding board 6 to domain_config file. /opt/SUNWssp/bin/hpost -H40,28 Opening SNMP server library... Significant contents of /export/home/ssp/.postrc: blacklist_file ./bf redlist_file ./rf Reading centerplane asics to obtain bus configuration... Bus configuration established as 3F. phase cplane_isolate: CP domain cluster mask clear... phase init_reset: Initial system resets... phase jtag_integ: JTAG probe and integrity test... phase mem_probe: Memory dimm probe... phase iom_probe: I/O module type probe... phase jtag_bbsram: JTAG basic test of bootbus sram... phase proc1: Initial processor module tests... phase pc/cic_reg: PC and CIC register tests... phase dtag: CIC DTAG tests... phase mem: MC register and memory tests... phase io: I/O controller tests... phase procmem2: Processor vs. memory II tests... phase lbexit: Centerplane connection tests... phase npb_mem: Non-Proc Board MC and memory tests... phase final_config: Final configuration... Configuring in 3F, FOM = 2048.00: 4 procs, 4 SCards, 1024 MBytes. Creating OBP handoff structures... Configured in 3F with 4 processors, 4 SBus cards, 1024 MBytes memory. Interconnect frequency is 83.294 MHz, from SNMP MIB. Processor frequency is 166.631 MHz, from SNMP MIB. Boot processor is 6.0 = 24 POST (level=16, verbose=20, -H28,0040) execution time 3:07 hpost is complete. obp_helper -H -m24 Board debut complete. Reconfiguring domain mask registers. Board attachment initiated successfully. Ready to COMPLETE board attachment.

4. Abort or complete the attach operation.

• After successfully completing the Init Attach operation, you can use drshow(1M) to see an inventory of the board resources:

dr> drshow board_number OBP

If you wish to abort the attach operation, execute abort_attach(1M) as follows:

dr> abort_attach board_number

• Alternatively, to complete the board attach operation, execute complete_attach(1M) as follows:

dr> complete_attach 6 Completing attach for board 6. Board attachment completed successfully. dr>

5. Execute drshow(1M) to display the I/O information for the newly attached board.

dr> drshow 6 IO SBus Controllers and Devices for Board 6 ------------------------ Sbus 0 : Slot 0 : SUNW,pln0 ---------- -------------- device opens name usage ------ ----- ---- ----- ssd0 0 /dev/dsk/c1t0d0s0 ssd16 0 /dev/dsk/c1t1d0s0 ssd32 0 /dev/dsk/c1t2d0s0 ssd48 0 /dev/dsk/c1t3d0s0 ssd64 0 /dev/dsk/c1t4d0s0 ssd80 0 /dev/dsk/c1t5d0s0 ------------------------ Sbus 0 : Slot 1 : SUNW,pln2 ---------- -------------- device opens name usage ------ ----- ---- ----- ssd96 0 /dev/dsk/c2t0d0s0 ssd97 0 /dev/dsk/c2t0d1s0 ...

6. Type exit to terminate this dr(1M) session.

dr> exit %

The SSP login shell is again displayed.

Detaching a System Board

---

Note - This section gives a broad overview of the actions that occur when you execute DR Detach. For step-by-step instructions, see "To Detach a Board with Hostview" on page 3-18.

---

System boards that are currently being used by the operating system can be detached if they meet the requirements covered in "Configuring for DR Detach" on page 2-4. Once you select an eligible board, you can detach that board by performing two operations: Drain and Complete Detach.

Drain

The primary function of the Drain operation is to determine how the board's memory is to be vacated by the operating system and, if required, to select a target memory area for copying the board's non-pageable memory. If a suitable target memory area is not available when the Drain operation is requested, the request is denied. If the Drain is rejected for this reason, you can continue to retry until target memory is available. See "Configuring for DR Detach" on page 2-4.

Once the Drain operation is started, the board's pageable memory is flushed to disk, which removes it from use by the system. Whenever a page of memory becomes free, that page is locked from further use. The Drain has no noticeable impact on the processes using the board resources. However, less memory is available to the system.

---

Note - When memory is drained, there must be enough memory and swap space remaining in the system to accommodate the current workload.

---

During the Drain period, Hostview and dr(1M) are available to monitor the detach progress. You can view the current status of the Drain operation, including the number of memory pages remaining to be drained, and the usage of devices on the board. With this information, you can prepare the system for detaching the remaining board devices.

If you decide not to proceed with the detach operation, you can abort the operation, and the board's memory is returned to regular usage.

The Drain operation is complete when all memory pages are drained. You can then Complete the operation.

Complete Detach

Before the detach operation can be completed, you must terminate all usage of board resources (processors, memory, and I/O devices). DR terminates the use of memory, processors, and network devices automatically, and you must terminate the use of all non-network I/O devices. This subject is discussed in "Configuring the System for DR" on page 2-1.

---

Note - To identify the components that are on the board to be detached, use drshow(1M), or the Board Detach window displayed in Hostview (when you select the Configuration menu and then choose the Board pullright menu and the Detach menu item). Another somewhat less informative way is to execute the prtdiag(1M) command.

---

Network Devices

DR automatically terminates usage of all network interfaces on the board that is being detached. When you complete the detach operation, the dr_daemon(1M) identifies all configured interfaces on the board being detached and issues the following ifconfig(1M) commands on each such interface.

ifconfig interface down ifconfig interface unplumb

Additionally, if FDDI interfaces are detached, DR kills the FDDI network monitoring daemon before performing the detach operation, and then restarts it after the detach is complete. Note that the /usr/sbin/nf_snmd daemon for nf devices is neither started nor stopped when a board that contains a FDDI interface is attached.

DR does not execute the above commands on a board that contains a network interface that fits any of the following conditions. In these cases, the detach operation fails and DR displays an error message. The operation fails if the interface is:

• The primary network interface for the domain; that is, the interface whose IP address corresponds to the network interface name contained in the file /etc/nodename. Note that bringing down the primary network interface for the domain prevents network information name services from operating, which results in the inability to make network connections to remote hosts using applications such as ftp(1), rsh(1), rcp(1), rlogin(1). NFS client and server operations are also affected.
• On the same subnet as the SSP host for the system; that is, the subnet of the IP address that corresponds to the SSP host name found in /etc/ssphostname. Bringing down this interface interrupts communication between the host and SSP. Since DR operations are initiated on the SSP, control of the detach process would be lost. (Note that the /etc/ssphostname file contains the name of the SSP that controls the host. If the SSP is renamed, /etc/ssphostname must be manually updated.)
• The active alternate for an Alternate Pathing (AP) meta device when the AP meta device is plumbed. Interfaces used by the AP system should not be the active path when the board is being detached. Manually switch the active path to one that is not on the board being detached. If no such path exists, manually execute the ifconfig down and ifconfig unplumb commands on the AP interface. (To manually switch an active path, use the apconfig(1M) command.)

Non-Network Devices

All non-network devices must be closed before they are detached. In the Hostview device display and in the drshow(1M) I/O listing, there is an open count field that indicates how many processes have opened particular devices. To see which processes have these devices open, use the fuser(1M) command on the domain.

You must perform the following tasks for non-network devices.

• If the redundancy features of Alternate Pathing or Solstice DiskSuite mirroring are used to access a device connected to the board, reconfigure these subsystems so that the device or network is accessible via controllers on other system boards.
• Unmount file systems, including Solstice DiskSuite meta-devices that have a board resident partition. Example: umount /partit

• Remove Solstice DiskSuite or Alternate Pathing databases from board-resident partitions. The location of Solstice DiskSuite or Alternate Pathing databases is explicitly chosen by the user and can be changed.
• Remove any private regions used by Sun Volume Manager or Veritas Volume Manager. Volume Manager by default uses a private region on each device that it controls, so such devices must be removed from Volume Manager control before they can be detached.
• Any RSM 2000 controllers on the board that is being detached should be taken offline, using the rm6 or rdacutil commands.
• Remove disk partitions from the swap configuration.
• Either kill any process that directly opens a device or raw partition, or direct it to close the open device on the board.
• If a detach-unsafe device is present on the board, close all instances of the device and use modunload(1M) to unload the driver.

---

Caution - Unmounting file systems may effect NFS client systems.

---

Processors

The boot processor is responsible for servicing the tick-timer interrupts and for broadcasting the heartbeat request to the other processors in the domain. Before detaching a board on which the boot processor resides, the dr_daemon(1M) must assign the boot processor role to another active (on-line) processor.

When a board is detached, all processes bound to its processors are automatically unbound. You can use pbind(1M) to rebind them to other processors.

Finishing the Complete Detach Operation

Once all board usage is terminated, you can perform the complete detach operation. If a device is still in use at this time, the detach operation fails and the device in use is reported. After resolving the problem, you can perform the complete detach operation again.

The complete detach operation may also fail due to quiesce problems, which are described in "Operating System Quiesce" on page 2-10. After resolving the quiesce problem you can again execute the complete detach operation.

If you decide that you do not want to proceed with the detach operation at this time, you can abort the detach. The board's memory is returned to normal usage and detached board devices are reattached. If the system configuration was modified to remove board usage (i.e., file systems were unmounted and networks were unplumbed), it is your responsibility to undo these modifications and return the devices to normal operation.

After the board is successfully detached from the operating system, it is isolated from the centerplane by moving it out of the host's hardware domain. In addition, the board list is updated in the domain_config file.

You can now attach the board to another domain, remove it via Hot Swap, leave it in the system unattached, or reattach it at a later time.

Hostview Detach Buttons

The Hostview detach window displays the following buttons at various times during a detach operation:

drain Starts to drain memory (see "Drain" on page 3-12). Once the Drain operation is finished, the drain button becomes the complete button.

complete Completes the detach operation (see "Complete Detach" on page 3-

13).

force If the complete detach operation fails due to a forcible quiesce condition, the force button is enabled, permitting you to complete the detach operation by forcibly quiescing the domain (see "Operating System Quiesce" on page 2-10).

reconfig Automatically reconfigures device directories in a domain. You

may want to run reconfig after permanently detaching a board. Use reconfig with extreme caution (see "Reconfiguration After a DR Operation" on page 2-7).

abort

Cancels the DR operation. This button is enabled after the drain operation starts and remains enabled until the complete detach operation starts. To stop the draining of memory and cancel the detach, choose abort (see "Detaching a System Board" on page 3- 12).

dismiss

Cancels any step that is in progress, and leaves the board in its current state (In Use, drain, Present). At any point during the DR Detach operation you can remove the DR Detach window by choosing dismiss which terminates any work being done on the SSP for the detach operation. Note that dismiss does not terminate work being done on the host via RPC calls to the dr_daemon(1M). Once an RPC call is initiated, the host completes the RPC call regardless of whether Hostview is waiting for the RPC call to finish.

The host dr_daemon(1M) keeps track of the progress of the detach operation. Once the drain is started, it remembers this state. So you can dismiss the window and then return to the DR operation later and either complete or abort the detach operation.

help..Accesses online information regarding DR detach operations.

· To Detach a Board with Hostview

---

Note - Before executing the following steps, see "Detaching a System Board" on page 3-12.

---

1. From the Hostview menu, choose Configuration >> Board >> Detach. The following window is displayed.

Figure 3-4

2. Select the board that you wish to detach in the main Hostview window (if that board is not already selected).

3. Click the Select button in the window shown above. The Board and Source domain fields are automatically filled in for you. (You can also manually edit those fields if you wish.)

4. Click Execute in the window shown above. If the target domain is not currently booted, the attach operation simply manipulates the domain configuration file on the SSP. However, if the domain is currently running, the following window is displayed.

Figure 3-5

5. Click the drain button.

   Hostview begins draining memory. The memory display automatically appears and allows you to monitor the progress of the Drain operation.

   The memory drain statistics are automatically updated at periodic intervals if you enable the Auto Update System Information Displays option in the DR Properties window, as described in "Viewing System Information" on page 3-23.

   If the Drain operation fails, an explanatory message is displayed in the Information pane of the window, above. Once you've determined the cause, and corrected it, you may wish to choose drain again.

   You may proceed to the next step without waiting; it does not depend on completion of the Drain.

6. To determine which devices are active on the board, click the Device button.

   This brings up the DR Device Configuration window which is periodically updated, providing you with a current snapshot of device usage.

7. Terminate all usage of board-resident I/O devices.

   For more information, see "Complete Detach" on page 3-13.

   When the complete button is displayed, DR is finished draining memory and you can proceed to the next step.

8. Choose complete.

   This operation may take several minutes to complete. When it is finished, the board devices are detached from the operating system.

   If your attempt to complete the detach fails, it may be due to any of the following reasons.

• All online processors in the system are on the board being detached.
• Critical network interfaces are on the board being detached. You must stop all usage of these networks manually (see "Complete Detach" on page 3- 13).
• All usage of the I/O devices has not been stopped. The Information pane identifies the device on which the error was encountered (see "Complete Detach" on page 3-13).
• The Quiesce failed. You must determine and resolve the cause of the error (see "Operating System Quiesce" on page 2-10).

  Once you've resolved the reason for the failure, you can select either complete or force to complete the detach. If there are no further problems, the board is detached and reset. When the board is successfully detached, the following message is displayed.

Board detachment completed successfully.

---

Caution - Before choosing the reconfig option, be sure to read "Reconfiguration After a DR Operation" on page 2-7.

---

You can now either reconfigure the device directories or dismiss the Detach window. The board can be powered off and removed via Hot Swap, attached to another domain, left in the system unattached, or reattached at a later time.

· To Detach a Board with dr(1M)

Before executing the following steps, see "Detaching a System Board" on page 3-12. The process of detaching a board is very similar with either Hostview or dr(1M). The basic concepts are not repeated in this section. The dr(1M) program was introduced in Chapter 1, "Introduction to DR".

1. Execute the dr(1M) command in an SSP Window to bring up the dr(1M) prompt.

% dr dr>

2. Execute drinit(1M) to establish communication with the dr_daemon(1M) on the desired domain.

dr> drinit xf3 Checking environment... Establishing Control Board Server connection... Initializing SSP SNMP MIB... Establishing communication with DR daemon... xf3: System Status - Summary BOARD #: 0 1 2 5 8 9 10 11 13 physically present. BOARD #: 4 6 7 being used by the system. dr>

3. Drain the board.

dr> drain 6 Removing board 6 from domain_config file. Start draining board 6 Board drain started. Retrieving System Info... Bound Processes for Board 6 cpu user sys procs --- ---- --- ----- 24 0 1 25 0 1 26 0 1 27 0 1 Active Devices for Board 6 device opens name usage ------ ----- ---- ----- ssd384 0 /dev/rdsk/c5t0d0s4 AP database Memory Drain for Board 6 - IN PROGRESS Reduction= 1024 MBytes Remaining in System= 1024 MBytes Percent Complete= 99% (5696 KBytes remaining) Drain operation started at Wed Oct 09 18:06:00 1996 Current time Wed Oct 09 18:06:34 1996 Memory Drain is in progress. When Drain has finished, you may COMPLETE the board detach. dr>

This initiates the drain operation, and returns immediately. You can monitor the progress of the drain operation with the following command.

dr> drshow board_number drain

In addition, you can initiate the drain with the wait option of the

drain(1M) command, which does not return until after the drain has completed. Refer to drain(1M) for more information regarding the wait option.

4. After the Drain operation has finished successfully, execute

   complete_detach(1M)</> to complete the detach:

dr> complete_detach 6 Completing detach of board 6 Operating System has detached the board. Processors on board 6 reset. Reconfiguring domain mask registers. Board 6 placed into loopback. Board detachment completed successfully. dr>

If the complete detach fails with the message "Operating system failed to quiesce due to forcible conditions.", and you have determined the root cause of the quiesce failure, you may choose to retry the complete_detach with the force option. (You can see the console messages to help determine the cause of the quiesce failure.) Refer to complete_detach(1M) for more information.

You can abort the detach operation, rather than complete it. To do so, use the command abort_detach board_number, instead of the complete_detach command shown above.

Viewing System Information

Both dr(1M) and Hostview allow you to display information about the suspend-unsafe devices as well as information about the board selected during DR operations. For dr(1M), this information is accessible via the drshow(1M) command. From Hostview, this information is available by clicking the cpu, memory, device, obp, and unsafe buttons in the attach or detach windows. The informational content is the same for both dr(1M) and Hostview. Note that the cpu, memory, and device displays are only enabled when the board is attached to the operating system. When the cpu, memory, and device displays are available, they always contain accurate information. The obp display shows the information known to OBP, and it is not guaranteed to be as detailed as the other three displays. This section shows how to use the displays.

When you are using Hostview to do a DR operation, you can view system information by using the following buttons:

Figure 3-6

When you click any of the buttons shown above, a window is displayed. The window remains on the screen until you click the dismiss button within that window. If you click the All button, all of the currently enabled windows are displayed.

By default, the cpu, memory, device, and unsafe windows are updated periodically as long as they are displayed. You can set two properties that determine how the displays are updated. To do this, click the Properties button in the Dynamic Reconfiguration window (for attach or detach). The properties window is shown in Figure 3-7.

Figure 3-7

If you set Auto Update System Information Displays to On (which is the default), the displays are periodically updated. You can set the Update Interval to a value, in seconds, to determine how often updates occur. If you set Auto Update System Information Displays to Off, none of the displays are updated; each display is a snapshot taken at the time the button was pressed. Click the Save button to save the settings between Hostview invocations.

---

Note - When the update interval is set to a low value, such as 10 seconds, and several informational displays are active, responsiveness of the DR windows may be degraded. This is especially true when device detail displays are active. Each time an informational display is updated, an RPC call is issued to the dr_daemon running on the domain. dr_daemon is an iterative RPC server, so each RPC request is run sequentially.

---

To view processor configuration information, click on the cpu button, and the following window is displayed.

Figure 3-8

For each processor on the selected board, the window shows the numeric ID, status (Online/Offline), and bound threads information. Threads may be bound to a processor via the pbind(1M) command. Some operating system device drivers may bind threads to processes to provide better servicing of a device. The number of user and system threads, and the process IDs of the bound threads are displayed.

To view memory configuration information, click the memory button, and the following window appears.

Figure 3-9

The memory configuration window is divided into system memory information, information that pertains to a particular board, and if a Drain operation is in progress, information showing the status of the memory Drain.

The system memory display includes:

• Current System--The total size of memory in the system from all boards
• Attach Capacity--The amount of memory that can currently be added via a DR Attach operation
• dr-max-mem--The value of the OBP variable that determines the maximum amount of memory the system can support; you cannot perform any DR operation unless this variable has a non-zero value

The board memory window shows the amount of memory on the selected board, the board it is interleaved with, and the highest and lowest physical pages that are occupied by this board's memory. (Small memory areas in the middle of this range may not be used by this board; but, for the sake of simplicity, such areas are not indicated.)

---

Note - Currently, DR is not able to detach boards that have interleaved memory.

---

The memory drain display may be in one of the following states: Unavailable, Estimated, In Progress, or complete. Unavailable means that a suitable target memory area is not currently available. The estimated values are displayed prior to starting the Drain operation. The values displayed reflect the memory configuration that would result if the Drain operation were started at this point in time. Note that the estimated values may differ from the in-progress values depending on the system memory usage at the time Drain was started. Once the Drain operation has been started, the state is either In Progress, or complete. The displayed values are defined as follows.

• Reduction--The amount of memory to be removed from system usage when the board is detached.
• Remaining in System--The system memory size once the board is detached.
• Percent Complete--How far along the Drain operation has progressed. Note that the time required to drain each memory page is not constant. Some memory pages take longer to drain than others.

As an aid in tracking Drain progress, the Drain operation start time and current time are also displayed.

To view the device configuration information, click on the device button. The following window is displayed.

Figure 3-10

The controllers or devices in each slot are listed. The controller and device names are a concatenation of their device name and their operating system instance number (for example, sd31).

---

Note - The Device Configuration display does not necessarily show all devices that are physically present on the board. For example, controllers whose drivers are unattached do not appear in the list. The device display that is available via the obp button lists the cards on the board that are configured in the system.

---

For more detailed information, highlight one or more controller(s) and choose Detail. The following window is displayed for each selected controller.

Figure 3-11

The current usage information for each device is shown. The window includes an open count (if available) and the common name by which the device is known; a disk partition, meta device, or an interface name. Additional usage information is also provided, including the partition mount points, network interface configuration, swap space usage, and meta device usage.

---

Note - Some device usage, such as disk partitions used for Sun Solstice DiskSuite and Alternate Pathing databases, and Sun Volume Manager usage, may not be reported.

---

If a controller or network interface is part of the AP database, the window indicates whether it is an AP alternate and whether it is active. For active AP alternates, the usage of the AP meta-device is displayed.

The OBP window contains board configuration information derived from the OBP device tree. This information is less detailed than that available from the other windows described here. For example, in the Init Attach state, only the I/O adapters--not the devices attached to those controllers nor the

memory interleave configuration--are known. The OBP window is usually used when a board is in the Init Attach state. The OBP window is shown in Figure 3-12.

Figure 3-12

To see a list of the suspend-unsafe devices across the entire domain--not just those that are resident on the selected system board--click on the unsafe button and the following window is displayed.

Figure 3-13

This display shows the suspend-unsafe devices that are currently open. This information is useful for determining the cause of operating system quiesce errors due to unsafe devices being open. In this example, no unsafe devices are open.