#46 e1000e/82579LM weird packet loss issue

closed
dertman
e1000e (107)
in-kernel_driver
5
2015-04-06
2011-11-28
Jim Westfall
No

I have a intel DQ67EP desktop board with the following onboard nic.

00:19.0 Ethernet controller: Intel Corporation 82579LM Gigabit Network Connection (rev 04)
Subsystem: Intel Corporation Device 200f
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort-="">SERR- <PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 43
Region 0: Memory at fe600000 (32-bit, non-prefetchable) [size=128K]
Region 1: Memory at fe628000 (32-bit, non-prefetchable) [size=4K]
Region 2: I/O ports at f080 [size=32]
Capabilities: [c8] Power Management version 2
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=1 PME-
Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+
Address: 00000000fee0100c Data: 41d9
Capabilities: [e0] PCI Advanced Features
AFCap: TP+ FLR+
AFCtrl: FLR-
AFStatus: TP-
Kernel driver in use: e1000e
Kernel modules: e1000e

ethtool -i eth0

driver: e1000e
version: 1.6.3-NAPI
firmware-version: 0.13-4
bus-info: 0000:00:19.0

$ uname -a
Linux jwestfall-desktop 2.6.38-12-generic #51-Ubuntu SMP Wed Sep 28 14:27:32 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux

I am observing some weird packet loss issue thats trivial to reproduce.

hostA = DQ67EP board (10.0.0.221)
hostB = Other linux box #1
hostC = Other linux box #2

hostB# ping -f hostA -c 10000
PING 10.0.0.221 (10.0.0.221) 56(84) bytes of data.
...............
--- 10.0.0.221 ping statistics ---
10000 packets transmitted, 9985 received, 0% packet loss, time 1535ms
rtt min/avg/max/mdev = 0.077/0.114/0.354/0.024 ms, ipg/ewma 0.153/0.112 ms

In general there will be 15-20 drops per 10k packets on this ping
flood test.

The weird thing is if I run the following command plus the above ping
flood at the same time, the packetloss will go away.

hostC# hping3 hostA --udp -p 1000 --faster -d 1492
HPING 10.0.0.221 (eth0 10.0.0.221): udp mode set, 28 headers + 1328 data bytes

hostB# ping -f hostA -c 10000
PING 10.0.0.221 (10.0.0.221) 56(84) bytes of data.

--- 10.0.0.221 ping statistics ---
10000 packets transmitted, 10000 received, 0% packet loss, time 2500ms
rtt min/avg/max/mdev = 0.082/0.235/0.364/0.026 ms, ipg/ewma 0.250/0.238 ms

eth0 Link encap:Ethernet HWaddr 00:22:4d:50:fd:1d
inet addr:10.0.0.221 Bcast:10.0.0.255 Mask:255.255.255.0
inet6 addr: fe80::222:4dff:fe50:fd1d/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:9433085 errors:0 dropped:0 overruns:0 frame:0
TX packets:50280 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:7389143658 (7.3 GB) TX bytes:4991608 (4.9 MB)
Interrupt:20 Memory:fe600000-fe620000

ethtool -S eth0

NIC statistics:
rx_packets: 12658127
tx_packets: 50318
rx_bytes: 9977857378
tx_bytes: 5209746
rx_broadcast: 92
tx_broadcast: 6
rx_multicast: 0
tx_multicast: 43
rx_errors: 0
tx_errors: 0
tx_dropped: 0
multicast: 0
collisions: 0
rx_length_errors: 0
rx_over_errors: 0
rx_crc_errors: 0
rx_frame_errors: 0
rx_no_buffer_count: 0
rx_missed_errors: 0
tx_aborted_errors: 0
tx_carrier_errors: 0
tx_fifo_errors: 0
tx_heartbeat_errors: 0
tx_window_errors: 0
tx_abort_late_coll: 0
tx_deferred_ok: 0
tx_single_coll_ok: 0
tx_multi_coll_ok: 0
tx_timeout_count: 0
tx_restart_queue: 0
rx_long_length_errors: 0
rx_short_length_errors: 0
rx_align_errors: 0
tx_tcp_seg_good: 0
tx_tcp_seg_failed: 0
rx_flow_control_xon: 0
rx_flow_control_xoff: 0
tx_flow_control_xon: 0
tx_flow_control_xoff: 0
rx_long_byte_count: 9977857378
rx_csum_offload_good: 286
rx_csum_offload_errors: 0
rx_header_split: 0
alloc_rx_buff_failed: 0
tx_smbus: 0
rx_smbus: 50105
dropped_smbus: 1542
rx_dma_failed: 0
tx_dma_failed: 0

