weird realtek gigabit ethernet issue

weird realtek gigabit ethernet issue

[Shaya Potter]

[please cc me in any response as not subscribed]

I have an Asus M3A78-EM motherboard with a "Realtek Semiconductor Co.,
Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 02)"
(per lspci)

which is using the r8169 module on ubuntu intrepid (specifically ubuntu
kernel 2.6.27-9-generic)

kernel reports

RTL8168c/8111c at 0xf88be000, 00:22:15:a1:d2:41, XID 3c4000c0 IRQ 222

well, what's the issue, its going crazy on the dropped packets, even
when the only thing connected to it is is an ssh session.

namely ifconfig shows

eth0 Link encap:Ethernet HWaddr 00:22:15:a1:d2:41
inet addr:192.168.0.41 Bcast:192.168.0.255 Mask:255.255.255.0
inet6 addr: fe80::222:15ff:fea1:d241/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:499 errors:0 dropped:2867537736 overruns:0 frame:0
TX packets:538 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:38995 (38.9 KB) TX bytes:87571 (87.5 KB)
Interrupt:222 Base address:0xe000

and the dropped count keeps on cycling through its entire space rapidly.

it's running in gigabit mode

root@nas:/home/spotter# mii-tool
eth0: negotiated 1000baseT-FD flow-control, link ok

I have no idea why.  never seen anything like this before.  been
wondering what could be doing it.

in investigating the driver

