Scheduled Maintenance: We are aware of an issue with Google, AOL, and Yahoo services as email providers which are blocking new registrations. We are trying to fix the issue and we have several internal and external support tickets in process to resolve the issue. Please see: viewtopic.php?t=158230

 

 

 

High RX dropped counter on RTL8101E

Need help with peripherals or devices?
Post Reply
Message
Author
anto
Posts: 12
Joined: 2008-07-02 21:07
Location: Vienna, Austria

High RX dropped counter on RTL8101E

#1 Post by anto »

Hello everybody,

I hope I could get the answers for the issue I have.

On my eth0 interface, the RX dropped counter is quite high as below

Code: Select all

eth0      Link encap:Ethernet  HWaddr 00:1c:c0:32:a5:b4
          inet addr:192.168.102.19  Bcast:192.168.102.23  Mask:255.255.255.248
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:3030 errors:0 dropped:3229297126 overruns:0 frame:0
          TX packets:3353 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:475825 (464.6 KiB)  TX bytes:2332683 (2.2 MiB)
          Interrupt:220 Base address:0xc000
It is a RealTek RTL8101E ethernet controller as shown below

Code: Select all

01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8101E PCI Express Fast Ethernet controller (rev 02)
        Subsystem: Intel Corporation Device 0001
        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: 32 bytes
        Interrupt: pin A routed to IRQ 220
        Region 0: I/O ports at 2000 [size=256]
        Region 2: Memory at 88200000 (64-bit, non-prefetchable) [size=4K]
        Region 4: Memory at 88000000 (64-bit, prefetchable) [size=64K]
        Expansion ROM at 88020000 [disabled] [size=128K]
        Capabilities: [40] Power Management version 3
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-
        Capabilities: [50] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable+
                Address: 00000000fee0300c  Data: 41e1
        Capabilities: [70] Express (v2) Endpoint, MSI 01
                DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s <512ns, L1 <8us
                        ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
                DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
                        RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop-
                        MaxPayload 128 bytes, MaxReadReq 512 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+ Suprise- 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: [ac] MSI-X: Enable- Mask- TabSize=2
                Vector table: BAR=4 offset=00000000
                PBA: BAR=4 offset=00000800
        Capabilities: [cc] Vital Product Data <?>
        Kernel driver in use: r8169
        Kernel modules: r8169
As we can see, that RTL8101E is using the kernel module r8169. Is it compatibility issue? If so, should I use the r8101-1.007.00 driver from RealTek?

Is the high figure of dropped counter because of RTL8101E does not support jumbo frames? But how come, the MTU is only 1500? What is possibly causing that high dropped anyway?

FYI, I am using lenny, but kernel 2.6.25-2-686 from sid as that is the most stable combination for my system so far, after quite a lot of trying different combinations.

Thanks a lot in advance for your help.

Anto

Gunirus
Posts: 1
Joined: 2008-08-03 09:13

Realtek thingie

#2 Post by Gunirus »

http://forums.debian.net/viewtopic.php? ... w=previous

=> I have exactly the same problem, you found a way to solve it?
Thx in advance,

Gunirus

slanbarn
Posts: 91
Joined: 2007-06-03 16:03
Location: sweden

#3 Post by slanbarn »

What about conflicting duplex-settings(full-half-auto negotiation)? maybe bad cables? :D

gkfricke
Posts: 3
Joined: 2008-08-03 05:01

Check driver

#4 Post by gkfricke »

I had this symptom (along with non-performance) with a different Realtek chip (8111C); I did notice though that the dropped packets were counting at a ridiculous rate -- something like 2 billion per second.
You may wish to check the Realtek website for a new driver.

User avatar
brain
Posts: 253
Joined: 2006-04-25 17:15

Re: High RX dropped counter on RTL8101E

#5 Post by brain »

anto wrote:Is the high figure of dropped counter because of RTL8101E does not support jumbo frames? But how come, the MTU is only 1500? What is possibly causing that high dropped anyway?
Taken from drivers/net/r8169.c in the linux kernel

Code: Select all

	/*
	 * The driver does not support incoming fragmented
	 * frames. They are seen as a symptom of over-mtu
	 * sized frames.
	 */
if (unlikely(rtl8169_fragmented_frame(status))) {
	dev->stats.rx_dropped++;
	dev->stats.rx_length_errors++;
	rtl8169_mark_to_asic(desc, tp->rx_buf_sz);
	continue;
}

anto
Posts: 12
Joined: 2008-07-02 21:07
Location: Vienna, Austria

Re: High RX dropped counter on RTL8101E

#6 Post by anto »

Gunirus wrote:=> I have exactly the same problem, you found a way to solve it?
Since about 2 weeks ago, I use the driver from Realtek. And it looks that fixes the problem as the Rx dropped counter is always 0, but I am not sure if that really fixed it.

