Bug 468360 - Regression: kernels greater than 2..6.27.3-30 fail to initialise Realtek RTL 8101E Ethernet controller
Summary: Regression: kernels greater than 2..6.27.3-30 fail to initialise Realtek RTL ...
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: rawhide
Hardware: i686
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 468251 468435 (view as bug list)
Depends On:
Blocks: F10KernelBlocker
TreeView+ depends on / blocked
 
Reported: 2008-10-24 11:11 UTC by Tim Hawkins
Modified: 2008-10-31 17:24 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-10-31 17:24:37 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Tim Hawkins 2008-10-24 11:11:54 UTC
Recent updates to kernel after 2.6.27.3-30 have resulted in no "eth0" device being listed for this device 

Booting with 2.6.27.3-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.

Comment 1 Yanko Kaneti 2008-10-24 12:08:15 UTC
This is fixed for me in 2.6.27.3-44, as the offending patch was disabled.

Comment 2 Dave Jones 2008-10-24 15:21:01 UTC
*** Bug 468251 has been marked as a duplicate of this bug. ***

Comment 3 Dave Jones 2008-10-24 22:19:16 UTC
*** Bug 468435 has been marked as a duplicate of this bug. ***

Comment 4 Andy Lawrence 2008-10-24 23:39:06 UTC
-44 no Joy for me!

[root@localhost ~]# uname -r
2.6.27.3-44.fc10.i686
[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
          collisions:0 txqueuelen:1000 
          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)
[root@localhost ~]#

Comment 5 Andy Lawrence 2008-10-24 23:47:31 UTC
Sorry, forgot:

24 19:38:41 localhost NetworkManager: <WARN>  nm_device_hw_bring_up(): (eth0): device not up after timeout!


With the -44 kernel.

Comment 6 Dave Jones 2008-10-25 00:03:53 UTC
ugh.  Andy, what was the last kernel that worked for you?

Comment 7 Andy Lawrence 2008-10-25 00:14:13 UTC
Hey Dave, looks like 2.6.27.3-27.rc1.fc10.i686 but I'd have to reinstall it to be sure.

Shall I DL it from Koji and try it?

Comment 8 Chris 2008-10-25 01:14:31 UTC
The last working kernel here was 2.6.27.3-30.rc1.fc10.i686 -> https://bugzilla.redhat.com/attachment.cgi?id=321445

Comment 9 Yanko Kaneti 2008-10-25 06:38:08 UTC
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.

Comment 10 John Poelstra 2008-10-25 15:04:30 UTC
adding to blocker... I can't tell from the last comment if this issues is fixed or still open.

Comment 11 Francois Romieu 2008-10-25 15:59:52 UTC
This is fixed in 2.6.28-rc1 since commit e1564ec938b759268d6e67f24b5d6f429da4a5a9.

2.6.27 is not affected.

-- 
Ueimor

Comment 12 Ralf Corsepius 2008-10-25 16:30:40 UTC
kernel-2.6.27.3-39.fc10.i686 didn't work for me.

kernel-2.6.27.3-44.fc10.i686 works again.

01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8101E PCI Express Fast Ethernet controller (rev 02)

Comment 13 Chris 2008-10-25 17:39:04 UTC
This one:

02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 01)

is still broken with kernel-2.6.27.3-44.fc10.i686

Comment 14 Chuck Ebbert 2008-10-25 20:04:57 UTC
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

Comment 15 Francois Romieu 2008-10-25 21:33:45 UTC
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:
- a2de6b89b74b28052e293fdb39975a5a03c432e0
  r8169: wake up the PHY of the 8168
- 523a609496dbc3897e530db2a2f27650d125ea00
  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.

-- 
Ueimor

Comment 16 Andy Lawrence 2008-10-26 22:56:00 UTC
Chuck, good deal.  Let me know which kernel it is once built and I'll test asap.

Comment 17 Chris 2008-10-27 03:01:16 UTC
kernel -47 and -51 are still broken for me

Comment 18 Tom "spot" Callaway 2008-10-27 18:25:02 UTC
Just as a datapoint:

2.6.27.3-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)

Comment 19 Andy Lawrence 2008-10-27 22:29:43 UTC
All is working with the 2.6.27.4-51.fc10.i686 Kernel Chuck built!

Thanks Chuck!

Comment 20 Chris 2008-10-28 18:34:38 UTC
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 2.6.27.3-30.rc1, this exact same version (-30) is not working anymore. Could the NIC be physically damaged?

Comment 21 Francois Romieu 2008-10-28 19:47:48 UTC
(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.

-- 
Ueimor

Comment 22 Chris 2008-10-29 05:44:54 UTC
(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!

Comment 23 Chuck Ebbert 2008-10-31 17:24:37 UTC
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


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