Bug 452761 - r8169 driver broken in 2.6.18-92+ kernels.
r8169 driver broken in 2.6.18-92+ kernels.
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel (Show other bugs)
All Linux
low Severity high
: rc
: ---
Assigned To: Ivan Vecera
Martin Jenner
Depends On:
  Show dependency treegraph
Reported: 2008-06-24 17:07 EDT by Steve Snyder
Modified: 2009-01-20 15:23 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-01-20 15:23:07 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Final patch sent to review (95.88 KB, patch)
2008-08-21 11:35 EDT, Ivan Vecera
no flags Details | Diff

  None (edit)
Description Steve Snyder 2008-06-24 17:07:19 EDT
Description of problem:

Updated to kernel 2.6.18-92.el5 and my r8169-based network card stopped working.
 Updated again to 2.6.18-92.1.1.el5 and it still is not working.  Reverted to
(RHEL v5.1) kernel 2.6.18-53.1.21.el5 and the device is working again.

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


How reproducible:


Steps to Reproduce:
1. Install 2.6.18-92.1.1.el5 (or 2.6.18-92.el5) kernel
2. Reboot, to use new kernel
3. Note that the r8169 device cannot communicate.
Actual results:

The interface is up but cannot exchange traffic with the switch it is connected
to.  The mii-tool utility shows the device at 10BaseTx-HD (this on a GBit NIC
connected to a GBit switch).

Expected results:

The connectivity should work, as it last did in kernel version 2.6.18-53.1.21.el5.

Additional info:

This on a fully-updated RHEL 5.2 system.  It is the installed kernel that is the
difference between a functional and non-functional r8169-based device.
Comment 1 Steve Snyder 2008-06-24 17:15:53 EDT
For the sake on completeness I should note that this r8169 device is in a
NetGear GA511 PCCard.  Nothing ominous seen in the logs as the PCMCIA (Yenta)
driver load.

It is poossible that it is the Yenta driver that is screwed up between kernels,
but unlikely.  I have 2 PCCard NICs, the GA511 as eth0 and a 3Com Vortex as
eth1.  While the GA511 is broken in the 2.6.18-92+ kernels referred to above,
the functionality of the Vortex (eth1) is unimpaired.
Comment 3 Ivan Vecera 2008-06-25 11:00:21 EDT
I'm solving another issues regarding r8169 driver. Now I have a backport of
upstream r8169 that should probably solve your problem. Could you please try a
test kernel and provide me a result? The kernel is available here

Comment 4 Steve Snyder 2008-06-25 12:16:21 EDT
It's working in the test kernel.  See below.

Will we have to wait until RHEL v5.3 for this, or will the fix be rolled out in
a v5.2 update?


[root@nemesis ~]# uname -a
Linux nemesis 2.6.18-94.el5.ivtest.1 #1 SMP Wed Jun 25 16:33:22 CEST 2008 i686
i686 i386 GNU/Linux

[root@nemesis ~]# ping -I eth0 -c 3
PING ( from eth0: 56(84) bytes of data.
64 bytes from icmp_seq=1 ttl=64 time=0.382 ms
64 bytes from icmp_seq=2 ttl=64 time=0.298 ms
64 bytes from icmp_seq=3 ttl=64 time=0.296 ms

--- ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2000ms
rtt min/avg/max/mdev = 0.296/0.325/0.382/0.042 ms

[root@nemesis ~]# mii-tool eth0
  No MII transceiver present!.

[root@nemesis ~]# ethtool eth0
Settings for eth0:
        Supported ports: [ TP ]
        Supported link modes:   10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
        Supports auto-negotiation: Yes
        Advertised link modes:  10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
        Advertised auto-negotiation: Yes
        Speed: 1000Mb/s
        Duplex: Full
        Port: Twisted Pair
        PHYAD: 0
        Transceiver: internal
        Auto-negotiation: on
        Supports Wake-on: pumbg
        Wake-on: g
        Current message level: 0x00000033 (51)
        Link detected: yes

[root@nemesis ~]# ethtool -i eth0
driver: r8169
version: 2.2LK-NAPI
bus-info: 0000:02:00.0
Comment 5 Ivan Vecera 2008-08-21 11:35:45 EDT
Created attachment 314712 [details]
Final patch sent to review
Comment 6 RHEL Product and Program Management 2008-09-10 22:21:34 EDT
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
Comment 7 Daniel Senie 2008-09-11 14:01:42 EDT
For the benefit of the RHEL Product and Program Management team: please do include this in a bug fix for 5.2, and roll into 5.3. We're waiting on this making it into a proper release to move forward with a platform. It solves a problem that we can't solve otherwise (we're using a micro-sized server that has no ability to have a different Ethernet plugged in).
Comment 8 Don Zickus 2008-09-15 10:17:50 EDT
in kernel-2.6.18-115.el5
You can download this test kernel from http://people.redhat.com/dzickus/el5
Comment 9 Daniel Senie 2008-09-15 11:33:00 EDT
With this kernel, I am seeing a Mac address that is wrong. Output of ifconfig is below for eth0. Note the Mac address, and the inet6 address.

# ifconfig
eth0      Link encap:Ethernet  HWaddr FE:FF:FF:FF:FF:FF  
          inet addr:  Bcast:  Mask:
          inet6 addr: fe80::fcff:ffff:feff:ffff/64 Scope:Link
          RX packets:90 errors:0 dropped:2726790010 overruns:0 frame:0
          TX packets:122 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:10875 (10.6 KiB)  TX bytes:17206 (16.8 KiB)
          Interrupt:17 Base address:0x4000 

The /etc/sysconfig/network-scripts/ifcfg-eth0 says:

# Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet con

Also note that a "service network restart" complains about this:

# service network restart
Shutting down interface eth0:  Device eth0 has MAC address FE:FF:FF:FF:FF:FF, instead of configured address 00:01:80:76:7A:9C. Ignoring.
Shutting down loopback interface:                          [  OK  ]
Bringing up loopback interface:                            [  OK  ]
Bringing up interface eth0:                                [  OK  ]
Comment 13 errata-xmlrpc 2009-01-20 15:23:07 EST
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.


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