Recent updates to kernel after 184.108.40.206-30 have resulted in no "eth0" device being listed for this device
Booting with 220.127.116.11-30 allows the device to initialise.
The log entries for -34 and -39 kernels..
nm_device_hw_bring_up(): (eth0) device not up after timeout
The device is loading the r8169 driver in both working and not working kernels.
This is fixed for me in 18.104.22.168-44, as the offending patch was disabled.
*** Bug 468251 has been marked as a duplicate of this bug. ***
*** Bug 468435 has been marked as a duplicate of this bug. ***
-44 no Joy for me!
[root@localhost ~]# uname -r
[root@localhost ~]# ifconfig eth0
eth0 Link encap:Ethernet HWaddr 00:00:00:00:00:00
BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
Interrupt:18 Base address:0xa000
[root@localhost ~]# lspci | grep Ethernet
05:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8101E PCI Express Fast Ethernet controller (rev 01)
24 19:38:41 localhost NetworkManager: <WARN> nm_device_hw_bring_up(): (eth0): device not up after timeout!
With the -44 kernel.
ugh. Andy, what was the last kernel that worked for you?
Hey Dave, looks like 22.214.171.124-27.rc1.fc10.i686 but I'd have to reinstall it to be sure.
Shall I DL it from Koji and try it?
The last working kernel here was 126.96.36.199-30.rc1.fc10.i686 -> https://bugzilla.redhat.com/attachment.cgi?id=321445
FWIW, the device that got broken (-34, -39) by the patch and now works (-44, -47) for me is
Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller [10ec:8168] (rev 02)
The symptoms were the same as here.
adding to blocker... I can't tell from the last comment if this issues is fixed or still open.
This is fixed in 2.6.28-rc1 since commit e1564ec938b759268d6e67f24b5d6f429da4a5a9.
2.6.27 is not affected.
kernel-188.8.131.52-39.fc10.i686 didn't work for me.
kernel-184.108.40.206-44.fc10.i686 works again.
01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8101E PCI Express Fast Ethernet controller (rev 02)
02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 01)
is still broken with kernel-220.127.116.11-44.fc10.i686
Okay, two patches were merged upstream on Wed Oct 22, two days after I put the update to the 2.6.27-git driver into F10 that caused this bug. With those two patches we should be able to update to the latest driver. Or maybe not, since there's still a risk of regressions.
The driver is broken for a different group of people without that update -- see bug #460747
The fix was included in mainline during the merge of
2242d5eff17cf91110a3c44747f9f2e1a938cbda (Fri Oct 24 04:19:54 2008), so it
came a bit after Oct 22.
I have been reported no regression for the post-2.6.27 r8169 driver which
could not be explained by 7bf6bf4803df1adc927f585168d2135fb019c698.
There are several confirmed bugfixes in 2.6.28-rc1 which are not included
in 2.6.27 as they came after the previous merge window and did not deserve
the "fix a regression" label:
r8169: wake up the PHY of the 8168
r8169: fix RxMissed register access
If you do not trust the r8169.c driver in 2.6.28-rc1 and want to stay with
a 2.6.27 driver, you should really consider these two patches.
Chuck, good deal. Let me know which kernel it is once built and I'll test asap.
kernel -47 and -51 are still broken for me
Just as a datapoint:
18.104.22.168-44.fc10.x86_64 got my networking working again:
02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 02)
All is working with the 22.214.171.124-51.fc10.i686 Kernel Chuck built!
fyi: I just booted an old 2.6.26 kernel and the card doesn't work with this kernel, too. Although I can remember (and still have logs to proof), that I had no problems until 126.96.36.199-30.rc1, this exact same version (-30) is not working anymore. Could the NIC be physically damaged?
(In reply to comment #20)
> anymore. Could the NIC be physically damaged?
I do not think so but it commonly needs a complete power-down and a
removal of the power cable.
(In reply to comment #21)
> > Could the NIC be physically damaged?
> I do not think so but it commonly needs a complete power-down and a
> removal of the power cable.
D'oh! Working again... Thanks a lot!
This regression is fixed, though some machines may need a complete powerdown before the adapter will work. Other problems with r8169 should be tracked using bug #460747