[CentOS] Eth1 problem on CentOS-6.3

Mon Aug 13 14:37:33 UTC 2012
Ned Slider <ned at unixmail.co.uk>

On 13/08/12 14:08, James B. Byrne wrote:
>
> On Sun, August 12, 2012 12:00, Ned Slider wrote:
>> On 11/08/12 22:17, James B. Byrne wrote:
>>> I am trying to transport a dd image between to hosts over a cross
>>> linked gigabit connection.  Both hosts have an eth1 configured to a
>>> non routable ip addr on a shared network.   No other devices exist
>>> on this link.
>>>
>>> When transferring via sftp I received a stall warning.  Checking the
>>> logs I see this:
>>>
>>> dmesg | grep eth
>>>
>>> e1000e 0000:00:19.0: eth0: (PCI Express:2.5GT/s:Width x1)
>>> 00:1c:c0:f2:1f:bb
>>> e1000e 0000:00:19.0: eth0: Intel(R) PRO/1000 Network Connection
>>> e1000e 0000:00:19.0: eth0: MAC: 7, PHY: 8, PBA No: FFFFFF-0FF
>>> r8169 0000:01:00.0: eth1: RTL8168d/8111d at 0xffffc9000187c000,
>>> 00:0a:cd:1d:44:fe, XID 081000c0 IRQ 31
>>> r8169 0000:01:00.0: eth1: jumbo features [frames: 9200 bytes, tx
>>> checksumming: ko]
>>> ADDRCONF(NETDEV_UP): eth0: link is not ready
>>> device eth0 entered promiscuous mode
>>> r8169 0000:01:00.0: eth1: invalid firwmare
>>> r8169 0000:01:00.0: eth1: unable to load firmware patch
>>> rtl_nic/rtl8168d-1.fw (-22)
>>> r8169 0000:01:00.0: eth1: link down
>>> r8169 0000:01:00.0: eth1: link down
>>> ADDRCONF(NETDEV_UP): eth1: link is not ready
>>> r8169 0000:01:00.0: eth1: link up
>>> ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
>>> e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control:
>>> None
>>> ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
>>> br0: port 1(eth0) entering learning state
>>> eth1: no IPv6 routers present
>>> eth0: no IPv6 routers present
>>> br0: port 1(eth0) entering forwarding state
>>> r8169 0000:01:00.0: eth1: link down
>>> r8169 0000:01:00.0: eth1: link up
>>> r8169 0000:01:00.0: eth1: link down
>>> r8169 0000:01:00.0: eth1: link up
>>>
>>> This may, or may not, be related to this bug:
>>>
>>> https://bugzilla.kernel.org/show_bug.cgi?id=12411
>>>
>>> Is there some way to confirm whether or not this is the case.  Is
>>> there a work-around for it if it is this bug?  If it is not then has
>>> anyone any idea what is happening and how to fix it?
>>>
>>
>> Elrepo.org has updated drivers for both e1000e and r8169 devices (I'm
>> guessing it's probably the kmod-r8168 you'd need). You could try these
>> to see if they resolve the issue.
>>
>> If you want more help identifying the correct driver for your
>> hardware, see FAQ #4 here:
>>
>
> The network card for eth1 seems to have disappeared somehow.
> On the problem host:
>
> # /sbin/lspci -nn | grep -i net
> 00:19.0 Ethernet controller [0200]: Intel Corporation 82567V-2 Gigabit
> Network Connection [8086:10ce]
> #
>
> On another but nearly identically configured host (same MB and
> additional NIC:
>
> # /sbin/lspci -nn | grep -i net00:19.0 Ethernet controller [0200]:
> Intel Corporation 82567V-2 Gigabit Network Connection [8086:10ce]
> 01:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd.
> RTL8111/8168B PCI Express Gigabit Ethernet controller [10ec:8168] (rev
> 03)
> 04:04.0 Serial controller [0700]: NetMos Technology PCI 9835 Multi-I/O
> Controller [9710:9835] (rev 01)
>
> Where did eth1 on the first host go?  How do I get it back?  A restart?
>

Faulty hardware maybe? Try a reboot and see if it reappears. If it's 
located on a card try reseating the card (although I suspect this is an 
integrated NIC on the motherboard?).

The chipset is not necessarily the same in the second example (different 
revision); RTL8111/8168B is not RTL8168d/8111d. They probably do use the 
same driver but I'd need to see the Vendor:Device ID pairing to know for 
sure.