Bug 438046 - r8169 does not work after reboot
r8169 does not work after reboot
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
10
i386 Linux
low Severity high
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
:
: 437619 444966 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-03-18 15:51 EDT by Need Real Name
Modified: 2009-12-18 01:05 EST (History)
12 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-12-18 01:05:38 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
josep.puigdemont: fedora_requires_release_note?


Attachments (Terms of Use)
output from lspci -vv (10.34 KB, text/plain)
2008-11-18 10:40 EST, Jochen Schmitt
no flags Details
dmesg about when r8168 nic hangs on dhcp after reboot from Windows Vista (31.17 KB, text/plain)
2008-11-20 14:21 EST, Jochen Schmitt
no flags Details
Output of mii-tools -vv before removing r8169 after reboot from Windows Vista (122 bytes, text/plain)
2008-11-24 11:15 EST, Jochen Schmitt
no flags Details
Output of mii-tools -vv before reloading r8169 module after reboot from Windows Vista (696 bytes, text/plain)
2008-11-24 11:17 EST, Jochen Schmitt
no flags Details
Output of demsg on gentoo-2.6.25-r6 (27.07 KB, text/plain)
2008-11-24 13:40 EST, Jochen Schmitt
no flags Details
mii-tool output on 2.6.26.5-49.fc8 (1.05 KB, text/plain)
2008-11-27 14:56 EST, Erik P. Olsen
no flags Details
dmesg output on 2.6.26.5-49.fc8 (23.35 KB, text/plain)
2008-11-27 14:58 EST, Erik P. Olsen
no flags Details
Another user's output from dmesg, lspci -vv, and mii-tool -vv. (38.63 KB, application/x-gzip)
2008-12-24 06:46 EST, Joseph D. Wagner
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
Linux Kernel 12284 None None None Never

  None (edit)
Description Need Real Name 2008-03-18 15:51:23 EDT
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:

Always

