Bug 444966 - r8169 does not work after reboot
r8169 does not work after reboot
Status: CLOSED DUPLICATE of bug 438046
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
i386 Linux
low Severity medium
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2008-05-02 09:31 EDT by Josep
Modified: 2009-03-28 09:22 EDT (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-03-28 09:22:33 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Josep 2008-05-02 09:31:15 EDT
+++ This bug was initially created as a clone of Bug #438046 +++

Description of problem:

After reboot, the my r8169 does not start properly. Must use rmmod and modprobe
to get it working.

Version-Release number of selected component (if applicable):

Only kernel 2.6.24 has the problem. All previous kernels are OK. 

How reproducible:


Steps to Reproduce:
1. Reboot or power on the computer
[root@linus ~]# lsmod | grep r8169
r8169                  28229  0 
[root@linus ~]# /etc/init.d/network restart
Shutting down loopback interface:                          [  OK  ]
Bringing up loopback interface:                            [  OK  ]
Bringing up interface eth0:  
Determining IP information for eth0...PING ( from eth0: 56(84) bytes of data.

--- ping statistics ---
4 packets transmitted, 0 received, +3 errors, 100% packet loss, time 2999ms
, pipe 3
[root@linus ~]# rmmod r8169
[root@linus ~]# lsmod | grep r8169
[root@linus ~]# modprobe r8169
[root@linus ~]# /etc/init.d/network restart
Shutting down interface eth0:                              [  OK  ]
Shutting down loopback interface:                          [  OK  ]
Bringing up loopback interface:                            [  OK  ]
Bringing up interface eth0:  
Determining IP information for eth0... done.
                                                           [  OK  ]
[root@linus ~]# uname -a 
Linux linus.localdomain #1 SMP Wed Mar 12 18:17:20 EDT 2008 i686
athlon i386 GNU/Linux
[root@linus ~]# 

Actual results:

Network card works as expected after rmmod and modprobe. 

Expected results:

Network card should have been working after reboot. 

Additional info:

-- Additional comment from sveinrn@hotmail.com on 2008-03-18 16:59 EST --
I just noticed that mii-tool does not recognize the card after the reboot:

[root@linus ~]# lsmod | grep 8169
r8169                  28229  0 
[root@linus ~]# mii-tool 
no MII interfaces found
[root@linus ~]# 
[root@linus ~]# rmmod r8169
[root@linus ~]# modprobe r8169
[root@linus ~]# 
[root@linus ~]# mii-tool 
eth0: negotiated 100baseTx-FD flow-control, link ok
[root@linus ~]# 

-- Additional comment from harald@redhat.com on 2008-03-31 06:09 EST --
*** Bug 437619 has been marked as a duplicate of this bug. ***

-- Additional comment from loganjerry@gmail.com on 2008-04-03 16:08 EST --
Same problem here.  I've had this machine since FC-5, and have had no problems
on any kernel prior to 2.6.24.  While the machine is trying to initialize eth0
during bootup, it waits for some timeout, then prints a message about a failed
ping.  However, the FROM address of the ping is the one I instructed my DHCP
server to give to my machine, and the TO address is my router/gateway/DHCP
server.  Therefore, DHCP succeeded on the initial boot, and eth0 became unusable

I'm willing to experiment if anyone has any ideas.

-- Additional comment from sveinrn@hotmail.com on 2008-04-07 07:50 EST --
As I can see that several other people have the same problem, I changed the
severity to "medium". Even though it is easy for me to work around this one, it
could be a real showstopper for somebody trying out Linux for their first time. 

-- Additional comment from josep.puigdemont@gmail.com on 2008-04-26 16:05 EST --
Similar problem for Fedora 9 (preview release), which meant Fedora 9 could not
be installed from network, and that network wouldn't work after installation
from DVD/CDs.

I doesn't only happen after reboot, it happens always here.

I noticed that at start up, and just after 1 minute uptime, the r8169 driver had
registered 17 million interrupts, according to /proc/interrupts:
$ grep eth /proc/interrupts
 16:   17132211   IO-APIC-fasteoi   eth0
$ uptime 
 21:02:30 up 1 min,  2 users,  load average: 0.97, 0.44, 0.16

The problem is solved after rmmod, and then modprobe the module again.
This is an extract of dmesg when doing rmmod and modprobe:

ACPI: PCI interrupt for device 0000:00:0b.0 disabled
r8169 Gigabit Ethernet driver 2.2LK-NAPI loaded
ACPI: PCI Interrupt 0000:00:0b.0[A] -> GSI 16 (level, low) -> IRQ 16
eth0: RTL8110s at 0xf8904f00, 00:11:09:ce:a6:ca, XID 04000000 IRQ 16

Is the interrupt different? What does the extra [A] mean after modprobing the

I think the severity should be higher (for some people it might block
installation of F9), but on the other hand it might not affect too many people.
Comment 1 Josep 2008-05-02 09:38:10 EDT
This is the same hardware as in this Fedora 8 installation:
Comment 2 Bug Zapper 2008-05-14 06:30:52 EDT
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
Comment 3 Need Real Name 2008-08-17 20:39:11 EDT
I updated my Fedora installation a while ago to version 9, and the problem was still there. But today I just noticed that I could remove the rmmod/modprobe and the NIC was still working. So I guess that at least part of the problem has been fixed in one of the later kernel updates, but I can't tell the exact version. And of course I don't now if it has been fixed for everyone.
Comment 4 Pablo Iranzo Gómez 2009-02-10 08:50:15 EST
Happens on F10 with updated as 9th February 2009.

Doing the rmmod r8169; modprobe r8169 makes it work again
Comment 5 Josep 2009-02-10 09:16:22 EST
Updating to F10 according to comment #4.
Comment 6 Chuck Ebbert 2009-03-28 09:22:33 EDT

*** This bug has been marked as a duplicate of bug 438046 ***

Note You need to log in before you can comment on or make changes to this bug.