Hi,
Recently, I had to disable autoneg in one of my servers having ixgbe1 interface. While using below command I got "Permission denied" error:
ndd -set /dev/ixgbe1 adv_autoneg_cap 0
On investigating further I found that adv_autoneg_cap is showing as read-only parameter. Although it is read & write parameter in all other servers. But I don't know how it has become read only parameter in this system.
ndd -get /dev/ixgbe1 /?
adv_autoneg_cap (read only)
Thanks in advance.
//BR
Autonegotiation is a required part of the 1000baseT, 1000baseTX, and 10GbaseT standards:
If something isn't working properly, disabling autonegotiation isn't going to fix it.
In fact, it might even make it worse - your devices are neither certified nor tested to work at all under those standards with autonegotiation disabled.
Also, read this excerpt from a Solaris 11.2 copy of /kernel/drv/bge.conf, a configuration file for a Broadcom NIC:
# If autonegotiation is turned OFF ("forced mode"), the remaining 'adv_*'
# speed/duplex properties force selection of a specific mode, namely,
# the first mode found to be enabled, in highest-to-lowest speed order
# (thus, if adv_1000fdx_cap=1, all other values will be ignored; to force
# 10/hdx mode, *all* the faster modes must be explicitly disabled).
#
# BEWARE - it's very easy to end up with a non-working link using forced
# mode. There's NO validation that the link partner actually supports
# the mode that this device has been forced into. In some cases, this
# will prevent the link coming up; in others, the link status will show
# 'up' (electrical connection made) but data transfer will not work at
# all, or will work poorly (low throughput, high collision rates, etc).
#
# Note that many switches *require* autonegotiation in order to operate
# at 1000Mbps or in full-duplex mode or with flow control. In other words,
# the only combinations that are likely to work with autonegotiation off
# are 100Mbps/half-duplex and 10Mbps/half-duplex, unless the peer has also
# been manually forced to some other (matching) combination.
#
# With autonegotiation ON (the default and preferred mode), the 'adv_*'
# properties control which capabilities are advertised to the partner.
# The default is to advertise all the capabilities that the hardware
# supports; thus, the properties below serve only to limit the advertised
# capabilities to restricted subset -- it is not possible to advertise a
# capability that the hardware does not support.
#
# The autonegotiation process will then automagically select the fastest
# speed/duplex mode and greatest degree of flow control supported by both
# partners.
#
# If the local device is set to autonegotiate, but the link partner can't
# or doesn't autonegotiate, the correct speed will be determined anyway,
# and HALF-DUPLEX mode will be selected, as mandated by the IEEE802.3
# standard. This will yield the correct result if the partner is in fact
# incapable of autonegotiating: it must be a half-duplex device, because
# the only devices that don't support autonegotation are half-duplex (the
# standard says that all full-duplex-capable devices must also support
# autonegotiation).
#
# However, this choice will NOT be correct if the peer is actually capable
# of autonegotiation and full-duplex operation, and has been manually set
# to "forced full-duplex without autonegotiation" (a mode not recommended
# by the IEEE standard). The link will appear to work, but the duplex
# mismatch will result in packet loss and spurious "late collisions". In
# such cases, the preferred solution is to enable autonegotiation by the
# peer. Failing that, autonegotiation by the BGE device can be disabled,
# and forced mode used to match the peer's forced settings as above.
Not only is disabling autonegotiation a bad idea, if you have a support contract and have network problems, you WILL NOT GET SUPPORT until you enable autonegotiation, for one simple reason: it's part of the standard.