Thanks
jim

Discussion

  • Can you please extend this to 82579V as it has the same symptoms, just loses more packets - about 150 per 10K.

    The motherboard is X79-based MSI X79A-GD65 (8D):

    lspci -vvv -s 00:19.0

    00:19.0 Ethernet controller: Intel Corporation 82579V Gigabit Network Connection (rev 05)
    Subsystem: Micro-Star International Co., Ltd. Device 7760
    Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
    Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort-="">SERR- <PERR- INTx-
    Latency: 0
    Interrupt: pin A routed to IRQ 77
    Region 0: Memory at fb600000 (32-bit, non-prefetchable) [size=128K]
    Region 1: Memory at fb649000 (32-bit, non-prefetchable) [size=4K]
    Region 2: I/O ports at f040 [size=32]
    Capabilities: [c8] Power Management version 2
    Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
    Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=1 PME-
    Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+
    Address: 00000000fee00000 Data: 4052
    Capabilities: [e0] PCI Advanced Features
    AFCap: TP+ FLR+
    AFCtrl: FLR-
    AFStatus: TP-
    Kernel driver in use: e1000e
    Kernel modules: e1000e

    Tried in-kernel default driver and the latest 1.6.3 from this site:

    uname -a

    Linux elrond 3.1.4 #1 SMP PREEMPT Thu Dec 1 01:31:36 EST 2011 i686 Intel(R) Core(TM) i7-3930K CPU @ 3.20GHz GenuineIntel GNU/Linux

    ethtool -i eth0

    driver: e1000e
    version: 1.6.3-NAPI
    firmware-version: 0.13-4
    bus-info: 0000:00:19.0
    supports-statistics: yes
    supports-test: yes
    supports-eeprom-access: yes
    supports-register-dump: yes

    ifconfig eth0

    eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 metric 1
    inet 192.168.0.7 netmask 255.255.255.0 broadcast 192.168.0.255
    ether 8c:89:a5:80:b3:2b txqueuelen 1000 (Ethernet)
    RX packets 4839854 bytes 3211936156 (2.9 GiB)
    RX errors 56 dropped 296 overruns 0 frame 28
    TX packets 5692066 bytes 2100142146 (1.9 GiB)
    TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
    device interrupt 20 memory 0xfb600000-fb620000

    ethtool -S eth0

    NIC statistics:
    rx_packets: 4840115
    tx_packets: 5692370
    rx_bytes: 3231354042
    tx_bytes: 6405340513
    rx_broadcast: 24053
    tx_broadcast: 11497
    rx_multicast: 1031
    tx_multicast: 38
    rx_errors: 56
    tx_errors: 0
    tx_dropped: 0
    multicast: 1031
    collisions: 0
    rx_length_errors: 0
    rx_over_errors: 0
    rx_crc_errors: 28
    rx_frame_errors: 0
    rx_no_buffer_count: 0
    rx_missed_errors: 0
    tx_aborted_errors: 0
    tx_carrier_errors: 0
    tx_fifo_errors: 0
    tx_heartbeat_errors: 0
    tx_window_errors: 0
    tx_abort_late_coll: 0
    tx_deferred_ok: 0
    tx_single_coll_ok: 0
    tx_multi_coll_ok: 0
    tx_timeout_count: 0
    tx_restart_queue: 0
    rx_long_length_errors: 0
    rx_short_length_errors: 0
    rx_align_errors: 0
    tx_tcp_seg_good: 700549
    tx_tcp_seg_failed: 0
    rx_flow_control_xon: 0
    rx_flow_control_xoff: 0
    tx_flow_control_xon: 0
    tx_flow_control_xoff: 0
    rx_long_byte_count: 3231354042
    rx_csum_offload_good: 4786692
    rx_csum_offload_errors: 0
    rx_header_split: 0
    alloc_rx_buff_failed: 0
    tx_smbus: 0
    rx_smbus: 0
    dropped_smbus: 0
    rx_dma_failed: 0
    tx_dma_failed: 0

    10K-packet flood tests between other machines (Intel 82573V and 82573L as well as Atheros AR8121/AR8113/AR8114) work flawlessly. The network is gigabit/full w/o jumbo frames.

    Thanks for your attention.

     
  • Lorenz
    Lorenz
    2011-12-12

    I also had this issue with the 82579LM in my Thinkpad T420 4180W1H. Which version of e1000e are you guys using? Seems to be fixed with 1.6.3 (and some previous versions, too, but I don't know with which exactly), at least for me...

     
  • Jim Westfall
    Jim Westfall
    2011-12-12

    We are both running 1.6.3, its included in the output we provided.

    ethtool -i eth0

    driver: e1000e
    version: 1.6.3-NAPI
    firmware-version: 0.13-4
    bus-info: 0000:00:19.0

     
  • Tushar Dave
    Tushar Dave
    2012-02-02

    Sorry for delay. We have reproduced this issue in our lab and working on root cause.

     
  • Galen Seitz
    Galen Seitz
    2012-02-28

    FWIW, I am experiencing a similar problem, albeit with what is apparently an older driver. I have an Intel DB65AL motherboard with an Intel 82579V network interface. This machine has Mythbuntu 11.10 installed. When it is connected to an HDHomerun ATSC-to-ethernet(100Mb) receiver via a 100Mb switch, everthing works fine. When I connect both devices to a gigabit switch, I experience network packet loss or corruption. Here is an example using the HDHomerun diagnostic tool.

    82579V and HDHomerun both connected to Allied Telesyn FS708E unmanaged 100Mb switch

    hdhomerun_config 1030A79E save /tuner0/debug null
    .........................................................................^C
    -- Video statistics --
    135480 packets received, 0 overflow errors, 0 network errors, 0 transport errors, 0 sequence errors

    82579V and HDHomerun both connected to D-Link DGS-1005D unmanaged gigabit switch.

    hdhomerun_config 1030A79E save /tuner0/debug null
    ..nnn.n.nnnn.n.nnnnnnn..nnnn.nnnnn.nnnnnnnn.nnnn.nnnnnnnnnnnnnnn.n.nnnn.nn^C
    -- Video statistics --
    137148 packets received, 0 overflow errors, 105 network errors, 0 transport errors, 0 sequence errors

    Here is another example using iperf and an ASUS EEE901 netbook instead of the HDHomerun. The netbook has an Attansic L2 10/100Mb network interface.

    82579V and Eee901 both connected to Allied Telesyn FS708E unmanaged 100Mb switch.

    Eee901 client sending to 82579V

    iperf -c myth-master -u -b 20m -t 60

    82579V server receiving from Eee901

    iperf -s -u -i 5

    Server listening on UDP port 5001
    Receiving 1470 byte datagrams
    UDP buffer size: 124 KByte (default)


    [ 3] local 192.168.1.134 port 5001 connected with 192.168.1.246 port 38705
    [ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
    [ 3] 0.0- 5.0 sec 11.9 MBytes 20.0 Mbits/sec 0.013 ms 0/ 8503 (0%)
    [ 3] 5.0-10.0 sec 11.9 MBytes 20.0 Mbits/sec 0.009 ms 0/ 8503 (0%)
    [ 3] 10.0-15.0 sec 11.9 MBytes 20.0 Mbits/sec 0.014 ms 0/ 8504 (0%)
    [ 3] 15.0-20.0 sec 11.9 MBytes 20.0 Mbits/sec 0.006 ms 0/ 8503 (0%)
    [ 3] 20.0-25.0 sec 11.9 MBytes 20.0 Mbits/sec 0.003 ms 0/ 8504 (0%)
    [ 3] 25.0-30.0 sec 11.9 MBytes 20.0 Mbits/sec 0.006 ms 0/ 8503 (0%)
    [ 3] 30.0-35.0 sec 11.9 MBytes 20.0 Mbits/sec 0.005 ms 0/ 8503 (0%)
    [ 3] 35.0-40.0 sec 11.9 MBytes 20.0 Mbits/sec 0.011 ms 0/ 8504 (0%)
    [ 3] 40.0-45.0 sec 11.9 MBytes 20.0 Mbits/sec 0.008 ms 0/ 8503 (0%)
    [ 3] 45.0-50.0 sec 11.9 MBytes 20.0 Mbits/sec 0.002 ms 0/ 8503 (0%)
    [ 3] 50.0-55.0 sec 11.9 MBytes 20.0 Mbits/sec 0.003 ms 0/ 8503 (0%)
    [ 3] 55.0-60.0 sec 11.9 MBytes 20.0 Mbits/sec 0.004 ms 0/ 8503 (0%)
    [ 3] 0.0-60.0 sec 143 MBytes 20.0 Mbits/sec 0.004 ms 0/102040 (0%)
    [ 3] 0.0-60.0 sec 1 datagrams received out-of-order

    82579V and Eee901 both connected to D-Link DGS-1005D unmanaged gigabit switch.

    Eee901 client sending to 82579V

    iperf -c myth-master -u -b 20m -t 60

    82579V server receiving from Eee901

    iperf -s -u -i 5

    Server listening on UDP port 5001
    Receiving 1470 byte datagrams
    UDP buffer size: 124 KByte (default)


    [ 3] local 192.168.1.134 port 5001 connected with 192.168.1.246 port 53138
    [ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
    [ 3] 0.0- 5.0 sec 11.9 MBytes 20.0 Mbits/sec 0.010 ms 0/ 8505 (0%)
    [ 3] 5.0-10.0 sec 11.9 MBytes 20.0 Mbits/sec 0.013 ms 3/ 8503 (0.035%)
    [ 3] 10.0-15.0 sec 11.9 MBytes 20.0 Mbits/sec 0.002 ms 6/ 8504 (0.071%)
    [ 3] 15.0-20.0 sec 11.9 MBytes 20.0 Mbits/sec 0.014 ms 1/ 8503 (0.012%)
    [ 3] 20.0-25.0 sec 11.9 MBytes 20.0 Mbits/sec 0.005 ms 3/ 8503 (0.035%)
    [ 3] 25.0-30.0 sec 11.9 MBytes 20.0 Mbits/sec 0.013 ms 1/ 8504 (0.012%)
    [ 3] 30.0-35.0 sec 11.9 MBytes 20.0 Mbits/sec 0.003 ms 8/ 8503 (0.094%)
    [ 3] 35.0-40.0 sec 11.9 MBytes 20.0 Mbits/sec 0.006 ms 6/ 8504 (0.071%)
    [ 3] 40.0-45.0 sec 11.9 MBytes 20.0 Mbits/sec 0.005 ms 4/ 8503 (0.047%)
    [ 3] 45.0-50.0 sec 11.9 MBytes 20.0 Mbits/sec 0.010 ms 2/ 8503 (0.024%)
    [ 3] 50.0-55.0 sec 11.9 MBytes 20.0 Mbits/sec 0.007 ms 2/ 8504 (0.024%)
    [ 3] 0.0-60.0 sec 143 MBytes 20.0 Mbits/sec 0.005 ms 37/102041 (0.036%)
    [ 3] 0.0-60.0 sec 1 datagrams received out-of-order

    lspci -vvv -s 00:19.0
    00:19.0 Ethernet controller: Intel Corporation 82579V Gigabit Network Connection (rev 04)
    Subsystem: Intel Corporation Device 200b
    Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
    Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort-="">SERR- <PERR- INTx-
    Latency: 0
    Interrupt: pin A routed to IRQ 41
    Region 0: Memory at fe400000 (32-bit, non-prefetchable) [size=128K]
    Region 1: Memory at fe428000 (32-bit, non-prefetchable) [size=4K]
    Region 2: I/O ports at f080 [size=32]
    Capabilities: [c8] Power Management version 2
    Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
    Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=1 PME-
    Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+
    Address: 00000000fee0100c Data: 4191
    Capabilities: [e0] PCI Advanced Features
    AFCap: TP+ FLR+
    AFCtrl: FLR-
    AFStatus: TP-
    Kernel driver in use: e1000e
    Kernel modules: e1000e

    ethtool -i eth0
    driver: e1000e
    version: 1.3.10-k2
    firmware-version: 0.13-4
    bus-info: 0000:00:19.0
    supports-statistics: yes
    supports-test: yes
    supports-eeprom-access: yes
    supports-register-dump: yes

    uname -a
    Linux myth-master 3.0.0-16-generic #28-Ubuntu SMP Fri Jan 27 17:44:39 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

     
  • Galen Seitz
    Galen Seitz
    2012-02-28

    I forgot to mention in my previous comment that I have also observed this problem when using a TRENDnet TEG-S24DG unmanaged gigabit switch. I also tried different cables.

     
  • Tushar Dave
    Tushar Dave
    2012-02-29

    We are still working on resolution of the issue. We will update you asap.

     
  • Galen Seitz
    Galen Seitz
    2012-03-31

    I just built and installed the recently released driver update. The problem I was seeing with streaming UDP traffic from an HDHomeRun appears to be fixed. Thanks!

    $ # 82579V and HDHomerun both connected to TRENDnet TEG-S24DG unmanaged gigabit switch.
    $ hdhomerun_config 1018F24D save /tuner0/debug null
    .......................................................................^C
    -- Video statistics --
    132037 packets received, 0 overflow errors, 0 network errors, 0 transport errors, 0 sequence errors

    $ ethtool -i eth0
    driver: e1000e
    version: 1.10.6-NAPI
    firmware-version: 0.13-4
    bus-info: 0000:00:19.0
    supports-statistics: yes
    supports-test: yes
    supports-eeprom-access: yes
    supports-register-dump: yes

     
  • Jim Westfall
    Jim Westfall
    2012-03-31

    The new driver doesn't resolve the issue for me

    ethtool -i eth0

    driver: e1000e
    version: 1.10.6-NAPI
    firmware-version: 0.13-4
    bus-info: 0000:00:19.0

    ping -f 10.0.0.10 -c 10000

    PING 10.0.0.10 (10.0.0.10) 56(84) bytes of data.
    ..........
    --- 10.0.0.10 ping statistics ---
    10000 packets transmitted, 9990 received, 0% packet loss, time 1441ms
    rtt min/avg/max/mdev = 0.049/0.115/0.511/0.025 ms, ipg/ewma 0.144/0.111 ms

     
  • Galen Seitz
    Galen Seitz
    2012-04-01

    The flood ping test is working for me.

    hostA# lspci -v -s 00:19.0
    00:19.0 Ethernet controller: Intel Corporation 82579V Gigabit Network Connection (rev 04)
    Subsystem: Intel Corporation Device 200b
    Flags: bus master, fast devsel, latency 0, IRQ 41
    Memory at fe400000 (32-bit, non-prefetchable) [size=128K]
    Memory at fe428000 (32-bit, non-prefetchable) [size=4K]
    I/O ports at f080 [size=32]
    Capabilities: <access denied="">
    Kernel driver in use: e1000e
    Kernel modules: e1000e
    hostA# ethtool -i eth0
    driver: e1000e
    version: 1.3.10-k2 <-------- old driver
    firmware-version: 0.13-4
    bus-info: 0000:00:19.0
    supports-statistics: yes
    supports-test: yes
    supports-eeprom-access: yes
    supports-register-dump: yes

    hostB# /sbin/lspci -v -s 05:08.0
    05:08.0 Ethernet controller: Intel Corporation 82541PI Gigabit Ethernet Controller (rev 05)
    Subsystem: Intel Corporation PRO/1000 GT Desktop Adapter
    Flags: bus master, 66MHz, medium devsel, latency 32, IRQ 66
    Memory at d3000000 (32-bit, non-prefetchable) [size=128K]
    Memory at d3020000 (32-bit, non-prefetchable) [size=128K]
    I/O ports at a400 [size=64]
    Expansion ROM at 50000000 [disabled] [size=128K]
    Capabilities: <access denied="">
    Kernel driver in use: e1000
    Kernel modules: e1000
    hostB# /sbin/ethtool -i eth0
    driver: e1000
    version: 7.3.21-k4-3-NAPI
    firmware-version: N/A
    bus-info: 0000:05:08.0

    hostB# ping -f hostA-c 10000
    PING hostA (192.168.1.134) 56(84) bytes of data.
    ........
    --- hostA ping statistics ---
    10000 packets transmitted, 9992 received, 0% packet loss, time 2117ms
    rtt min/avg/max/mdev = 0.091/0.138/0.569/0.023 ms, pipe 2, ipg/ewma 0.211/0.128 ms

    hostA# rmmod e1000e # remove old driver
    hostA# insmod e1000e # install new driver
    hostA# ethtool -i eth0
    driver: e1000e
    version: 1.10.6-NAPI <--------- new driver
    firmware-version: 0.13-4
    bus-info: 0000:00:19.0
    supports-statistics: yes
    supports-test: yes
    supports-eeprom-access: yes
    supports-register-dump: yes

    hostB# ping -f hostA -c 10000
    PING hostA (192.168.1.134) 56(84) bytes of data.

    --- hostA ping statistics ---
    10000 packets transmitted, 10000 received, 0% packet loss, time 1990ms
    rtt min/avg/max/mdev = 0.071/0.129/0.667/0.021 ms, pipe 2, ipg/ewma 0.199/0.129 ms

     
  • Jim Westfall
    Jim Westfall
    2012-04-25

    Hi

    Can we get an update on where this is at for getting fixed? Its been about 2 months since 'will update you asap'.

    thanks
    jim

     
  • Galen Seitz
    Galen Seitz
    2012-05-01

    I take back what I said about the problem being fixed. The problem appears to be reduced somewhat, but it still exists. I'm seeing occasional errors with both flood pings and the HD Homerun diagnostic tool. The frequency of errors seems to depend on what cable I'm using, with a 3 meter Belden Cat 6 cable actually causing more errors than other, lower quality cables.

     
  • I am experiencing the exact same issue under Windows using Intel's latest (17.1) driver. My Intel motherboard (DH61AG) has an 82579V. I also have an HDHomeRun tuner.

    Using a gigabit switch I experience packet loss of about 0.1%. For TCP this is hardly noticable (the infrequent resends of lost packets cause only little extra overhead), but for the UDP stream from the TV tuner it causes lots of glitches. A ping flood from another machine causes similar rates of dropped packets.

    When connecting to the switch at 100Mbps there is no packet loss.

    This issue has been discussed on the HDHomeRun forum from Silicon Dust, but the thread has gone (they do not retain older threads).
    Another discussion here: http://www.avsforum.com/avs-vb/archive/index.php/t-1376542.html
    And finally one on the Intel forum: http://communities.intel.com/message/148986

    Intel has acknowledged this problem more than 6 months ago. They have released multiple updates to the driver (I started at 16.6) since, claiming improvement. There has been improvement (older driver versions had much more packet loss). Some have hinted that it is caused by the PHY wrongfully detecting line noise as the start of an ethernet frame. I personally think this turns out to be an unsolvable hardware problem, and that Intel has decided that packet loss < 1% is the best they can squeeze out of it, and that Intel finds that acceptable.

    I truely hope that you (the Linux driver guys) can prove them wrong!

     
  • Oliver Wagner
    Oliver Wagner
    2013-06-09

    Summary: Issue still happens with e1000e 2.3.2-NAPI

    I appear to have the same issue with a Supermicro X9SCL/X9SCM board which has both a

    product: 82579LM Gigabit Network Connection
    configuration: autonegotiation=on broadcast=yes driver=e1000e driverversion=2.3.2-NAPI duplex=full firmware=0.13-4 latency=0 link=no multicast=yes port=twisted pair slave=yes speed=1Gbit/s

    AND a

    product: 82574L Gigabit Network Connection
    configuration: autonegotiation=on broadcast=yes driver=e1000e driverversion=2.3.2-NAPI duplex=full firmware=2.1-2 latency=0 link=yes multicast=yes port=twisted pair slave=yes speed=1Gbit/s

    on board.

    uname -a:
    Linux store 3.5.0-34-generic #55~precise1-Ubuntu SMP Fri Jun 7 16:25:50 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

    eth0 is the 82579LM, eth1 is the 82574L.

    The remote switch is a HP Procurve 2520G-24-PoE(J9299A). Cabling has been replaced multiple times and measures good with a Fluke analyzer. Also, if I switch cables between eth0 and eth1 at the board, errors remain on eth0.

    I belive the 82574L exhibited an identical problem until I applied the EEPROM fix on it. For the 82579LM, there is no such fix.

    I'm seeing exactly the same behavior as the original bug reporter:

    --- gateway1.w ping statistics ---
    10000 packets transmitted, 9996 received, 0% packet loss, time 2238ms
    rtt min/avg/max/mdev = 0.100/0.180/0.478/0.020 ms, ipg/ewma 0.223/0.180 ms

    ethtool -S eth0
    NIC statistics:
    rx_packets: 50703837
    tx_packets: 38350605
    rx_bytes: 68328042701
    tx_bytes: 12302686771
    rx_broadcast: 27851
    tx_broadcast: 6787
    rx_multicast: 68457
    tx_multicast: 2344
    rx_errors: 452
    tx_errors: 0
    tx_dropped: 0
    multicast: 68457
    collisions: 0
    rx_length_errors: 0
    rx_over_errors: 0
    rx_crc_errors: 226
    rx_frame_errors: 0
    rx_no_buffer_count: 0
    rx_missed_errors: 0
    tx_aborted_errors: 0
    tx_carrier_errors: 0
    tx_fifo_errors: 0
    tx_heartbeat_errors: 0
    tx_window_errors: 0
    tx_abort_late_coll: 0
    tx_deferred_ok: 0
    tx_single_coll_ok: 0
    tx_multi_coll_ok: 0
    tx_timeout_count: 0
    tx_restart_queue: 0
    rx_long_length_errors: 0
    rx_short_length_errors: 0
    rx_align_errors: 0
    tx_tcp_seg_good: 508373
    tx_tcp_seg_failed: 0
    rx_flow_control_xon: 0
    rx_flow_control_xoff: 0
    tx_flow_control_xon: 0
    tx_flow_control_xoff: 0
    rx_csum_offload_good: 50521430
    rx_csum_offload_errors: 0
    rx_header_split: 0
    alloc_rx_buff_failed: 0
    tx_smbus: 0
    rx_smbus: 0
    dropped_smbus: 0
    rx_dma_failed: 0
    tx_dma_failed: 0
    rx_hwtstamp_cleared: 0
    uncorr_ecc_errors: 0
    corr_ecc_errors: 0

    Best Regards,
    Olli

     
  • Todd Fujinaka
    Todd Fujinaka
    2013-07-09

    • assigned_to: Tushar Dave --> Bruce Allan
    • Group: --> in-kernel_driver
     
  • Oliver Wagner
    Oliver Wagner
    2013-07-09

    Problem appears to be reproducible with

    e1000e: Intel(R) PRO/1000 Network Driver - 2.4.14-NAPI

     
  • Oliver Wagner
    Oliver Wagner
    2013-07-09

    This patch (taken from the ML) makes the issue go away in 2.3.2 and 2.4.14:

    @@ -2244,6 +2244,8 @@
    if (ret_val)
    return ret_val;
    pm_phy_reg &= ~HV_PM_CTRL_PLL_STOP_IN_K1_GIGA;
    + / Disable K1 mode when in GIGA mode /
    + pm_phy_reg |= 0x2000;
    ret_val = e1e_wphy(hw, HV_PM_CTRL, pm_phy_reg);
    if (ret_val)
    return ret_val;

     
    • David M.
      David M.
      2014-02-05

      Hi. I'm experiencing what could be the same issue on e1000e 1.3.10-k2.

      Do you know when the driver would be patched with this fix?

      Thanks.

      David

       
  • Todd Fujinaka
    Todd Fujinaka
    2014-02-19

    • assigned_to: Bruce Allan --> dertman
     
  • dertman
    dertman
    2014-03-07

    The problem is related to a power saving mode for the interconnect between the MAC and the PHY. Packet loss can occur in 1000/100 speeds when exiting this mode (K1). There is now a public errata for this issue.

    The newest version of the SourceForge driver (3.0.4.1) has a fix in place for this issue. A fix has also started the process of being pushed upstream into the kernel driver.

    Please let me know if this does not fix your issues.

    Thanks.
    Dave Ertman

     
  • Todd Fujinaka
    Todd Fujinaka
    2015-04-06

    • status: open --> closed
     
  • Todd Fujinaka
    Todd Fujinaka
    2015-04-06

    Closing due to inactivity.