'\" te .\" Copyright (c) 2009, 2011, Oracle and/or its affiliates. All rights reserved. .TH cfgadm_shp 1M "25 Aug 2009" "SunOS 5.11" "System Administration Commands" .SH NAME cfgadm_shp \- PCI Express and Standard PCI Hotplug hardware-specific commands for cfgadm .SH SYNOPSIS .LP .nf \fB/usr/sbin/cfgadm\fR [\fB-f\fR] [\fB-y\fR | \fB-n\fR] [\fB-v\fR] [\fB-o\fR \fIhardware_options\fR] \fB-c\fR \fIfunction\fR \fIap_id\fR [\fIap_id\fR] .fi .LP .nf \fB/usr/sbin/cfgadm\fR [\fB-f\fR] [\fB-y\fR | \fB-n\fR] [\fB-v\fR] [\fB-o\fR \fIhardware_options\fR] \fB-x\fR \fIhardware_function\fR \fIap_id\fR [\fIap_id\fR] .fi .LP .nf \fB/usr/sbin/cfgadm\fR [\fB-v\fR] [\fB-s\fR \fIlisting_options\fR] [\fB-o\fR \fIhardware_options\fR] \fB-x\fR \fIhardware_function\fR \fIap_id\fR [\fIap_id\fR] .fi .LP .nf \fB/usr/sbin/cfgadm\fR [\fB-v\fR] [\fB-o\fR \fIhardware_options\fR] \fB-t\fR\fIap_id\fR [\fIap_id\fR] .fi .LP .nf \fB/usr/sbin/cfgadm\fR [\fB-v\fR] [\fB-o\fR \fIhardware_function\fR]\fB-h\fR [\fIap_id\fR | \fIap_type\fR] .fi .SH DESCRIPTION .sp .LP The PCI Express and Standard PCI Hotplug hardware-specific library, \fB/usr/lib/cfgadm/shp.so.1\fR, provides support for hotplugging PCI Express and Standard PCI Hotplug adapter cards into the respective hotpluggable slots in a system that is hotplug-capable, through the \fBcfgadm\fR command (see \fBcfgadm\fR(1M)). Support for the rest PCI Hotplug adapter cards (other than PCI Express and Standard PCI Hotplug cards) are provided by \fBcfgadm_pci\fR library (see \fBcfgadm_pci\fR(1M)). Hotplug administrative models between PCI Express Hotplug and Standard PCI Hotplug remain the same except where noted in this man page. .sp .LP For PCI hotplug, each hotplug slot on a specific PCI bus is represented by an attachment point of that PCI bus. .sp .LP An attachment point consist of two parts: a receptacle and an occupant. The receptacle under PCI hotplug is usually referred to as the physical hot pluggable slot; and the occupant is usually referred to as the PCI adapter card that plugs into the slot. .sp .LP Attachment points are named through \fBap_id\fRs. There are two types of \fBap_id\fRs: logical and physical. The physical \fBap_id\fR is based on the physical pathname, for example: .sp .in +2 .nf /devices/pci@7c,0/pci10de,5d@d:pcie2 .fi .in -2 .sp .sp .LP Whereas the logical \fBap_id\fR is a shorter, more user-friendly name, for example, \fBpcie2\fR. The \fBap_type\fR for Hotplug PCI is \fBpci\fR. .sp .LP Note that the \fBap_type\fR is not the same as the information in the \fBType\fR field. .SS "PCI Express ap_id Naming" .sp .LP For attachment points located in a PCI Express hierarchy (that is, the parent or an ancestor is a PCI Express device), including attachment points that are not PCI Express devices themselves, the naming scheme shown below is used. .sp .LP Grammar: .sp .ne 2 .mk .na \fB\fBAPID\fR : \fIabsolute-slot-path\fR\fR .ad .sp .6 .RS 4n Fundamental term. .RE .sp .ne 2 .mk .na \fB\fIabsolute-slot-path\fR : \fIslot-path\fR[:\fIslot-path\fR[:\fIslotpath\fR ...]]\fR .ad .sp .6 .RS 4n \&...where \fIfru-id\fR indicates the chassis FRU, if any, containing the \fIslot-id\fR. .RE .sp .ne 2 .mk .na \fB\fIfru-id\fR : \fIfru-type\fR[\fIserialid#\fR]\fR .ad .sp .6 .RS 4n \&...where \fIfru-type\fR is "iob" for a PCI Express expansion chassis, followed by its serial number \fIserialid#\fR, if available .RE .sp .ne 2 .mk .na \fB\fIslot-id\fR : \fIslot-name\fR | \fIdevice-type\fR \fIphysical-slot#\fR | \e\fR .ad .br .na \fB\fInexus-driver-name\fR \fInexus-driver-instance\fR.\e\fR .ad .br .na \fB\fIdevice-type\fR \fIpci-device-number\fR\fR .ad .sp .6 .RS 4n \&...where \fIslot-name\fR is a name assigned by the platform or hardware itself. \fIdevice-type\fR is either \fBpcie\fR for PCI Express devices or \fBpci\fR for PCI devices. \fInexus-driver-name\fR is the driver name for the device component; \fIphysical-slot#\fR is the hardware slot number; and \fIpci-device-number\fR is the PCI device number in standard PCI nomenclature. .RE .sp .LP First, an \fIabsolute-slot-path\fR is constructed that attempts to describe the attachment point's topological location in more physically identifiable terms for the user. This \fIabsolute-slot-path\fR consists of \fIslot-path\fR components each separated by a \fB:\fR (colon). The leaf or leftmost \fIslot-path\fR component describes the device of the attachment point itself, while its right-adjacent \fIslot-path\fR component up to the rightmost or topmost \fIslot-path\fR component describes the parent up to the root devices, respectively. .sp .LP Each \fIslot-path\fR consists of a \fIslot-id\fR optionally preceded by a \fIfru-id\fR, which identifies an expansion chassis containing the device described by \fIslot-id\fR (detailed below). \fIfru-id\fR consists of \fIfru-type\fR followed by an optional \fIserialid#\fR. \fIfru-type\fR is "iob" for PCI Express expansion chassis types, while \fIserialid#\fR is either a 64-bit hexadecimal number indicating a raw serial number obtained from the expansion chassis hardware, or an upper-case, ASCII four-character sequence for a Sun-branded expansion chassis. .sp .LP Each slot-id consists of one of three possible forms: .sp .ne 2 .mk .na \fB\fIslot-id\fR form (1)\fR .ad .sp .6 .RS 4n \fIslot-names\fR .RE .sp .ne 2 .mk .na \fB\fIslot-id\fR form (2)\fR .ad .sp .6 .RS 4n \fIdevice-type\fR \fIphysical-slot#\fR .RE .sp .ne 2 .mk .na \fB\fIslot-id\fR form (3)\fR .ad .sp .6 .RS 4n \fInexus-driver-name\fR \fInexus-driver-instance\fR \fIdevice-type\fR \fIpci-device-number\fR .RE .sp .LP The precedence of which form to select flows from the lowest form number to the highest form number, or from top to bottom as described above. If a form cannot be successfully constructed, then the next numerically higher form is attempted. .sp .LP The \fIslot-names\fR in \fIslot-id\fR form (1) is taken from the \fBslot-names\fR property of the corresponding node in the device tree and is a name assigned by hardware or the platform. This format is not predefined or established. .sp .LP In \fIslot-id\fR form (2), \fIdevice-type\fR indicates the device type of the component's slot, and is either \fBpcie\fR for PCI Express or \fBpci\fR for PCI, while \fIphysical-slot#\fR, taken from the \fBphysical-slot#\fR property of its corresponding device node, indicates the hardware slot number of the component. .sp .LP \fIslot-id\fR form (3) is used when all other forms cannot be successfully constructed, and is considered to be the default form. \fInexus-driver-name\fR is the component's driver name; \fInexus-driver-instance\fR is this driver's instance; \fIdevice-type\fR is the same as described in form (2); \fIpci-device-number\fR is the PCI device number as described and used for device configuration cycles in standard PCI nomenclature. .sp .LP In summary of the \fIslot-path\fR component, expanding the optional FRU component that might precede it, \fIslot-path\fR will consist one of the following forms in order: .sp .ne 2 .mk .na \fB(1) [ iob[\fIserialid#\fR]. ]\fR .ad .sp .6 .RS 4n \fIslot-names\fR .RE .sp .ne 2 .mk .na \fB(2) [ iob[\fIserialid#\fR]. ]\fR .ad .sp .6 .RS 4n \fIdevice_type\fR \fIphysical_slot#\fR .RE .sp .ne 2 .mk .na \fB(2) [ iob[\fIserialid#\fR]. ]\fR .ad .sp .6 .RS 4n \fInexus-driver-name\fR \fInexus-driver-instance\fR. .sp \fIdevice_type\fR \fIpci-device-number\fR .RE .sp .LP Lastly, the final form of the actual \fBap_id\fR name used in \fBcfgadm\fR is decided as follows, specified in order of precedence: .sp .ne 2 .mk .na \fB\fBap_id\fR form (1)\fR .ad .sp .6 .RS 4n If the \fIabsolute-slot-path\fR can fit within the fixed length limit of \fBcfgadm\fR's \fBap_id\fR field, then \fIabsolute-slot-path\fR itself is used .RE .sp .ne 2 .mk .na \fB\fBap_id\fR form (2)\fR .ad .sp .6 .RS 4n (\fIabsolute-slot-path\fR exceeds the \fBap_id\fR length limit) If the last \fIslot_path\fR component is contained within an expansion chassis, and it contains a \fIserialid#\fR, then the last \fIslot_path\fR component is used. The requirement for a \fIserialid#\fR in this form is to ensure a globally unique \fBap_id\fR. .RE .sp .ne 2 .mk .na \fB\fBap_id\fR form (3)\fR .ad .sp .6 .RS 4n (\fIabsolute-slot-path\fR exceeds the \fBap_id\fR length limit) The default form, \fIslot-id\fR form (3), of the last \fIslot_path\fR component is used. .RE .sp .LP Whichever final \fBap_id\fR name is used, the \fIabsolute-slot-path\fR is stored in the Information (\fBinfo\fR) field which can be displayed using the \fB-s\fR or \fB-v\fR options. This information can be used to physically locate any \fBap_id\fRs named using \fBap_id\fR form (2) or \fBap_id\fR form (3). The \fIabsolute-slot-path\fR is transformed slightly when stored in the information field, by the replacement of a colon (\fB:\fR) with forward slashes (\fB/\fR) to more closely denote a topological context. The \fIabsolute-slot-path\fR can include \fIslot-path\fR components that are not hotpluggable above the leaf or rightmost \fIslot-path\fR component up to the onboard host slot. .sp .LP See the Examples section for a list of hotpluggable examples. .SH OPTIONS .sp .LP The following options are supported: .sp .ne 2 .mk .na \fB\fB-c\fR \fIfunction\fR\fR .ad .sp .6 .RS 4n The following functions are supported for PCI hotpluggable slots: .sp .ne 2 .mk .na \fB\fBconfigure\fR\fR .ad .sp .6 .RS 4n Configure the PCI device in the slot to be used by Solaris. .RE .sp .ne 2 .mk .na \fB\fBconnect\fR\fR .ad .sp .6 .RS 4n Connect the slot to PCI bus. .RE .sp .ne 2 .mk .na \fB\fBdisconnect\fR\fR .ad .sp .6 .RS 4n Disconnect the slot from the PCI bus. .RE .sp .ne 2 .mk .na \fB\fBinsert\fR\fR .ad .sp .6 .RS 4n Not supported. .RE .sp .ne 2 .mk .na \fB\fBremove\fR\fR .ad .sp .6 .RS 4n Not supported. .RE .sp .ne 2 .mk .na \fB\fBunconfigure\fR\fR .ad .sp .6 .RS 4n Logically remove the PCI device's resources from the system. .RE .RE .sp .ne 2 .mk .na \fB\fB-f\fR \fI\fR\fR .ad .sp .6 .RS 4n Not supported. .RE .sp .ne 2 .mk .na \fB\fB-h\fR \fIap_id\fR | \fIap_type\fR\fR .ad .sp .6 .RS 4n Display PCI hotplug-specific help message. .RE .sp .ne 2 .mk .na \fB\fB-l\fR \fIlist\fR\fR .ad .sp .6 .RS 4n List the values of PCI Hot Plug slots. .RE .sp .ne 2 .mk .na \fB\fB-o\fR \fIhardware_options\fR\fR .ad .sp .6 .RS 4n No hardware specific options are currently defined. .RE .sp .ne 2 .mk .na \fB\fB-s\fR \fIlisting_options\fR\fR .ad .sp .6 .RS 4n Same as the generic \fBcfgadm\fR(1M). .RE .sp .ne 2 .mk .na \fB\fB-t\fR \fIap_id\fR\fR .ad .sp .6 .RS 4n This command is only supported on platforms that support testing capability on the slot. .RE .sp .ne 2 .mk .na \fB\fB-v\fR\fR .ad .sp .6 .RS 4n Execute in verbose mode. .sp When the \fB-v\fR option is used with the \fB-l\fR option, the \fBcfgadm\fR command outputs information about the attachment point. For attachment points located in a PCI Express hierarchy, the Information field will contain the attachment point's absolute slot path location, including any hardware- or platform-specific labeling information for each component in the slot path. Each component in the slot path will be separated by a \fB/\fR (forward slash). See "PCI Express \fBap_id\fR Naming," above. For PCI Hot Plug attachment points not located in a PCI Express hierarchy, see \fBcfgadm_pci\fR(1M). The information in the \fBType\fR field is printed with or without the \fB-v\fR option. The occupant \fBType\fR field will describe the contents of the slot. There are two possible values: .sp .ne 2 .mk .na \fB\fBunknown\fR\fR .ad .sp .6 .RS 4n The slot is empty. If a card is in the slot, the card is not configured or there is no driver for the device on the card. .RE .sp .ne 2 .mk .na \fB\fIsubclass\fR/\fIboard\fR\fR .ad .sp .6 .RS 4n The card in the slot is either a single-function or multi-function device. .sp \fIsubclass\fR is a string representing the subclass code of the device, for example, \fBSCSI\fR, \fBethernet\fR, \fBpci-isa\fR, and so forth. If the card is a multi-functional device, \fBMULT\fR will get displayed instead. .sp \fIboard\fR is a string representing the board type of the device. For example, \fBhp\fR is the string used for a PCI Hot Plug adapter. .RE .RE .sp .ne 2 .mk .na \fB\fB-x\fR \fIhardware_function\fR\fR .ad .sp .6 .RS 4n Perform hardware-specific function. These hardware-specific functions should not normally change the state of a receptacle or occupant. .sp The following \fIhardware_function\fR is supported: .sp .ne 2 .mk .na \fB\fBled\fR=[\fIled_sub_arg\fR],\fBmode\fR=[\fImode_sub_arg\fR]\fR .ad .sp .6 .RS 4n Without subarguments, display a list of the current LED settings. With subarguments, set the mode of a specific LED for a slot. .sp Specify \fIled_sub_arg\fR as \fBfault\fR, \fBpower\fR, \fBattn\fR, or \fBactive\fR. .sp Specify \fImode_sub_arg\fR as \fBon\fR, \fBoff\fR, or \fBblink\fR. .sp For PCI Express, only the \fBpower\fR and \fBattn\fR LEDs are valid and only the state of the \fBattn\fR LED can be changed. .sp Changing the state of the LED does not change the state of the receptacle or occupant. Normally, the LEDs are controlled by the hotplug controller, no user intervention is necessary. Use this command for testing purposes. .LP Caution - .sp .RS 2 Changing the state of the LED can misrepresent the state of occupant or receptacle. .RE The following command displays the values of LEDs: .sp .in +2 .nf example# \fBcfgadm -x led pcie2\fR Ap_Id Led pcie2 power=on,fault=off,active=off,attn=off .fi .in -2 .sp The following command sets the \fBattn\fR LED to blink to indicate the location of the slot: .sp .in +2 .nf example# \fBcfgadm -x led=attn,mode=blink pcie2\fR .fi .in -2 .sp .RE .RE .SH EXAMPLES .LP \fBExample 1 \fRDisplaying the Value of Each Slot .sp .LP The following command displays the values of each slot: .sp .in +2 .nf example# \fBcfgadm -l\fR Ap_Id Type Receptacle Occupant Condition c0 scsi-bus connected configured unknown c1 scsi-bus connected unconfigured unknown c2 scsi-bus connected unconfigured unknown pcie7 etherne/hp connected configured ok pcie8 unknown empty unconfigured unknown pcie9 fibre/hp connected configured ok .fi .in -2 .sp .LP \fBExample 2 \fRReplacing a Card .sp .LP The following command lists all DR-capable attachment points: .sp .in +2 .nf example# \fBcfgadm\fR Type Receptacle Occupant Condition c0 scsi-bus connected configured unknown c1 scsi-bus connected unconfigured unknown c2 scsi-bus connected unconfigured unknown pcie7 etherne/hp connected configured ok pcie8 unknown empty unconfigured unknown pcie9 fibre/hp connected configured ok .fi .in -2 .sp .sp .LP The following command unconfigures and electrically disconnects the card identified by \fBpcie7\fR: .sp .in +2 .nf example# \fBcfgadm -c disconnect pcie7\fR .fi .in -2 .sp .sp .LP The change can be verified by entering the following command: .sp .in +2 .nf example# \fBcfgadm pcie7\fR Ap_Id Type Receptacle Occupant Condition pcie7 unknown disconnected unconfigured unknown .fi .in -2 .sp .sp .LP At this point the card can be swapped. The following command electrically connects and configures the replacement card: .sp .in +2 .nf example# \fBcfgadm -c configure pcie7\fR .fi .in -2 .sp .sp .LP The change can be verified by entering the following command: .sp .in +2 .nf example# \fBcfgadm pcie7\fR Ap_Id Type Receptacle Occupant Condition pcie7 etherne/hp connected configured ok .fi .in -2 .sp .LP \fBExample 3 \fRInterpreting ApIds in a PCI Express Topology .sp .LP The following command shows a listing for a topology with both PCI Express and PCI attachment points in an I/O expansion chassis connected to hotpluggable slots at the host level: .sp .in +2 .nf example# \fBcfgadm -s cols=ap_id:info\fR Ap_Id Information iou#0-pci#0 Location: iou#0-pci#0 iou#0-pci#1 Location: iou#0-pci#1 iou#0-pci#1:iob.pci3 Location: iou#0-pci#1/iob.pci3 iou#0-pci#1:iob.pci4 Location: iou#0-pci#1/iob.pci4 iou#0-pci#2 Location: iou#0-pci#2 iou#0-pci#2:iob58071.pcie1 Location: iou#0-pci#2/iob58071.pcie1 iou#0-pci#2:iob58071.special Location: iou#0-pci#2/iob58071.special iou#0-pci#3 Location: iou#0-pci#3 iou#0-pci#3:iobBADF.pcie1 Location: iou#0-pci#3/iobBADF.pcie1 iou#0-pci#3:iobBADF.pcie2 Location: iou#0-pci#3/iobBADF.pcie2 iou#0-pci#3:iobBADF.pcie3 Location: iou#0-pci#3/iobBADF.pcie3 iou#0-pci#3:iobBADF.pci1 Location: iou#0-pci#3/iobBADF.pci1 iou#0-pci#3:iobBADF.pci2 Location: iou#0-pci#3/iobBADF.pci2 .fi .in -2 .sp .sp .LP In this example, the \fBiou#0-pci#[0-3]\fR entries represents the topmost hotpluggable slots in the system. Because the \fBiou#\fR\fIn\fR-\fBpci#\fR\fIn\fR form does not match any of the forms stated in the grammar specification section described above, we can infer that such a name for the base component in this hotplug topology is derived from the platform through the \fBslot-names\fR property. .sp .LP The slots in the preceding output are described as follows: .sp .ne 2 .mk .na \fBSlot \fBiou#0-pci#0\fR\fR .ad .sp .6 .RS 4n This slot is empty or its occupant is unconfigured. .RE .sp .ne 2 .mk .na \fBSlot \fBiou#0-pci#1\fR\fR .ad .sp .6 .RS 4n This slot contains an expansion chassis with two hotpluggable slots, \fBpci3\fR and \fBpci4\fR. \fBpci3\fR and \fBpci4\fR represent two PCI slots contained within that expansion chassis with physical slot numbers \fB3\fR and \fB4\fR, respectively. The expansion chassis in this case does not have or export a serial-id. .RE .sp .ne 2 .mk .na \fBSlot \fBiou#0-pci#2\fR\fR .ad .sp .6 .RS 4n This slot contains a third-party expansion chassis with a hexadecimal serial-id of \fB58071\fR. Within that expansion chassis are two hotpluggable slots, \fBpcie1\fR and \fBspecial\fR. \fBpcie1\fR represents a PCI Express slot with physical slot number \fB1\fR. The slot \fBspecial\fR has a label which is derived from the platform, hardware, or firmware. .RE .sp .ne 2 .mk .na \fBSlot \fBiou#0-pci#3\fR\fR .ad .sp .6 .RS 4n This slot contains a Sun expansion chassis with an FRU identifier of \fBBADF\fR. This expansion chassis contains three PCI Express slots, \fBpcie1\fR, \fBpcie2\fR, and \fBpcie3\fR with physical slot numbers \fB1\fR, \fB2\fR, and \fB3\fR, respectively; and two PCI slots, \fBpci1\fR and \fBpci2\fR, with physical slot numbers 1 and 2, respectively. .RE .sp .LP The following command shows a listing for a topology with both PCI Express and PCI attachment points in an I/O expansion chassis with connected hotpluggable and non-hotpluggable host slots: .sp .in +2 .nf example# \fBcfgadm -s cols=ap_id:info\fR Ap_Id Information Slot1 Location: Slot1 Slot2:iob4ffa56.pcie1 Location: Slot2/iob4ffa56.pcie1 Slot2:iob4ffa56.pcie2 Location: Slot2/iob4ffa56.pcie2 Slot5:iob3901.pci1 Location: Slot2/iob3901.pci1 Slot5:iob3901.pci2 Location: Slot2/iob3901.pci2 .fi .in -2 .sp .sp .LP In this example, the host system only has one hotpluggable slot, \fBSlot1\fR. We can infer that \fBSlot2\fR and \fBSlot5\fR are not hotpluggable slots because they do not appear as attachment points themselves in \fBcfgadm\fR. However, \fBSlot2\fR and \fBSlot5\fR each contains a third party expansion chassis with hotpluggable slots. .sp .LP The following command shows a listing for a topology with attachment points that are lacking in certain device properties: .sp .in +2 .nf example# \fBcfgadm -s cols=ap_id:info\fR Ap_Id Information px_pci7.pcie0 Location: px_pci7.pcie0 px_pci11.pcie0 Location: px_pci11.pcie0 px_pci11.pcie0:iob.pcie1 Location: px_pci11.pcie0/iob.pcie1 px_pci11.pcie0:iob.pcie2 Location: px_pci11.pcie0/iob.pcie2 px_pci11.pcie0:iob.pcie3 Location: px_pci11.pcie0/iob.pcie3 .fi .in -2 .sp .sp .LP In this example, the host system contains two hotpluggable slots, \fBpx_pci7.pcie0\fR and \fBpx_pci11.pcie0\fR. In this case, it uses \fBslot-id\fR form (3) ( the default form) for the base \fIslot-path\fR component in the \fIabsolute-slot-path\fR, because the framework could not obtain enough information to produce other more descriptive forms of higher precedence. .sp .LP Interpreting right-to-left, attachment point \fBpx_pci7.pcie0\fR represents a PCI Express slot with PCIdevice number \fB0\fR (which does not imply a physical slot number of the same number), bound to nexus driver \fBpx_pci\fR, instance \fB7\fR. Likewise, attachment point \fBpx_pci11.pcie0\fR represents a PCI Express slot with PCI device number \fB0\fR bound to driver instance \fB11\fR of \fBpx_pci\fR. .sp .LP Under \fBpx_pci11.pcie0\fR is a third-party expansion chassis without a serial-id and with three hotpluggable PCI Express slots. .sp .LP The following command shows a listing for a topology with attachment point paths exceeding the \fBApId\fR field length limit: .sp .in +2 .nf example# \fBcfgadm -s cols=ap_id:info\fR Ap_Id Information pcie4 Location: pcie4 pcie4:iobSUNW.pcie1 Location: pcie4/iobSUNW.pcie1 pcie4:iobSUNW.pcie2 Location: pcie4/iobSUNW.pcie2 iob8879c3f3.pci1 Location: pcie4/iobSUNW.pcie2/iob8879c3f3.pci1 iob8879c3f3.pci2 Location: pcie4/iobSUNW.pcie2/iob8879c3f3.pci2 iob8879c3f3.pci3 Location: pcie4/iobSUNW.pcie2/iob8879c3f3.pci3 .fi .in -2 .sp .sp .LP In this example, there is only one hotpluggable slot, \fBpcie4\fR in the host. Connected under \fBpcie4\fR is a Sun expansion chassis with FRU identifier \fBSUNW\fR. Nested under PCI Express slot \fBpcie2\fR of that expansion chassis (\fBApId\fR \fBpcie4:iobSUNW.pcie2\fR) lies another expansion chassis with three hotpluggable PCI slots. .sp .LP Because the length of the absolute-slot-path form of: .sp .in +2 .nf pcie4/iobSUNW.pcie2/iob8879c3f3.pci1...3 .fi .in -2 .sp .sp .LP \&...exceeds the \fBApId\fR field length limit, and the leaf slot-path component is globally unique, \fBap_id\fR form (2) is used, where the leaf \fIslot-path\fR component in the \fIabsolute-slot-path\fR is used as the final \fBApId\fR. .sp .LP The following command shows a listing for a topology with attachment point paths exceeding the \fBApId\fR field-length limit and lacking enough information to uniquely identify the leaf \fIslot-id\fR on its own (for example, missing the serial-id): .sp .in +2 .nf example# \fBcfgadm -s cols=ap_id:info\fR Ap_Id Information pcie4 Location: pcie4 pcie4:iob4567812345678.pcie3 Location: pcie4/iob4567812345678.pcie3 px_pci20.pcie0 Location: pcie4/iob4567812345678.pcie3/iob.pcie1 px_pci21.pcie0 Location: pcie4/iob4567812345678.pcie3/iob.pcie2 .fi .in -2 .sp .sp .LP In this example, there is only one hotpluggable slot, \fBpcie4\fR in the host. Connected under \fBpcie4\fR is a third-party expansion chassis with hexadecimal serial-id \fB4567812345678\fR. Nested under the PCI Express slot \fBpcie3\fR of that expansion chassis (\fBApId\fR \fBpcie4:iob4567812345678.pcie3\fR), lies another third-party expansion chassis without a serial- id and with two hotpluggable PCI Express slots. .sp .LP Because the length of the absolute-slot-path form of: .sp .in +2 .nf pcie4/iob4567812345678.pcie3/iob.pcie1...2 .fi .in -2 .sp .sp .LP exceeds the \fBApId\fR field length limit, and the leaf \fIslot-path\fR component is not globally unique, \fBap_id\fR form (3) is used. \fBap_id\fR form (2) is where \fIslot-id\fR form (3) (the default form) of the leaf \fIslot-path\fR component in the \fIabsolute-slot-path\fR is used as the final \fBApId\fR. .sp .LP The default form or \fBslot-id\fR form (3) of the leaf component \fB\&.../iob.pcie1\fR represents a PCI Express slot with device number \fB0\fR, bound to driver instance \fB20\fR of \fBpx_pci\fR. Likewise, the default form of the leaf component \fB\&.../iob.pcie2\fR represents a PCI Express slot with device number \fB0\fR, bound to driver instance \fB21\fR of \fBpx_pci\fR. .SH FILES .sp .ne 2 .mk .na \fB\fB/usr/lib/cfgadm/shp.so.1\fR\fR .ad .sp .6 .RS 4n Hardware-specific library for PCI Express and Standard PCI hotplugging. .RE .SH ATTRIBUTES .sp .LP See \fBattributes\fR(5) for descriptions of the following attributes: .sp .sp .TS tab() box; cw(2.75i) |cw(2.75i) lw(2.75i) |lw(2.75i) . ATTRIBUTE TYPEATTRIBUTE VALUE _ Availabilitysystem/library _ Interface StabilityUncommitted .TE .SH SEE ALSO .sp .LP \fBcfgadm\fR(1M), \fBcfgadm_pci\fR(1M), \fBhotplugd\fR(1M), \fBconfig_admin\fR(3CFGADM), \fBlibcfgadm\fR(3LIB), \fBattributes\fR(5), \fBsmf\fR(5) .SH NOTES .sp .LP The \fBcfgadm_shp\fR library is dependent on the \fBhotplug\fR service, which is managed by \fBsmf\fR(5) under FMRI: .sp .in +2 .nf svc:/system/hotplug:default .fi .in -2 .sp .sp .LP The service must be enabled for the \fBcfgadm_shp\fR library to function properly. See \fBhotplugd\fR(1M) for details.