# Massive packet loss, timeouts and lags with Realtek NIC

## ronino

Hello,

I'm running a root server with with a 2.6.34-xen kernel and for unknown reasons, the machine suffers considerable packet loss when pinging it and timeouts and lags in SSH and HTTP connections so it's not yet ready for production.

The ethernet controller is a Realtek RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 02).

Pinging the Dom0 or the machine running with the XEN or a non-XEN kernel always results in a packet loss from 2 % sometimes up to 30 %. So the problem doesn't seem to be XEN-related.

I installed the r8168 driver Realtek provides, but this didn't change much (if anything at all, I'm not sure).

Dropping all packets in iptables' FORWARD chain (via iptables -P FORWARD DROP) or setting net.ipv4.ip_forward = 0 in /etc/sysctl.conf removes the problem, but of course doesn't forward any packets to the DomU's. What I don't understand: What packets are forwarded even for a single ping? How can I find out which forwarded packets cause such trouble?

I couldn't find any log messages so far, nothing in /var/log/messages or other log files.

I also tried the latest 2.6.36-r5 kernel, same issues.

Interestingly, the hoster provides a rescue system based on Debian Lenny and a 2.6.30 kernel which doesn't have the problem at all, though IP forwarding is enabled and no FORWARD packets are dropped.

I'm not the only one at that hoster with this problem, but so far, there is no solution found. The hoster offers adding an Intel NIC to the machine for additional money and others report that there are no packet losses and timeouts with this adapter. But this is no real solution for me.

Now some system data in case it helps:

```
$ lspci -vv

...

06:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 02)

        Subsystem: Micro-Star International Co., Ltd. Device 7522

        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, Cache Line Size: 256 bytes

        Interrupt: pin A routed to IRQ 465

        Region 0: I/O ports at e800 [size=256]

        Region 2: Memory at fbeff000 (64-bit, non-prefetchable) [size=4K]

        Region 4: Memory at f6ff0000 (64-bit, prefetchable) [size=64K]

        [virtual] Expansion ROM at f6f00000 [disabled] [size=128K]

        Capabilities: [40] Power Management version 3

                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0+,D1+,D2+,D3hot+,D3cold+)

                Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-

        Capabilities: [50] MSI: Enable+ Count=1/1 Maskable- 64bit+

                Address: 00000000fee0200c  Data: 41d0

        Capabilities: [70] Express (v1) Endpoint, MSI 01

                DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s <512ns, L1 <64us

                        ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset-

                DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-

                        RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop-

                        MaxPayload 128 bytes, MaxReadReq 4096 bytes

                DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr+ TransPend-

                LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 <512ns, L1 <64us

                        ClockPM+ Surprise- LLActRep- BwNot-

                LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk-

                        ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-

                LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-

        Capabilities: [b0] MSI-X: Enable- Count=2 Masked-

                Vector table: BAR=4 offset=00000000

                PBA: BAR=4 offset=00000800

        Capabilities: [d0] Vital Product Data

                Unknown small resource type 05, will not decode more.

        Kernel driver in use: r8168

        Kernel modules: r8168
```

Here is what ethtool reports:

```
$ ethtool peth0

Settings for peth0:

        Supported ports: [ TP ]

        Supported link modes:   10baseT/Half 10baseT/Full 

                                100baseT/Half 100baseT/Full 

                                1000baseT/Full 

        Supports auto-negotiation: Yes

        Advertised link modes:  10baseT/Half 10baseT/Full 

                                100baseT/Half 100baseT/Full 

                                1000baseT/Full 

        Advertised auto-negotiation: Yes

        Speed: 100Mb/s

        Duplex: Full

        Port: Twisted Pair

        PHYAD: 0

        Transceiver: internal

        Auto-negotiation: on

        Supports Wake-on: pumbg

        Wake-on: g

        Current message level: 0x00000033 (51)

        Link detected: yes
```

```
$ ethtool -i peth0

driver: r8168

version: 8.020.00-NAPI

firmware-version: 

bus-info: 0000:06:00.0
```

From the hoster's rescue system:

```
$ ethtool eth0

Settings for eth0:

        Supported ports: [ TP MII ]

        Supported link modes:   10baseT/Half 10baseT/Full 

                                100baseT/Half 100baseT/Full 

                                1000baseT/Half 1000baseT/Full 

        Supports auto-negotiation: Yes

        Advertised link modes:  10baseT/Half 10baseT/Full 

                                100baseT/Half 100baseT/Full 

                                1000baseT/Half 1000baseT/Full 

        Advertised auto-negotiation: Yes

        Speed: 100Mb/s

        Duplex: Full

        Port: MII

        PHYAD: 0

        Transceiver: internal

        Auto-negotiation: on

        Supports Wake-on: pumbg

        Wake-on: g

        Current message level: 0x00000033 (51)

        Link detected: yes
```

```
$ ethtool -i eth0

driver: r8169

version: 2.3LK-NAPI

firmware-version: 

bus-info: 0000:06:00.0
```

----------

## Mousee

Looks like two different kernel modules to me. Have you tried enabling r8169 (in use by the hoster's rescue system), instead of r8168, to see how it performs?

----------

## ronino

 *Mousee wrote:*   

> Looks like two different kernel modules to me. Have you tried enabling r8169 (in use by the hoster's rescue system), instead of r8168, to see how it performs?

 

Yes. Just enabled it, same issues. The previously used r8168 driver is directly from Realtek, r8169 is the one from the kernel.

```
$ ethtool -i peth0

driver: r8169

version: 2.3LK-NAPI

firmware-version: 

bus-info: 0000:06:00.0
```

ethtool peth0 says exactly the same as on the hoster's rescue system.

----------

## duh

Hi,

I found your post yesterday while debugging my Realtek issues, however I managed to solve the issues I was having. You can read about it here... Hopefully that will resolve your issues as well?

Cheers,

Jeroen

----------