Steps to Reproduce:
1. Reboot or power on the computer
2.
[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 192.168.0.1 (192.168.0.1) from
192.168.0.193 eth0: 56(84) bytes of data.

--- 192.168.0.1 ping statistics ---
4 packets transmitted, 0 received, +3 errors, 100% packet loss, time 2999ms
, pipe 3
 failed.
                                                           [FAILED]
[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 2.6.24.3-34.fc8 #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:
Comment 1 Need Real Name 2008-03-18 16:59:06 EDT
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 ~]# 
Comment 2 Harald Hoyer 2008-03-31 06:09:21 EDT
*** Bug 437619 has been marked as a duplicate of this bug. ***
Comment 3 Jerry James 2008-04-03 16:08:05 EDT
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
afterwards.

I'm willing to experiment if anyone has any ideas.
Comment 4 Need Real Name 2008-04-07 07:50:09 EDT
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. 
Comment 5 Josep 2008-04-26 16:05:38 EDT
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
module?

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 6 Burkhard Holl 2008-05-04 16:07:26 EDT
Similar problem for Fedora 8 x86_64 after installation of kernel  2.6.24.3-12
and further kernel releases. Solving the problem with rmmod and modprobe might
be O.K., but  I support the recommendation to increase the severity for this
problem.  
Comment 7 Roger Kavallin 2008-07-13 15:19:49 EDT
I have the same problem on x86-64 with kernel 2.6.25.9-40
r8169 Gigabit Ethernet driver 2.2LK-NAPI loaded
eth0: RTL8168b/8111b at 0xffffc20000336000, 00:1e:8c:17:f0:63, XID 38000000 IRQ 19


Comment 8 Josep 2008-09-06 05:15:23 EDT
Maybe a duplicate of Bug #394221
Comment 9 Erik P. Olsen 2008-10-02 18:38:06 EDT
Same problem here. On Fedora 8 I keep sticking to kernel 2.6.23.1-42.fc8 because it performs OK. But in installing F10 rawhide I can't pass the point of getting an IP-address from dhcp. For me the severity for this problem is the highest because I cannot install and use Fedora 9 and up. My chipset is Realtek 8110S using the broken driver r8169.
Comment 10 Adam Pribyl 2008-10-03 03:29:13 EDT
Please could you check that, as is reported in bug #394221, this problem is not fixed for you with kernels
2.6.26.5-28.fc8 
2.6.27-0.352.rc7.git1.fc10
Comment 11 Erik P. Olsen 2008-10-03 04:23:03 EDT
I can confirm that the problem is not fixed for me with the two kernels mentioned. I have specifically tested this with 32 bit systems which is different from the report in bug 394221. Also my chipset is Realtek 8110S/8169S from MSI mobo K8T Neo2-F which is different from the reporter's chipset.
Comment 12 Josep 2008-10-05 13:14:01 EDT
I can also confirm that the problem is not solved with kernel 2.6.27-0.391.rc8.git.fc10.
Comment 13 Josep 2008-10-19 04:22:45 EDT
Bug #460747, which is a similar issue as this one (if not the same), has been marked as a kernel blocker for the upcoming F10.
Comment 14 Jochen Schmitt 2008-11-17 12:08:31 EST
I have a simular issue.

But if I have booted FreeBSD 7.0 and reboot the system to start Fedora all works fine.
Comment 15 Francois Romieu 2008-11-17 17:07:20 EST
Jochen, can you specify your kernel version and include the XID line printed
by the r8169 driver ?

-- 
Ueimor
Comment 16 Jochen Schmitt 2008-11-18 10:06:18 EST
I will notify, that the issue reported in this bug ticket didn't occurs on gentoo linux.
Comment 17 Jochen Schmitt 2008-11-18 10:39:01 EST
$ uname -a
Linux zeus.herr-schmitt.de 2.6.27.5-37.fc9.x86_64 #1 SMP Wed Nov 12 18:31:37 EST 2008 x86_64 x86_64 x86_64 GNU/Linux

XID-line:

Nov 18 16:21:29 zeus kernel: eth0: RTL8168b/8111b at 0xffffc200008bc000, 00:17:31:8e:92:86, XID 38000000 IRQ 19
Comment 18 Jochen Schmitt 2008-11-18 10:40:02 EST
Created attachment 323914 [details]
output from lspci -vv
Comment 19 Jochen Schmitt 2008-11-18 13:43:06 EST
I assume, taht this is a x86_64 related issue, because it's works on Gentoo Linux and FreeBSD.
Comment 20 Francois Romieu 2008-11-18 14:38:11 EST
Thanks for the information Jochen. 

Do you know the version of the kernel which is used with Gentoo ?

-- 
Ueimor
Comment 21 Jochen Schmitt 2008-11-18 15:01:12 EST
It was kernel-genkernel-2.6.26-gentoo-r1
Comment 22 Francois Romieu 2008-11-19 17:48:51 EST
Jochen, can you attach the complete dmesg of both the gentoo kernel and the
latest fedora 2.6.27 one ?

It would be interesting if you could find a working fc9 2.6.26.something
kernel since its r8169 would be very close to 2.6.26-gentoo-r1. If you do not
have one, I'll backport the relevant r8169 changes from 2.6.27.5-94 to 2.6.26
for you to test with gentoo's kernel so as to know if there is a regression
in the driver itself.

Erik, can you try the latest fc8 kernel and send a 'mii-tool -vv' of the
r8169 interface after the driver is inserted and the interface is up ?
A complete 'dmesg' will be welcome too so that I can compare with some
8169 (XID 04000000) which went correctly through a network fc9 install.

Thanks in advance.

-- 
Ueimor
Comment 23 Erik P. Olsen 2008-11-19 18:38:36 EST
I am sorry. I have changed to using a 3com card since it works OK and I couldn't wait for a fix. I'll to fall back to the faulty chipset but it may take a while because I have to schedule a time slot for it and I am too busy right now. Maybe someone else can do it?
Comment 24 Jochen Schmitt 2008-11-20 13:40:07 EST
I have try to send a email to nicfae@realtek.com.tw, because the reported issue occurs with the original kernel module from realtek too.
Comment 25 Jochen Schmitt 2008-11-20 14:21:29 EST
Created attachment 324220 [details]
dmesg about when r8168 nic hangs on dhcp after reboot from Windows Vista

Now some new information about the issue:

I have updated to the most recent F-9 kernel

]$ uname -a
Linux zeus.herr-schmitt.de 2.6.27.5-41.fc9.x86_64 #1 SMP Thu Nov 13 20:29:07 EST 2008 x86_64 x86_64 x86_64 GNU/Linu

