Realtec NIC stopped working, looks like most packets are lost

TiborB · 2010-01-03 21:59:25

Hi,
three days ago I upgraded whole system (inc. to 2.6.32 kernel), and after reboot, network (Realtec card - RTL-8110SC/8169SC) effectively stopped working.
Though everything seems to be set up right.
No error messages in kernel.log, just ".....kernel: r8169: eth0: link up"
according to ifconfig, network is configured properly.

ping somehow works, see below:

$ ping www.sme.sk
PING www.sme.sk (85.xxx.xx.xxx) 56(84) bytes of data.
64 bytes from www.sme.sk (85.248.69.187): icmp_seq=2 ttl=59 time=6.89 ms
^C
--- www.sme.sk ping statistics ---
4 packets transmitted, 1 received, 75% packet loss, time 5040ms
rtt min/avg/max/mdev = 6.895/6.895/6.895/0.000 ms

but most packets are just lost... When pinging IP adresses, it is even worse - no packet transmitted at all. (strange I know)

Web browsers just dont work, only once it succeded to partialy open one website and then stopped downloading data...

Now, I downgraded to 2.6.31 kernel, but the problem is stil here (what is strange, it worked correctly with that kernel before).
With liveCDs everything is all right...

Any ideas?

Tibor

More details:

ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000
    link/ether 00:16:17:d2:e0:94 brd ff:ff:ff:ff:ff:ff
    
    
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: 1000Mb/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

guitou · 2010-01-04 18:44:39

We found the same problem on a NEC laptop.
The NIC does not work anymore using either 2.6.31 or 2.6.32 (tested with both kernel26 and kernel26-firmware packages up/downgraded).
This card is a 10ec:8167 device.
It worked when using previous kernel 2.6.31 (upgrading seems to have triggered something weird).

Trying to ping some local ip results in a lot of packet loss followed by a really high number of hardware interrupts (almost 100k/s while watching /proc/interrupts).
The system load then goes from ~0 to ~0.6.
The network interface is not usable.
Bringing down the interface seems to stop this problem. rmmod'ing the module r8169 as well.

TiborB · 2010-01-04 21:52:37

guitou,
I'm really happy that you confirmed my problem, It seems to be the same issue.
Just to clarify your advice, you suggest to rmmod and then to modprobe r8169 module and it will fix it? If not, what can I do? Try to downgrade to 2.6.30? How? Or buy a new card? Change the distribution?
I would realy appreciate an advice what to do.....

guitou · 2010-01-05 12:59:50

Nop, we observed the same problem but did not manage to find a solution ...
I only wanted to report what we observed.

I think a solution might be to compile the driver from Realtek website but I don't have time to try it.
A colleague is looking into this.
As you can see in the bug FS#17063, the reporter suggests that compiling the driver from the latest source used to solve the same kind of problem.

guitou · 2010-01-05 18:04:10

Ok, something weird again ...

So, the colleague booted its arch this afternoon on a 2.6.31 kernel. The network worked ok ...
Then, she tried to upgrade to 2.6.32 and the problem has returned.
So she downgraded to 2.6.31 and rebooted, the problem persisted.

BUT she tried to halt the system and booted it from scratch on 2.6.31. The NIC is working ...

So it looks like the NIC remembers something from the 2.6.32 driver until you poweroff the system.

TiborB, as a workaround, can you downgrade to 2.6.31, halt your system and then boot it on 2.6.31 ?

(we still have to try to compile the driver, maybe tomorrow)

Last edited by guitou (2010-01-05 18:04:52)

TiborB · 2010-01-05 22:16:36

guitou,
I just tried to compile driver from realtek (r8169-6.011.00.tar.bz2) against 2.6.32, but it failed to compile..... sad....

I'm going to downgrade to 2.6.31 and check if your workaround works.

TiborB · 2010-01-05 23:32:19

kernel 2.6.31 works!! Thank you very much...
As temporary solution it is fine, I added following to /etc/pacman.conf
IgnorePkg=kernel26
IgnorePkg=kernel-headers
IgnorePkg=kernel26-firmware
but over time I will want to upgrade to newer kernel, so I hope, It will be fixed ...

Or if you find a better solution, let me know...

BTW, I did as you suggested, I even turned the swith on the back side of box off, than pushed power button on the front side on (I was said it helps to discharge some current, whatever) and then reverted back button on...

