A Much Simpler Fix for the r8169 “Link-Down” Problem

June 2008
M	T	W	T	F	S	S
	1
2	3	4	5	6	7	8
9	10	11	12	13	14	15
16	17	18	19	20	21	22
23	24	25	26	27	28	29
30

Filed under Debian, Free Software, Linux, Tips by adam | June 21, 2008 | 133820 hits | 28 comments

There is a widespread problem with the Linux driver for the Realtek 8168/8169 cards where the modules load properly and the card is visible but no link is detected. E.g.:

Jun 21 18:28:41 localhost kernel: r8169: eth0: link down
Jun 21 18:28:41 localhost kernel: ADDRCONF(NETDEV_UP): eth0: link is not ready

There are lots of details and suggested solutions from the Ubuntu people. None of the suggestions worked for me, however. Several of them suggest configuring the card under Windows, but the box containing this device is a single-boot linux fileserver. The “wake-on-LAN” functionality seems to be implicated, but not in a way I can see how to fix.

After much head-banging (in the bad sense), I found a simple solution:

(1) Install ethtool
(2) Modify /etc/network/interfaces as follows (substitute your r8169 interface for ‘eth1’ and other settings accordingly):

iface eth1 inet static
pre-up /usr/sbin/ethtool -s eth1 autoneg off
address 192.168.98.1
netmask 255.255.255.0

This did the trick for me where no other solution would work. Of course, link autodetection no longer occurs, but that’s a small price to pay for connectivity.

This is a Debian etch installation using a slightly more recent kernel (2.6.25-2-686).

As an interesting side note, on this new box, the interface appears as eth0 in the kernel logs, but is actually mapped as eth1. Similarly, a second Ethernet interface appears in the log as a different device number than that by which it is referenced. Any ideas why?

Update 6/22/08: Still not getting 1000BaseT (Gigabit), however. If I force 1000BaseT with ethtool -s eth1 speed 1000, the link goes down again (even with autoneg off). The same card in another box, however, detects the link and goes to 1000BaseT automatically. So I’m stuck at 100BaseT.

Update 6/24/08: Linux 2.6.26-rc5 fixes the problem 100% for me.

[Tags]realtek, r8169, linux, drivers, hacking[/Tags]

28 comments

Matthew W. S. Bell Jun 21

2008 and people still implement link auto-negotiation badly?!
Vincent Bernat Jun 22

Look at /etc/udev/rules.d/persistent-net.rules
Luca Toscano Jun 22

Hi,

I’ve tried to apply your guide to my laptop (dell vostro 1310) and now my r8169 card work perfectly!

Thanks a lot!

Luca
Markus Hochholdinger Jun 22

For me
pre-up /usr/sbin/ethtool -s eth0 duplex full speed 1000
is working very well.
This is my notebook and I noticed when I’m connected to 100MBit/s and switch later to 1GBit/s I mostly ended up with 10 MBit/s or no connection.
Rafael Vuijk Jun 22

I have the same problem. I could get 1000mbit at some point, but not anymore. 100mbit works fine but not what I want. I’ll try to use the driver from Realtek.

adam Jun 22

I couldn’t get the driver from Realtek to compile. I get a series of errors starting with:

/tmp/r8169-6.006.00/src/r8169n.c: In function 'rtl8169initone':
/tmp/r8169-6.006.00/src/r8169n.c:2432: error: implicit declaration of function 'SETMODULEOWNER'
/tmp/r8169-6.006.00/src/r8169n.c:2595: error: 'struct netdevice' has no member named 'poll'
/tmp/r8169-6.006.00/src/r8169n.c:2596: error: 'struct netdevice' has no member named 'weight'

Rafael Vuijk Jun 24

Seems like the netdevice struct misses the member named ‘owner’.
Add #define SETMODULE_OWNER(dev) and it will compile.
adam Jun 24

It turns out it was fixed in 2.6.26-rc5, so I’m all set.
Rafael Vuijk Jun 24

Hard to believe though. It’s been so long :)
At least the source from realtek gave me back 1000mbit for now. I hope not something else is still broken.
Jorj Jul 4

