| 跳过导航链接 | |
| 退出打印视图 | |
|
手册页第 5 部分：标准、环境和宏 Oracle Solaris 11.1 Information Library (简体中文) |
| 跳过导航链接 | |
| 退出打印视图 | |
|
|
手册页第 5 部分：标准、环境和宏 Oracle Solaris 11.1 Information Library (简体中文) |
- Ethernet mii kstat and dladm parameters
This page describes the kernel statistics and the dladm(1M) configuration parameters used to monitor and configure the Ethernet physical layer.
The cap_* parameters exist in the kernel statistics for an Ethernet device. The parameters describe the maximum capability of a device. When the value of a statistic is 1, the device has the capability described. When the value is 0, the device does not have the capability.
The exceptions to this rule are the cap_asym_pause and cap_pause parameters which are explained later in this page.
Capable of auto-negotiation
Capable of 1000 full duplex operation
Capable of 1000 half duplex operation
Capable of 100 full duplex operation
Capable of 100 half duplex operation
Capable of 10 full duplex operation
Capable of 10 half duplex operation
Capable of reporting locally detected faults to link partner
The adv_cap_* parameters exist in the kernel statistics and represent a mirror image of the dladm adv_*_cap parameter list for an Ethernet device. The dladm adv_*_cap tuning parameters allow fine grain control of the Ethernet device physical layer. The parameters are also a subset of the cap_* statistics. If the cap_* value is 0, the corresponding adv_cap_* must also be 0. The exceptions to this rule are the adv_cap_asym_pause and adv_cap_pause parameters.
When auto-negotiation is enabled, the adv_*_cap statistics show which capabilities are advertised to the link partner. When auto-negotiation is disabled in forced mode, the statistics precisely show how a link should function and that it must be matched on the link partner to achieve a valid link up.
Statistics with values other than 0 and 1 are also described in the following.
Advertise auto-negotiation capability
Advertise 1000 full duplex capability
Advertise 1000 half duplex capability
Advertise 100 full duplex capability
Advertise 100 half duplex capability
Advertise 10 full duplex capability
Advertise 10 half duplex capability
Fault value reported by the local system to the peer
Link is good
Fault
The lp_cap_* parameters exist as kernel statistics for an Ethernet device. The statistics are the advertised capabilities provided by the link partner on completion of auto-negotiation. If the capabilities match the capabilities provided in the local advertisement, the link can proceed to a link up state. If no match is found, the link remains down. In two other instances, lp_cap_* values might all be zero: (1) when a cable is not present and (2) when forced mode is enabled.
Link partner advertises auto-negotiation capability
Link partner advertises 1000 full duplex capability
Link partner advertises 1000 half duplex capability
Link partner advertises 100 full duplex capability
Link partner advertises 100 half duplex capability
Link partner advertises 10 full duplex capability
Link partner advertises 10 half duplex capability
Fault value the remote system reports
Link is good
Fault
The xcvr_* kernel statistics provide information about the physical layer device that is in use.
MII address in the 0 to 31 range of the physical layer device in use for a given Ethernet device
MII transceiver manufacturer and device ID
MII transceiver type, based on the following list:
Undefined
MII present, but nothing connected
10Mb/s Manchester encoding
100 Mb/s 8B/6T
100 Mb/s 4B/5B
100 Mb/s PAM5X5
1000 Mb/s 8B/10B
1000 Mb/s 4D-PAM5
The above values define maximum capability. In many cases, lower speeds can occur. The cap_* statistics must be viewed to establish the range of capability.
The link_* kernel statistics show the link state at the local end of the connection.
|
The cap_asym_pause, cap_pause, adv_cap_asym_pause, and adv_cap_pause parameters do not follow the rules of other cap_* and adv_cap_* kstats or parameters. The cap_*pause kstats provide information about the capabilities supported by the device and constrain the values that may be set to the corresponding adv_cap_*pause parameters.
Symmetric pause capability.
Asymmetric pause capability.
The adv_cap_pause and adv_cap_asym_pause statistics are limited by the available settings for cap_pause and cap_asym_pause. These statistics are read-only values whose settings may be administratively controlled by setting the flowctrl property supported by dladm(1M). For a device that is fully capable of pausing both Rx (receive) and Tx (transmit) operations, the settings available are defined in the truth table that follows the adv_cap_pause and adv_cap_asm_pause parameter descriptions below.
When adv_cap_pause is 1, the device can both assert and respond to flow control. This is the pre-Gigabit, symmetric mode of operation, and implies a full (both send and receive) implementation of the PAUSE mechanism within the device. In addition, if adv_cap_asym_pause is 1, the device can operate either symmetrically or asymmetrically in either direction.
If adv_cap_pause is 0, advertised, flow-control behavior is determined by adv_cap_asym_pause. If the value of adv_cap_asym_pause is 1, the device can assert flow control, but cannot resend.
No flow control is available when bot adv_cap_pause and adv_cap_asym_pause are 0.
Asymmetric pause capability.
The cap_asym_pause and cap_pause statistics show the capability of a device and also limit the legal setting for adv_cap_asym_pause and adv_cap_pause. The following truth table describes the available adv_cap_asym_pause and adv_cap_pause settings limited by cap_asym_pause and cap_pause statistics. The abbreviations below are used in the table.
cap_asym_pause
cap_pause
adv_cap_asym_pause
adv_cap_pause
|
In the cases above, an error is posted when a device driver cannot advertise. A new setting is ignored and values revert to the previous setting.
The lp_cap_pause and the lp_cap_asym_pause provide the advertised capabilities of the link partners.
When lp_cap_pause is 1, the link-partner can both assert and respond to flow control. This is the pre-Gigabit, symmetric mode of operation, and implies a full (both send and receive) implementation of the PAUSE mechanism within the device. In addition, if lp_cap_asym_pause is 1, the link-partner can operate either symmetrically or asymmetrically in either direction.
If lp_cap_pause is 0, the flow-control behavior supported by the link-partner is determined by lp_cap_asym_pause. If the value of lp_cap_asym_pause is 1, the link-partner can assert flow control, but cannot respond to any pause-frames sent to it.
No flow control is available when both lp_cap_pause and lp_cap_asym_pause are 0.
Asymmetric pause capability
When adv_*pause_cap and lp_*pause_cap are compared on completion of auto-negotiation, the chosen flow control mechanism for the link depends on what is most meaningful.
Link partner can assert flow control by sending pause frames when congestion is experienced.
Link partner can respond to pause frames received.
The following truth table illustrates the meaningful flow control combinations related to local and link partner configurations. The abbreviations below are used in the table.
adv_cap_asym_pause
adv_cap_pause
lp_cap_asym_pause
lp_cap_pause
link_asym_pause
link_pause
|
When forced mode is enabled, the current setting of adv_cap_asym_pause and adv_cap_pause are used for the link. The link_asym_pause and link_pause become equal to the current adv_cap_asym_pause and adv_cap_pause settings. The above table also applies in forced mode, but the link partner configuration must be checked to verify that flow control is operating on the link.
dladm(1M), driver.conf(4), bge(7D), dlpi(7P), eri(7D), gld(7D), hme(7D), qfe(7d)
When adv_cap_autoneg is set to 0, the highest priority speed and duplex is used for forced mode.
The highest priority is the highest speed at full duplex. The lowest priority is the lowest speed at half duplex.
MII transceivers can exist internally to a system or can be connected to an external MII connector. Typically, an internal transceiver has an xcvr_addr of 1, while an external connection has an xcvr_addr of 0.
|
