NOTE: This release includes four Linux* Base Drivers for
Intel® Ethernet Network Connection. These drivers are named
igb, e1000,
e1000e and
igbvf.
igb driver supports all 82575, 82576 and 82580-based gigabit network connections.
The igbvf driver supports 82576-based virtual function devices that
can only be activated on kernels that support SR-IOV. SR-IOV requires
the correct platform and OS support.
e1000 driver supports all PCI and PCI-X gigabit network connections.
e1000e driver supports all PCI Express gigabit network connections,
except those that are 82580, 82575 and 82576-based.
NOTE: The Intel(R) PRO/1000 P Dual Port Server Adapter
is supported by the e1000 driver, not the e1000e due to the
82546 part being used behind a PCI Express bridge.
First identify
your adapter. Then follow the appropriate steps for building,
installing, and configuring the driver.
UPGRADING: If you currently have the e1000 driver installed
and need to install e1000e, perform the following:
If your version of e1000 is 7.6.15.5 or less, upgrade to e1000
version 8.x, using the instructions in the
e1000 section.
Install the e1000e driver using the instructions in the
e1000e section.
Modify /etc/modprobe.conf to point your PCIe devices to use the new
e1000e driver using alias ethX e1000e, or use your distribution's
specific method for configuring network adapters like RedHat's
setup/system-config-network
or SuSE's yast2.
Identifying Your Adapter
First identify your adapter. Then select the name of the specified base driver: igb,
e1000 or e1000e.
For more information on how to identify your adapter, go to the Adapter &
Driver ID Guide at:
The Linux base drivers
support the 2.4.x and 2.6.x kernels. These drivers includes support for Itanium®
2-based systems.
These drivers are only supported as a loadable module. Intel is not supplying
patches against the kernel source to allow for static linking of the drivers. For questions related
to hardware requirements, refer to the documentation supplied with your Intel
Gigabit adapter. All
hardware requirements listed apply to use with Linux.
The following features are now available in supported kernels:
Native VLANs
Channel Bonding (teaming)
SNMP
Channel Bonding documentation can be found in the Linux kernel source:
/documentation/networking/bonding.txt
The igb driver supports IEEE 1588 time stamping for kernels 2.6.30 and above.
The driver information previously displayed in the /proc file system is not
supported in this release. Alternatively, you can use ethtool (version 1.6 or
later), lspci, and ifconfig to obtain the same information. Instructions on
updating ethtool can be found in the section Additional
Configurations later in this document.
Building and Installation
To build a binary RPM* package of this driver, run 'rpmbuild -tb
igb.tar.gz'.
NOTES:
For the build to work properly, the currently running kernel
MUST match the version and configuration of the installed kernel sources. If you have just
recompiled the kernel reboot the system now.
RPM functionality has only
been tested in Red Hat distributions.
Move the base driver tar file to the directory of your
choice. For example, use '/home/username/igb' or '/usr/local/src/igb'.
Untar/unzip the archive, where <x.x.x> is the version number for the driver
tar file:
tar zxf igb-<x.x.x>.tar.gz
Change to the driver src directory, where <x.x.x> is the version number for the driver
tar:
With 2.6 based kernels also make sure that older igb drivers are removed
from the kernel, before loading the new module:
rmmod igb; modprobe igb
Assign an IP address to the interface by entering the
following, where <x> is the interface number:
ifconfig eth<x> <IP_address>
Verify that the interface works. Enter the following, where
<IP_address>
is the IP address for another machine on the same subnet as the interface
that is being tested:
ping <IP_address>
TROUBLESHOOTING:Some systems have
trouble supporting MSI and/or MSI-X interrupts. If you believe your
system needs to disable this style of interrupt, the driver can be built
and installed with the command:
# make CFLAGS_EXTRA=-DDISABLE_PCI_MSI
install
Normally the driver will generate an interrupt
every two seconds, so if you can see that you're no longer getting
interrupts in cat /proc/interrupts for the ethX igb device, then this
workaround may be necessary.
To build igb driver with DCA:
If your kernel supports DCA, the driver will build by
default with DCA enabled.
Command Line Parameters
If the driver is built as a module, the following optional parameters are used by entering them on the command
line with the modprobe command using this syntax:
modprobe igb
[<option>=<VAL1>,<VAL2>,...]
For example, with two Gigabit PCI
adapters, entering:
modprobe igb TxDescriptors=80,128
loads the igb driver with 80 TX descriptors for the first adapter and 128 TX
descriptors for the second adapter.
The default value for each parameter is generally the recommended setting, unless otherwise noted.
NOTES:
For more information about the AutoNeg, Duplex, and Speed parameters, see the
Speed and Duplex
Configuration section in this document.
The driver can limit the amount of interrupts per second that the adapter
will generate for incoming packets. It does this by writing a value to
the adapter that is based on the maximum amount of interrupts that the
adapter will generate per second.
Setting InterruptThrottleRate to a value greater or equal to 100
will program the adapter to send out a maximum of that many interrupts
per second, even if more packets have come in. This reduces interrupt
load on the system and can lower CPU utilization under heavy load, but
will increase latency as packets are not processed as quickly.
The default behaviour of the driver previously assumed a static
InterruptThrottleRate
value of 8000, providing a good fallback value for all traffic types,
but lacking in small packet performance and latency. The hardware can
handle many more small packets per second however, and for this reason
an adaptive interrupt moderation algorithm was implemented.
The driver has two adaptive modes (setting 1 or 3) in which
it dynamically adjusts the InterruptThrottleRate value based on the traffic that it
receives. After determining the type of incoming traffic in the last
timeframe, it will adjust the InterruptThrottleRate to an appropriate value for that
traffic.
The algorithm classifies the incoming traffic every interval into
classes. Once the class is determined, the InterruptThrottleRate value is adjusted to
suit that traffic type the best. There are three classes defined: "Bulk
traffic", for large amounts of packets of normal size; "Low latency",
for small amounts of traffic and/or a significant percentage of small
packets; and "Lowest latency", for almost completely small packets or
minimal traffic.
In dynamic conservative mode, the InterruptThrottleRate value is set to 4000 for traffic
that falls in class "Bulk traffic". If traffic falls in the "Low
latency"
or "Lowest latency" class, the InterruptThrottleRate is increased stepwise to 20000. This
default mode is suitable for most applications.
For situations where low latency is vital such as cluster or grid
computing, the algorithm can reduce latency even more when
InterruptThrottleRate is set to mode 1. In this mode, which operates
the same as mode 3, the InterruptThrottleRate will be increased stepwise to 70000 for
traffic in class "Lowest latency".
Setting InterruptThrottleRate to 0 turns off any interrupt moderation
and may improve small packet latency, but is generally not suitable
for bulk throughput traffic
NOTE:
InterruptThrottleRate takes precedence over the TxAbsIntDelay and
RxAbsIntDelay parameters. In other words, minimizing the receive and/or
transmit absolute delays does not force the controller to generate more
interrupts than what the Interrupt Throttle Rate allows.
LLIPort
0-65535
0 (disabled)
LLI (Low Latency Interrupts): LLI allows for immediate generation of an
interrupt upon processing receive packets that match certain criteria as set
by the parameters described below. LLI parameters are not enabled when
Legacy interrupts are used. You must be using MSI or MSI-X (see cat
/proc/interrupts) to successfully use LLI.
LLI is configured with the LLIPort command-line parameter, which specifies
which TCP port should generate Low Latency Interrupts.
For example, using
LLIPort=80 would cause the board to generate an immediate interrupt upon
receipt of any packet sent to TCP port 80 on the local machine.
CAUTION:
Enabling LLI can result in an excessive number of interrupts/second that may
cause problems with the system and in some cases may cause a kernel panic.
LLIPush
0-1
0 (disabled)
LLIPush can be set to be enabled or disabled (default). It is most effective
in an environment with many small transactions.
NOTE: Enabling LLIPush may allow a denial of service attack.
LLISize
0-1500
0 (disabled)
LLISize causes an immediate interrupt if the board receives a packet smaller
than the specified size.
IntMode
0-2 (0 = Legacy Int, 1 = MSI and 2 = MSI-X)
2
IntMode controls allow load time control over the type of interrupt registered for by the driver. MSI-X is required for multiple queue support, and some kernels and combinations of kernel .config options will force a lower level of interrupt support. 'cat /proc/interrupts' will show different values for each type of interrupt.
RSS
0-8
1
0 - Assign up to whichever is less, number of CPUS or number of queues
X - Assign X queues where X is less than the maximum number of queues
NOTE: for 82575-based adapters the maximum number
of queues is 4; for 82576-based and newer adapters it is 8.
This parameter is also affected by the VMDq parameter in that it will limit
the queues more.
0 - 4 on 82575-based adapters; and 0 - 8 for 82576/82580-based adapters.
0 = disabled
1 = sets the netdev as pool 0
2+ = add additional queues but they currently are not used.
0
Supports enabling VMDq pools as this is needed to support SR-IOV.
This parameter is forced to 1 or more if the max_vfs module parameter is
used. In addition the number of queues available for RSS is limited if
this is set to 1 or greater.
max_vfs
0-7
If the value is greater than 0 it will also force the VMDq parameter to be 1
or more.
0
This parameter adds support for SR-IOV. It causes the driver to spawn up to
max_vfs worth of virtual function.
QueuePairs
0-1
1 (TX and RX will be paired onto one
interrupt vector)
If set to 0, when MSI-X is enabled, the TX and RX will attempt to occupy
separate vectors.
This option can be overridden to 1 if there are not sufficient interrupts
available. This can occur if any combination of RSS, VMDQ, and max_vfs
results in more than 4 queues being used.
Node
0-n
0 - n: where n is the number of the NUMA node that
should be used to allocate memory for this adapter port.
-1: uses the
driver default of allocating memory on whichever processor is running insmod/modprobe.
-1 (off)
The Node parameter will allow you to pick which NUMA node you want to have the adapter allocate memory from. All driver structures, in-memory queues,
and receive buffers will be allocated on the node specified. This parameter is
only useful when interrupt affinity is specified, otherwise some portion of the
time the interrupt could run on a different core than the memory is allocated
on, causing slower memory access and impacting throughput, CPU, or both.
EEE
0-1
1 (enabled)
A link between two EEE-compliant devices will result in periodic bursts of data followed by periods where the link is in an idle state. This Low Power Idle (LPI) state is supported in both 1Gbps and 100Mbps link speeds.
Enables or disables DMA Coalescing feature. Values are
in usecs and increase the internal DMA Coalescing features internal timer. DMA (Direct Memory Access) allows the network device to move packet data directly to the system's memory, reducing CPU utilization. However, the frequency and random intervals at which packets arrive do not allow the system to enter a lower power state.
DMA Coalescing allows the adapter to collect packets before it initiates a DMA event. This may increase network latency but also increases the chances that the system will enter a lower power state.
Turning on DMA Coalescing may save energy with kernel 2.6.32 and later.
This will impart the greatest chance for your system to consume less power.
DMA Coalescing is effective in helping potentially saving the platform power
only when it is enabled across all active ports.
InterruptThrottleRate (ITR) should be set to dynamic. When ITR=0, DMA
Coalescing is automatically disabled.
A whitepaper containing information on how to best configure your platform is available on the Intel website.
MDD (Malicious Driver Detection)
Valid Range: 0, 1; 0 = Disable, 1 = Enable
Default Value: 1
This parameter is only relevant for I350 devices operating
in SR-IOV mode. When this parameter is set, the driver detects malicious VF
driver and disables its TX/RX queues until a VF driver reset occurs.
Additional Configurations
Configuring the Driver on Different Distributions
Configuring a network driver to load properly when the system is started
is distribution dependent. Typically, the configuration process involves
adding an alias line to /etc/modules.conf or /etc/modprobe.conf as well as editing other system
startup scripts and/or configuration files. Many popular Linux
distributions ship with tools to make these changes for you. To learn
the proper way to configure a network device for your system, refer to
your distribution documentation. If during this process you are asked
for the driver or module name, the name for the Linux Base Driver for the Gigabit
family of adapters
is e1000.
As an example, if you install the igb driver for two Gigabit adapters (eth0
and eth1) and want to set the interrupt mode to MSI-X and MSI respectively,
add the following to modules.conf or /etc/modprobe.conf:
alias eth0 igb
alias eth1 igb
options igb IntMode=2,1
Viewing Link Messages
Link messages will not be displayed to the console if the distribution is restricting system messages.
In order to see network driver link
messages on your console, set dmesg to eight by entering the following:
dmesg -n 8
NOTE: This setting is not saved across reboots.
Jumbo Frames
Jumbo Frames support is enabled by changing the
Maximum Transmission Unit (MTU) to a value larger
than the default value of 1500. Use the ifconfig command to increase the MTU size. For
example:
ifconfig eth<x> mtu 9000 up
This setting is not saved across reboots. The
setting change can be made permanent by adding MTU=9000
to the file: /etc/sysconfig/network-scripts/ifcfg-eth<x> (Red
Hat
distributions). Other distributions may store this setting in a
different location.
NOTES:
To enable Jumbo Frames,
increase the MTU size on the interface beyond 1500.
The maximum MTU setting for Jumbo Frames is
9216. This value coincides with the maximum Jumbo Frames size of
9234.
Using Jumbo frames at 10 or 100 Mbps is not supported and may result in poor performance or loss of link.
ethtool
The driver utilizes the ethtool interface for driver configuration and
diagnostics, as well as displaying statistical information. ethtool version 3
or later is required for this functionality, although we strongly recommend
downloading the latest version at:
Speed and Duplex are configured through the ethtool* utility. ethtool is
included with all versions of Red Hat after Red Hat 7.2. For other Linux
distributions, download and install ethtool from the following website:
http://ftp.kernel.org/pub/software/network/ethtool/.
Enabling Wake on LAN* (WoL)
WoL is configured through the ethtool* utility. ethtool is included with all
versions of Red Hat after Red Hat 7.2. For other Linux distributions,
download and install ethtool from the following website:
http://ftp.kernel.org/pub/software/network/ethtool/.
For instructions on enabling WoL with ethtool, refer to the website listed
above.
WoL will be enabled on the system during the next shut down or reboot. For this
driver version, in order to enable WoL, the e1000 driver must be
loaded prior to shutting down or suspending the system.
NOTES: Wake On LAN is only supported on port A of
multi-port devices.
Wake On LAN is not supported for the Intel® Gigabit
VT Quad Port Server Adapter.
Multiqueue
In this mode, a separate MSI-X vector is allocated for each queue and one for
"other" interrupts such as link status change and errors. All interrupts are
throttled via interrupt moderation. Interrupt moderation must be used to avoid
interrupt storms while the driver is processing one interrupt. The moderation
value should be at least as large as the expected time for the driver to process
an interrupt. Multiqueue is off by default.
Requirements: MSI-X support is required for Multiqueue. If MSI-X is not found, the system will
fallback to MSI or to Legacy interrupts. This driver supports multiqueue in kernel versions 2.6.24 and greater. This driver supports receive multiqueue on all kernels that support MSI-X.
NOTES: Do not use MSI-X with the 2.6.19 or 2.6.20
kernels.
On some kernels a reboot is
required to switch between a single queue mode and multiqueue modes, or
vice-versa.
LRO
Large Receive Offload (LRO) is a technique for increasing inbound throughput
of high-bandwidth network connections by reducing CPU overhead. It works by
aggregating multiple incoming packets from a single stream into a larger buffer
before they are passed higher up the networking stack, thus reducing the number
of packets that have to be processed. LRO combines multiple Ethernet frames into
a single receive in the stack, thereby potentially decreasing CPU utilization
for receives.
NOTE: LRO requires 2.4.22 or later kernel version.
IGB_LRO is a compile time flag. The user can enable it at compile time to
add support for LRO from the driver. The flag is used by adding
CFLAGS_EXTRA="-DIGB_LRO" to the make file when it's being compiled.
#
make CFLAGS_EXTRA="-DIGB_LRO" install
You can verify that the driver is using LRO by looking at these counters in
ethtool:
lro_aggregated - count of total packets that were combined
lro_flushed - counts the number of packets flushed out of LRO
lro_recycled - reflects the number of buffers returned to the ring from
recycling
NOTE: IPv6 and UDP are not supported by LRO.
MAC and VLAN anti-spoofing feature
When a malicious driver attempts to send a spoofed packet, it is dropped by
the hardware and not transmitted. An interrupt is sent to the PF driver
notifying it of the spoof attempt.
When a spoofed packet is detected the PF driver will send the following message
to the system log (displayed by the "dmesg" command):
Spoof event(s) detected on VF(n)
Where n=the VF that attempted to do the spoofing.
Setting MAC Address, VLAN and Rate Limit Using IProute2 Tool
You can set a MAC address of a Virtual Function (VF), a default VLAN and the rate limit using the IProute2 tool. Download the latest version of the iproute2 tool from Sourceforge if your version does not have all the features you require.
Known Issues
NOTE: After installing the driver, if your Intel Ethernet Network
Connection is not working, verify that you have installed the correct
driver.
Using the igb driver on 2.4 or older 2.6 based kernels
Due to limited support for PCI-Express in 2.4 kernels and older 2.6 kernels,
the igb driver may run into interrupt related problems on some systems, such as
no link or hang when bringing up the device.
We recommend the newer 2.6 based kernels, as these kernels correctly
configure the PCI-Express configuration space of the adapter and all intervening
bridges. If you are required to use a 2.4 kernel, use a 2.4 kernel newer than
2.4.30. For 2.6 kernels we recommend using the 2.6.21 kernel or newer.
Alternatively, on 2.6 kernels you may disable MSI support in the kernel by
booting with the "pci=nomsi" option or permanently disable MSI support in your
kernel by configuring your kernel with CONFIG_PCI_MSI unset.
Intel® Active Management Technology 2.0, 2.1, 2.5 not
supported in conjunction with Linux driver
Detected Tx Unit Hang in Quad Port Adapters
In some cases ports 3 and 4 don't pass traffic and report 'Detected Tx Unit
Hang' followed by 'NETDEV WATCHDOG: ethX: transmit timed out' errors. Ports 1
and 2 don't show any errors and will pass traffic.
This issue MAY be resolved by updating to the latest kernel and BIOS. The
user is encouraged to run an OS that fully supports MSI interrupts. You can
check your system's BIOS by downloading the Linux Firmware Developer Kit that
can be obtained at http://www.linuxfirmwarekit.org/
Compiling the Driver
When trying to compile the driver by running make install, the following
error may occur: "Linux kernel source not configured - missing
version.h"
To solve this issue, create the version.h file by going to the Linux source
tree and entering:
#
make include/linux/version.h
Performance Degradation with Jumbo Frames
Degradation in throughput performance may be observed in some Jumbo frames
environments. If this is observed, increasing the application's socket buffer
size and/or increasing the /proc/sys/net/ipv4/tcp_*mem entry values may help.
See the specific application manual and /usr/src/linux*/Documentation/networking/ip-sysctl.txt
for more details.
Jumbo frames on Foundry BigIron 8000 switch
There is a known issue using Jumbo frames when connected to a Foundry BigIron
8000 switch. This is a 3rd party limitation. If you experience loss of packets,
lower the MTU size.
Multiple Interfaces on Same Ethernet Broadcast Network
Due to the default ARP behavior on Linux, it is not possible to have one
system on two IP networks in the same Ethernet broadcast domain
(non-partitioned switch) behave as expected. All Ethernet interfaces will
respond to IP traffic for any IP address assigned to the system.
This results in unbalanced receive traffic.
If you have multiple interfaces in a server, either turn on ARP filtering by
entering:
echo 1 >
/proc/sys/net/ipv4/conf/all/arp_filter
(this only works if your kernel's version is higher than 2.4.5)
NOTE: This setting is not saved across reboots. The
configuration change can be made permanent by adding the line:
net.ipv4.conf.all.arp_filter = 1
to the file /etc/sysctl.conf
or,
install the interfaces in separate broadcast domains (either in different
switches or in a switch partitioned to VLANs).
Disable rx flow control with ethtool
In order to disable receive flow control using ethtool, you must turn off auto-negotiation on the same command line.
For example:
ethtool -A
eth? autoneg off rx off
Unplugging network cable while ethtool -p is running
In kernel versions 2.5.50 and later (including 2.6 kernel), unplugging the
network cable while ethtool -p is running will cause the system to
become unresponsive to keyboard commands, except for control-alt-delete.
Restarting the system appears to be the only remedy.
Trouble passing traffic with on ports 1 and 2 using RHEL3
There is a known hardware compatibility issue on some systems with RHEL3
kernels. Traffic on ports 1 and 2 may be slower than expected and ping times
higher than expected.
This issue MAY be resolved by updating to the latest kernel and BIOS. You can
check your system's BIOS by downloading the Linux Firmware Developer Kit that
can be obtained at http://www.linuxfirmwarekit.org/
Do Not Use LRO When Routing Packets
Due to a known general compatibilty issue with LRO and routing, do not use
LRO when routing packets.
Build error with Asianux 3.0 - redefinition of typedef 'irq_handler_t'
Some systems may experience build issues due to redefinition of irq_handler_t.
To resolve this issue build the driver (step 4 above) using the command:
# make CFLAGS_EXTRA=-DAX_RELEASE_CODE=1 install
MSI-X Issues with Kernels between 2.6.19 - 2.6.21 (inclusive)
Kernel panics and instability may be observed on any MSI-X hardware if you
use irqbalance with kernels between 2.6.19 and 2.6.21. If such problems are
encountered, you may disable the irqbalance daemon or upgrade to a newer kernel.
Rx Page Allocation Errors
Page allocation failure. order:0 errors may occur under stress with kernels
2.6.25 and above. This is caused by the way the Linux kernel reports this
stressed condition.
Under Redhat 5.4-GA - System May Crash when Closing Guest OS Window after
Loading/Unloading Physical Function (PF) Driver
Do not remove the igb driver from Dom0 while Virtual Functions (VFs) are
assigned to guests. VFs must first use the xm "pci-detach" command to hot-plug
the VF device out of the VM it is assigned to or else shut down the
VM.
SLES10 SP3 random system panic when reloading driver
This is a known SLES-10 SP3 issue. After requesting interrupts for MSI-X
vectors, system may panic.
Currently the only known workaround is to build the drivers with CFLAGS_EXTRA=-DDISABLE_PCI_MSI
if the driver need to be loaded/unloaded. Otherwise the driver can be loaded
once and will be safe, but unloading it will lead to the issue.
Enabling SR-IOV in a 32-bit Microsoft* Windows* Server 2008 Guest OS using
Intel® 82576-based GbE or Intel® 82599-based 10GbE controller under KVM
KVM Hypervisor/VMM supports direct assignment of a PCIe device to a VM. This
includes traditional PCIe devices, as well as SR-IOV-capable devices using Intel
82576-based and 82599-based controllers.
While direct assignment of a PCIe device or an SR-IOV Virtual Function (VF) to a
Linux-based VM running 2.6.32 or later kernel works fine, there is a known issue
with Microsoft Windows Server 2008 VM that results in a "yellow bang" error.
This problem is within the KVM VMM itself, not the Intel driver, or the SR-IOV
logic of the VMM, but rather that KVM emulates an older CPU model for the
guests, and this older CPU model does not support MSI-X interrupts, which is a
requirement for Intel SR-IOV.
If you wish to use the Intel 82576 or 82599-based controllers in SR-IOV mode
with KVM and a Microsoft Windows Server 2008 guest try the following workaround.
The workaround is to tell KVM to emulate a different model of CPU when using
qemu to create the KVM guest:
"-cpu qemu64,model=13"
Host May Reboot after Removing PF when VF is Active in Guest
Using kernel versions earlier than 3.2, do not unload the PF driver with active VFs. Doing
this will cause your VFs to stop working until you reload the PF driver and may
cause a spontaneous reboot of your system.
The Linux Base Drivers support the 2.4.x and 2.6.x kernels. These drivers includes support for Itanium®
2-based systems.
These drivers are only supported as a loadable module. Intel is not supplying
patches against the kernel source to allow for static linking of the drivers. For questions related
to hardware requirements, refer to the documentation supplied with your Intel
Gigabit adapter. All
hardware requirements listed apply to use with Linux.
The following features are now available in supported kernels:
Native VLANs
Channel Bonding (teaming)
SNMP
Channel Bonding documentation can be found in the Linux kernel source:
/documentation/networking/bonding.txt
The driver information previously displayed in the /proc file system is not
supported in this release. Alternatively, you can use ethtool (version 1.6 or
later), lspci, and ifconfig to obtain the same information. Instructions on
updating ethtool can be found in the section Additional
Configurations later in this document.
NOTE: The Intel®
82562v 10/100 Network Connection only
provides 10/100 support.
Building and Installation
To build a binary RPM* package of this driver, run 'rpmbuild -tb e1000.tar.gz'.
NOTES:
For the build to work properly, the currently running kernel
MUST match the version and configuration of the installed kernel sources. If you have just
recompiled the kernel reboot the system now.
RPM functionality has only
been tested in Red Hat distributions.
Move the base driver tar file to the directory of your
choice. For example, use '/home/username/e1000' or '/usr/local/src/e1000'.
Untar/unzip the archive, where <x.x.x> is the version number for the driver
tar file:
tar zxf e1000-<x.x.x>.tar.gz
Change to the driver src directory, where <x.x.x> is the version number for the driver
tar:
With 2.6 based kernels also make sure that older e1000 drivers are removed
from the kernel, before loading the new module:
rmmod e1000; modprobe
e1000
Assign an IP address to the interface by entering the
following, where <x> is the interface number:
ifconfig eth<x> <IP_address>
Verify that the interface works. Enter the following, where
<IP_address>
is the IP address for another machine on the same subnet as the interface
that is being tested:
ping <IP_address>
Command Line Parameters
If the driver is built as a module, the following optional parameters are used by entering them on the command
line with the modprobe command using this syntax:
modprobe e1000
[<option>=<VAL1>,<VAL2>,...]
For example, with two Gigabit PCI
adapters, entering:
modprobe e1000 TxDescriptors=80,128
loads the e1000 driver with 80 TX descriptors for the first adapter and 128 TX
descriptors for the second adapter.
The default value for each parameter is generally the recommended setting, unless otherwise noted.
NOTES:
For more information about the AutoNeg, Duplex, and Speed parameters, see the
Speed and Duplex
Configuration section in this document.
A
descriptor describes a data buffer and attributes related to the data
buffer. This information is accessed by the hardware.
Parameter Name
Valid Range/Settings
Default
Description
AutoNeg
0x01-0x0F, 0x20-0x2F
0x2F
This parameter is a bit mask that specifies which speed and duplex
settings the board advertises. When this parameter is used, the
Speed and Duplex parameters must not be specified.
This parameter is supported only on adapters using copper connections.
NOTE: Refer to the Speed and Duplex section
of this readme for more
information on the AutoNeg parameter.
Duplex
0-2 (0=auto-negotiate, 1=half, 2=full)
0
Defines the direction in which data is allowed to flow. Can be either
one or two-directional. If both Duplex and the link partner are set to auto-negotiate, the board
auto-detects the correct duplex. If the link partner is forced
(either full or half), Duplex defaults to half-duplex.
This parameter is supported only on adapters using copper connections.
FlowControl
0-3 (0=none, 1=Rx only, 2=Tx only, 3=Rx&Tx)
Read flow control settings from the EEPROM
This parameter controls the automatic generation(Tx) and
response(Rx) to Ethernet PAUSE frames.
InterruptThrottleRate
(not supported on Intel(R) 82542, 82543 or 82544-based adapters)
Valid Range: 0,1,3,4, 100-100000 (0=off, 1=dynamic, 3=dynamic conservative,
4=simplified balancing)
3
The driver can limit the amount of interrupts per second that the adapter
will generate for incoming packets. It does this by writing a value to
the adapter that is based on the maximum amount of interrupts that the
adapter will generate per second.
Setting InterruptThrottleRate to a value greater or equal to 100
will program the adapter to send out a maximum of that many interrupts
per second, even if more packets have come in. This reduces interrupt
load on the system and can lower CPU utilization under heavy load, but
will increase latency as packets are not processed as quickly.
The default behaviour of the driver previously assumed a static
InterruptThrottleRate
value of 8000, providing a good fallback value for all traffic types,
but lacking in small packet performance and latency. The hardware can
handle many more small packets per second however, and for this reason
an adaptive interrupt moderation algorithm was implemented.
Since 7.3.x, the driver has two adaptive modes (setting 1 or 3) in which
it dynamically adjusts the InterruptThrottleRate value based on the traffic that it
receives. After determining the type of incoming traffic in the last
timeframe, it will adjust the InterruptThrottleRate to an appropriate value for that
traffic.
The algorithm classifies the incoming traffic every interval into
classes. Once the class is determined, the InterruptThrottleRate value is adjusted to
suit that traffic type the best. There are three classes defined: "Bulk
traffic", for large amounts of packets of normal size; "Low latency",
for small amounts of traffic and/or a significant percentage of small
packets; and "Lowest latency", for almost completely small packets or
minimal traffic.
In dynamic conservative mode, the InterruptThrottleRate value is set to 4000 for traffic
that falls in class "Bulk traffic". If traffic falls in the "Low
latency"
or "Lowest latency" class, the InterruptThrottleRate is increased stepwise to 20000. This
default mode is suitable for most applications.
For situations where low latency is vital such as cluster or grid
computing, the algorithm can reduce latency even more when
InterruptThrottleRate is set to mode 1. In this mode, which operates
the same as mode 3, the InterruptThrottleRate will be increased stepwise to 70000 for
traffic in class "Lowest latency".
In simplified mode the
interrupt rate is based on the ratio of tx and rx traffic. If the bytes
per second rate is approximately equal, the interrupt rate will drop as
low as 2000 interrupts per second. If the traffic is mostly transmit or
mostly receive, the interrupt rate could
be as high as 8000.
Setting InterruptThrottleRate to 0 turns off any interrupt moderation
and may improve small packet latency, but is generally not suitable
for bulk throughput traffic
NOTE:
InterruptThrottleRate takes precedence over the TxAbsIntDelay and
RxAbsIntDelay parameters. In other words, minimizing the receive and/or
transmit absolute delays does not force the controller to generate more
interrupts than what the Interrupt Throttle Rate allows.
CAUTION:
If you are using the Intel(R) PRO/1000 CT Network Connection (controller
82547), setting InterruptThrottleRate to a value greater than 75,000,
may hang (stop transmitting) adapters
under certain network conditions. If this occurs a NETDEV
WATCHDOG message is logged in the system event log. In
addition, the controller is automatically reset, restoring the network
connection. To eliminate the potential for the hang, ensure that
InterruptThrottleRate is set no greater than 75,000 and is not set to 0.
NOTE:
When e1000 is loaded with default settings and multiple adapters are in
use simultaneously, the CPU utilization may increase non-linearly. In
order to limit the CPU utilization without impacting
the overall throughput, we recommend that you load the driver as
follows:
This sets the InterruptThrottleRate to 3000 interrupts/sec for the first,
second, and third instances of the driver. The range of 2000 to 3000
interrupts per second works on a majority of systems and is a good
starting point, but the optimal value will be platform-specific. If CPU
utilization is not a concern, use RX_POLLING (NAPI) and default driver
settings.
RxDescriptors
80-4096
256
This value specifies the number of receive buffer descriptors allocated
by the driver. Increasing this value allows the driver to buffer more
incoming packets, at the expense of increased system memory utilization.
Each descriptor is 16 bytes. A receive buffer is also allocated for each
descriptor and can be either 2048, 4096, 8192, or 16384 bytes, depending
on the MTU setting. The maximum MTU size is 16110.
NOTE:
MTU designates the frame size. It only needs to be set for Jumbo Frames.
Depending on the available system resources, the request for a higher
number of receive descriptors may be denied. In this case, use a lower
number.
RxIntDelay
0-65535 (0=off)
0
This value delays the generation of receive interrupts in units of
1.024 microseconds. Receive interrupt reduction can improve CPU
efficiency if properly tuned for specific network traffic.
Increasing this value adds extra latency to frame reception
and can end up decreasing the throughput of TCP traffic. If the system is
reporting dropped receives, this value may be set too high, causing the
driver to run out of available receive descriptors.
CAUTION: When setting RxIntDelay to a value other than 0,
adapters may
hang (stop transmitting) under certain network conditions. If
this occurs a NETDEV WATCHDOG message is logged in the system event log. In
addition, the controller is automatically reset, restoring the
network connection. To eliminate the potential for the hang
ensure that RxIntDelay is set to zero.
RxAbsIntDelay
0-65535 (0=off)
8
This value, in units of 1.024 microseconds, limits the delay in which a
receive interrupt is generated. Useful only if RxIntDelay is non-zero,
this value ensures that an interrupt is generated after the initial
packet is received within the set amount of time. Proper tuning,
along with RxIntDelay, may improve traffic throughput in specific
network conditions.
This parameter is supported only on 82540, 82545 and later adapters.
Speed
0, 10, 100, 1000
0
Speed forces the line speed to the specified value in megabits per second (Mbps). If this parameter
is not specified or is set to 0 and the link partner is set to auto-negotiate, the board
will auto-detect the correct speed. Duplex must also be set when Speed is set to either 10 or 100.
This parameter is supported only on adapters using copper connections.
TxDescriptors
80-4096
256
This value is the number of transmit descriptors allocated by the
driver. Increasing this value allows the driver to queue more
transmits. Each descriptor is 16 bytes.
TxDescriptorStep
1 (use every Tx Descriptor)
4 (use every 4th Tx Descriptor)
1 (use every Tx Descriptor)
On certain non-Intel architectures, it has been observed that intense TX
traffic bursts of short packets may result in an improper descriptor
writeback. If this occurs, the driver will report a "TX Timeout" and reset
the adapter, after which the transmit flow will restart, though data may
have stalled for as much as 10 seconds before it resumes.
The improper writeback does not occur on the first descriptor in a system
memory cache-line, which is typically 32 bytes, or 4 descriptors long.
Setting TxDescriptorStep to a value of 4 will ensure that all TX descriptors
are aligned to the start of a system memory cache line, and so this problem
will not occur.
NOTES:
Setting TxDescriptorStep to 4 effectively reduces the number of
TxDescriptors available for transmits to 1/4 of the normal allocation. This
has a possible negative performance impact, which may be compensated for by
allocating more descriptors using the TxDescriptors module parameter.
There are other conditions which may result in "TX Timeout", which will not
be resolved by the use of the TxDescriptorStep parameter. As the issue
addressed by this parameter has never been observed on Intel Architecture
platforms, it should not be used on Intel platforms.
TxIntDelay
0-65535 (0=off)
8
This value delays the generation of transmit interrupts in units of 1.024
microseconds. Transmit interrupt reduction can improve CPU efficiency if
properly tuned for specific network traffic. If the system is reporting
dropped transmits, this value may be set too high causing the driver to run
out of available transmit descriptors.
TxAbsIntDelay
0-65535 (0=off)
32
This value, in units of 1.024 microseconds, limits the delay in which a transmit
interrupt is generated. Useful only if TxIntDelay is non-zero, this value
ensures that an interrupt is generated after the initial packet is sent on
the wire within the set amount of time. Proper tuning, along with TxIntDelay,
may improve traffic throughput in specific network conditions.
This parameter is supported only on 82540, 82545 and later adapters.
XsumRX
0-1
1
A value of '1' indicates that the driver should enable IP checksum
offload for received packets (both UDP and TCP) to the adapter
hardware.
This parameter is not supported on the 82542-based adapter.
Copybreak
0-xxxxxxx (0=off)
256
Usage: insmod e1000.ko copybreak=128
Driver copies all packets below or equaling this size to a fresh rx buffer
before handing it up the stack.
This parameter is different than other parameters, in that it is a single
(not 1,1,1 etc.) parameter applied to all driver instances and it is also
available during runtime at /sys/module/e1000/parameters/copybreak
SmartPowerDownEnable
0-1
0 (disabled)
Allows Phy to turn off in lower power states. The user can turn off
this parameter in supported chipsets.
KumeranLockLoss
0-1
1 (enabled)
This workaround skips resetting the Phy at shutdown for the initial
silicon releases of ICH8 systems.
TxDescPower
6-12
12
This value represents the size-order of each transmit descriptor. The valid
size for descriptors would be 2^6 (64) to 2^12 (4096) bytes each. As this
value decreases one may want to consider increasing the TxDescriptors value
to maintain the same amount of frame memory.
Speed and Duplex Configuration
Three keywords are used to control the speed and duplex configuration. These keywords are Speed,
Duplex, and AutoNeg.
If the board uses a fiber interface, these keywords are ignored, and the fiber interface board only links at 1000 Mbps full-duplex.
For copper-based boards, the keywords interact as follows:
The default operation is auto-negotiate. The board advertises all supported
speed and duplex combinations, and it links at the highest common speed and
duplex mode IF the link partner is set to auto-negotiate.
If Speed = 1000, limited auto-negotiation is enabled and only 1000 Mbps is
advertised (The 1000BaseT spec requires auto-negotiation.)
If Speed = 10 or 100, then both Speed and Duplex should be set. Auto-negotiation is disabled,
and the AutoNeg parameter is ignored. Partner SHOULD also be forced.
The AutoNeg parameter is used when more control is required over the
auto-negotiation process. It should be used when you wish to control which speed
and duplex combinations are advertised during the auto-negotiation process.
The parameter may be specified as either a decimal or hexadecimal value as
determined by the bitmap below.
Bit Position
7
6
5
4
3
2
1
0
Decimal Value
128
64
32
16
8
4
2
1
Hex Value
80
40
20
10
8
4
2
1
Speed (Mbps):
N/A
N/A
1000
N/A
100
100
10
10
Duplex:
Full
Full
Half
Full
Half
Some examples of using AutoNeg:
modprobe e1000 AutoNeg=0x01 (Restricts autonegotiation to 10 Half)
modprobe e1000 AutoNeg=1 (Same as above)
modprobe e1000 AutoNeg=0x02 (Restricts autonegotiation to 10 Full)
modprobe e1000 AutoNeg=0x03 (Restricts autonegotiation to 10 Half or 10 Full)
modprobe e1000 AutoNeg=0x04 (Restricts autonegotiation to 100 Half)
modprobe e1000 AutoNeg=0x05 (Restricts autonegotiation to 10 Half or 100 Half)
modprobe e1000 AutoNeg=0x020 (Restricts autonegotiation to 1000 Full)
modprobe e1000 AutoNeg=32 (Same as above)
Note that when this parameter is used, Speed and Duplex must not be specified.
If the link partner is forced to a specific speed and duplex, then this
parameter should not be used. Instead, use the Speed and Duplex parameters
previously mentioned to force the adapter to the same speed and duplex.
Additional Configurations
Configuring the Driver on Different Distributions
Configuring a network driver to load properly when the system is started
is distribution dependent. Typically, the configuration process involves
adding an alias line to /etc/modules.conf or /etc/modprobe.conf as well as editing other system
startup scripts and/or configuration files. Many popular Linux
distributions ship with tools to make these changes for you. To learn
the proper way to configure a network device for your system, refer to
your distribution documentation. If during this process you are asked
for the driver or module name, the name for the Linux Base Driver for the Gigabit
family of adapters
is e1000.
As an example, if you install the e1000 driver for two Gigabit adapters
(eth0 and eth1) and set the speed and duplex to 10full and 100half, add the
following to modules.conf or /etc/modprobe.conf:
alias eth0 e1000
alias eth1 e1000
options e1000 Speed=10,100 Duplex=2,1
Viewing Link Messages
Link messages will not be displayed to the console if the distribution is restricting system messages.
In order to see network driver link
messages on your console, set dmesg to eight by entering the following:
dmesg -n 8
NOTE: This setting is not saved across reboots.
Jumbo Frames
Jumbo Frames support is enabled by changing the
Maximum Transmission Unit (MTU) to a value larger
than the default value of 1500. Use the ifconfig command to increase the MTU size. For
example:
ifconfig eth<x> mtu 9000 up
This setting is not saved across reboots. The
setting change can be made permanent by adding MTU=9000
to the file: /etc/sysconfig/network-scripts/ifcfg-eth<x> (Red
Hat
distributions). Other distributions may store this setting in a
different location.
NOTES:
To enable Jumbo Frames,
increase the MTU size on the interface beyond 1500.
The maximum MTU setting for Jumbo Frames is
16110. This value coincides with the maximum Jumbo Frames size of
16128.
Some Intel gigabit adapters that support Jumbo Frames
have a frame size limit of 9238 bytes, with a corresponding MTU size
limit of 9216 bytes. The adapters with this limitation are based on the
Intel® 82571EB, 82572EI, 82573L, 82566, 82562, 82575, and 80003ES2LAN controllers.
These correspond to the following product names: Intel® PRO/1000 PT Server Adapter Intel® PRO/1000 PT Desktop Adapter Intel® PRO/1000 PT Network Connection Intel® PRO/1000 PT Dual Port Server Adapter Intel® PRO/1000 PT Dual Port Network Connection Intel® PRO/1000 PF Server Adapter Intel® PRO/1000 PF Network Connection Intel® PRO/1000 PF Dual Port Server Adapter Intel® PRO/1000 PB Server Connection Intel® PRO/1000 PL Network Connection Intel® PRO/1000 EB Network Connection with I/O Acceleration Intel® PRO/1000 EB Backplane Connection with I/O Acceleration
Intel® PRO/1000 PT Quad Port Server Adapter Intel® PRO/1000 PF Quad Port Server Adapter Intel® 82566DM-2 Gigabit Network Connection Intel®
Gigabit PT Quad Port Server ExpressModule
Using Jumbo frames at 10 or 100 Mbps is not supported and may result in poor performance or loss of link.
The driver utilizes the ethtool interface for driver configuration and
diagnostics, as well as displaying statistical information. ethtool version 3
or later is required for this functionality, although we strongly recommend
downloading the latest version at:
WoL is configured through the ethtool* utility. ethtool is included with all
versions of Red Hat after Red Hat 7.2. For other Linux distributions,
download and install ethtool from the following website:
http://ftp.kernel.org/pub/software/network/ethtool/.
For instructions on enabling WoL with ethtool, refer to the website listed
above.
WoL will be enabled on the system during the next shut down or reboot. For this
driver version, in order to enable WoL, the e1000 driver must be
loaded prior to shutting down or suspending the system.
NOTES: Wake On LAN is only supported on port A for the
following devices:
Intel® PRO/1000 PT Dual Port Network Connection
Intel® PRO/1000 PT Dual Port Server Connection
Intel® PRO/1000 PT Dual Port Server Adapter
Intel® PRO/1000 PF Dual Port Server Adapter
Intel PRO/1000 PT Quad Port Server Adapter
Intel® Gigabit PT Quad Port Server ExpressModule
NAPI
NAPI (Rx polling mode) is supported in the e1000 driver. NAPI is enabled or
disabled based on the configuration of the kernel. To override the
default, use the following compile-time flags.
To enable NAPI, compile the driver module, passing in a configuration option:
# make CFLAGS_EXTRA=-DE1000_NAPI install
To disable NAPI, compile the driver module, passing in a configuration
option:
NOTE: After installing the driver, if your Intel Ethernet Network
Connection is not working, verify that you have installed the correct
driver.
Intel® Active Management Technology 2.0, 2.1, 2.5 not
supported in conjunction with Linux driver
Detected Tx Unit Hang in Quad Port Adapters
In some cases ports 3 and 4 don't pass traffic and report 'Detected Tx Unit
Hang' followed by 'NETDEV WATCHDOG: ethX: transmit timed out' errors. Ports 1
and 2 don't show any errors and will pass traffic.
This issue MAY be resolved by updating to the latest kernel and BIOS. The
user is encouraged to run an OS that fully supports MSI interrupts. You can
check your system's BIOS by downloading the Linux Firmware Developer Kit that
can be obtained at http://www.linuxfirmwarekit.org/
82573(V/L/E) TX Unit Hang Messages
Several adapters with the 82573 chipset display "TX unit
hang" messages during normal operation with the e1000 driver.
The issue appears both with TSO enabled and disabled, and is
caused by a power management function that is enabled in the
EEPROM. Early releases of the chipsets to vendors had the EEPROM
bit that enabled the feature. After the issue was discovered
newer adapters were released with the feature disabled in the
EEPROM.
If you encounter the problem in an adapter, and the chipset
is an 82573-based one, you can verify that your adapter needs
the fix by using ethtool:
The value at offset 0x001e (de) has bit 0 unset. This enables
the problematic power saving feature. In this case, the EEPROM
needs to read "df" at offset 0x001e.
A one-time EEPROM fix is available as a shell script. This
script will verify that the adapter is applicable to the fix and
if the fix is needed or not. If the fix is required, it applies
the change to the EEPROM and updates the checksum. The user must
reboot the system after applying the fix if changes were made to
the EEPROM.
Example output of the script:
# bash fixeep-82573-dspd.sh eth0
eth0: is a "82573E Gigabit Ethernet Controller"
This fixup is applicable to your hardware
executing command: ethtool -E eth0 magic 0x109a8086 offset 0x1e value 0xdf
Change made. You *MUST* reboot your machine before changes take effect!
Dropped Receive Packets on Half-duplex 10/100 Networks
If you have an Intel PCI Express adapter running at 10mbps or 100mbps,
half-duplex, you may observe occasional
dropped receive packets. There are no workarounds for this problem in this
network configuration. The network must be updated to operate in full-duplex,
and/or 1000mbps only.
Compiling the Driver
When trying to compile the driver by running make install, the following
error may occur: "Linux kernel source not configured - missing
version.h"
To solve this issue, create the version.h file by going to the Linux source
tree and entering:
#
make include/linux/version.h
Performance Degradation with Jumbo Frames
Degradation in throughput performance may be observed in some Jumbo frames
environments. If this is observed, increasing the application's socket buffer
size and/or increasing the /proc/sys/net/ipv4/tcp_*mem entry values may help.
See the specific application manual and /usr/src/linux*/Documentation/networking/ip-sysctl.txt
for more details.
Jumbo frames on Foundry BigIron 8000 switch
There is a known issue using Jumbo frames when connected to a Foundry BigIron
8000 switch. This is a 3rd party limitation. If you experience loss of packets,
lower the MTU size.
Allocating Rx Buffers when Using Jumbo Frames
Allocating Rx buffers when using Jumbo Frames on 2.6.x kernels may fail if
the available memory is heavily fragmented. This issue may be seen with PCI-X
adapters or with packet split disabled. This can be reduced or eliminated by
changing the amount of available memory for receive buffer allocation, by
increasing /proc/sys/vm/min_free_kbytes.
Multiple Interfaces on Same Ethernet Broadcast Network
Due to the default ARP behavior on Linux, it is not possible to have one
system on two IP networks in the same Ethernet broadcast domain
(non-partitioned switch) behave as expected. All Ethernet interfaces will
respond to IP traffic for any IP address assigned to the system.
This results in unbalanced receive traffic.
If you have multiple interfaces in a server, either turn on ARP filtering by
entering:
echo 1 >
/proc/sys/net/ipv4/conf/all/arp_filter
(this only works if your kernel's version is higher than 2.4.5)
NOTE: This setting is not saved across reboots. The
configuration change can be made permanent by adding the line:
net.ipv4.conf.all.arp_filter = 1
to the file /etc/sysctl.conf
or,
install the interfaces in separate broadcast domains (either in different
switches or in a switch partitioned to VLANs).
82541/82547 can't link or is slow to link with some link partners
There is a known compatibility issue with 82541/82547 and some low-end
switches where the link will not be established, or will
be slow to establish. In particular, these switches are known to be incompatible
with 82541/82547:
Planex FXG-08TE
I-O Data ETG-SH8
To workaround this issue, the driver can be compiled with an override of the
PHY's master/slave setting. Forcing master or forcing slave
mode will improve time-to-link.
In order to disable receive flow control using ethtool, you must turn off auto-negotiation on the same command line.
For example:
ethtool -A
eth? autoneg off rx off
Unplugging network cable while ethtool -p is running
In kernel versions 2.5.50 and later (including 2.6 kernel), unplugging the
network cable while ethtool -p is running will cause the system to
become unresponsive to keyboard commands, except for control-alt-delete.
Restarting the system appears to be the only remedy.
The Linux Base Drivers support the 2.4.x and 2.6.x kernels. These drivers includes support for Itanium®
2-based systems.
These drivers are only supported as a loadable module. Intel is not supplying
patches against the kernel source to allow for static linking of the drivers. For questions related
to hardware requirements, refer to the documentation supplied with your Intel
Gigabit adapter. All
hardware requirements listed apply to use with Linux.
The following features are now available in supported kernels:
Native VLANs
Channel Bonding (teaming)
SNMP
Channel Bonding documentation can be found in the Linux kernel source:
/documentation/networking/bonding.txt
The driver information previously displayed in the /proc file system is not
supported in this release. Alternatively, you can use ethtool (version 1.6 or
later), lspci, and ifconfig to obtain the same information. Instructions on
updating ethtool can be found in the section Additional
Configurations later in this document.
NOTE: The Intel®
82562v 10/100 Network Connection only
provides 10/100 support.
Building and Installation
To build a binary RPM* package of this driver, run 'rpmbuild -tb e1000e.tar.gz'.
NOTES:
For the build to work properly, the currently running kernel
MUST match the version and configuration of the installed kernel sources. If you have just
recompiled the kernel reboot the system now.
RPM functionality has only
been tested in Red Hat distributions.
Move the base driver tar file to the directory of your
choice. For example, use '/home/username/e1000e' or '/usr/local/src/e1000e'.
Untar/unzip the archive, where <x.x.x> is the version number for the driver
tar file:
tar zxf e1000e-<x.x.x>.tar.gz
Change to the driver src directory, where <x.x.x> is the version number for the driver
tar:
With 2.6 based kernels also make sure that older e1000e drivers are removed
from the kernel, before loading the new module:
rmmod e1000e; modprobe
e1000e
Assign an IP address to the interface by entering the
following, where <x> is the interface number:
ifconfig eth<x> <IP_address>
Verify that the interface works. Enter the following, where
<IP_address>
is the IP address for another machine on the same subnet as the interface
that is being tested:
ping <IP_address>
TROUBLESHOOTING:Some systems have
trouble supporting MSI and/or MSI-X interrupts. If you believe your
system needs to disable this style of interrupt, the driver can be built
and installed with the command:
# make CFLAGS_EXTRA=-DDISABLE_PCI_MSI
install
Normally the driver will generate an interrupt
every two seconds, so if you can see that you're no longer getting
interrupts in cat /proc/interrupts for the ethX e1000e device, then this
workaround may be necessary.
Command Line Parameters
If the driver is built as a module, the following optional parameters are used by entering them on the command
line with the modprobe command using this syntax:
modprobe e1000e
[<option>=<VAL1>,<VAL2>,...]
The default value for each parameter is generally the recommended setting, unless otherwise noted.
The driver can limit the amount of interrupts per second that the adapter
will generate for incoming packets. It does this by writing a value to
the adapter that is based on the maximum amount of interrupts that the
adapter will generate per second.
Setting InterruptThrottleRate to a value greater or equal to 100
will program the adapter to send out a maximum of that many interrupts
per second, even if more packets have come in. This reduces interrupt
load on the system and can lower CPU utilization under heavy load, but
will increase latency as packets are not processed as quickly.
The default behavior of the driver previously assumed a static
InterruptThrottleRate value of 8000, providing a good fallback value for
all traffic types, but lacking in small packet performance and latency.
The driver has two adaptive modes (setting 1 or 3) in which
it dynamically adjusts the InterruptThrottleRate value based on the traffic that it
receives. After determining the type of incoming traffic in the last
timeframe, it will adjust the InterruptThrottleRate to an appropriate value for that
traffic.
The algorithm classifies the incoming traffic every interval into
classes. Once the class is determined, the InterruptThrottleRate value is adjusted to
suit that traffic type the best. There are three classes defined: "Bulk
traffic", for large amounts of packets of normal size; "Low latency",
for small amounts of traffic and/or a significant percentage of small
packets; and "Lowest latency", for almost completely small packets or
minimal traffic.
In dynamic conservative mode, the InterruptThrottleRate value is set to 4000 for traffic
that falls in class "Bulk traffic". If traffic falls in the "Low
latency"
or "Lowest latency" class, the InterruptThrottleRate is increased stepwise to 20000. This
default mode is suitable for most applications.
For situations where low latency is vital such as cluster or grid
computing, the algorithm can reduce latency even more when
InterruptThrottleRate is set to mode 1. In this mode, which operates
the same as mode 3, the InterruptThrottleRate will be increased stepwise to 70000 for
traffic in class "Lowest latency".
In simplified mode the
interrupt rate is based on the ratio of tx and rx traffic. If the bytes
per second rate is approximately equal, the
interrupt rate will drop as low as 2000 interrupts per second. If the
traffic is mostly transmit or mostly receive, the interrupt rate could
be as high as 8000.
Setting InterruptThrottleRate to 0 turns off any interrupt moderation
and may improve small packet latency, but is generally not suitable
for bulk throughput traffic
NOTE:
InterruptThrottleRate takes precedence over the TxAbsIntDelay and
RxAbsIntDelay parameters. In other words, minimizing the receive and/or
transmit absolute delays does not force the controller to generate more
interrupts than what the Interrupt Throttle Rate allows.
NOTE:
When e1000e is loaded with default settings and multiple adapters are in
use simultaneously, the CPU utilization may increase non-linearly. In
order to limit the CPU utilization without impacting
the overall throughput, we recommend that you load the driver as
follows:
This sets the InterruptThrottleRate to 3000 interrupts/sec for the first,
second, and third instances of the driver. The range of 2000 to 3000
interrupts per second works on a majority of systems and is a good
starting point, but the optimal value will be platform-specific. If CPU
utilization is not a concern, use RX_POLLING (NAPI) and default driver
settings.
RxIntDelay
0-65535 (0=off)
0
This value delays the generation of receive interrupts in units of
1.024 microseconds. Receive interrupt reduction can improve CPU
efficiency if properly tuned for specific network traffic.
Increasing this value adds extra latency to frame reception
and can end up decreasing the throughput of TCP traffic. If the system is
reporting dropped receives, this value may be set too high, causing the
driver to run out of available receive descriptors.
CAUTION: When setting RxIntDelay to a value other than 0,
adapters may
hang (stop transmitting) under certain network conditions. If
this occurs a NETDEV WATCHDOG message is logged in the system event log. In
addition, the controller is automatically reset, restoring the
network connection. To eliminate the potential for the hang
ensure that RxIntDelay is set to zero.
RxAbsIntDelay
0-65535 (0=off)
8
This value, in units of 1.024 microseconds, limits the delay in which a
receive interrupt is generated. Useful only if RxIntDelay is non-zero,
this value ensures that an interrupt is generated after the initial
packet is received within the set amount of time. Proper tuning,
along with RxIntDelay, may improve traffic throughput in specific
network conditions.
TxIntDelay
0-65535 (0=off)
8
This value delays the generation of transmit interrupts in units of 1.024
microseconds. Transmit interrupt reduction can improve CPU efficiency if
properly tuned for specific network traffic. If the system is reporting
dropped transmits, this value may be set too high causing the driver to run
out of available transmit descriptors.
TxAbsIntDelay
0-65535 (0=off)
32
This value, in units of 1.024 microseconds, limits the delay in which a transmit
interrupt is generated. Useful only if TxIntDelay is non-zero, this value
ensures that an interrupt is generated after the initial packet is sent on
the wire within the set amount of time. Proper tuning, along with TxIntDelay,
may improve traffic throughput in specific network conditions.
copybreak
0-xxxxxxx (0=off)
256
Usage: insmod e1000e.ko copybreak=128
Driver copies all packets below or equaling this size to a fresh rx buffer
before handing it up the stack.
This parameter is different than other parameters, in that it is a single
(not 1,1,1 etc.) parameter applied to all driver instances and it is also
available during runtime at /sys/module/e1000e/parameters/copybreak
SmartPowerDownEnable
0-1
0 (disabled)
Allows Phy to turn off in lower power states. The user can turn off
this parameter in supported chipsets.
KumeranLockLoss
0-1
1 (enabled)
This workaround skips resetting the Phy at shutdown for the initial
silicon releases of ICH8 systems.
IntMode
0-2
(0=legacy, 1=MSI, 2=MSI-X)
2 (MSI-X)
Allows changing the interrupt mode at module load time, without requiring a
recompile. If the driver load fails to enable a specific interrupt mode, the
driver will try other interrupt modes, from least to most compatible. The
interrupt order is MSI-X, MSI, Legacy. If specifying MSI (IntMode=1)
interrupts, only MSI and Legacy will be attempted.
CrcStripping
0-1
1 (enabled)
Strip the CRC from received packets before sending up the network stack. If
you have a machine with a BMC enabled but cannot receive IPMI traffic after
loading or enabling the driver, try disabling this feature.
EEE
0-1
1 (enabled for parts supporting EEE)
This option allows for the ability of IEEE802.3az (a.k.a. Energy Efficient
Ethernet or EEE) to be advertised to the link partner on parts supporting
EEE. EEE saves energy by putting the device into a low-power state when the
link is idle, but only when the link partner also supports EEE and after the
feature has been enabled during link negotiation. It is not necessary to
disable the advertisement of EEE when connected with a link partner that
does not support EEE.
Node
0-n
0 - n: where n is the number of the NUMA node that
should be used to allocate memory for this adapter port.
-1: uses the
driver default of allocating memory on whichever processor is running insmod/modprobe.
-1 (off)
The Node parameter will allow you to pick which NUMA node you want to have the adapter allocate memory from. All driver structures, in-memory queues,
and receive buffers will be allocated on the node specified. This parameter is
only useful when interrupt affinity is specified, otherwise some portion of the
time the interrupt could run on a different core than the memory is allocated
on, causing slower memory access and impacting throughput, CPU, or both.
Additional Configurations
Configuring the Driver on Different Distributions
Configuring a network driver to load properly when the system is started
is distribution dependent. Typically, the configuration process involves
adding an alias line to /etc/modules.conf or /etc/modprobe.conf as well as editing other system
startup scripts and/or configuration files. Many popular Linux
distributions ship with tools to make these changes for you. To learn
the proper way to configure a network device for your system, refer to
your distribution documentation. If during this process you are asked
for the driver or module name, the name for the Linux Base Driver for the Gigabit
family of adapters
is e1000e.
As an example, if you install the e1000e driver for two Gigabit adapters
(eth0 and eth1) and want to set the interrupt mode to MSI-X and MSI
respectively, add the following to modules.conf or /etc/modprobe.conf:
alias eth0 e1000e
alias eth1 e1000e
options e1000e IntMode=2,1
Viewing Link Messages
Link messages will not be displayed to the console if the distribution is restricting system messages.
In order to see network driver link
messages on your console, set dmesg to eight by entering the following:
dmesg -n 8
NOTE: This setting is not saved across reboots.
Jumbo Frames
Jumbo Frames support is enabled by changing the
Maximum Transmission Unit (MTU) to a value larger
than the default value of 1500. Use the ifconfig command to increase the MTU size. For
example:
ifconfig eth<x> mtu 9000 up
This setting is not saved across reboots. The
setting change can be made permanent by adding MTU=9000
to the file: /etc/sysconfig/network-scripts/ifcfg-eth<x> (Red
Hat
distributions). Other distributions may store this setting in a
different location.
NOTES:
To enable Jumbo Frames,
increase the MTU size on the interface beyond 1500.
The maximum MTU setting for Jumbo Frames is 9216. This
value coincides with the maximum Jumbo Frames size of 9234 bytes.
Using Jumbo frames at 10 or 100 Mbps is not supported and may result in poor performance or loss of link.
The following adapters limit Jumbo Frames sized
packets to a maximum of 4088 bytes:
Intel® 82578DM Gigabit Network Connection
Intel® 82577LM Gigabit Network Connection
Jumbo Frames cannot be configured on an 82579-based
Network device, if MACSec is enabled on the system.
ethtool
The driver utilizes the ethtool interface for driver configuration and
diagnostics, as well as displaying statistical information. ethtool version 3
or later is required for this functionality, although we strongly recommend
downloading the latest version at:
NOTE: When validating enable/disable tests on some parts (82578, for example) you need to add a few seconds between tests when working with ethtool.
Speed and Duplex Configuration
Speed and Duplex are configured through the ethtool* utility. ethtool is
included with all versions of Red Hat after Red Hat 7.2. For other Linux
distributions, download and install ethtool from the following website:
http://ftp.kernel.org/pub/software/network/ethtool/.
Enabling Wake on LAN* (WoL)
WoL is configured through the ethtool* utility. ethtool is included with all
versions of Red Hat after Red Hat 7.2. For other Linux distributions,
download and install ethtool from the following website:
http://ftp.kernel.org/pub/software/network/ethtool/.
For instructions on enabling WoL with ethtool, refer to the website listed
above.
WoL will be enabled on the system during the next shut down or reboot. For this
driver version, in order to enable WoL, the e1000e driver must be
loaded prior to shutting down or suspending the system.
NOTES: Wake On LAN is only supported on port A for the
following devices:
Intel® PRO/1000 PT Dual Port Network Connection
Intel® PRO/1000 PT Dual Port Server Connection
Intel® PRO/1000 PT Dual Port Server Adapter
Intel® PRO/1000 PF Dual Port Server Adapter
Intel PRO/1000 PT Quad Port Server Adapter
Intel® Gigabit PT Quad Port Server ExpressModule
NAPI
NAPI (Rx polling mode) is supported in the e1000e driver. NAPI is enabled by
default.
To disable NAPI, compile the driver module, passing in a configuration
option:
NOTE: After installing the driver, if your Intel Network
Connection is not working, verify that you have installed the correct
driver.
Intel® Active Management Technology 2.0, 2.1, 2.5 not
supported in conjunction with Linux driver
Detected Tx Unit Hang in Quad Port Adapters
In some cases ports 3 and 4 don't pass traffic and report 'Detected Tx Unit
Hang' followed by 'NETDEV WATCHDOG: ethX: transmit timed out' errors. Ports 1
and 2 don't show any errors and will pass traffic.
This issue MAY be resolved by updating to the latest kernel and BIOS. The
user is encouraged to run an OS that fully supports MSI interrupts. You can
check your system's BIOS by downloading the Linux Firmware Developer Kit that
can be obtained at http://www.linuxfirmwarekit.org/
Adapters with 4 ports behind a PCIe bridge
Adapters that have 4 ports behind a PCIe bridge may be incompatible with some
systems. The user should run the Linux firmware kit from http://www.linuxfirmwarekit.org/ to test their BIOS, if they have interrupt or "missing
interface" problems, especially with older kernels.
82573(V/L/E) TX Unit Hang Messages
Several adapters with the 82573 chipset display "TX unit
hang" messages during normal operation with the e1000e driver.
The issue appears both with TSO enabled and disabled, and is
caused by a power management function that is enabled in the
EEPROM. Early releases of the chipsets to vendors had the EEPROM
bit that enabled the feature. After the issue was discovered
newer adapters were released with the feature disabled in the
EEPROM.
If you encounter the problem in an adapter, and the chipset
is an 82573-based one, you can verify that your adapter needs
the fix by using ethtool:
The value at offset 0x001e (de) has bit 0 unset. This enables
the problematic power saving feature. In this case, the EEPROM
needs to read "df" at offset 0x001e.
A one-time EEPROM fix is available as a shell script. This
script will verify that the adapter is applicable to the fix and
if the fix is needed or not. If the fix is required, it applies
the change to the EEPROM and updates the checksum. The user must
reboot the system after applying the fix if changes were made to
the EEPROM.
Example output of the script:
# bash fixeep-82573-dspd.sh eth0
eth0: is a "82573E Gigabit Ethernet Controller"
This fixup is applicable to your hardware
executing command: ethtool -E eth0 magic 0x109a8086 offset 0x1e value 0xdf
Change made. You *MUST* reboot your machine before changes take effect!
Dropped Receive Packets on Half-duplex 10/100 Networks
If you have an Intel PCI Express adapter running at 10mbps or 100mbps,
half-duplex, you may observe occasional
dropped receive packets. There are no workarounds for this problem in this
network configuration. The network must be updated to operate in full-duplex,
and/or 1000mbps only.
Compiling the Driver
When trying to compile the driver by running make install, the following
error may occur: "Linux kernel source not configured - missing
version.h"
To solve this issue, create the version.h file by going to the Linux source
tree and entering:
#
make include/linux/version.h
Performance Degradation with Jumbo Frames
Degradation in throughput performance may be observed in some Jumbo frames
environments. If this is observed, increasing the application's socket buffer
size and/or increasing the /proc/sys/net/ipv4/tcp_*mem entry values may help.
See the specific application manual and /usr/src/linux*/Documentation/networking/ip-sysctl.txt
for more details.
Jumbo frames on Foundry BigIron 8000 switch
There is a known issue using Jumbo frames when connected to a Foundry BigIron
8000 switch. This is a 3rd party limitation. If you experience loss of packets,
lower the MTU size.
Allocating Rx Buffers when Using Jumbo Frames
Allocating Rx buffers when using Jumbo Frames on 2.6.x kernels may fail if
the available memory is heavily fragmented. This issue may be seen with PCI-X
adapters or with packet split disabled. This can be reduced or eliminated by
changing the amount of available memory for receive buffer allocation, by
increasing /proc/sys/vm/min_free_kbytes.
Multiple Interfaces on Same Ethernet Broadcast Network
Due to the default ARP behavior on Linux, it is not possible to have one
system on two IP networks in the same Ethernet broadcast domain
(non-partitioned switch) behave as expected. All Ethernet interfaces will
respond to IP traffic for any IP address assigned to the system.
This results in unbalanced receive traffic.
If you have multiple interfaces in a server, either turn on ARP filtering by
entering:
echo 1 >
/proc/sys/net/ipv4/conf/all/arp_filter
(this only works if your kernel's version is higher than 2.4.5)
NOTE: This setting is not saved across reboots. The
configuration change can be made permanent by adding the line:
net.ipv4.conf.all.arp_filter = 1
to the file /etc/sysctl.conf
or,
install the interfaces in separate broadcast domains (either in different
switches or in a switch partitioned to VLANs).
Disable rx flow control with ethtool
In order to disable receive flow control using ethtool, you must turn off auto-negotiation on the same command line.
For example:
ethtool -A
eth? autoneg off rx off
Unplugging network cable while ethtool -p is running
In kernel versions 2.5.50 and later (including 2.6 kernel), unplugging the
network cable while ethtool -p is running will cause the system to
become unresponsive to keyboard commands, except for control-alt-delete.
Restarting the system appears to be the only remedy.
MSI-X Issues with Kernels between 2.6.19 - 2.6.21 (inclusive)
Kernel panics and instability may be observed on any MSI-X hardware if you
use irqbalance with kernels between 2.6.19 and 2.6.21. If such problems are
encountered, you may disable the irqbalance daemon or upgrade to a newer kernel.
Rx Page Allocation Errors
Page allocation failure. order:0 errors may occur under stress with kernels
2.6.25 and above. This is caused by the way the Linux kernel reports this
stressed condition.
Network throughput degradation observed with Onboard video versus add-in
Video Card on 82579LM Gigabit Network Connection when used with some older
kernels.
This issue can be worked around by specifying "pci=nommconf" in the kernel
boot parameter or by using another kernel boot parameter
"memmap=128M$0x100000000" which marks 128 MB region at 4GB as reserved and
therefore OS won't use these RAM pages.
This issue is fixed in kernel version 2.6.21, where the kernel tries to
dynamically find out the mmconfig size by looking at the number of buses that
the mmconfig segment maps to.
This issue won't be seen on 32bit version of EL5, as in that case, the kernel
sees that RAM is located around the 256MB window and avoids using the mmconfig
space.
Activity LED blinks unexpectedly
If a system based on the 82577, 82578, or 82579 controller is connected to a
hub, the Activity LED will blink for all network traffic present on the hub.
Connecting the system to a switch or router will filter out most traffic not
addressed to the local port.
Link may take longer than expected
With some Phy and switch combinations, link can take longer than expected. This can be an issue on Linux distributions that timeout when checking for link prior to acquiring a DHCP address; however there is usually a way to work around this (e.g. set LINKDELAY in the interface configuration on RHEL).
Tx flow control is disabled by default on 82577 and 82578-based adapters
Possible performance degradation on certain 82566 and 82577 devices
Internal stress testing with jumbo frames shows the reliability on some 82566 and 82567 devices is improved in certain corner cases by disabling the Early Receive feature. Doing so can impact Tx performance. To reduce the impact, the packet buffer sizes and relevant flow control settings are modified accordingly.
The igbvf driver supports 82576-based virtual function devices that can only be
activated on kernels that support SR-IOV. SR-IOV requires the correct
platform and OS support.
The igbvf driver requires the igb driver, version 2.0 or later. The igbvf driver
supports virtual functions generated by the igb driver with a max_vfs value of 1
or greater. For more information on the max_vfs parameter refer to the section
on the the igb driver.
The guest OS loading the igbvf driver must support MSI-X interrupts.
This driver is only supported as a loadable module at this time. Intel is not
supplying patches against the kernel source to allow for static linking of the
driver. For questions related to hardware requirements, refer to the
documentation supplied with your Intel Gigabit adapter. All hardware
requirements listed apply to use with Linux.
Instructions on updating ethtool can be found in the section Additional
Configurations later in this document.
VLANs: There is a limit of a total of 32 shared VLANs to 1 or more VFs.
Building and Installation
To build a binary RPM* package of this driver, run 'rpmbuild -tb <filename.tar.gz>'.
Replace <filename.tar.gz> with the specific filename of the driver.
NOTE: For the build to work
properly, the currently running kernel MUST match the version and
configuration of the installed kernel sources. If you have just recompiled
the kernel reboot the system now.
RPM functionality has only been tested in Red Hat distributions.
Move the base driver tar file to the directory of your
choice. For example, use ' /home/username/igbvf or /usr/local/src/igbvf.'.
With 2.6 based kernels also make sure that older e1000e drivers are removed
from the kernel, before loading the new module:
rmmod igbvf; modprobe
igbvf
Assign an IP address to the interface by entering the
following, where <x> is the interface number:
ifconfig eth<x> <IP_address>
Verify that the interface works. Enter the following, where
<IP_address>
is the IP address for another machine on the same subnet as the interface
that is being tested:
ping <IP_address>
Troubleshooting: Some systems have trouble supporting
MSI and/or MSI-X interrupts. If you believe your system needs to disable
this style of interrupt, the driver can be built and installed with the
command:
make CFLAGS_EXTRA=-DDISABLE_PCI_MSI
install
Normally the driver will generate an interrupt every two seconds, so if you
can see that you're no longer getting interrupts in cat /proc/interrupts for the
ethX igbvf device, then this workaround may be necessary.
Command Line Parameters
If the driver is built as a module, the following optional parameters are used by entering them on the command
line with the modprobe command using this syntax:
modprobe igbvf
[<option>=<VAL1>,<VAL2>,...]
For example:
modprobe igbvf InterruptThrottleRate=16000,16000
The default value for each parameter is generally the recommended setting, unless otherwise noted.
The driver can limit the amount of interrupts per second that the adapter
will generate for incoming packets. It does this by writing a value to
the adapter that is based on the maximum amount of interrupts that the
adapter will generate per second.
Setting InterruptThrottleRate to a value greater or equal to 100
will program the adapter to send out a maximum of that many interrupts
per second, even if more packets have come in. This reduces interrupt
load on the system and can lower CPU utilization under heavy load, but
will increase latency as packets are not processed as quickly.
The default behaviour of the driver previously assumed a static
InterruptThrottleRate
value of 8000, providing a good fallback value for all traffic types,
but lacking in small packet performance and latency. The hardware can
handle many more small packets per second however, and for this reason
an adaptive interrupt moderation algorithm was implemented.
The driver has two adaptive modes (setting 1 or 3) in which
it dynamically adjusts the InterruptThrottleRate value based on the traffic that it
receives. After determining the type of incoming traffic in the last
timeframe, it will adjust the InterruptThrottleRate to an appropriate value for that
traffic.
The algorithm classifies the incoming traffic every interval into
classes. Once the class is determined, the InterruptThrottleRate value is adjusted to
suit that traffic type the best. There are three classes defined: "Bulk
traffic", for large amounts of packets of normal size; "Low latency",
for small amounts of traffic and/or a significant percentage of small
packets; and "Lowest latency", for almost completely small packets or
minimal traffic.
In dynamic conservative mode, the InterruptThrottleRate value is set to 4000 for traffic
that falls in class "Bulk traffic". If traffic falls in the "Low
latency"
or "Lowest latency" class, the InterruptThrottleRate is increased stepwise to 20000. This
default mode is suitable for most applications.
For situations where low latency is vital such as cluster or grid
computing, the algorithm can reduce latency even more when
InterruptThrottleRate is set to mode 1. In this mode, which operates
the same as mode 3, the InterruptThrottleRate will be increased stepwise to 70000 for
traffic in class "Lowest latency".
Setting InterruptThrottleRate to 0 turns off any interrupt moderation
and may improve small packet latency, but is generally not suitable
for bulk throughput traffic
NOTE:
Dynamic interrupt throttling is only applicable to adapters
operating in MSI or Legacy interrupt mode, using a single
receive queue.
NOTE:
When igbvf is loaded with default settings and multiple adapters are in
use simultaneously, the CPU utilization may increase non-linearly. In
order to limit the CPU utilization without impacting
the overall throughput, we recommend that you load the driver as
follows:
This sets the InterruptThrottleRate to 3000 interrupts/sec for the first,
second, and third instances of the driver. The range of 2000 to 3000
interrupts per second works on a majority of systems and is a good
starting point, but the optimal value will be platform-specific. If CPU
utilization is not a concern, use default driver settings.
Additional Configurations
Configuring the Driver on Different Distributions
Configuring a network driver to load properly when the system is started is
distribution dependent. Typically, the configuration process involves adding an
alias line to /etc/modules.conf or /etc/modprobe.conf as well as editing other
system startup scripts and/or configuration files. Many popular Linux
distributions ship with tools to make these changes for you. To learn the proper
way to configure a network device for your system, refer to your distribution
documentation. If during this process you are asked for the driver or module
name, the name for the Linux Base Driver for the Gigabit Family of Adapters is
igbvf.
As an example, if you install the igbvf driver for two Gigabit adapters (eth0
and eth1) and want to set the interrupt mode to MSI-X and MSI respectively, add
the following to modules.conf or /etc/modprobe.conf:
alias eth0 igbvf
alias eth1 igbvf
options igbvf InterruptThrottleRate=3,1
Viewing Link Messages
Link messages will not be displayed to the console if the distribution is
restricting system messages. In order to see network driver link messages on
your console, set dmesg to eight by entering the following:
dmesg -n 8
NOTE: This setting is not saved
across reboots.
Jumbo Frames
Jumbo Frames support is enabled by changing the MTU to a value larger than
the default of 1500. Use the ifconfig command to increase the MTU size.
For example:
ifconfig eth<x> mtu 9000 up
This setting is not saved across reboots. It can be made permanent if you
add:
MTU=9000
to the file /etc/sysconfig/network-scripts/ifcfg-eth<x>. This example applies
to the Red Hat distributions; other distributions may store this setting in a
different location.
NOTES:
To enable Jumbo Frames,
increase the MTU size on the interface beyond 1500.
The maximum MTU setting for Jumbo Frames is 9216. This
value coincides with the maximum Jumbo Frames size of 9234 bytes.
Using Jumbo frames at 10 or 100 Mbps is not supported and may result in poor performance or loss of link.
ethtool
The driver utilizes the ethtool interface for driver configuration and
diagnostics, as well as displaying statistical information. ethtool version 3.0
or later is required for this functionality, although we strongly recommend
downloading the latest version at:
NOTE: After installing the driver, if your Intel Network
Connection is not working, verify that you have installed the correct
driver.
Driver Compilation
When trying to compile the driver by running make install, the following
error may occur:
"Linux kernel source not configured - missing version.h"
To solve this issue, create the version.h file by going to the Linux source tree
and entering:
make include/linux/version.h.
Multiple Interfaces on Same Ethernet Broadcast Network
Due to the default ARP behavior on Linux, it is not possible to have one
system on two IP networks in the same Ethernet broadcast domain (non-partitioned
switch) behave as expected. All Ethernet interfaces will respond to IP traffic
for any IP address assigned to the system. This results in unbalanced receive
traffic.
If you have multiple interfaces in a server, either turn on ARP filtering by
entering:
echo 1 > /proc/sys/net/ipv4/conf/all/arp_filter
(this only works if your kernel's version is higher than 2.4.5),
NOTE: This setting is not saved across reboots. The
configuration change can be made permanent by adding the line:
net.ipv4.conf.all.arp_filter = 1
to the file /etc/sysctl.conf
or,
install the interfaces in separate broadcast domains (either in
different switches or in a switch partitioned to VLANs).
Do Not Use LRO When Routing Packets
Due to a known general compatibility issue with LRO and routing, do not use
LRO when routing packets.
Build error with Asianux 3.0 - redefinition of typedef 'irq_handler_t'
Some systems may experience build issues due to redefinition of irq_handler_t.
To resolve this issue build the driver (step 4 above) using the command:
make CFLAGS_EXTRA=-DAX_RELEASE_CODE=1
install
MSI-X Issues with Kernels between 2.6.19 - 2.6.21 (inclusive)
Kernel panics and instability may be observed on any MSI-X hardware if you
use irqbalance with kernels between 2.6.19 and 2.6.21. If such problems are
encountered, you may disable the irqbalance daemon or upgrade to a newer kernel.
Rx Page Allocation Errors
Page allocation failure. order:0 errors may occur under stress with kernels
2.6.25 and above. This is caused by the way the Linux kernel reports this
stressed condition.
Under Redhat 5.4 - System May Crash when Closing Guest OS Window after
Loading/Unloading Physical Function (PF) Driver
Do not remove the igbvf driver from Dom0 while Virtual Functions (VFs) are
assigned to guests. VFs must first use the xm "pci-detach" command to hot-plug
the VF device out of the VM it is assigned to or else shut down the VM.
Unloading Physical Function (PF) Driver Causes System Reboots When VM is
Running and VF is Loaded on the VM
Do not unload the PF driver (igb) while VFs are assigned to guests.
Host May Reboot after Removing PF when VF is Active in Guest
Using kernel versions earlier than 3.2, do not unload the PF driver with active VFs. Doing
this will cause your VFs to stop working until you reload the PF driver and may
cause a spontaneous reboot of your system.
Last modified on 11/03/11 4:12p Revision
LINUX/index.htm 0000755 0000000 0000000 00000001063 11662465060 010475 0 ustar
Intel® Linux Base Driver for Intel Ethernet Adapters
/html>
LINUX/ixgb.htm 0000755 0000000 0000000 00000226765 11730102574 010333 0 ustar
Linux Driver for Intel 10GbE Network Connections
Linux* Base Driver for 10 Gigabit Intel® Ethernet Network Connection
NOTES:
This release includes the ixgbe and ixgbevf Linux* Base Drivers for the IntelEthernet 10
Gigabit Family of Adapters.
All 82599, X540 and 82598-based 10 Gigabit network connections
require the ixgbe driver.
The ixgbevf driver supports 82599
and X540-based virtual function devices that
can only be activated on kernels that support SR-IOV. SR-IOV requires
the correct platform and OS support.
Warning: The ixgbe driver compiles by default with the LRO (Large Receive
Offload) feature enabled. This option offers the lowest CPU utilization for
receives, but is completely incompatible with *routing/ip forwarding* and
*bridging*. If enabling ip forwarding or bridging is a requirement, it is
necessary to disable LRO using compile time options as noted in the LRO section
later in this document. The result of not disabling LRO when combined with ip
forwarding or bridging can be low throughput or even a kernel panic.
Overview
The Linux* base driver supports the 2.6.x
and 3.x kernels, and includes support for any Linux supported system, including
Itanium(R)2, x86_64, i686, and PPC.
These drivers are only supported as a loadable module at this time. Intel is not
supplying patches against the kernel source to allow for static linking of the
driver. A version of the driver may already be included by your distribution
and/or the kernel.org kernel. For questions related to hardware requirements, refer to the
documentation supplied with your Intel adapter. All hardware
requirements listed apply to use with Linux.
The following features are now available in supported kernels:
Native VLANs
Channel Bonding (teaming)
SNMP
Generic Receive Offload
Data Center Bridging
Channel Bonding documentation can be found in the Linux kernel source:
/Documentation/networking/bonding.txt
The driver information previously displayed in the /proc file system is not
supported in this release. Alternatively, you can use ethtool (version 1.6 or
later), lspci, and ifconfig to obtain the same information. Instructions on
updating ethtool can be found in the section Additional
Configurations later in this document.
The driver in this release is compatible with 82598, 82599 and X540-based Intel
Ethernet Network Connections.
For more information on how to identify your adapter, go to the Adapter &
Driver ID Guide at:
If your 82599-based
Intel® Network Adapter came with Intel optics or is an Intel® Ethernet
Server Adapter X520-2, then it only supports Intel optics and/or the
direct attach cables listed below.
When 82599-based SFP+ devices are connected back to back, they
should be set to the same Speed setting via ethtool. Results may
vary if you mix speed settings.
Supplier
Type
Part Numbers
SR Modules
Intel
DUAL RATE 1G/10G SFP+ SR (bailed)
AFBR-703SDZ-IN2
Intel
DUAL RATE 1G/10G SFP+ SR (bailed)
FTLX8571D3BCV-IT
Intel
DUAL RATE 1G/10G SFP+ SR (bailed)
AFBR-703SDDZ-IN1
LR Modules
Intel
DUAL RATE 1G/10G SFP+ LR (bailed)
FTLX1471D3BCV-IT
Intel
DUAL RATE 1G/10G SFP+ LR (bailed)
AFCT-701SDZ-IN2
Intel
DUAL RATE 1G/10G SFP+ LR (bailed)
AFCT-701SDDZ-IN1
The following is a list of 3rd party SFP+ modules and direct attach cables
that have received some testing. Not all modules are applicable to all devices.
Supplier
Type
Part Numbers
Finisar
SFP+ SR bailed, 10g single rate
FTLX8571D3BCL
Avago
SFP+ SR bailed, 10g single rate
AFBR-700SDZ
Finisar
SFP+ LR bailed, 10g single rate
FTLX1471D3BCL
Finisar
DUAL RATE 1G/10G SFP+ SR (No Bail)
FTLX8571D3QCV-IT
Avago
DUAL RATE 1G/10G SFP+ SR (No Bail)
AFBR-703SDZ-IN1
Finisar
DUAL RATE 1G/10G SFP+ LR (No Bail)
FTLX1471D3QCV-IT
Avago
DUAL RATE 1G/10G SFP+ LR (No Bail)
AFCT-701SDZ-IN1
Finisar
1000BASE-T SFP
FCLF8522P2BTL
Avago
1000BASE-T SFP
ABCU-5710RZ
82599-based adapters support all passive and active limiting direct attach
cables that comply with SFF-8431 v4.1 and SFF-8472 v10.4 specifications.
Laser turns off for SFP+ when ifconfig ethX down
"ifconfig ethX down" turns off the laser for 82599-based SFP+ fiber adapters. "ifconfig
ethX
up" turns on the laser.
82598-BASED ADAPTERS
NOTES:
Intel Ethernet Network Adapters
that support removable optical modules only support their original
module type (i.e., the Intel 10 Gigabit SR Dual Port Express Module
only supports SR optical modules). If you plug in a different type of
module, the driver will not load.
Hot Swapping/hot plugging
optical modules is not supported.
Only single speed, 10
gigabit modules are supported.
LAN on Motherboard (LOMs)
may support DA, SR, or LR modules. Other module types are not supported.
Please see your system documentation for details.
The following is a list of SFP+ modules and direct attach cables that have
received some testing. Not all modules are applicable to all devices.
Supplier
Type
Part Numbers
Finisar
SFP+ SR bailed, 10g single rate
FTLX8571D3BCL
Avago
SFP+ SR bailed, 10g single rate
AFBR-700SDZ
Finisar
SFP+ LR bailed, 10g single rate
FTLX1471D3BCL
82598-based adapters support all passive direct attach cables that comply
with SFF-8431 v4.1 and SFF-8472 v10.4 specifications. Active direct attach
cables are not supported.
THIRD PARTY OPTIC
MODULES AND CABLES REFERRED TO ABOVE ARE LISTED ONLY FOR THE PURPOSE OF
HIGHLIGHTING THIRD PARTY SPECIFICATIONS AND POTENTIAL COMPATIBILITY, AND ARE NOT
RECOMMENDATIONS OR ENDORSEMENT OR SPONSORSHIP OF ANY THIRD PARTYS PRODUCT BY
INTEL. INTEL IS NOT ENDORSING OR PROMOTING PRODUCTS MADE BY ANY THIRD PARTY AND
THE THIRD PARTY REFERENCE IS PROVIDED ONLY TO SHARE INFORMATION REGARDING
CERTAIN OPTIC MODULES AND CABLES WITH THE ABOVE SPECIFICATIONS. THERE MAY BE
OTHER MANUFACTURERS OR SUPPLIERS, PRODUCING OR SUPPLYING OPTIC MODULES AND
CABLES WITH SIMILAR OR MATCHING DESCRIPTIONS. CUSTOMERS MUST USE THEIR OWN
DISCRETION AND DILIGENCE TO PURCHASE OPTIC MODULES AND CABLES FROM ANY THIRD PARTY OF THEIR CHOICE. CUSTOMERS ARE SOLELY
RESPONSIBLE FOR ASSESSING THE SUITABILITY OF THE PRODUCT AND/OR DEVICES AND FOR
THE SELECTION OF THE VENDOR FOR PURCHASING ANY PRODUCT. THE OPTIC MODULES AND
CABLES REFERRED TO ABOVE ARE NOT WARRANTED OR SUPPORTED BY INTEL. INTEL ASSUMES
NO LIABILITY WHATSOEVER, AND INTEL DISCLAIMS ANY EXPRESS OR IMPLIED WARRANTY,
RELATING TO SALE AND/OR USE OF SUCH THIRD PARTY PRODUCTS OR SELECTION OF VENDOR
BY CUSTOMERS.
Building and Installation
To build a binary RPM* package of this driver, run 'rpmbuild
-tb ixgbe.tar.gz'.
NOTE: For the build to work properly, the currently running kernel
MUST match the version and configuration of the installed kernel sources. If you have just
recompiled the kernel, reboot the system before building.
RPM functionality has only
been tested in Red Hat distributions.
To manually build this driver:
Move the base driver tar file to the directory of your
choice. For example, use '/home/username/ixgbe' or '/usr/local/src/ixgbe'.
With 2.6 based kernels also
make sure that older ixgbe drivers are removed from the kernel, before
loading the new module:
rmmod ixgbe; modprobe ixgbe
Assign an IP address to the interface by entering the
following, where x is the interface number:
ifconfig ethX <IP_address>
netmask <netmask>
Verify that the interface works. Enter the following, where
<IP_address>
is the IP address of another machine on the same subnet as the interface
that is being tested:
ping <IP_address>
To build ixgbe driver with DCA
If your kernel supports DCA, the driver will build by default with DCA enabled.
Command Line Parameters
If the driver is built as a module, the following optional parameters are used by
entering them on the command line with the modprobe command
using this syntax:
modprobe ixgbe [<option>=<VAL1>,<VAL2>,...]
For example:
modprobe ixgbe
InterruptThrottleRate=16000,16000
The default value for each parameter is generally the recommended setting, unless otherwise noted.
Parameter Name
Valid Range/Settings
Default
Description
RSS - Receive Side Scaling (or multiple queues for receives)
0 - 16
1
0 = disables RSS
1 = enables RSS and sets the descriptor queue count to 16 or the number
of
online cpus, whichever is less.
2-16 = enables RSS, with 2-16 queues
RSS also effects the number of
transmit queues allocated on 2.6.23 and
newer kernels with CONFIG_NETDEVICES_MULTIQUEUE set in the kernel .config
file. CONFIG_NETDEVICES_MULTIQUEUE only exists from 2.6.23 to 2.6.26. Other
options enable multiqueue in 2.6.27 and newer kernels.
MQ - Multi Queue
0, 1
1
0 = Disables Multiple Queue support
1 = Enables Multiple Queue support (a prerequisite for RSS)
DCA - Direct Cache Access
0, 1
1 (when IXGBE_DCA is enabled)
0 = Disables DCA support in the driver
1 = Enables DCA support in the driver
See the above instructions for enabling DCA. If the driver is enabled for
DCA this parameter allows load-time control of the feature.
IntMode
0-2 (0 = Legacy Int, 1 = MSI and 2 = MSIX)
2
IntMode controls allow load time control over the type of interrupt
registered for by the driver. MSI-X is required for multiple queue support,
and some kernels and combinations of kernel .config options will force a
lower level of interrupt support. 'cat /proc/interrupts' will show
different values for each type of interrupt.
InterruptThrottleRate
956-488281 (0=off, 1=dynamic)
1
Interrupt Throttle Rate (interrupts/sec). The ITR parameter controls how
many interrupts each interrupt vector can generate per second. Increasing ITR lowers
latency at the cost of increased CPU utilization, though it may help
throughput in some circumstances.
1 = Dynamic mode attempts to moderate
interrupts per vector while maintaining very low latency. This can sometimes
cause extra CPU utilization. If planning on deploying ixgbe in a latency
sensitive environment please consider this parameter.
0 = Setting
InterruptThrottleRate to 0 turns off any interrupt moderation and may
improve small packet latency, but is generally not suitable for bulk
throughput traffic due to the increased cpu utilization of the higher
interrupt rate. Please note that on 82599 and X540-based adapters, disabling InterruptThrottleRate will also result in the driver disabling HW RSC. On
82598-based adapters, disabling InterruptThrottleRate will also result in
disabling LRO (Large Receive Offloads).
LLI (Low Latency Interrupts)
LLI allows for immediate generation of an interrupt upon processing receive
packets that match certain criteria as set by the parameters described
below.
LLI parameters are not enabled when Legacy interrupts are used. You must be
using MSI or MSI-X (see cat /proc/interrupts) to successfully use LLI.
LLIPort
0 - 65535
0 (disabled)
LLI is configured with the LLIPort command-line parameter, which specifies
which TCP port should generate Low Latency Interrupts.
For example, using LLIPort=80 would cause the hardware to generate an
immediate interrupt upon receipt of any packet sent to TCP port 80 on the
local machine.
CAUTION: Enabling LLI can result in an excessive
number of interrupts/second that may cause problems with the system and in
some cases may cause a kernel panic.
LLIPush
0-1
0 (disabled)
LLIPush can be set to be enabled or disabled (default). It is most effective
in an environment with many small transactions.
NOTE: Enabling LLIPush may allow a denial of service attack.
LLISize
0-1500
0 (disabled)
LLISize causes an immediate interrupt if the board receives a packet smaller
than the specified size.
LLIEType
0-x8fff
0 (disabled)
Low Latency Interrupt Ethernet Protocol Type.
LLIVLANP
0-7
0 (disabled)
Low Latency Interrupt on VLAN priority threshold.
Flow Control
Ethernet Flow Control (IEEE 802.3x) can be configured with ethtool to
enable receiving and transmitting pause frames for ixgbe. When tx is
enabled, PAUSE frames are generated when the receive packet buffer crosses a
predefined threshold. When rx is enabled, the transmit unit will halt for
the time delay specified when a PAUSE frame is received.
Flow Control is
enabled by default. If you want to disable a flow control capable link
partner,
use ethtool:
ethtool -A eth? autoneg off rx off tx off
NOTE:
For 82598 backplane cards entering 1 gig mode, flow control default behavior
is changed to off. Flow control in 1 gig mode on these devices can lead to
Tx hangs.
Intel® Ethernet Flow Director
NOTE: Flow director parameters are only supported
on kernel versions 2.6.30 or later.
Supports advanced filters that direct receive packets by their flows to
different queues. Enables tight control on routing a flow in the platform.
Matches flows and CPU cores for flow affinity. Supports multiple parameters
for flexible flow classification and load balancing.
Flow director is enabled only if the kernel is multiple TX queue capable.
An included script (set_irq_affinity.sh) automates setting the IRQ to CPU
affinity.
You can verify that the driver is using Flow Director by looking at the
counter in ethtool: fdir_miss and fdir_match.
Perfect Filter: Perfect filter is an interface to load the filter
table that funnels all flow
into queue_0 unless an alternative queue is specified using "action". In
that
case, any flow that matches the filter criteria will be directed to the
appropriate queue.
Support for Virtual Function (VF) is via the user-data field. You must
update
to the version of ethtool built for the 2.6.40 kernel. Perfect Filter is
supported on all kernels 2.6.30 and later. Rules may be deleted from the
table
itself. This is done via "ethtool -U ethX delete N" where N is the rule
number
to be deleted.
NOTE: Flow Director Perfect
Filters can run in single queue mode, when SR-IOV is enabled, or
when DCB is enabled.
If the queue is defined as -1, filter will drop matching packets.
To account for filter matches and misses, there are two stats in ethtool:
fdir_match and fdir_miss. In addition, rx_queue_N_packets shows the number of
packets processed by the Nth queue.
NOTE: Receive Packet Steering
(RPS) and Receive Flow Steering (RFS) are not
compatible with Flow Director. IF Flow Director is enabled, these will be
disabled.
NOTE: For VLAN Masks only 4
masks are supported.
NOTE: Once a rule is defined,
you must supply the same fields and masks (if masks are specified).
Support for UDP RSS
This feature adds an ON/OFF switch for hashing over certain flow types. You
can't turn on anything other than UDP. The default setting is disabled. We
only support enabling/disabling hashing on ports for UDP over IPv4 (udp4) or
IPv6 (udp6).
NOTE: Fragmented packets may
arrive out of order when RSS UDP support is configured.
Supported Ethtool Commands and Options:
-n --show-nfc
Retrieves the receive network flow classification configurations.
rx-flow-hash tcp4|udp4|ah4|esp4|sctp4|tcp6|udp6|ah6|esp6|sctp6
Retrieves the hash options for the specified network traffic type.
-N --config-nfc
Configures the receive network flow classification.
rx-flow-hash tcp4|udp4|ah4|esp4|sctp4|tcp6|udp6|ah6|esp6|sctp6
m|v|t|s|d|f|n|r...
Configures the hash options for the specified network traffic type.
udp4 UDP over IPv4
udp6 UDP over IPv6
f Hash on bytes 0 and 1 of the Layer 4 header of the rx packet.
n Hash on bytes 2 and 3 of the Layer 4 header of the rx packet.
The following is an example using udp4 (UDP over IPv4):
To include UDP port numbers in RSS hashing run:
ethtool -N ethX rx-flow-hash udp4 sdfn
To exclude UDP port numbers from RSS hashing run:
ethtool -N ethX rx-flow-hash udp4 sd
To display UDP hashing current configuration run:
ethtool -n ethX rx-flow-hash udp4
The results of running that call will be the following, if UDP hashing is
enabled:
UDP over IPV4 flows use these fields for computing Hash flow key:
IP SA
IP DA
L4 bytes 0 & 1 [TCP/UDP src port]
L4 bytes 2 & 3 [TCP/UDP dst port]
The results if UDP hashing is disabled would be:
UDP over IPV4 flows use these fields for computing Hash flow key:
IP SA
IP DA
The following three parameters impact Flow Director:
FdirMode
0-2 (0=off, 1=ATR, 2=Perfect filter mode)
1 (ATR)
Flow Director filtering modes.
FdirPballoc
0-2 (0=64k, 1=128k, 2=256k)
0 (64k)
Flow Director allocated packet buffer size.
AtrSampleRate
1-100
20
Software ATR Tx packet sample rate. For example, when set to 20, every 20th
packet, looks to see if the packet will create a new flow.
max_vfs
1-63
0
If the value is greater than 0 it will also force the VMDq parameter
to be 1 or more.
This parameter adds support for SR-IOV. It causes the driver to spawn up to
max_vfs worth of virtual function.
The parameters for the driver are referenced by position. So, if you have a
dual port 82599 or X540-based adapter and you want N virtual functions per port, you
must specify a number for each port with each parameter separated by a
comma.
For example:
insmod ixgbe max_vfs=63,63
NOTE:
If both 82598 and 82599 or X540-based adapters are installed on the same machine,
you must be careful in loading the driver with the parameters. Depending on
system configuration, number of slots, etc. its impossible to predict in
all cases where the positions would be on the command line and the user will
have to specify zero in those positions occupied by an 82598 port.
L2LBen
0 = disable, 1 = enable (default)
1 (enable)
This parameter controls the internal switch (L2 loopback between pf and vf). By default the switch is enabled.
LRO
0(off), 1(on)
1 (on)
Enable/disable Large Receive Offload.
Additional Configurations
Configuring the Driver on Different Distributions
Configuring a network driver to load properly when the system is started is
distribution dependent. Typically, the configuration process involves adding an
alias line to /etc/modules.conf or etc/modprobe.conf, as well as editing other system startup scripts
and/or configuration files. Many popular Linux distributions ship with tools to
make these changes for you. To learn the proper way to configure a network
device for your system, refer to your distribution documentation. If during this
process you are asked for the driver or module name, the name for the Linux Base
Driver for the 10 Gigabit Family of Adapters is ixgbe.
Viewing Link Messages
Link messages will not be displayed to the console if the distribution is
restricting system messages. In order to see network driver link messages on
your console, set dmesg to eight by entering the following:
dmesg -n 8
NOTE: This setting is not saved across reboots.
Jumbo Frames
The driver supports Jumbo Frames for all adapters. Jumbo Frames support
is enabled by changing the MTU to a value larger than the default of 1500. The
maximum value for the MTU is 16110. Use the ifconfig command to increase the MTU size.
For example, enter the following where <x> is the interface number:
ifconfig ethX mtu 9000 up
The maximum MTU setting for Jumbo Frames is 16110. This value coincides with
the maximum Jumbo Frames size of 16128. This driver will attempt to
use multiple page sized buffers to receive each jumbo packet. This should help
to avoid buffer starvation issues when allocating receive packets.
ethtool
The driver utilizes the ethtool interface for driver configuration and
diagnostics, as well as displaying statistical information. The latest ethtool
version is required for this functionality.
NAPI (Rx polling mode) is supported in the ixgbe driver. NAPI is enabled or
disabled based on the configuration of the kernel. To override the default, use
the following compile-time flags.
You can tell if NAPI is enabled in the driver by looking at the version
number of the driver. It will contain the string -NAPI if NAPI is enabled.
To enable NAPI, compile the driver module, passing in a configuration option:
make CFLAGS_EXTRA=-DIXGBE_NAPI install
NOTE: This will not do anything if NAPI is disabled in
the kernel.
To disable NAPI, compile the driver module, passing in a configuration
option:
Large Receive Offload (LRO) is a technique for increasing inbound throughput
of high-bandwidth network connections by reducing CPU overhead. It works by
aggregating multiple incoming packets from a single stream into a larger buffer
before they are passed higher up the networking stack, thus reducing the number
of packets that have to be processed. LRO combines multiple Ethernet frames into
a single receive in the stack, thereby potentially decreasing CPU utilization
for receives.
IXGBE_NO_LRO is a compile time flag. The user can enable it
at compile time to remove support for LRO from the driver. The flag is used by
adding
CFLAGS_EXTRA="-DIXGBE_NO_LRO" to the make file when it's being compiled.
make CFLAGS_EXTRA="-DIXGBE_NO_LRO"
install
You can verify that the driver is using LRO by looking at these counters in
ethtool:
lro_flushed - the total number of receives using LRO.
lro_aggregated - counts the total number of Ethernet packets that were
combined.
NOTE: IPv6 and UDP are not
supported by LRO.
HW RSC
82599 and X540-based adapters support HW based
receive side coalescing (RSC) which can merge multiple frames from the same IPv4
TCP/IP flow into a single structure that can span one or more descriptors. It
works similarly to SW Large receive offload technique. By default
HW RSC is enabled and SW LRO can not be used for 82599 and X540-based adapters unless HW RSC is disabled.
IXGBE_NO_HW_RSC is a compile time flag. The
user can enable it at compile time to remove support for HW RSC from the driver.
The flag is used by adding CFLAGS_EXTRA="-DIXGBE_NO_HW_RSC" to the make file
when it's being compiled.
make
CFLAGS_EXTRA="-DIXGBE_NO_HW_RSC" install
You can verify that the driver is using
HW RSC by looking at the counter in ethtool:
hw_rsc_count - counts the total number of Ethernet packets
that were being combined.
rx_dropped_backlog
When in a non-Napi (or Interrupt) mode, this counter indicates that the stack
is dropping packets. There is an adjustable parameter in the stack that allows
you to adjust the amount of backlog. We recommend increasing the
netdev_max_backlog if the counter goes up.
# sysctl -a |grep
netdev_max_backlog
net.core.netdev_max_backlog =
1000
# sysctl -e
net.core.netdev_max_backlog=10000
net.core.netdev_max_backlog =
10000
Flow Control
Flow control is enabled by default. If you want to disable a flow
control capable link partner, use ethtool:
ethtool -A eth? autoneg off rx off tx off
MAC and VLAN anti-spoofing feature
When a malicious driver attempts to send a spoofed packet, it is dropped
by the hardware and not transmitted. An interrupt is sent to the PF driver
notifying it of the spoof attempt.
When a spoofed packet is detected the PF driver will send the following
message to the system log (displayed by the "dmesg" command):
ixgbe ethX: ixgbe_spoof_check: n
spoofed packets detected
Where x=the PF interface# n=the VF that attempted to do the spoofing.
Setting MAC Address, VLAN and Rate Limit Using IProute2 Tool
You can set a MAC address of a Virtual Function (VF), a default VLAN and the
rate limit using the IProute2 tool. Download the latest version of the iproute2
tool from Sourceforge if your version does not have all the features you
require.
(WoL) Wake on LAN Support
Some adapters do not support Wake on LAN. To determine if your adapter
supports Wake on LAN, run
ethtool ethX
Performance Tuning
An excellent article on performance tuning can be found
at:
NOTE: After installing the driver, if your Intel
Ethernet Network Connection is not working, verify that you have installed the
correct driver.
MSI-X Issues with Kernels between 2.6.19 - 2.6.21 (inclusive)
Kernel panics and instability may be observed on any MSI-X hardware if you use
irqbalance with kernels between 2.6.19 and 2.6.21. If such problems are
encountered, you may disable the irqbalance daemon or upgrade to a newer kernel.
Driver Compilation
When trying to compile the driver by running make install, the following
error may occur: "Linux kernel source not configured - missing
version.h"
To solve this issue, create the version.h file by going to the Linux source
tree and entering:
make include/linux/version.h
Do Not Use LRO When Routing or Bridging Packets
Due to a known general compatibility issue with LRO and routing, do not use
LRO when routing or bridging packets.
LRO and iSCSI Incompatibility
LRO is incompatible with iSCSI target or initiator traffic. A panic may occur
when iSCSI traffic is received through the ixgbe driver with LRO enabled. To
workaround this, the driver should be built and installed with:
# make CFLAGS_EXTRA=-DIXGBE_NO_LRO install
Performance Degradation with Jumbo Frames
Degradation in throughput performance may be observed in some Jumbo frames
environments. If this is observed, increasing the application's socket buffer
size and/or increasing the /proc/sys/net/ipv4/tcp_*mem entry values may help.
See the specific application manual and /usr/src/linux*/Documentation/networking/ip-sysctl.txt
for more details.
Multiple Interfaces on Same Ethernet Broadcast Network
Due to the ARP behavior on Linux, it is not possible to have one system on
two IP networks in the same Ethernet broadcast domain (non-partitioned switch)
behave as expected. All Ethernet interfaces will respond to IP traffic for any
IP address assigned to the system. This results in unbalanced receive traffic.
If you have multiple interfaces in a server, either turn on ARP filtering by
entering:
echo 1 >
/proc/sys/net/ipv4/conf/all/arp_filter
(this only works if your kernel's version is higher than 2.4.5), or install
the interfaces in separate broadcast domains (either in different switches or in
a switch partitioned to VLANs).
UDP Stress Test Dropped Packet Issue
Under small packets UDP stress test with 10GbE driver, the Linux system may
drop UDP packets due to the fullness of socket buffers. You may want to change
the driver's Flow Control variables to the minimum value for controlling packet
reception.
Or you can increase the kernel's default buffer sizes for UDP by changing the
values in
/proc/sys/net/core/rmem_default
and rmem_max
Unplugging network cable while ethtool -p is running
In kernel versions 2.5.50 and later (including 2.6 kernel), unplugging the
network cable while ethtool -p is running will cause the system to become
unresponsive to keyboard commands, except for control-alt-delete. Restarting the
system appears to be the only remedy.
Cisco Catalyst 4948-10GE port resets may cause switch to shut
down ports
82598-based hardware can re-establish link quickly and when connected to some
switches, rapid resets within the driver may cause the switch port to become
isolated due to "link flap". This is typically indicated by a yellow instead of
a green link light. Several operations may cause this problem, such as
repeatedly running ethtool commands that cause a reset.
A potential workaround is to use the Cisco IOS command "no errdisable detect
cause all" from the Global Configuration prompt which enables the switch to keep
the interfaces up, regardless of errors.
Installing Red Hat Enterprise Linux 4.7, 5.1, or 5.2 with an Intel(R) 10 Gigabit AT Server
Adapter may cause kernel panic
A known issue may cause a kernel panic or hang after installing an
82598AT-based Intel(R) 10 Gigabit AT Server Adapter in a Red Hat Enterprise Linux
4.7, 5.1, or 5.2 system. The ixgbe driver for both the install kernel and the runtime kernel
can create this panic if the 82598AT adapter is installed. Red Hat may release a
security update that contains a fix for the panic that you can download using
RHN (Red Hat Network) or Intel recommends that you install the ixgbe-1.3.31.5
driver or newer BEFORE installing the hardware.
Rx Page Allocation Errors
Page allocation failure. order:0 errors may occur under stress with kernels
2.6.25 and above. This is caused by the way the Linux kernel reports this
stressed condition.
DCB: Generic segmentation offload on causes bandwidth allocation issues
In order for DCB to work correctly, GSO (Generic Segmentation Offload aka
software TSO) must be disabled using ethtool. By default since the hardware
supports TSO (hardware offload of segmentation) GSO will not be running. The GSO
state can be queried with ethtool using ethtool -k ethX.
When using 82598-based network connections, ixgbe driver only supports 16 queues
on a platform with more than 16 cores
Due to known hardware limitations, RSS can only filter in a maximum of 16
receive queues.
82599 and X540-based network connections support up to 64 queues.
Disable GRO when routing/bridging
Due to a known kernel issue, GRO must be turned off when routing/bridging.
GRO can be turned off via ethtool.
ethtool -K ethX gro off
where ethX is the ethernet interface you're trying to modify.
Lower than expected performance on dual port and quad port 10GbE
devices
Some PCI-E x8
slots are actually configured as x4 slots. These slots have insufficient
bandwidth for full 10Gbe line rate with dual port and quad port 10GbE devices. The driver can
detect this situation and will write the following message in the system log:
PCI-Express bandwidth available for this card is not sufficient for optimal
performance. For optimal performance a x8 PCI-Express slot is required.
If this error
occurs, moving your adapter to a true x8 slot will resolve the issue.
ethtool may incorrectly display SFP+ fiber module as Direct Attached cable
Due to kernel limitations, port type can only be correctly displayed on kernel
2.6.33 or greater.
Under Redhat 5.4 - System May Crash when Closing Guest OS Window after
Loading/Unloading Physical Function (PF) Driver
Do
not remove the ixgbe driver from Dom0 while Virtual Functions (VFs) are
assigned to guests. VFs must first use the xm "pci-detach" command to hot-plug
the VF device out of the VM it is assigned to or else shut down the VM.
Unloading Physical Function (PF) Driver Causes System Reboots When VM is
Running and VF is Loaded on the VM
Do not unload the PF driver (ixgbe) while VFs are assigned to guests.
Running ethtool -t ethX command causes break between PF and test client
When there are active VFs, "ethtool -t" will only run the link test. The
driver will also log in syslog that VFs should be shut down to run a full diags
test.
SLES10 SP3 random system panic when reloading driver
This is a known SLES-10 SP3 issue. After requesting interrupts for MSI-X
vectors, system may panic.
Currently the only known workaround is to build the drivers with CFLAGS_EXTRA=-DDISABLE_PCI_MSI
if the driver need to be loaded/unloaded. Otherwise the driver can be loaded
once and will be safe, but unloading it will lead to the issue.
Enabling SR-IOV in a 32-bit or 64-bit Microsoft* Windows* Server 2008/R2 Guest OS using
Intel® 82576-based GbE, Intel® 82599 or X540-based 10GbE controller under KVM
KVM Hypervisor/VMM supports direct assignment of a PCIe device to a VM. This
includes traditional PCIe devices, as well as SR-IOV-capable devices using Intel
82576-based and 82599 or X540-based controllers.
While direct assignment of a PCIe device or an SR-IOV Virtual Function (VF) to a
Linux-based VM running 2.6.32 or later kernel works fine, there is a known issue with
Microsoft Windows Server 2008/R2 VM that results in a "yellow bang" error. This
problem is within the KVM VMM itself, not the Intel driver, or the SR-IOV logic
of the VMM, but rather that KVM emulates an older CPU model for the guests, and
this older CPU model does not support MSI-X interrupts, which is a requirement for Intel SR-IOV.
If you wish to use the Intel 82576, 82599 or X540-based controllers in SR-IOV mode
with KVM and a Microsoft Windows Server 2008/R2 guest try the following workaround.
The workaround is to tell KVM to emulate a different model of CPU when using qemu to create the KVM guest:
"-cpu qemu64,model=13"
Loading ixgbe driver in 3.2.x and above kernels displays kernel tainted message
Due to recent kernel changes, loading an out of tree driver will cause the kernel to be tainted.
Unable to obtain DHCP lease on boot with RedHat
For configurations where the auto-negotiation process takes more than 5 seconds,
the boot script may fail with the following message:
ethX: failed. No
link present. Check cable?
If this error appears even though the presence of a link
can be confirmed using ethtool ethX, try setting
LINKDELAY=5 in
/etc/sysconfig/network-scripts/ifcfg-ethX.
NOTE:
Link time can take up to 30 seconds. Adjust LINKDELAY value accordingly.
Host may Reboot after Removing PF when VF is Active in Guest
Using kernel versions earlier than 3.2, do not unload the PF driver with
active VFs. Doing this will cause your VFs to stop working until you reload the
PF driver and may cause a spontaneous reboot of your system.
Support
For general information, go to the Intel support website at:
If an issue is identified with the released source code on the supported
kernel with a supported adapter, email the specific information related to the
issue to linux.nics@intel.com.
The ixgbevf driver supports 82599 and X540-based virtual function devices that can only be
activated on kernels that support SR-IOV. SR-IOV requires the correct
platform and OS support.
The ixgbevf driver requires the ixgbe driver, version 2.0 or later.
The ixgbevf driver supports virtual functions generated by the ixgbe driver with a max_vfs value of 1 or greater.
For more information on the max_vfs parameter refer to the section on the the ixgbe driver.
The guest OS loading the ixgbevf driver must support MSI-X interrupts.
This driver is only supported as a loadable module at this time.
Intel is not supplying patches against the kernel source to allow for static linking of the driver.
For questions related to hardware requirements, refer to the documentation supplied with your Intel Gigabit adapter.
All hardware requirements listed apply to use with Linux.
Instructions on updating ethtool can be found in the section Additional Configurations later in this document.
VLANs: There is a limit of a total of 64 shared VLANs to 1 or more VFs.
Building and Installation
To build a binary RPM* package of this driver, run 'rpmbuild -tb <filename.tar.gz>'.
Replace <filename.tar.gz> with the specific filename of the driver.
NOTE: For the build to work
properly, the currently running kernel MUST match the version and
configuration of the installed kernel sources. If you have just recompiled
the kernel reboot the system now.
RPM functionality has only been tested in Red Hat distributions.
Move the base driver tar file to the directory of your
choice. For example, use ' /home/username/ ixgbevf or /usr/local/src/
ixgbevf.'.
With 2.6 based kernels also make sure that older e1000e drivers are removed
from the kernel, before loading the new module:
rmmod ixgbevf; modprobe
ixgbevf
Assign an IP address to the interface by entering the
following, where <x> is the interface number:
ifconfig eth<x> <IP_address>
Verify that the interface works. Enter the following, where
<IP_address>
is the IP address for another machine on the same subnet as the interface
that is being tested:
ping <IP_address>
Command Line Parameters
If the driver is built as a module, the following optional parameters are used by entering them on the command
line with the modprobe command using this syntax:
A
descriptor describes a data buffer and attributes related to the data
buffer. This information is accessed by the hardware.
Parameter Name
Valid Range/Settings
Default
Description
InterruptThrottleRate
0,1,956-488281 (0=off, 1=dynamic)
8000
The driver can limit the amount of interrupts per second that the adapter
will generate for incoming packets. It does this by writing a value to
the adapter that is based on the maximum amount of interrupts that the
adapter will generate per second.
Setting InterruptThrottleRate to a value greater or equal to 100
will program the adapter to send out a maximum of that many interrupts
per second, even if more packets have come in. This reduces interrupt
load on the system and can lower CPU utilization under heavy load, but
will increase latency as packets are not processed as quickly.
The default behaviour of the driver previously assumed a static
InterruptThrottleRate
value of 8000, providing a good fallback value for all traffic types,
but lacking in small packet performance and latency. The hardware can
handle many more small packets per second however, and for this reason
an adaptive interrupt moderation algorithm was implemented.
The driver has one adaptive mode (setting 1) in which
it dynamically adjusts the InterruptThrottleRate value based on the traffic that it
receives. After determining the type of incoming traffic in the last
timeframe, it will adjust the InterruptThrottleRate to an appropriate value for that
traffic.
The algorithm classifies the incoming traffic every interval into
classes. Once the class is determined, the InterruptThrottleRate value is adjusted to
suit that traffic type the best. There are three classes defined: "Bulk
traffic", for large amounts of packets of normal size; "Low latency",
for small amounts of traffic and/or a significant percentage of small
packets; and "Lowest latency", for almost completely small packets or
minimal traffic.
In dynamic conservative mode, the InterruptThrottleRate value is set to 4000 for traffic
that falls in class "Bulk traffic". If traffic falls in the "Low
latency"
or "Lowest latency" class, the InterruptThrottleRate is increased stepwise to 20000. This
default mode is suitable for most applications.
For situations where low latency is vital such as cluster or grid
computing, the algorithm can reduce latency even more when
InterruptThrottleRate is set to mode 1. In this mode, the InterruptThrottleRate will be increased stepwise to 70000 for
traffic in class "Lowest latency".
Setting InterruptThrottleRate to 0 turns off any interrupt moderation
and may improve small packet latency, but is generally not suitable
for bulk throughput traffic
NOTE:
Dynamic interrupt throttling is only applicable to adapters
operating in MSI or Legacy interrupt mode, using a single
receive queue.
NOTE:
When ixgbevf is loaded with default settings and multiple adapters are in
use simultaneously, the CPU utilization may increase non-linearly. In
order to limit the CPU utilization without impacting
the overall throughput, we recommend that you load the driver as
follows:
This sets the InterruptThrottleRate to 3000 interrupts/sec for the first,
second, and third instances of the driver. The range of 2000 to 3000
interrupts per second works on a majority of systems and is a good
starting point, but the optimal value will be platform-specific. If CPU
utilization is not a concern, use default driver settings.
Additional Configurations
Configuring the Driver on Different Distributions
Configuring a network driver to load properly when the system is started is
distribution dependent. Typically, the configuration process involves adding an
alias line to /etc/modules.conf or /etc/modprobe.conf as well as editing other
system startup scripts and/or configuration files. Many popular Linux
distributions ship with tools to make these changes for you. To learn the proper
way to configure a network device for your system, refer to your distribution
documentation. If during this process you are asked for the driver or module
name, the name for the Linux Base Driver for the Gigabit Family of Adapters is
ixgbevf.
As an example, if you install the ixgbevf driver for two Gigabit adapters (eth0
and ethX) and want to set the interrupt mode to MSI-X and MSI respectively, add
the following to modules.conf or /etc/modprobe.conf:
alias eth0 ixgbevf
alias eth1 ixgbevf
options ixgbevf InterruptThrottleRate=3,1
Viewing Link Messages
Link messages will not be displayed to the console if the distribution is
restricting system messages. In order to see network driver link messages on
your console, set dmesg to eight by entering the following:
dmesg -n 8
NOTE: This setting is not saved
across reboots.
ethtool
The driver utilizes the ethtool interface for driver configuration and
diagnostics, as well as displaying statistical information. ethtool version 3.0
or later is required for this functionality, although we strongly recommend
downloading the latest version at:
ixgbevf supports MACVLAN on those kernels that have the feature included. Kernel support for MACVLAN can be tested by checking if the MACVLAN driver is loaded. The user can run 'lsmod | grep macvlan' to see if the MACVLAN driver is loaded or run 'modprobe macvlan' to try to load the MACVLAN driver.
It may be necessary to update to a recent release of the iproute2 package to get support of MACVLAN via the 'ip' command.
Known Issues/Troubleshooting
NOTE: After installing the driver, if your Intel Network
Connection is not working, verify that you have installed the correct
driver.
Driver Compilation
When trying to compile the driver by running make install, the following
error may occur:
"Linux kernel source not configured - missing version.h"
To solve this issue, create the version.h file by going to the Linux source tree
and entering:
make include/linux/version.h.
Multiple Interfaces on Same Ethernet Broadcast Network
Due to the default ARP behavior on Linux, it is not possible to have one
system on two IP networks in the same Ethernet broadcast domain (non-partitioned
switch) behave as expected. All Ethernet interfaces will respond to IP traffic
for any IP address assigned to the system. This results in unbalanced receive
traffic.
If you have multiple interfaces in a server, either turn on ARP filtering by
entering:
echo 1 > /proc/sys/net/ipv4/conf/all/arp_filter
(this only works if your kernel's version is higher than 2.4.5)
NOTE: This setting is not saved across reboots. The
configuration change can be made permanent by adding the line:
net.ipv4.conf.all.arp_filter = 1
to the file /etc/sysctl.conf
or,
install the interfaces in separate broadcast domains (either in
different switches or in a switch partitioned to VLANs).
Build error with Asianux 3.0 - redefinition of typedef 'irq_handler_t'
Some systems may experience build issues due to redefinition of irq_handler_t.
To resolve this issue build the driver (step 4 above) using the command:
make CFLAGS_EXTRA=-DAX_RELEASE_CODE=1
install
MSI-X Issues with Kernels between 2.6.19 - 2.6.21 (inclusive)
Kernel panics and instability may be observed on any MSI-X hardware if you
use irqbalance with kernels between 2.6.19 and 2.6.21. If such problems are
encountered, you may disable the irqbalance daemon or upgrade to a newer kernel.
Rx Page Allocation Errors
Page allocation failure. order:0 errors may occur under stress with kernels
2.6.25 and above. This is caused by the way the Linux kernel reports this
stressed condition.
Host may Reboot after Removing PF when VF is Active in Guest
Using kernel versions earlier than 3.2, do not unload the PF driver with
active VFs. Doing this will cause your VFs to stop working until you reload the
PF driver and may cause a spontaneous reboot of your system.
Support
For general information, go to the Intel support website at:
If an issue is identified with the released source code on the supported
kernel with a supported adapter, email the specific information related to the
issue to linux.nics@intel.com.
Intel Corporation, 5200 N.E. Elam Young Parkway, Hillsboro, OR 97124-6497 USA
Intel Corporation assumes no responsibility for errors or omissions in this document.
Nor does Intel make any commitment to update the information contained herein.
Intel, Itanium, and Pentium are trademarks of Intel Corporation in the U.S. and other countries.
*Other names and brands may be claimed as the property of others.
Last modified on 1/25/11 10:21p Revision
LINUX/license.htm 0000755 0000000 0000000 00000035273 11654245266 011027 0 ustar
Software License
INTEL SOFTWARE LICENSE AGREEMENT
IMPORTANT - READ BEFORE COPYING, INSTALLING OR USING.
Do not copy, install, or use this software and any associated materials (collectively, the “Software”) provided under this license agreement (“Agreement”) until you have carefully read the following terms and conditions.
By copying, installing, or otherwise using the Software, you agree to be bound by the terms of this Agreement.
If you do not agree to the terms of this Agreement, do not copy, install, or use the Software.
LICENSES:
Please Note:
If you are a network or system administrator, the “Site License” below shall apply to you.
If you are an end user, the “Single User License” shall apply to you.
If you are an original equipment manufacturer (OEM), the “OEM License” shall apply to you.
SITE LICENSE: You may copy the Software onto your organization’s computers for your organization’s use, and you may make a reasonable number of back-up copies of the Software, subject to these conditions:
This Software is licensed for use only in conjunction with
(a) physical Intel component products, and
(b) virtual ("emulated") devices designed to appear as Intel component products to a Guest operating system running within the context of a virtual machine.
Any other use of the Software, including but not limited to use with non-Intel component products, is not licensed hereunder.
Subject to all of the terms and conditions of this Agreement, Intel Corporation ("Intel") grants to you a non-exclusive, non-assignable, copyright license to use the Materials.
You may not copy, modify, rent, sell, distribute, or transfer any part of the Software except as provided in this Agreement, and you agree to prevent unauthorized copying of the Software.
You may not reverse engineer, decompile, or disassemble the Software.
The Software may include portions offered on terms in addition to those set out here, as set out in a license accompanying those portions.
SINGLE USER LICENSE:
You may copy the Software onto a single computer for your personal use, and you may make one back-up copy of the Software, subject to these conditions:
This Software is licensed for use only in conjunction with
(a) physical Intel component products, and
(b) virtual (“emulated”) devices designed to appear as Intel component products to a Guest operating system running within the context of a virtual machine.
Any other use of the Software, including but not limited to use with non-Intel component products, is not licensed hereunder.
Subject to all of the terms and conditions of this Agreement, Intel Corporation ("Intel") grants to you a non-exclusive, non-assignable, copyright license to use the Materials.
You may not copy, modify, rent, sell, distribute, or transfer any part of the Software except as provided in this Agreement, and you agree to prevent unauthorized copying of the Software.
You may not reverse engineer, decompile, or disassemble the Software.
The Software may include portions offered on terms in addition to those set out here, as set out in a license accompanying those portions.
OEM LICENSE:
You may reproduce and distribute the Software only as an integral part of or incorporated in your product, as a standalone Software maintenance update for existing end users of your products, excluding any other standalone products, or as a component of a larger Software distribution, including but not limited to the distribution of an installation image or a Guest Virtual Machine image, subject to these conditions:
This Software is licensed for use only in conjunction with
(a) physical Intel component products, and
(b) virtual (“emulated”) devices designed to appear as Intel component products to a Guest operating system running within the context of a virtual machine.
Any other use of the Software, including but not limited to use with non-Intel component products, is not licensed hereunder.
Subject to all of the terms and conditions of this Agreement, Intel Corporation ("Intel") grants to you a non-exclusive, non-assignable, copyright license to use the Materials.
You may not copy, modify, rent, sell, distribute or transfer any part of the Software except as provided in this Agreement, and you agree to prevent unauthorized copying of the Software.
You may not reverse engineer, decompile, or disassemble the Software.
You may only distribute the Software to your customers pursuant to a written license agreement.
Such license agreement may be a "break-the-seal" license agreement.
At a minimum such license shall safeguard Intel's ownership rights to the Software.
The Software may include portions offered on terms in addition to those set out here, as set out in a license accompanying those portions.
LICENSE RESTRICTIONS.
You may NOT:
(i) use or copy the Materials except as provided in this Agreement;
(ii) rent or lease the Materials to any third party;
(iii) assign this Agreement or transfer the Materials without the express written consent of Intel;
(iv) modify, adapt, or translate the Materials in whole or in part except as provided in this Agreement;
(v) reverse engineer, decompile, or disassemble the Materials;
(vi) attempt to modify or tamper with the normal function of a license manager that regulates usage of the Materials;
(vii) distribute, sublicense or transfer the Source Code form of any components of the Materials, Redistributables and Sample Source and derivatives thereof to any third party except as provided in this Agreement.
NO OTHER RIGHTS.
No rights or licenses are granted by Intel to you, expressly or by implication, with respect to any proprietary information or patent, copyright, mask work, trademark, trade secret, or other intellectual property right owned or controlled by Intel, except as expressly provided in this Agreement.
Except as expressly provided herein, no license or right is granted to you directly or by implication, inducement, estoppel, or otherwise.
Specifically, Intel grants no express or implied right to you under Intel patents, copyrights, trademarks, or other intellectual property rights.
OWNERSHIP OF SOFTWARE AND COPYRIGHTS.
The Software is licensed, not sold.
Title to all copies of the Software remains with Intel.
The Software is copyrighted and protected by the laws of the United States and other countries and international treaty provisions.
You may not remove any copyright notices from the Software.
You agree to prevent any unauthorized copying of the Software.
Intel may make changes to the Software, or to items referenced therein, at any time without notice, but is not obligated to support or update the Software.
You may transfer the Software only if the recipient agrees to be fully bound by these terms and if you retain no copies of the Software.
ADDITIONAL TERMS FOR PRE-RELEASE SOFTWARE.
If the Software you are installing or using under this Agreement is pre-commercial release or is labeled or otherwise represented as “alpha-“ or “beta-“ versions of the Software ("pre-release Software"), then the following terms apply.
To the extent that any provision in this Section conflicts with any other term(s) or condition(s) in this Agreement with respect to pre-release Software, this Section shall supersede the other term(s) or condition(s), but only to the extent necessary to resolve the conflict.
You understand and acknowledge that the Software is pre-release Software, does not represent the final Software from Intel, and may contain errors and other problems that could cause data loss, system failures, or other errors.
The pre-release Software is provided to you "as-is" and Intel disclaims any warranty or liability to you for any damages that arise out of the use of the pre-release Software.
You acknowledge that Intel has not promised that pre-release Software will be released in the future, that Intel has no express or implied obligation to you to release the pre-release Software and that Intel may not introduce Software that is compatible with the pre-release Software. You acknowledge that the entirety of any research or development you perform that is related to the pre-release Software or to any product making use of or associated with the pre-release Software is done at your own risk.
If Intel has provided you with pre-release Software pursuant to a separate written agreement, your use of the pre-release Software is also governed by such agreement.
LIMITED MEDIA WARRANTY.
If the Software has been delivered by Intel on physical media, Intel warrants the media to be free from material physical defects for a period of ninety days after delivery by Intel.
If such a defect is found, return the media to Intel for replacement or alternate delivery of the Software as Intel may select.
EXCLUSION OF OTHER WARRANTIES.
EXCEPT AS PROVIDED ABOVE, THE SOFTWARE IS PROVIDED "AS IS" WITHOUT ANY EXPRESS OR IMPLIED WARRANTY OF ANY KIND INCLUDING WARRANTIES OF MERCHANTABILITY, NONINFRINGEMENT, OR FITNESS FOR A PARTICULAR PURPOSE.
Intel does not warrant or assume responsibility for the accuracy or completeness of any information, text, graphics, links, or other items contained within the Software.
LIMITATION OF LIABILITY.
IN NO EVENT SHALL INTEL OR ITS SUPPLIERS BE LIABLE FOR ANY DAMAGES WHATSOEVER (INCLUDING, WITHOUT LIMITATION, LOST PROFITS, BUSINESS INTERRUPTION, OR LOST INFORMATION) ARISING OUT OF THE USE OF OR INABILITY TO USE THE SOFTWARE, EVEN IF INTEL HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
SOME JURISDICTIONS PROHIBIT EXCLUSION OR LIMITATION OF LIABILITY FOR IMPLIED WARRANTIES OR CONSEQUENTIAL OR INCIDENTAL DAMAGES, SO THE ABOVE LIMITATION MAY NOT APPLY TO YOU.
YOU MAY ALSO HAVE OTHER LEGAL RIGHTS THAT VARY FROM JURISDICTION TO JURISDICTION.
In the event that you use the Software in conjunction with a virtual (“emulated”) device designed to appear as an Intel component product, you acknowledge that Intel is neither the author nor the creator of the virtual (“emulated”) device.
You understand and acknowledge that Intel makes no representations about the correct operation of the Software when used with a virtual (“emulated”) device, that Intel did not design the Software to operate in conjunction with the virtual (“emulated”) device, and that the Software may not be capable of correct operation in conjunction with the virtual (“emulated”) device.
You agree to assume the risk that the Software may not operate properly in conjunction with the virtual (“emulated”) device.
You agree to indemnify and hold Intel and its officers, subsidiaries and affiliates harmless against all claims, costs, damages, and expenses, and reasonable attorney fees arising out of, directly or indirectly, any claim of product liability, personal injury or death associated with the use of the Software in conjunction with the virtual (“emulated”) device, even if such claim alleges that Intel was negligent regarding the design or manufacture of the Software.
UNAUTHORIZED USE.
THE SOFTWARE IS NOT DESIGNED, INTENDED, OR AUTHORIZED FOR USE IN ANY TYPE OF SYSTEM OR APPLICATION IN WHICH THE FAILURE OF THE SOFTWARE COULD CREATE A SITUATION WHERE PERSONAL INJURY OR DEATH MAY OCCUR (E.G MEDICAL SYSTEMS, LIFE SUSTAINING OR LIFE SAVING SYSTEMS).
If you use the Software for any such unintended or unauthorized use, you shall indemnify and hold Intel and its officers, subsidiaries and affiliates harmless against all claims, costs, damages, and expenses, and reasonable attorney fees arising out of, directly or indirectly, any claim of product liability, personal injury or death associated with such unintended or unauthorized use, even if such claim alleges that Intel was negligent regarding the design or manufacture of the part.
TERMINATION OF THIS AGREEMENT.
Intel may terminate this Agreement at any time if you violate its terms.
Upon termination, you will immediately destroy the Software or return all copies of the Software to Intel.
APPLICABLE LAWS.
Claims arising under this Agreement shall be governed by the laws of the State of California, without regard to principles of conflict of laws.
You agree that the terms of the United Nations Convention on Contracts for the Sale of Goods do not apply to this Agreement.
You may not export the Software in violation of applicable export laws and regulations.
Intel is not obligated under any other agreements unless they are in writing and signed by an authorized representative of Intel.
GOVERNMENT RESTRICTED RIGHTS.
The enclosed Software and documentation were developed at private expense, and are provided with “RESTRICTED RIGHTS.”
Use, duplication, or disclosure by the Government is subject to restrictions as set forth in FAR 52.227-14 and DFARS 252.227-7013 et seq. or its successor.
The use of this product by the Government constitutes acknowledgement of Intel’s proprietary rights in the Software.
Contractor or Manufacturer is Intel.
LANGUAGE; TRANSLATIONS.
In the event that the English language version of this Agreement is accompanied by any other version translated into any other language, such translated version is provided for convenience purposes only and the English language version shall control.
For general information and support, see the Support
page.
If an issue is identified with the released source code on the supported
kernel with a supported adapter, email the specific information related to the
issue to linux.nics@intel.com.
Intel support is available on the web or by phone. Support offers the
most up-to-date information about Intel products, including installation
instructions, troubleshooting tips, and general product information.
LINUX/test_ln.htm 0000755 0000000 0000000 00000010573 11660711056 011041 0 ustar
Test the Adapter
Adapter Testing Using Ethtool
Intel adapters have built-in self-test diagnostics, such as I/O conflicts,
memory faults, EEPROM operability, and basic transmit/receive operation. This
can help determine if there is a hardware fault due to the adapter or cable
connectivity. This testing capability is built into the adapter and is accessed
via the driver. Ethtool (version 1.6 or later) is used as the interface for the diagnostic tests and
results.
Ethtool is an open-source program that can be used as an interface to provide
driver configuration and diagnostics, as well as displaying statistical
information.
To invoke diagnostics from ethtool, enter this command:
ethtool -t <EthX>
where <EthX> is the name of the Ethernet device under test (e.g., "eth0").
Here is a sample of the diagnostics output:
The test result is PASS
Register test (offline).......... Passed
EEPROM test (offline).......... Passed
Interrupt test (offline).......... Passed
Loopback test (offline).......... Passed
Link test (on/offline).......... Passed
By default, the more comprehensive "offline" test set is invoked. This will
momentarily disrupt any active traffic on the device under test. The set of
available diagnostic tests is determined internally by the NIC. The tests that
are run are determined by the ethtool command line parameters.
The following tests are common to many Intel adapters:
Test Name
Description
Test Results
Register Test
Test patterns are written, read and verified through the adapter's
device registers to ensure proper functionality.
Test failure may indicate a faulty adapter.
FIFO Test
This utility will write test bit patterns to the adapter's FIFO
buffers, to make sure the FIFOs are working properly. Not all adapters
have FIFO buffers, so it may not appear in your test results.
Test failure may indicate a faulty adapter.
EEPROM Test
This test is run if the adapter is equipped with this type of
memory. It tests both the readability of the EEPROM and the integrity of
the data via checksum.
Test failure may indicate a faulty adapter.
Interrupt Test
This tests the adapter's ability to generate an interrupt. This test
sets the interrupt cause register and reads the interrupt set register,
verifying the adapter correctly registered an internal interrupt.
Test failure may indicate a faulty adapter.
Loopback Test
There are two internal loopback tests: MAC (media access controller)
Loopback and PHY (LAN controller) Loopback. Neither test requires an
external loopback connection or responder. These tests set the adapter
in the appropriate loopback mode and send packets back through the
adapter's receive circuitry and logic.
Test failure may indicate a faulty adapter.
Link Test
This checks to see whether or not the adapter has established link
with its link partner.
If this test fails, check the cable connection and the status of the
link partner.
Check for interrupt conflicts and sharing problems. Make sure the other adapter supports shared
interrupts. Also, make sure your operating system supports shared interrupts.
Unload all PCI device drivers, then reload all drivers.
Adapter unable to connect to switch at correct speed. Gigabit adapter connects
at 100 Mbps and 10 gigabit adapter connects at 1000 Mbps.
This is applicable only to copper-based connections.
Make sure the adapter and the link partner are set to auto-negotiate.
Verify that you are running the latest operating system
revision for your switch and that the switch is compliant with the proper IEEE
standard:
IEEE 802.3ad-compliant (gigabit over copper)
IEEE 802.3an-compliant (10 gigabit over copper)
The adapter stops working without apparent cause
Run the adapter and network tests described under
"Test
the Adapter".
The Link indicator light is off
Run the adapter and network tests described under
"Test
the Adapter".
Make sure the proper (and latest) driver is loaded.
Make sure that the link partner is configured to
auto-negotiate (or forced to match adapter)
Verify that the switch is IEEE 802.3ad-compliant.
The link light is on, but communications
are not properly established
Make sure the proper (and latest) driver is
loaded.
Both the adapter and its link partner must be set to either
auto-detect or manually
set to the same speed and duplex settings.
NOTE: The adapter's link indicator
light may be on even if
communications between the adapter and its link partner have not been
properly established. Technically, the link indicator
light
represents the presence of a carrier signal but not necessarily the
ability to properly communicate with a link partner. This is
expected behavior and is consistent with IEEE's specification for
physical layer operation.
RX or TX light is off
Network may be idle; try creating traffic while
monitoring the lights.
The diagnostic utility reports the adapter is
"Not enabled by BIOS"
When configuring a multi-adapter environment, you must upgrade all Intel
adapters in the computer to the latest software.
If the computer has trouble detecting all adapters, consider the following:
If you enable Wake on LAN* (WoL) on more than two
adapters, the Wake on LAN feature may overdraw your systems auxiliary power
supply, resulting in the inability to boot the system and other
unpredictable problems. For multiple desktop/management adapters, it is
recommended that you install one adapter at a time and use the IBAUtil
utility (ibautil.exe in \APPS\BOOTAGNT) to disable the WoL feature on adapters
that do not require WoL capabilities. On server adapters, the WoL
feature is disabled by default.
Adapters with Intel Boot Agent enabled will require a
portion of the limited start up memory for each adapter enabled. Disable the
service on adapters that do not need to boot Pre-Boot Execution Environment (PXE).
PCI / PCI-X / PCI Express Configuration
If the adapter is not recognized by your OS or if it does not
work you may need to change some BIOS settings. Try the following
only if you are having problems with the adapter and are familiar with BIOS
settings.
Check to see that the "Plug-and-Play" setting is
compatible with the operating system you are using.
Make sure the slot is enabled.
Install the
adapter in a bus-master slot.
Configure interrupts for level-triggering, as opposed to
edge-triggering.
Reserve interrupts and/or memory addresses. This prevents
multiple buses or bus slots from using the same interrupts. Check the BIOS
for IRQ options for PCI / PCI-X / PCIe.
Here are some examples of BIOS parameters:
PCI / PCI-X / PCIe slot #: Slot where the adapter is installed Master: ENABLED Slave: ENABLED Latency timer: 40 - 80 Interrupt: Choose any one of several that the BIOS provides. Edge-level: Level
The exact wording of the parameters varies with different computers.
Attaining the best speed requires that many components are operating at peak
efficiency. Among them are the following:
Cable quality and length - Do not exceed the maximum
recommended length for your cable type. Shorter lengths often provide better
results. Check for loose or damaged connectors. Check the cable for kinked
or damaged sections.
Bus speed and traffic - The PCI bus speed
accommodates the slowest PCI card installed. Check to see if you have a card
that is slowing down your system.
Processor and Memory - Check your performance
monitoring programs to see if traffic is being affected by your processor
speed, available memory or other processes.
Transmission frame size - Your network performance
may be enhanced by adjusting or maximizing the transmission frame size.
Operating systems, switches and adapters will impose varying limits on
maximum frame size. See the discussion on Jumbo Frames for your OS.
Operating System - Networking feature
implementation will vary by operating system version, such as offloading and multiprocessor threading.
Intel warrants to the original owner that the adapter product delivered in this package will be free from defects in material and workmanship. This warranty does not cover the adapter product if it is damaged in the process of being installed or improperly used.
THE ABOVE WARRANTY IS IN LIEU OF ANY OTHER WARRANTY, WHETHER EXPRESS, IMPLIED OR STATUTORY, INCLUDING BUT NOT LIMITED TO ANY WARRANTY OF NONINFRINGEMENT OF INTELLECTUAL PROPERTY, MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE ARISING OUT OF ANY PROPOSAL, SPECIFICATION, OR SAMPLE.
This warranty does not cover replacement of adapter products damaged by abuse, accident, misuse, neglect, alteration, repair, disaster, improper installation, or improper testing. If the adapter product is found to be defective, Intel, at its option, will replace or repair the hardware product at no charge except as set forth below, or refund your purchase price provided that you deliver the adapter product along with a Return Material Authorization
(RMA) number (see below), along with proof of purchase (if not registered), either to the dealer from whom you purchased it or to Intel with an explanation of any deficiency. If you ship the adapter product, you must assume the risk of damage or loss in transit. You must use the original container (or the equivalent) and pay the shipping charge.
Intel may replace or repair the adapter product with either new or reconditioned parts, and any adapter product, or part thereof replaced by Intel becomes Intel's property. Repaired or replaced adapter products will be returned to you at the same revision level as received or higher, at Intel's option. Intel reserves the right to replace discontinued adapter products with an equivalent current generation adapter product.
Returning a defective product
From North America:
Before returning any adapter product, contact Intel Customer Support and obtain a Return Material Authorization
(RMA) number by calling +1 916-377-7000.
If the Customer Support Group verifies that the adapter product is defective, they will have the RMA department issue you an RMA number to place on the outer package of the adapter product. Intel cannot accept any product without an RMA number on the package.
All other locations:
Return the adapter product to the place of purchase for a refund or replacement.
Intel Adapter Money-back Guarantee (North America Only)
Intel wants you to be completely satisfied with the Intel adapter product that you have purchased. Any time within ninety (90) days of purchase, you may return your Intel adapter to the original place of purchase for a full refund of the purchase price from your dealer. Resellers and distributors, respectively, accepting returns and refunding money back to their customers may return Intel adapters to their original place of purchase. Intel guarantees that it will accept returns under this policy and refund the original purchase price to customers purchasing directly from Intel.
Limitation of Liability and Remedies
INTEL'S SOLE LIABILITY HEREUNDER SHALL BE LIMITED TO DIRECT, OBJECTIVELY MEASURABLE DAMAGES. IN NO EVENT SHALL INTEL HAVE ANY LIABILITY FOR ANY INDIRECT OR SPECULATIVE DAMAGES (INCLUDING, WITHOUT LIMITING THE FOREGOING, CONSEQUENTIAL, INCIDENTAL, AND SPECIAL DAMAGES) INCLUDING, BUT NOT LIMITED TO, INFRINGEMENT OF INTELLECTUAL PROPERTY, REPROCUREMENT COSTS, LOSS OF USE, BUSINESS INTERRUPTIONS, LOSS OF GOODWILL, AND LOSS OF PROFITS, WHETHER ANY SUCH DAMAGES ARISE OUT OF CONTRACT NEGLIGENCE, TORT, OR UNDER ANY WARRANTY, IRRESPECTIVE OF WHETHER INTEL HAS ADVANCE NOTICE OF THE POSSIBILITY OF ANY SUCH DAMAGES. NOTWITHSTANDING THE FOREGOING, INTEL'S TOTAL LIABILITY FOR ALL CLAIMS UNDER THIS AGREEMENT SHALL NOT EXCEED THE PRICE PAID FOR THE PRODUCT. THESE LIMITATIONS ON POTENTIAL LIABILITIES WERE AN ESSENTIAL ELEMENT IN SETTING THE PRODUCT PRICE. INTEL NEITHER ASSUMES NOR AUTHORIZES ANYONE TO ASSUME FOR IT ANY OTHER LIABILITIES.
Some states do not allow the exclusion or limitation of incidental or consequential damages, so the above limitations may not apply to you.
Critical Control Applications: Intel specifically disclaims liability for use of the adapter product in critical control applications (including, for example only, safety or health care control systems, nuclear energy control systems, or air or ground traffic control systems) by Licensee or
Sublicensees, and such use is entirely at the user's risk. Licensee agrees to defend, indemnify, and hold Intel harmless from and against any and all claims arising out of use of the adapter product in such applications by Licensee or
Sublicensees.
Software: Software provided with the adapter product is not covered under the hardware warranty described above. See the applicable software license agreement which shipped with the adapter product for details on any software warranty.