rl8169 not work (((
JWS Aug 10

Thanks for this, it worked for me with the following steps:
- Boot with cable in eth1 (and assign the ip to eth1 also in the interfaces-file)
- When booted plug it into eth0 (change the interfaces-file, and restart network. link becomes ready)
- Bring down eth1 (ifconfig eth1 down)
- Link works again
(where eth0 and eth1 will be the first/second interface)

This is on a Gigabyte mobo with 2 Gigabit NICs, running Debian 2.6.18 kernel

Best way to solve this is just upgrading the kernel :)
plops Jan 11

I just installed a Slack12.2 on a laptop with said chipset : the 2.6.27.7-smp kernel wouldn’t speak to the 100Base-T cable, mii-tool did not find anything…

Well, in fact the “workaround” is stupid : just boot with the damned cable plugged !

I don’t do this normally because the box dual-boots with Vista by default and this bitch would destroy itself, in case it can reach any communication cable… I’ll have to be double cautious :-(

Anyway, problem solved, thanks for the page.
Fremmed Mar 31

I just encountered this very situation on one of my boxen, and I think I may have some new information.

I have two identical 8169 NICs (by C-net IIRC) and after about two weeks of continuous operation, with autoneg ON, running at gigabit, I suddenly get the link down problem, and have to turn autoneg off to get link detection again. however, if I swap the NIC for another, identical, card, I get autoneg operation again, for another couple of weeks (I’ll make a note of the exact time from now on), at which time the same problem develops, until I switch back to the NIC that stopped working the last time!
Colin May 15

Thank you! I’ve been searching for MONTHS on how to make my NIC built-in to my Gigabyte GA-P35-DS3L motherboard work. I’ll still monitor the connection for a couple of days but so far, so good.

The only better solution I can think of is if there was an option for the kernel module itself that would turn off auto negotiation.
MetaYii Jun 5

With slamd64, kernel 2.6.29.4, it recognized the card, loaded the module, but ifconfig reported “no such device”. I came here and followed the hint, placing

/usr/sbin/ethtool -s eth1 autoneg off

at the beginning of the rc.inet1.conf file. It worked. I haven’t tested in gigabit, because my desktop switch is 10 Mb., but I’ll try later (I hope it gives me 1 gb).
Linux Apr 5

My problem is the card slows down when I run rsync.

Offload parameters for eth0:
Cannot get device udp large send offload settings: Operation not supported
rx-checksumming: on
tx-checksumming: off
scatter-gather: off
tcp segmentation offload: off
udp fragmentation offload: off
generic segmentation offload: off
generic-receive-offload: off

Any ideas how to fix that, I am going to try and upgrade the driver today.
fixit Nov 11

You can fix this by editing rc.local and adding

ifconfig eth0 down
sleep 20
ifconfig eth0 up

there seem to be a delay after the driver is loaded during which you can’t set the interface up, but after a short period of time you can do it.
It doesn’t affect the booting time.
shift Mar 22

Upgraded my laptop kernel to 3.3 and this problem is back again, beware.
Chris Mar 12

Running Kernel 2.6.34 and still not working properly

The command

ethtool -s eth0 duplex full speed 100

worked very well. It does something similar like

ifconfig eth0 down
ifconfig eth0 up
mors Jun 15

Hello,
I just want to say thanks.

thanks for ur help.

in fact,we found

“2014 and people still implement link auto-negotiation badly.”
John Mar 26

Ubuntu 16.04, kernel 4.4 with r8169 driver, still have this problem.

Thank you for your article that pointed me to the solution: add `ethernet-autoneg off` to `/etc/network/interfaces`.

Also, “2016 and people still implement link auto-negotiation badly.”
Brock Jun 22

And it continues…

Yep, installed Ubuntu 16.04 LTS server yesterday…

It can ping itself but it cannot see anything on the local network…

Keeps coming back with network unreachable …

The motherboard has a Realtek RTL8169 PCI Gigabit Ethernet Controller.
The add on card has a Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller.

I have only tested the RTL8169 controller so far… but it is acting as described.

Interesting that the problem has existed since 2008…
gastax Sep 2

Same problem here with a Notebook Maxdata Belinea b.book 2 (from 2008) with ethernet device RTL8101/2/6E PCI Express 10ec:8136 Subsystem: 1019:90a0 and Arch Linux.
Since Arch Linux uses netctl (not ifupdown), does anyown know where to place the command*, which works around the bug?

*) ethtool -s enp6s0 speed 100 duplex full autoneg off

Thanks,
gastax
PaceyIV Jul 19

Same problem with my barebone GB-BACE-3150 on Debian 10 @4.19.0-5-amd64
I use this command in my case
sudo ethtool -s enp2s0 speed 1000 duplex full autoneg off

Thanks for your guide.
Joey Apr 8

I have found out that the simple command ethtool -s eth0 wol g doesn’t work in root_crontab file, but creating a simple script with the command inside the script enableNIC in my home folder and then use @reboot //home/name/enableNIC worked great after making it an executable file.

The Substantially Similar Weblog

Search