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:
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 ~]#
*** Bug 437619 has been marked as a duplicate of this bug. ***
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.
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.
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.
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.
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
Maybe a duplicate of Bug #394221
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.
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
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.
I can also confirm that the problem is not solved with kernel 2.6.27-0.391.rc8.git.fc10.
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.
I have a simular issue. But if I have booted FreeBSD 7.0 and reboot the system to start Fedora all works fine.
Jochen, can you specify your kernel version and include the XID line printed by the r8169 driver ? -- Ueimor
I will notify, that the issue reported in this bug ticket didn't occurs on gentoo linux.
$ 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
Created attachment 323914 [details] output from lspci -vv
I assume, taht this is a x86_64 related issue, because it's works on Gentoo Linux and FreeBSD.
Thanks for the information Jochen. Do you know the version of the kernel which is used with Gentoo ? -- Ueimor
It was kernel-genkernel-2.6.26-gentoo-r1
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
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?
I have try to send a email to nicfae.tw, because the reported issue occurs with the original kernel module from realtek too.
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.
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
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
(In reply to comment #27) > Jochen, is this an Asus P5LD2 SE motherboard ? Yes.
Created attachment 324497 [details] Output of mii-tools -vv before removing r8169 after reboot from Windows Vista
Created attachment 324498 [details] Output of mii-tools -vv before reloading r8169 module after reboot from Windows Vista
Created attachment 324523 [details] Output of demsg on gentoo-2.6.25-r6
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.
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
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.
Created attachment 324914 [details] dmesg output on 2.6.26.5-49.fc8 dmesg after r8169 was reinstated as requested.
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.
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?
Created attachment 327805 [details] Another user's output from dmesg, lspci -vv, and mii-tool -vv.
Confirming bug still valid against kernel-2.6.27.9-159.fc10.x86_64.
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.
Confirming bug valid with 2.6.27.19-170.2.35.fc10.x86_64
*** Bug 444966 has been marked as a duplicate of this bug. ***
Confirming bug still valid against kernel-2.6.27.21-170.2.56.fc10.x86_64.
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.
Jochen Schmitt (jochen) 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
This has been fixed for me since an update to 2.6.29.2.
The issue semms to been fixed from my side.
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
This issue was fixed in FC11.
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.