Problem with RTL8111/8168B card (F12/2.6.31.x kernel)

DelusionsMaster · #1 28th November 2009, 01:50 PM

Hi,

since my update to F12 I've a problem with my network. At system start the network doesn't work (I have to force it manually) and when it starts it is much slower than it should be.

Before proceeding with the report, this is the scenario. This is the card:

Code:

lspci | grep Ether
08:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 02)

and this is my running kernel:

Code:

uname -r
2.6.31.5-127.fc12.x86_64

As I anticipated, every time I boot the link is reported as being down:

Code:

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: 10Mb/s
	Duplex: Half
	Port: MII
	PHYAD: 0
	Transceiver: internal
	Auto-negotiation: on
	Supports Wake-on: pumbg
	Wake-on: g
	Current message level: 0x00000033 (51)
	Link detected: no

I can only bring it up by forcing a 'service network stop/start' or an 'ifdown eth0 -- ifup eth0' (and even this way I sometimes have to trigger the sequence again). This way the link goes up, but at 100mbit and not 1000mbit as it should:

Code:

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

mii-tool output:

Code:

mii-tool eth0
eth0: negotiated 100baseTx-FD flow-control, link ok

The 100mbit is confirmed from the orange light on my router (should be green). 1000mbit is surely supported (as the Supported/Advertised list conforms). I already verified that this is not a cable problem.

Whenever I try to force a 1000mbit using ethtool:

Code:

ethtool -s eth0 speed 1000

I get no output on the console, but the link goes down again (which means I have to force it going up again as already explained). When it goes up, needless to say speed is 100mbit and not 1000mbit.

Digging around I found some older, similar, reports, that suggested making use of the Realtek drivers instead of the provided r8169 driver. I tried the last one (r8168-8.015.00), which supports 2.6.31 kernels: this built a r8168.ko driver, which however was even worse than the r8169 one:

Code:

ethtool eth0
Settings for eth0:
	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: Unknown!
	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: no

I could find no way to bring the link up. I then tried some older driver (pre-015), for which I needed a patch since in 2.6.31 there was an API change regarding network drivers. I used the r8168_scripts.tar.bz2 patch (source: http://www.jamesonwilliams.com/hardy-r8168) and the results were exactly the same: Speed reported as unknown and no way to bring the link up.

Using lsmod I could at least verify different behaviours of the drivers, since with r8169 I get:

Code:

lsmod | grep r8169
r8169                  34004  0 
mii                     5104  1 r8169

while with r8168 I could only get

Code:

lsmod | grep r8168
r8168                  58344  0

showing that the Realtek driver didn't involve the mii driver (whatever this means).

Now, after all these attempts, I really don't know what else to try. In F11 the network surely worked as it should (I guess kernel was 2.6.30ish, can't remember precisely), so either something in the new Fedora release broke it, or the new kernel driver is broken somehow. Do any of you know what may be the cause?

Thanks in advance for all the help you'll be able to provide me with!

Edit: Some additional details. This is a more verbose report from mii-tool:

Code:

mii-tool -vv
eth0: negotiated 100baseTx-FD flow-control, link ok
  registers for MII PHY 32: 
    1000 796d 001c c912 0de1 45e1 0005 0000
    0000 0300 0000 0000 0000 0000 0000 3000
    0000 0000 0000 ec40 1660 0000 0101 2108
    2740 8c00 0040 011a 8404 0000 0000 0000
  product info: vendor 00:07:32, model 17 rev 2
  basic mode:   autonegotiation enabled
  basic status: autonegotiation complete, link ok
  capabilities: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
  advertising:  100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control
  link partner: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control

So no 1000 support seems to be detected by mii-tool (unlike ethtool). Trying to force 1000:

Code:

sudo mii-tool -vv -F 1000baseTx-FD eth0
Invalid media specification '1000baseTx-FD'.

It seems a lot of people generaly suggest using ethtool instead of mii-tool, since it's assumed to be more powerful and complete. Nevertheless, the driver doesn't seem to be listening to what ethtool (while instead causing the link to go down, as already explained). Is there any way I can disable the mii driver or something, if this can help?

DelusionsMaster · #2 29th November 2009, 09:55 AM

Noone with the same problem, not even the same card?
Did I post to the wrong forum, should I try the Hardware section instead?

leigh123linux · #3 29th November 2009, 10:14 AM

Quote:

Originally Posted by DelusionsMaster

Noone with the same problem, not even the same card?
Did I post to the wrong forum, should I try the Hardware section instead?

Moved to Hardware

adrianx · #4 1st December 2009, 09:47 PM

I have the same card - Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 02)

In Fedora 12 x86_64, my wired network connection dies (to DSL router), anywhere from 2 to 20 mins. of having been up.... I haven't tried much debugging yet, because I'm a bit disappointed and tired.

I use a static IP, b.t.w.

My mobile broadband which worked perfectly in F10/11, doesn't work in F12. That made me think that NM was to blame, so I tried disabling it. The problem persisted.

Edit: I keep getting this "kerneloops" which may or may not be relevant:

Code:

WARNING: at net/sched/sch_generic.c:246 dev_watchdog+0xf3/0x164() (Not tainted)
Hardware name: System Product Name
NETDEV WATCHDOG: eth0 (r8169): transmit queue 0 timed out
Modules linked in: fuse sunrpc ip6t_REJECT nf_conntrack_ipv6 ip6table_filter ip6_tables ipv6 cpufreq_ondemand powernow_k8 freq_table dm_multipath uinput snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_usb_audio snd_usb_lib snd_seq usblp amd64_edac_mod snd_pcm snd_rawmidi snd_seq_device edac_core uvcvideo snd_timer snd_hwdep ppdev asus_atk0110 videodev parport_pc r8169 shpchp v4l1_compat snd parport v4l2_compat_ioctl32 mii k8temp snd_page_alloc i2c_piix4 joydev serio_raw soundcore pata_acpi ata_generic pata_atiixp floppy radeon ttm drm_kms_helper drm i2c_algo_bit i2c_core [last unloaded: scsi_wait_scan]
Pid: 0, comm: swapper Not tainted 2.6.31.6-145.fc12.x86_64 #1
...
...

I have submitted it to kerneloops.org via ABRT....

**AdamW** · #5 3rd December 2009, 09:11 PM

bug report:

https://bugzilla.redhat.com/show_bug.cgi?id=538920

ubuntu report:

https://bugs.launchpad.net/bugs/472057

adrianx: did you get a URL for the kerneloops report? I'm having trouble finding it.

adrianx · #6 3rd December 2009, 10:11 PM

Quote:

Originally Posted by AdamW

adrianx: did you get a URL for the kerneloops report? I'm having trouble finding it.

Unfortunately not. The URL according to ABRT was something like submit.kerneloops.org/submit.php (sorry, I'm in F11 right now). I will try to find it in kerneloops - just trying to figure out how the site works.

I've just checked. This is the only feedback I got after the report.

---------- Post added at 12:11 AM CST ---------- Previous post was Yesterday at 11:21 PM CST ----------

Edit: I found something!

I couldn't find my report(s), but I came across this one:

http://www.kerneloops.org/raw.php?ra....cgi?id=538920

gwiesenekker · #7 17th January 2010, 09:42 AM

I was having a similar problem running Fedora Core 12 on a Shutlle XPC X27D, which has the same card:

$ lspci | grep Eth
01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 02)
$ uname -a
Linux xpcx27dp111 2.6.31.9-174.fc12.i686.PAE #1 SMP Mon Dec 21 06:04:56 UTC 2009 i686 i686 i386 GNU/Linux

It was running at 1000Mb as expected

# ethtool eth0 | grep Speed
Speed: 1000Mb/s

Under somewhat heavier network load (after starting zoneminder for example) within half an hour or so the network connection would die, without any error message in dmesg or /var/log/messages. A reboot was required to restore network connectivity.
In my case I could resolve the problem by downloading and installing the Realtek r8168-8.015.00 driver. I blacklisted the r8169 module in /etc/modprobe.d/blacklist.conf:

$ tail -2 /etc/modprobe.d/blacklist.conf
# network problem
blacklist r8169

and installed the Realtek driver:
# cd r8168-8.015.00
# make clean modules
# make install
# depmod -a
# modprobe r8168

and rebooted. The network connection seems to be stable now.

Gijsbert

gwiesenekker · #8 18th January 2010, 08:00 AM

Alas, the network connection now stopped working after 24 hours, so this workaround helps but not enough. I found out that instead of rebooting you can restore network connectivity by stopping the network, unloading and reloading the module and starting the network, so until a fix becomes available you can use the following script as a temporary workaround:

Code:

#!/bin/bash -eu
N=0
GATEWAY=192.168.1.1
while true
do
	if ! ping -c 1 -q $GATEWAY >/dev/null
	then
		if test "$N" -eq 0
		then
			echo `date +%Y-%m-%d:%H:%M:%S` Network down, restarting
		fi
		service network stop
		rmmod r8168
		modprobe r8168
		service network start
		let N=$N+1
	else
		if test "$N" -gt 0
		then
			echo `date +%Y-%m-%d:%H:%M:%S` Network up after $N restarts
			N=0
		fi
	fi
	sleep 60
done

Preferably GATEWAY should be the IP address of your router, but you can use any address like www.google.com if you like, but in that case the network will also be restarted if there is a problem with the network of your provider.
Save this script as /root/network.sh and start it from /etc/rc.local using

nohup /root/network.sh >/root/network.out 2>/root/network.err &

Gijsbert

buurin · #9 19th January 2010, 02:48 AM

I have a RTL8112L ethernet onboard a motherboard, which shares the same "r8168" driver with RTL8111/8168 as found on the motherboard's driver disc. I have it working fine with a plain vanilla 2.6.32.3 kernel with the r8169 driver from the kernel itself and have no problems. I have moved files across it at 54MB/s speeds. Just throwing this out, perhaps you can try a new kernel.