diff options
Diffstat (limited to 'README')
| -rw-r--r-- | README | 794 |
1 files changed, 794 insertions, 0 deletions
@@ -0,0 +1,794 @@ +e1000e Linux* Base Driver for Intel(R) Network Connection + +========================================================= + +May 15, 2019 + +===================== + +Contents +======== +- Overview +- Identifying Your Adapter +- Building and Installation +- Command Line Parameters +- Additional Features and Configurations +- Speed and Duplex Configuration +- Known Issues +- Support +- License + + +Overview +======== +This driver supports kernel versions 2.4.x, 2.6.x and later. + +Driver information can be obtained using ethtool, lspci, and ifconfig. +Instructions on updating ethtool can be found in the section Additional +Configurations later in this document. +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 +drivers. + +For questions related to hardware requirements, refer to the documentation +supplied with your Intel adapter. All hardware requirements listed apply to use +with Linux. + + +NOTE: The Intel(R) 82562v 10/100 Network Connection only provides 10/100 +support. + + +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 README. +- Install the e1000e driver using the instructions in the Building and + Installation section below. +- 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 +======================== +For information on how to identify your adapter, and for the latest Intel +network drivers, refer to the Intel Support website: +http://www.intel.com/support + + +Building and Installation +========================= + +To build a binary RPM package of this driver +-------------------------------------------- +Note: RPM functionality has only been tested in Red Hat distributions. + +1. Run the following command, where <x.x.x> is the version number for the + driver tar file. + + # rpmbuild -tb e1000e-<x.x.x>.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. + +2. After building the RPM, the last few lines of the tool output contain the + location of the RPM file that was built. Install the RPM with one of the + following commands, where <RPM> is the location of the RPM file: + + # rpm -Uvh <RPM> + or + # dnf/yum localinstall <RPM> + +NOTES: +- To compile the driver on some kernel/arch combinations, you may need to +install a package with the development version of libelf (e.g. libelf-dev, +libelf-devel, elfutilsl-libelf-devel). +- When compiling an out-of-tree driver, details will vary by distribution. +However, you will usually need a kernel-devel RPM or some RPM that provides the +kernel headers at a minimum. The RPM kernel-devel will usually fill in the link +at /lib/modules/'uname -r'/build. + + +To manually build the driver +---------------------------- +1. Move the base driver tar file to the directory of your choice. + For example, use '/home/username/e1000e' or '/usr/local/src/e1000e'. + +2. 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 + +3. Change to the driver src directory, where <x.x.x> is the version number + for the driver tar: + + # cd e1000e-<x.x.x>/src/ + +4. Compile the driver module: + + # make install + + The binary will be installed as: + /lib/modules/<KERNEL VER>/updates/drivers/net/ethernet/intel/e1000e/e1000e.ko + + The install location listed above is the default location. This may differ + for various Linux distributions. + +5. Load the module using the modprobe command. + + To check the version of the driver and then load it: + + # modinfo e1000e + # modprobe e1000e [parameter=port1_value,port2_value] + + Alternately, make sure that any older e1000e drivers are removed from the + kernel before loading the new module: + + # rmmod e1000e; modprobe e1000e + +6. Assign an IP address to the interface by entering the following, + where <ethX> is the interface name that was shown in dmesg after modprobe: + + # ip address add <IP_address>/<netmask bits> dev <ethX> + +7. 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> + +Note: For certain distributions like (but not limited to) Red Hat Enterprise +Linux 7 and Ubuntu, once the driver is installed, you may need to update the +initrd/initramfs file to prevent the OS loading old versions of the e1000e +driver. Use the dracut utility on Red Hat distributions: + # dracut --force + + For Ubuntu: + # update-initramfs -u + + + +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>,...] + +There needs to be a <VAL#> for each network port in the system supported by +this driver. The values will be applied to each instance, in function order. +For example: + +# modprobe e1000e InterruptThrottleRate=16000,16000 + +In this case, there are two network ports supported by e1000e in the system. +The default value for each parameter is generally the recommended setting, +unless otherwise noted. + +NOTE: For more information about the command line parameters, see the +application note at: http://www.intel.com/design/network/applnots/ap450.htm. + +NOTE: A descriptor describes a data buffer and attributes related to the data +buffer. This information is accessed by the hardware. + + +InterruptThrottleRate +--------------------- +Valid Range: +0=off +1=dynamic +4=simplified balancing +<min_ITR>-<max_ITR> +Interrupt Throttle Rate controls the number of 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. +0 = Setting InterruptThrottleRate to 0 turns off any interrupt moderation + and may improve small packet latency. However, this is generally not + suitable for bulk throughput traffic due to the increased CPU utilization + of the higher interrupt rate. +1 = Setting InterruptThrottleRate to Dynamic mode attempts to moderate + interrupts per vector while maintaining very low latency. This can + sometimes cause extra CPU utilization. If planning on deploying e1000e + in a latency sensitive environment, this parameter should be considered. +<min_ITR>-<max_ITR> = + Setting InterruptThrottleRate to a value greater or equal to <min_ITR> + will program the adapter to send at most 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. + +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. + + +RxIntDelay +---------- +Valid Range: 0-65535 (0=off) +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 0. + +RxAbsIntDelay +------------- +Valid Range: 0-65535 (0=off) +This value, in units of 1.024 microseconds, limits the delay in which a +receive interrupt is generated. This value ensures that an interrupt is +generated after the initial packet is received within the set amount of time, +which is useful only if RxIntDelay is non-zero. Proper tuning, along with +RxIntDelay, may improve traffic throughput in specific network conditions. + + +TxIntDelay +---------- +Valid Range: 0-65535 (0=off) +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 +------------- +Valid Range: 0-65535 (0=off) +This value, in units of 1.024 microseconds, limits the delay in which a +transmit interrupt is generated. It is useful only if TxIntDelay is non-zero. +It 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 +--------- +Valid Range: 0-xxxxxxx (0=off) +The driver copies all packets below or equaling this size to a fresh receive +buffer before handing it up the stack. +This parameter differs from other parameters because 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. + +To use copybreak, type: + +# modprobe e1000e.ko copybreak=128 + + +SmartPowerDownEnable +-------------------- +Valid Range: 0-1 +Allows Phy to turn off in lower power states. The user can turn off this +parameter in supported chipsets. + + +KumeranLockLoss +--------------- +Valid Range: 0-1 +This workaround skips resetting the Phy at shutdown for the initial silicon +releases of ICH8 systems. + + +IntMode +------- +Valid Range: 0-2 (0 = Legacy Int, 1 = MSI and 2 = MSI-X) +IntMode controls the allowed 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. + + +CrcStripping +------------ +Valid Range: 0-1 +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 (Energy Efficient Ethernet) +------------------------------- +Valid Range: 0-1 +0 = Disables EEE +1 = Enables EEE + +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 at 1 Gbps and 100 Mbps link speeds. + +NOTES: +- EEE support requires auto-negotiation. +- Both link partners must support EEE. +- EEE is not supported on all Intel(R) Ethernet Network devices or at all link +speeds. + +Example: + +# ethtool --show-eee <ethX> +# ethtool --set-eee <ethX> [eee on|off] + + +Node +---- +Valid Range: 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 modprobe. +The Node parameter allows you to choose 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, part of the +interrupt time could run on a different core than where the memory is +allocated causing slower memory access and impacting throughput, CPU, or both. + + +Additional Features and Configurations +====================================== + +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. Download it at: +https://kernel.org/pub/software/network/ethtool/ + +NOTE: When validating enable/disable tests on some parts (for example, 82578), +it is necessary to add a few seconds between tests when working with ethtool. + + +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. + + +IEEE 1588 Precision Time Protocol (PTP) Hardware Clock (PHC) +------------------------------------------------------------ +Precision Time Protocol (PTP) is used to synchronize clocks in a computer +network. PTP support varies among Intel devices that support this driver. Use +'ethtool -T <ethX>' to get a definitive list of PTP capabilities supported by +the device. + +E1000E_PTP is a compile time flag. The user can enable it at compile time to +add support for PTP from the driver. The flag is used by editing the make file +as follows when it is being compiled: + +# make CFLAGS_EXTRA="-DE1000E_PTP" install + + +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 Base Driver is e1000e. + +For example, if you install the e1000e driver for two 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 + + +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, enter the +following where <ethX> is the interface number: + +# ifconfig <ethX> mtu 9000 up + +Alternatively, you can use the ip command as follows: + +# ip link set mtu 9000 dev <ethX> +# ip link set up dev <ethX> + +This setting is not saved across reboots. The setting change can be made +permanent by adding 'MTU=9000' to the following file: + /etc/sysconfig/network-scripts/ifcfg-<ethX> for RHEL + or + /etc/sysconfig/network/<config_file> for SLES + +NOTE: The maximum MTU setting for jumbo frames is 8996. This corresponds to the +maximum jumbo frame size of 9018 bytes. + +NOTE: Using jumbo frames at 10 or 100 Mbps is not supported and may result in +poor performance or loss of link. + +NOTE: Packet loss may have a greater impact on throughput when you use jumbo +frames. If you observe a drop in performance after enabling jumbo frames, +enabling flow control may mitigate the issue. + +NOTE: The following adapters limit jumbo frames sized packets to a maximum of +4088 bytes: + - Intel(R) 82578DM Gigabit Network Connection + - Intel(R) 82577LM Gigabit Network Connection +- The following adapters do not support jumbo frames: + - Intel(R) PRO/1000 Gigabit Server Adapter + - Intel(R) PRO/1000 PM Network Connection + - Intel(R) 82562G 10/100 Network Connection + - Intel(R) 82562G-2 10/100 Network Connection + - Intel(R) 82562GT 10/100 Network Connection + - Intel(R) 82562GT-2 10/100 Network Connection + - Intel(R) 82562V 10/100 Network Connection + - Intel(R) 82562V-2 10/100 Network Connection + - Intel(R) 82566DC Gigabit Network Connection + - Intel(R) 82566DC-2 Gigabit Network Connection + - Intel(R) 82566DM Gigabit Network Connection + - Intel(R) 82566MC Gigabit Network Connection + - Intel(R) 82566MM Gigabit Network Connection + - Intel(R) 82567V-3 Gigabit Network Connection + - Intel(R) 82577LC Gigabit Network Connection + - Intel(R) 82578DC Gigabit Network Connection +- Jumbo frames cannot be configured on an 82579-based Network device if + MACSec is enabled on the system. + + +Speed and Duplex Configuration +------------------------------ +In addressing speed and duplex configuration issues, you need to distinguish +between copper-based adapters and fiber-based adapters. + +In the default mode, an Intel(R) Ethernet Network Adapter using copper +connections will attempt to auto-negotiate with its link partner to determine +the best setting. If the adapter cannot establish link with the link partner +using auto-negotiation, you may need to manually configure the adapter and link +partner to identical settings to establish link and pass packets. This should +only be needed when attempting to link with an older switch that does not +support auto-negotiation or one that has been forced to a specific speed or +duplex mode. Your link partner must match the setting you choose. 1 Gbps speeds +and higher cannot be forced. Use the autonegotiation advertising setting to +manually set devices for 1 Gbps and higher. + +Speed, duplex, and autonegotiation advertising are configured through the +ethtool* utility. ethtool is included with all versions of Red Hat after Red +Hat 7.2. For the latest version, download and install ethtool from the +following website: + + https://kernel.org/pub/software/network/ethtool/ + +To see the speed configurations your device supports, run the following: + +# ethtool <ethX> + +Caution: Only experienced network administrators should force speed and duplex +or change autonegotiation advertising manually. The settings at the switch must +always match the adapter settings. Adapter performance may suffer or your +adapter may not operate if you configure the adapter differently from your +switch. + +An Intel(R) Ethernet Network Adapter using fiber-based connections, however, +will not attempt to auto-negotiate with its link partner since those adapters +operate only in full duplex and only at their native speed. + + +Wake on LAN (WoL) Support +------------------------- +Some adapters do not support Wake on LAN (WoL). To determine if your adapter +supports WoL, run the following command: + +# ethtool <ethX> + +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: +https://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 shutdown 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. + +NOTE: Wake on LAN is only supported on port A for the following devices: +- Intel(R) PRO/1000 PT Dual Port Network Connection +- Intel(R) PRO/1000 PT Dual Port Server Connection +- Intel(R) PRO/1000 PT Dual Port Server Adapter +- Intel(R) PRO/1000 PF Dual Port Server Adapter +- Intel(R) PRO/1000 PT Quad Port Server Adapter +- Intel(R) Gigabit PT Quad Port Server ExpressModule + + +NAPI +---- +This driver supports NAPI (Rx polling mode). +To disable NAPI, compile the driver module, passing in a configuration option: +# make CFLAGS_EXTRA=-DE1000E_NO_NAPI install +For more information on NAPI, see +https://www.linuxfoundation.org/collaborate/workgroups/networking/napi + + +Known Issues/Troubleshooting +============================ + +Hardware Issues +--------------- +For known hardware and troubleshooting issues, either refer to the "Release +Notes" in your User Guide, or for more detailed information, go to +http://www.intel.com. + +In the search box enter your devices controller ID followed by "spec update" +(i.e., 82599 spec update). The specification update file has complete +information on known hardware issues. + + +Software Issues +--------------- +NOTE: After installing the driver, if your Intel Ethernet Network Connection +is not working, verify that you have installed the correct driver. + +Intel(R) Active Management Technology 2.0, 2.1, 2.5 are not supported in +conjunction with the 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 do not show any errors and will pass traffic. + +This issue may be resolved by updating to the latest kernel and BIOS. You +should use an OS that fully supports Message Signaled Interrupts (MSI) and make +sure that MSI is enabled in your system's BIOS. + + +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: + + # ethtool -e <ethX> + +Offset Values +------ ------ +0x0000 00 12 34 56 fe dc 30 0d 46 f7 f4 00 ff ff ff ff +0x0010 ff ff ff ff 6b 02 8c 10 d9 15 8c 10 86 80 de 83 + ^^ + +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! +The script can be downloaded at +http://e1000.sourceforge.net/files/fixeep-82573-dspd.sh. + + +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 the following: + +# 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 following line to the file /etc/sysctl.conf: + + net.ipv4.conf.all.arp_filter = 1 + +Another alternative is to 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: + +# ethtool -A <ethX> autoneg off rx off + + +Unplugging Network Cable While ethtool -p is Running +---------------------------------------------------- +In kernel versions 2.5.50 and newer, 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 should resolve +the issue. + + +Rx Page Allocation Errors +------------------------- +'Page allocation failure. order:0' errors may occur under stress with kernels +2.6.25 and newer. 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 4 GB as reserved so that the OS will not use these +RAM pages. + +This issue is fixed in kernel version 2.6.21, where the kernel dynamically +detects the mmconfig size by looking at the number of buses that the mmconfig +segment maps to. + +This issue will not be seen on the 32-bit version of EL5. In that case, the +kernel sees that RAM is located around the 256 MB 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 (for example, 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. + + +Support +======= +For general information, go to the Intel support website at: +http://www.intel.com/support/ + +or the Intel Wired Networking project hosted by Sourceforge at: +http://sourceforge.net/projects/e1000 + +If an issue is identified with the released source code on a supported kernel +with a supported adapter, email the specific information related to the issue +to e1000-devel@lists.sf.net. + + +License +======= +This program is free software; you can redistribute it and/or modify it under +the terms and conditions of the GNU General Public License, version 2, as +published by the Free Software Foundation. + +This program is distributed in the hope it will be useful, but WITHOUT ANY +WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A +PARTICULAR PURPOSE. See the GNU General Public License for more details. + +You should have received a copy of the GNU General Public License along with +this program; if not, write to the Free Software Foundation, Inc., 51 Franklin +St - Fifth Floor, Boston, MA 02110-1301 USA. + +The full GNU General Public License is included in this distribution in the +file called "COPYING". + +Copyright(c) 1999 - 2019 Intel Corporation. + + +Trademarks +========== +Intel is a trademark or registered trademark of Intel Corporation or its +subsidiaries in the United States and/or other countries. + +* Other names and brands may be claimed as the property of others. + + |