When I' reboot from Windows Vista the boot process will be continued after the DHCP if you wait for a longer time.

After this no nic is available.

If you make a /proc/interupts you will see a lot of it - over 1.5 millions - on IRQ #19 for on CPU.

At last I have remove the kernel module and reload it. when I'm doing a /sbin/dhclient after this I have network access.

The demsg output of this session is attached on this bug.
Comment 26 Jochen Schmitt 2008-11-20 14:31:26 EST
Additional info on comment #25

cat /proc/interupts

          CPU0       CPU1
  0:         32          0   IO-APIC-edge      timer
  1:       3200          0   IO-APIC-edge      i8042
  4:          2          0   IO-APIC-edge
  6:          4          1   IO-APIC-edge      floppy
  7:          0          0   IO-APIC-edge      parport0
  8:          1          0   IO-APIC-edge      rtc0
  9:          0          0   IO-APIC-fasteoi   acpi
 12:        113      21343   IO-APIC-edge      i8042
 14:      23589          0   IO-APIC-edge      ata_piix
 15:          0          0   IO-APIC-edge      ata_piix
 16:      53722          0   IO-APIC-fasteoi   nvidia
 17:          0          0   IO-APIC-fasteoi   uhci_hcd:usb3
 18:          0          0   IO-APIC-fasteoi   uhci_hcd:usb4
 19:   15221868          0   IO-APIC-fasteoi   uhci_hcd:usb5, HDA Intel, eth0
 20:          0          0   IO-APIC-fasteoi   ehci_hcd:usb1, uhci_hcd:usb2
 23:       7548      63655   IO-APIC-fasteoi   ata_piix
NMI:          0          0   Non-maskable interrupts
LOC:     278450     287287   Local timer interrupts
RES:       3158       5173   Rescheduling interrupts
CAL:        639        484   function call interrupts
TLB:       1772       1923   TLB shootdowns
TRM:          0          0   Thermal event interrupts
THR:          0          0   Threshold APIC interrupts
SPU:          0          0   Spurious interrupts
Comment 27 Francois Romieu 2008-11-20 17:57:08 EST
Jochen, is this an Asus P5LD2 SE motherboard ?

I would welcome:
- the dmesg from gentoo
- the output of mii-tool -vv before and after the module removal which
  helps dhclient  to work

Thanks a lot.