guitou · 2010-01-06 16:56:38

Ok, glad to know that this workaround works for you.

As far as the module is concerned, you can compile this driver if you use the 2.6.32 sources (I compiled it yesterday but did not test with the appropriate hardware). If you try with the 2.6.31 sources, the FS#17063 reporter said that it failed.

So, can you try with the new sources (kernel26, kernel26-firmware and kernel26-headers version 2.6.32) ?
Oh, I just remembered this detail, kernel-headers != kernel26-headers.
If you want to compile an external module, you need kernel26-headers.

Last edited by guitou (2010-01-06 19:44:16)

TiborB · 2010-01-06 21:49:47

guitou,
I decided to skip 2.6.32 kernel alltogether. Unless I run into serious problems with upgrades during 2.6.32 lifetime.
I will upgrade to 2.6.33. Perhaps this will be fixed by that time...
I'm not willing to mess my system again, but I would say that I had all packages (including kernel26-headers) installed on my box, when trying to compile the module.
I'm going to create a second arch linux installation on my box where I will be able to test it, but not right now. Is it important for you to have this feedback from me?

BTW, just for my curiosity, I tried to compile module with current kernel, and it gave same errors.......

BTW2, by my understanding, no package in arch linux (at least not in main repositories) contain kernel source code... According to few wikis, if you need them, you have to download the tarbal manually and unpack it somewhere... But I'm not sure if you really needs kernel sources....

guitou · 2010-01-07 15:13:08

Oh, this is not that important, I just wanted someone else to test since I have no time to do it :-)

I compiled the module using kernel26 and kernel26-headers version 2.6.32.
Are you sure you tried to compile with these packages version 2.6.32 ?

As far as I know, you are correct. No "official" package in Archlinux contains the kernel source code and if you want to compile the kernel, you can get the sources by looking at the kernel26 PKGBUILD file.
However, in our case, I did not say you needed the kernel sources.
You only need kernel26-headers which contains what is needed to compile "out-of-the-tree" drivers (Makefiles, some headers etc...).
I hope you understand what I mean :-)

Kasumi_Ninja · 2010-01-08 12:04:48

This worked for me:

A complete poweroff (AC) from the LAN card by powering off the power source unit (+ rebooting the router + 30 sec waiting) did help.

https://bugs.launchpad.net/ubuntu/+sour … bug/485696

TiborB · 2010-01-08 16:56:34

Kasumi_Ninja,
might be the same problem, but now I dont have 2.6.32 on my PC so I can't confirm that poweroff would work. As I stated above, I will skip 2.6.32 version altogether. In case I have the same problem with 2.6.33, I will try also the power-off. Though, this is only an emergency action, I hope they will fix it and make it work correctly.

tntcoda · 2010-01-10 14:46:08

Does anyone know if this is a known/reported kernel bug?

I have the same issue, but I have no idea what causes it, just want to make sure there's a good chance it will be fixed in the next kernel. Guess I will have to downgrade to 2.6.31 in the mean time

Arch Linux

#1 2010-01-03 21:59:25

Realtec NIC stopped working, looks like most packets are lost

#2 2010-01-04 18:44:39

Re: Realtec NIC stopped working, looks like most packets are lost

#3 2010-01-04 21:52:37

Re: Realtec NIC stopped working, looks like most packets are lost

#4 2010-01-05 12:59:50

Re: Realtec NIC stopped working, looks like most packets are lost

#5 2010-01-05 18:04:10

Re: Realtec NIC stopped working, looks like most packets are lost

#6 2010-01-05 22:16:36

Re: Realtec NIC stopped working, looks like most packets are lost

#7 2010-01-05 23:32:19

Re: Realtec NIC stopped working, looks like most packets are lost

#8 2010-01-06 16:56:38

Re: Realtec NIC stopped working, looks like most packets are lost

#9 2010-01-06 21:49:47

Re: Realtec NIC stopped working, looks like most packets are lost

#10 2010-01-07 15:13:08

Re: Realtec NIC stopped working, looks like most packets are lost

#11 2010-01-08 12:04:48

Re: Realtec NIC stopped working, looks like most packets are lost

#12 2010-01-08 16:56:34

Re: Realtec NIC stopped working, looks like most packets are lost

#13 2010-01-10 14:46:08

Re: Realtec NIC stopped working, looks like most packets are lost

Board footer