/*
 * 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;
}

so it would appear to be some issue relating to fragmented frames.

However, based on the amount of packets received, it seems to be very
strange.

I would have thought maybe it had something to do with jumbo packets,
but all the machines on the net are using an mtu of 1500 currently.

anyways, any explanation, if its not a bug, would be appreciated.

Re: weird realtek gigabit ethernet issue

[Giangiacomo Mariotti]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=UTF-8, Size: 3731 bytes --]

On Mon, Dec 8, 2008 at 6:56 AM, Shaya Potter <spotter@yucs.org> wrote:> [please cc me in any response as not subscribed]>> I have an Asus M3A78-EM motherboard with a "Realtek Semiconductor Co.,> Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 02)"> (per lspci)>> which is using the r8169 module on ubuntu intrepid (specifically ubuntu> kernel 2.6.27-9-generic)>> kernel reports>> RTL8168c/8111c at 0xf88be000, 00:22:15:a1:d2:41, XID 3c4000c0 IRQ 222>> well, what's the issue, its going crazy on the dropped packets, even> when the only thing connected to it is is an ssh session.>> namely ifconfig shows>> eth0 Link encap:Ethernet HWaddr 00:22:15:a1:d2:41> inet addr:192.168.0.41 Bcast:192.168.0.255 Mask:255.255.255.0> inet6 addr: fe80::222:15ff:fea1:d241/64 Scope:Link> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1> RX packets:499 errors:0 dropped:2867537736 overruns:0 frame:0> TX packets:538 errors:0 dropped:0 overruns:0 carrier:0> collisions:0 txqueuelen:1000> RX bytes:38995 (38.9 KB) TX bytes:87571 (87.5 KB)> Interrupt:222 Base address:0xe000>> and the dropped count keeps on cycling through its entire space rapidly.>> it's running in gigabit mode>> root@nas:/home/spotter# mii-tool> eth0: negotiated 1000baseT-FD flow-control, link ok>> I have no idea why.  never seen anything like this before.  been> wondering what could be doing it.>> in investigating the driver>> /*>  * 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;> }>> so it would appear to be some issue relating to fragmented frames.>> However, based on the amount of packets received, it seems to be very> strange.>> I would have thought maybe it had something to do with jumbo packets,> but all the machines on the net are using an mtu of 1500 currently.>> anyways, any explanation, if its not a bug, would be appreciated.> --> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in> the body of a message to majordomo@vger.kernel.org> More majordomo info at  http://vger.kernel.org/majordomo-info.html> Please read the FAQ at  http://www.tux.org/lkml/>Did you try using iproute2 instead of ifconfig? I have the sameproblem with ifconfig, but iproute says that there's no problem:ifconfig :
eth0      Link encap:Ethernet  HWaddr 00:1f:d0:ae:41:0e          inet addr:192.168.1.3  Bcast:192.168.1.255  Mask:255.255.255.0          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1          RX packets:16100 errors:0 dropped:152365729778 overruns:0 frame:0          TX packets:15465 errors:0 dropped:0 overruns:0 carrier:0          collisions:0 txqueuelen:1000          RX bytes:15693968 (14.9 MiB)  TX bytes:2565833 (2.4 MiB)          Interrupt:245 Base address:0xc000
ip -stats link show eth0 :
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_faststate UNKNOWN qlen 1000    link/ether 00:1f:d0:ae:41:0e brd ff:ff:ff:ff:ff:ff    RX: bytes  packets  errors  dropped overrun mcast    15677088   16028    0       0       0       0    TX: bytes  packets  errors  dropped carrier collsns    2536480    15384    0       0       0       0


-- You highest men whom my eyes have seen, this is my doubt about you andmy secret laughter: I guess that you would call my overman—devil!What is great is so alien to your souls that the overman would beterrifying to you in his goodness ...ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

Re: weird realtek gigabit ethernet issue

[Shaya Potter]

Giangiacomo Mariotti wrote:
> On Mon, Dec 8, 2008 at 6:56 AM, Shaya Potter <spotter@yucs.org> wrote:
>> [please cc me in any response as not subscribed]
>>
>> I have an Asus M3A78-EM motherboard with a "Realtek Semiconductor Co.,
>> Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 02)"
>> (per lspci)
>>
>> which is using the r8169 module on ubuntu intrepid (specifically ubuntu
>> kernel 2.6.27-9-generic)
>>
>> kernel reports
>>
>> RTL8168c/8111c at 0xf88be000, 00:22:15:a1:d2:41, XID 3c4000c0 IRQ 222
>>
>> well, what's the issue, its going crazy on the dropped packets, even
>> when the only thing connected to it is is an ssh session.
>>
>> namely ifconfig shows
>>
>> eth0 Link encap:Ethernet HWaddr 00:22:15:a1:d2:41
>> inet addr:192.168.0.41 Bcast:192.168.0.255 Mask:255.255.255.0
>> inet6 addr: fe80::222:15ff:fea1:d241/64 Scope:Link
>> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
>> RX packets:499 errors:0 dropped:2867537736 overruns:0 frame:0
>> TX packets:538 errors:0 dropped:0 overruns:0 carrier:0
>> collisions:0 txqueuelen:1000
>> RX bytes:38995 (38.9 KB) TX bytes:87571 (87.5 KB)
>> Interrupt:222 Base address:0xe000
>>
>> and the dropped count keeps on cycling through its entire space rapidly.
>>
>> it's running in gigabit mode
>>
>> root@nas:/home/spotter# mii-tool
>> eth0: negotiated 1000baseT-FD flow-control, link ok
>>
>> I have no idea why.  never seen anything like this before.  been
>> wondering what could be doing it.
>>
>> in investigating the driver
>>
>> /*
>>  * 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;
>> }
>>
>> so it would appear to be some issue relating to fragmented frames.
>>
>> However, based on the amount of packets received, it seems to be very
>> strange.
>>
>> I would have thought maybe it had something to do with jumbo packets,
>> but all the machines on the net are using an mtu of 1500 currently.
>>
>> anyways, any explanation, if its not a bug, would be appreciated.
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at  http://www.tux.org/lkml/
>>
> Did you try using iproute2 instead of ifconfig? I have the same
> problem with ifconfig, but iproute says that there's no problem:
> ifconfig :
> 
> eth0      Link encap:Ethernet  HWaddr 00:1f:d0:ae:41:0e
>           inet addr:192.168.1.3  Bcast:192.168.1.255  Mask:255.255.255.0
>           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>           RX packets:16100 errors:0 dropped:152365729778 overruns:0 frame:0
>           TX packets:15465 errors:0 dropped:0 overruns:0 carrier:0
>           collisions:0 txqueuelen:1000
>           RX bytes:15693968 (14.9 MiB)  TX bytes:2565833 (2.4 MiB)
>           Interrupt:245 Base address:0xc000
> 
> ip -stats link show eth0 :
> 
> 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
> state UNKNOWN qlen 1000
>     link/ether 00:1f:d0:ae:41:0e brd ff:ff:ff:ff:ff:ff
>     RX: bytes  packets  errors  dropped overrun mcast
>     15677088   16028    0       0       0       0
>     TX: bytes  packets  errors  dropped carrier collsns
>     2536480    15384    0       0       0       0

perhaps, it also show me no dropped packets, but that would indicate a
bug in /proc/net/dev.

root@nas:~# cat /proc/net/dev ; sleep 1; cat /proc/net/dev
Inter-|   Receive                                                |  Transmit
 face |bytes    packets errs drop fifo frame compressed multicast|bytes
   packets errs drop fifo colls carrier compressed
    lo:    6544      87    0    0    0     0          0         0
6544      87    0    0    0     0       0          0
  eth0:3088491699 2376860    0 672445284    0     0          0         0
1288945906 1663182    0    0    0     0       0          0
Inter-|   Receive                                                |  Transmit
 face |bytes    packets errs drop fifo frame compressed multicast|bytes
   packets errs drop fifo colls carrier compressed
    lo:    6544      87    0    0    0     0          0         0
6544      87    0    0    0     0       0          0
  eth0:3088491983 2376864    0 802845154    0     0          0         0
1288948788 1663188    0    0    0     0       0          0

Re: weird realtek gigabit ethernet issue

[Francois Romieu]

Shaya Potter <spotter@yucs.org> :
[...]
> perhaps, it also show me no dropped packets, but that would indicate a
> bug in /proc/net/dev.

It is unrelated.

It should be fixed in mainline as 523a609496dbc3897e530db2a2f27650d125ea00
and in 2.6.27-stable as 6269b8494da80250422ed8ce4e6ee7126c0010aa.

-- 
Ueimor

Re: weird realtek gigabit ethernet issue

[Francois Romieu]

(Ccing l-k as it may be of wider interest)

Giangiacomo Mariotti <giangiacomo.mariotti@gmail.com> :
> 2008/12/11 Francois Romieu <romieu@fr.zoreil.com>:
> > Giangiacomo Mariotti <giangiacomo.mariotti@gmail.com> :
> > [...]
> >> Dec  7 10:13:56 debian-hell kernel: [    4.064402] eth0: RTL8169 at
> >> 0xffffc2000062a000, 00:1f:d0:ae:41:0e, XID 281000c0 IRQ 1270
> >> Dec  7 10:13:56 debian-hell kernel: [    5.325793] eth1: RTL8169 at
> >> 0xffffc20000630000, 00:1f:d0:ae:41:10, XID 281000c0 IRQ 1269
> >> Dec  8 06:09:31 debian-hell kernel: [    6.253241] eth0:
> >> RTL8168d/8111d at 0xffffc2000064e000, 00:1f:d0:ae:41:0e, XID 281000c0
> >> IRQ 1270
> >> Dec  8 06:09:31 debian-hell kernel: [    6.258123] eth1:
> >> RTL8168d/8111d at 0xffffc20000652000, 00:1f:d0:ae:41:10, XID 281000c0
> >> IRQ 1269
[...]
> On Dec 8, at 06, I booted 2.6.28-rc7, while on Dec 7, at 10, I booted
> 2.6.26-1-amd64(debian, based on 2.6.26.8). I can't find any log for
> 2.6.27.8.

Ok. Looking at your logs and at the r8169.c code, here is the story.

1. On December 7, the r8169.c driver identifies your network card as an
   (old) "RTL8169" i.e. RTL_GIGA_MAC_VER_01 in r8169.c. This is the default
   choice when there is no specific match for the XID. You can check this
   in r8169.c::rtl8169_get_mac_version. Below RTL_GIGA_MAC_VER_06, the
   driver assumes that the device includes a "RxMissed" register (see
   r8169.c::rtl8169_rx_missed). This assumption is false for your device
   - as it is on nearly all new 816x flavors nowadays - and you will
   experience a broken rx missed counter in ifconfig's output.

2. On December 8, the r8169 driver identifies your network card as a more
   modern "RTL8168d/8111d" i.e. RTL_GIGA_MAC_VER_25. As far as I know, it
   should be the adequate choice given the XID. r8169.c::rtl8169_rx_missed
   will not try to access the non-existant RxMissed register and your
   stats should be fine.

While the fix for the RxMissed register access is in the stable branch,
it is useless if the adapter is (mis-)detected as an old RTL8169.

So, currently, your rx missed counters should be broken on anything
older than 2.6.28-rc1. If they were vanilla kernel (I have not checked
the content of Debian's kernel), Dec 7 should be broken and Dec 8 should
be ok.

Does the explanation above match your observations ?

Btw I should probably push new RTL_GIGA_MAC_VER_XX into -stable.
   
-- 
Ueimor

Re: weird realtek gigabit ethernet issue

[Giangiacomo Mariotti]

On Thu, Dec 11, 2008 at 11:00 PM, Francois Romieu <romieu@fr.zoreil.com> wrote:
> (Ccing l-k as it may be of wider interest)
>
> Giangiacomo Mariotti <giangiacomo.mariotti@gmail.com> :
>> 2008/12/11 Francois Romieu <romieu@fr.zoreil.com>:
>> > Giangiacomo Mariotti <giangiacomo.mariotti@gmail.com> :
>> > [...]
>> >> Dec  7 10:13:56 debian-hell kernel: [    4.064402] eth0: RTL8169 at
>> >> 0xffffc2000062a000, 00:1f:d0:ae:41:0e, XID 281000c0 IRQ 1270
>> >> Dec  7 10:13:56 debian-hell kernel: [    5.325793] eth1: RTL8169 at
>> >> 0xffffc20000630000, 00:1f:d0:ae:41:10, XID 281000c0 IRQ 1269
>> >> Dec  8 06:09:31 debian-hell kernel: [    6.253241] eth0:
>> >> RTL8168d/8111d at 0xffffc2000064e000, 00:1f:d0:ae:41:0e, XID 281000c0
>> >> IRQ 1270
>> >> Dec  8 06:09:31 debian-hell kernel: [    6.258123] eth1:
>> >> RTL8168d/8111d at 0xffffc20000652000, 00:1f:d0:ae:41:10, XID 281000c0
>> >> IRQ 1269
> [...]
>> On Dec 8, at 06, I booted 2.6.28-rc7, while on Dec 7, at 10, I booted
>> 2.6.26-1-amd64(debian, based on 2.6.26.8). I can't find any log for
>> 2.6.27.8.
>
> Ok. Looking at your logs and at the r8169.c code, here is the story.
>
> 1. On December 7, the r8169.c driver identifies your network card as an
>   (old) "RTL8169" i.e. RTL_GIGA_MAC_VER_01 in r8169.c. This is the default
>   choice when there is no specific match for the XID. You can check this
>   in r8169.c::rtl8169_get_mac_version. Below RTL_GIGA_MAC_VER_06, the
>   driver assumes that the device includes a "RxMissed" register (see
>   r8169.c::rtl8169_rx_missed). This assumption is false for your device
>   - as it is on nearly all new 816x flavors nowadays - and you will
>   experience a broken rx missed counter in ifconfig's output.
>
> 2. On December 8, the r8169 driver identifies your network card as a more
>   modern "RTL8168d/8111d" i.e. RTL_GIGA_MAC_VER_25. As far as I know, it
>   should be the adequate choice given the XID. r8169.c::rtl8169_rx_missed
>   will not try to access the non-existant RxMissed register and your
>   stats should be fine.
>
> While the fix for the RxMissed register access is in the stable branch,
> it is useless if the adapter is (mis-)detected as an old RTL8169.
>
> So, currently, your rx missed counters should be broken on anything
> older than 2.6.28-rc1. If they were vanilla kernel (I have not checked
> the content of Debian's kernel), Dec 7 should be broken and Dec 8 should
> be ok.
>
> Does the explanation above match your observations ?
>
Yes.

> Btw I should probably push new RTL_GIGA_MAC_VER_XX into -stable.
>
> --
> Ueimor
>