-- 
Ueimor
Comment 28 Jochen Schmitt 2008-11-24 10:42:18 EST
(In reply to comment #27)
> Jochen, is this an Asus P5LD2 SE motherboard ?

Yes.
Comment 29 Jochen Schmitt 2008-11-24 11:15:51 EST
Created attachment 324497 [details]
Output of mii-tools -vv before removing r8169 after reboot from Windows Vista
Comment 30 Jochen Schmitt 2008-11-24 11:17:17 EST
Created attachment 324498 [details]
Output of mii-tools -vv before reloading r8169 module after reboot from Windows Vista
Comment 31 Jochen Schmitt 2008-11-24 13:40:07 EST
Created attachment 324523 [details]
Output of demsg on gentoo-2.6.25-r6
Comment 32 Jochen Schmitt 2008-11-25 11:05:51 EST
I have another information which may be important for this issue.

On gentoo I have put the name of the r8169 module into /etc/modulules.autolad.d/kernel-2.6 file. 

Perhaps the issue is a timing issue which rise, if the intiinalization of the module may be exited before the nic initionalization was finisched.
Comment 33 Bug Zapper 2008-11-26 05:12:49 EST
This message is a reminder that Fedora 8 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 8.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '8'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 8's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 8 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 34 Erik P. Olsen 2008-11-27 14:56:16 EST
Created attachment 324913 [details]
mii-tool output on 2.6.26.5-49.fc8

This output was taken after module r8169 was reinstated as requested.
Comment 35 Erik P. Olsen 2008-11-27 14:58:09 EST
Created attachment 324914 [details]
dmesg output on 2.6.26.5-49.fc8

dmesg after r8169 was reinstated as requested.
Comment 36 Adam Pribyl 2008-11-29 08:14:20 EST
Even thou this bug was reported against F8 this is valid for F9 and F10 too. Changing the version to F10, to not close this bug due to houskeeping.
Comment 37 Joseph D. Wagner 2008-12-23 21:41:08 EST
Confirming bug still valid against kernel-2.6.27.7-134.fc10.x86_64.
http://www.smolts.org/show?uuid=pub_22376918-aed0-4812-ae6b-3daaf8aa59d9

I don't know if this is just a coincidence, but if I put "nousb" on the kernel boot parameters, the problem disappears.  Could there be some conflict between the two, possibly IRQ?
Comment 38 Joseph D. Wagner 2008-12-24 06:46:06 EST
Created attachment 327805 [details]
Another user's output from dmesg, lspci -vv, and mii-tool -vv.
Comment 39 Joseph D. Wagner 2009-01-07 09:09:57 EST
Confirming bug still valid against kernel-2.6.27.9-159.fc10.x86_64.
Comment 40 Jochen Schmitt 2009-02-05 15:10:13 EST
In the last time I have installed FreeBSD 7.1 amd64 in a parallel partition on my system. I was able to reproduced the reported issue even on this evil system. As far as I can recorgnise is, that is a x86_64 specific issue.
Comment 41 Alvaro 2009-03-16 15:43:30 EDT
Confirming bug valid with  2.6.27.19-170.2.35.fc10.x86_64
Comment 42 Chuck Ebbert 2009-03-28 09:22:33 EDT
*** Bug 444966 has been marked as a duplicate of this bug. ***
Comment 43 Joseph D. Wagner 2009-04-05 00:01:09 EDT
Confirming bug still valid against kernel-2.6.27.21-170.2.56.fc10.x86_64.
Comment 44 Jochen Schmitt 2009-05-12 16:14:54 EDT
Can anyone test, if this reported issue may occures after an update to Windows Vista SP2. I have installed it, and now the reported issue doesn't occures anymore.

Unfortunately, I have done an update to kernel-2.6.29.2-52, so I can't be sure,
which update has fixed this reported issue.
Comment 45 Francois Romieu 2009-05-12 16:47:06 EDT
Jochen Schmitt (jochen@herr-schmitt.de)  2009-05-12 16:14:54 EDT :
[...]
> Unfortunately, I have done an update to kernel-2.6.29.2-52, so I can't be sure,
> which update has fixed this reported issue.

The dhcp failure at boot may be fixed by commit 98bf3a0cf25dbd438500d9c9fcf583d7a2b97825 in 2.6.29.2 (and
d78ad8cbfe73ad568de38814a75e9c92ad0a907c in mainline)

See https://bugzilla.redhat.com/show_bug.cgi?id=460747 for details.

Does someone still experience a failure at boot with 2.6.29.2 or 2.6.30-rc ?

-- 
Ueimor
Comment 46 Josep 2009-05-12 17:22:36 EDT
This has been fixed for me since an update to 2.6.29.2.
Comment 47 Jochen Schmitt 2009-05-14 15:12:46 EDT
The issue semms to been fixed from my side.
Comment 48 Bug Zapper 2009-11-18 04:33:48 EST
This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '10'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 10's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 10 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 49 Joseph D. Wagner 2009-11-18 22:52:18 EST
This issue was fixed in FC11.
Comment 50 Bug Zapper 2009-12-18 01:05:38 EST
Fedora 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

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