I still can not figure out how to add that driver into the kernel tree or add that driver into the driver list so it can be loaded automatically during reboot. So I just followed the instruction in the readme file. Could anybody please give me suggestion especially on adding the Realtek driver into the kernel tree, so I can select that on "make menuconfig"?
brain wrote:Taken from drivers/net/r8169.c in the linux kernel

Code: Select all

	/*
	 * The driver does not support incoming fragmented
	 * frames. They are seen as a symptom of over-mtu
	 * sized frames.
	 */
if (unlikely(rtl8169_fragmented_frame(status))) {
	dev->stats.rx_dropped++;
	dev->stats.rx_length_errors++;
	rtl8169_mark_to_asic(desc, tp->rx_buf_sz);
	continue;
}
I am not really good in coding. But as I understood from the above codes, the RX dropped counter will be increased when the incoming packet has the size of more than the MTU size held by the r8169 driver. The thing is, the connection goes to a VLAN which interface has the MTU size of 1500. And all devices connected to that VLAN has exactly the same size of MTU. I thought the MTU size held by r8169 driver is the one on the output of ifconfig, but it looks that r8169 driver held MTU with the size of less than 1500. It does not look like because of something else outside the LAN port (e.g. cable, etc), as the Rx dropped counter is always 0 using Realtek driver (assuming that it is doing the job properly). Is my understanding wrong?

User avatar
brain
Posts: 253
Joined: 2006-04-25 17:15

#7 Post by brain »

If there are ethernet frames on the network with VLAN tagging, this adds 4 extra bytes to each ethernet frame. Maybe this is what's causing the r8169 driver to see the frames as oversized? However, you said "I am using lenny, but kernel 2.6.25-2-686 from sid", and there should be support for VLAN tagging (4 extra bytes) in the r8169 driver.

brain@hammerfall:~$ grep 8169 /boot/config-2.6.25-2-686
CONFIG_R8169=m
CONFIG_R8169_NAPI=y
CONFIG_R8169_VLAN=y

Maybe the VLAN tagging support is broken in the r8169 driver in 2.6.25-2-686? Don't really know, just guessing.

anto
Posts: 12
Joined: 2008-07-02 21:07
Location: Vienna, Austria

Re: High RX dropped counter on RTL8101E

#8 Post by anto »

brain wrote:Maybe the VLAN tagging support is broken in the r8169 driver in 2.6.25-2-686? Don't really know, just guessing.
It is the ethernet driver responsibility to strip off and add VLAN tagging to the incoming and outgoing packets, before and after the packets being processed. So yes, I think there is something wrong with r8169 driver.

I compared linux-source-2.6.25/drivers/net/r8169.c with r8101-1.009.00/src/r8101_n.c. There are a lot of similarities and differences. Particularly about the Rx buffer:

linux-source-2.6.25/drivers/net/r8169.c --> #define RX_BUF_SIZE 1536 /* Rx Buffer size */
r8101-1.009.00/src/r8101.h ----------------> #define RX_BUF_SIZE 1519 /* Rx Buffer size */

So I tried to change the RX_BUF_SIZE on r8169.c to 1519 and also changed below lines from

Code: Select all

static void rtl8169_set_rxbufsize(struct rtl8169_private *tp,
				  struct net_device *dev)
{
	unsigned int mtu = dev->mtu;

	tp->rx_buf_sz = (mtu > RX_BUF_SIZE) ? mtu + ETH_HLEN + 8 : RX_BUF_SIZE;
}
into

Code: Select all

static void rtl8169_set_rxbufsize(struct rtl8169_private *tp,
				  struct net_device *dev)
{
	unsigned int mtu = dev->mtu;

	tp->rx_buf_sz = (mtu > ETH_DATA_LEN) ? mtu + ETH_HLEN + 8 : RX_BUF_SIZE;
}
Then compiled and installed the kernel. But that did not help as the Rx dropped counter was still quite high. I am sure there are other parts that need to be changed, but it is too complicated for me especially that r8169 driver is also used by different ethernet devices. Who decided to combine all of those devices into r8169 driver anyway?

So I think it is better to use the Realtek driver. I would really appreciate any hint to add that driver into the kernel tree, especially of course for kernel source in Debian, not the vanilla one.

biatche
Posts: 2
Joined: 2008-11-13 16:38

#9 Post by biatche »

Hi, I too am suffering this issue, and I don't got a clue on how to fix it.

This happens on my Gigabyte P43-DS3L and P45-DS3R but NOT P35-DS3. I was actually having weird issues with my Intel PRO/1000 MT Dual Port Server Adapter on the first two boards. (I then later discovered these RX dropped packets on the onboard NIC too) I've yet to test it on my P35-DS3, and should it work fine there, I think I'm looking at a bigger issue than I expected. Those with this problem, mind posting your boards?

anto
Posts: 12
Joined: 2008-07-02 21:07
Location: Vienna, Austria

#10 Post by anto »

biatche wrote:Those with this problem, mind posting your boards?
Mine is D945GCLF. But I think this is not board specific issue because some people experience the same problem as mine on different boards, for instance:

http://ubuntuforums.org/showthread.php?t=216767

http://www.usenet-forums.com/linux-netw ... ckets.html

And I think your boards use RTL8111C Ethernet controller which driver was merged into r8169 as well. So I think this is because of very poor support on r8169 driver.

Did you try to use the latest Realtek driver which you can find here?

biatche
Posts: 2
Joined: 2008-11-13 16:38

#11 Post by biatche »

P35-DS3 uses 8111C as well if ive not mistaken

tuxracer
Posts: 434
Joined: 2008-02-11 00:34

#12 Post by tuxracer »

I thought the Gigabyte GA-EP35 boards use a Realtek 8111B LAN chip.

My guess is that's why the one poster is having more issues with the newer 8111C ethernet card in the P45 boards. Just speculating though.

If one downloads the file directly from the Realtek site, it's a file with a .tar.bz2 extension.

I understand you extract it by this command:

tar xvfj file.tar.bz2

What would be next?

Also, where should it be extracted to?

Is there anything else?

Sorry, I'm clueless.

I was curious because I was considering getting a new mobo/system and installing Debian on it. I understand the 8111C LAN chip is an issue for any distro, though.

anto
Posts: 12
Joined: 2008-07-02 21:07
Location: Vienna, Austria

#13 Post by anto »

tuxracer wrote:I thought the Gigabyte GA-EP35 boards use a Realtek 8111B LAN chip.
Did you mean P35-DS3 board? If so, yes. I think I read some where that it uses RTL8111B. It has different chip info in r8169 driver than RTL8111C as below:

Code: Select all

static const struct {
        const char *name;
        u8 mac_version;
        u32 RxConfigMask;       /* Clears the bits supported by this chip */
} rtl_chip_info[] = {
        _R("RTL8169",           RTL_GIGA_MAC_VER_01, 0xff7e1880), // 8169
        _R("RTL8169s",          RTL_GIGA_MAC_VER_02, 0xff7e1880), // 8169S
        _R("RTL8110s",          RTL_GIGA_MAC_VER_03, 0xff7e1880), // 8110S
        _R("RTL8169sb/8110sb",  RTL_GIGA_MAC_VER_04, 0xff7e1880), // 8169SB
        _R("RTL8169sc/8110sc",  RTL_GIGA_MAC_VER_05, 0xff7e1880), // 8110SCd
        _R("RTL8169sc/8110sc",  RTL_GIGA_MAC_VER_06, 0xff7e1880), // 8110SCe
        _R("RTL8168b/8111b",    RTL_GIGA_MAC_VER_11, 0xff7e1880), // PCI-E
        _R("RTL8168b/8111b",    RTL_GIGA_MAC_VER_12, 0xff7e1880), // PCI-E
        _R("RTL8101e",          RTL_GIGA_MAC_VER_13, 0xff7e1880), // PCI-E 8139
        _R("RTL8100e",          RTL_GIGA_MAC_VER_14, 0xff7e1880), // PCI-E 8139
        _R("RTL8100e",          RTL_GIGA_MAC_VER_15, 0xff7e1880), // PCI-E 8139
        _R("RTL8168b/8111b",    RTL_GIGA_MAC_VER_17, 0xff7e1880), // PCI-E
        _R("RTL8101e",          RTL_GIGA_MAC_VER_16, 0xff7e1880), // PCI-E
        _R("RTL8168cp/8111cp",  RTL_GIGA_MAC_VER_18, 0xff7e1880), // PCI-E
        _R("RTL8168c/8111c",    RTL_GIGA_MAC_VER_19, 0xff7e1880), // PCI-E
        _R("RTL8168c/8111c",    RTL_GIGA_MAC_VER_20, 0xff7e1880)  // PCI-E
};
So I think because of that r8169 treats it differently.
tuxracer wrote:If one downloads the file directly from the Realtek site, it's a file with a .tar.bz2 extension.

I understand you extract it by this command:

tar xvfj file.tar.bz2

What would be next?

Also, where should it be extracted to?

Is there anything else?

Sorry, I'm clueless.

I was curious because I was considering getting a new mobo/system and installing Debian on it. I understand the 8111C LAN chip is an issue for any distro, though.
Yes. You should extract .tar.bz using tar xjvf command, in any folder that you like. I have it extracted under /usr/src folder. And then, how about if you read and follow what is written in the "readme" file of that Realtek's driver?

Post Reply