On Mon, August 13, 2012 18:48, Ned Slider wrote:
On 13/08/12 19:50, James B. Byrne wrote:
On Mon, August 13, 2012 10:37, Ned Slider wrote:
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.
Eth1 is an xpci card sold by StarTech. A system with an identical card reports this:
OK, I'd definitely try reseating the card and if you still get no joy I'd swap it out for a replacement.
for BUSID in $(/sbin/lspci | awk '{ IGNORECASE=1 } /net/ { print $1 }'); do /sbin/lspci -s $BUSID -m; /sbin/lspci -s $BUSID -n; done
I swapped the suspect card and rebooted the host. After some fussing about with udev I managed to get the new card recognized as eth1 (vice eth2 as udev kept insisting).
I will do a transfer test later today and see if it stays up. The original failed in the midst of an sftp transfer.
James B. Byrne wrote:
On Mon, August 13, 2012 18:48, Ned Slider wrote:
On 13/08/12 19:50, James B. Byrne wrote:
On Mon, August 13, 2012 10:37, Ned Slider wrote:
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.
Eth1 is an xpci card sold by StarTech. A system with an identical card reports this:
<snip>
I swapped the suspect card and rebooted the host. After some fussing about with udev I managed to get the new card recognized as eth1 (vice eth2 as udev kept insisting).
Yup. I assume you edited /etc/udev/rules.d/70-persistent-net.rules, got rid of the lines for the old card, and told it the new one was eth1?
I will do a transfer test later today and see if it stays up. The original failed in the midst of an sftp transfer.
Good luck.
mark
Having replaced the suspect card and rebooted the host I see these messages in /var/log/messages repeated over and over:
Aug 15 07:17:10 vhost01 ntpd[2044]: Listening on interface #62 eth1, fe80::20a:cdff:fe1d:32e7#123 Enabled Aug 15 07:17:10 vhost01 ntpd[2044]: Listening on interface #63 eth1, 192.168.216.41#123 Enabled Aug 15 07:19:41 vhost01 lldpad[1836]: evb_ifdown:port eth1 remove failed Aug 15 07:19:41 vhost01 lldpad[1836]: evb_ifdown:port eth1 remove failed Aug 15 07:19:41 vhost01 lldpad[1836]: evb_ifdown:port eth1 remove failed Aug 15 07:19:43 vhost01 ntpd[2044]: Deleting interface #62 eth1, fe80::20a:cdff:fe1d:32e7#123, interface stats: received=0, sent=0, dropped=0, active_time=153 secs Aug 15 07:19:43 vhost01 ntpd[2044]: Deleting interface #63 eth1, 192.168.216.41#123, interface stats: received=0, sent=0, dropped=0, active_time=153 secs Aug 15 07:20:13 vhost01 kernel: r8169 0000:01:00.0: eth1: RTL8168d/8111d at 0xffffc9001258c000, 00:0a:cd:1d:32:e7, XID 081000c0 IRQ 30 Aug 15 07:20:13 vhost01 kernel: r8169 0000:01:00.0: eth1: jumbo features [frames: 9200 bytes, tx checksumming: ko] Aug 15 07:20:14 vhost01 kernel: r8169 0000:01:00.0: eth1: invalid firwmare Aug 15 07:20:14 vhost01 kernel: r8169 0000:01:00.0: eth1: unable to load firmware patch rtl_nic/rtl8168d-1.fw (-22) Aug 15 07:20:14 vhost01 kernel: r8169 0000:01:00.0: eth1: link down Aug 15 07:20:14 vhost01 kernel: r8169 0000:01:00.0: eth1: link down Aug 15 07:20:14 vhost01 kernel: ADDRCONF(NETDEV_UP): eth1: link is not ready Aug 15 07:20:16 vhost01 kernel: r8169 0000:01:00.0: eth1: link up Aug 15 07:20:16 vhost01 kernel: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready Aug 15 07:20:20 vhost01 ntpd[2044]: Listening on interface #64 eth1, fe80::20a:cdff:fe1d:32e7#123 Enabled Aug 15 07:20:20 vhost01 ntpd[2044]: Listening on interface #65 eth1, 192.168.216.41#123 Enabled Aug 15 07:28:14 vhost01 lldpad[1836]: evb_ifdown:port eth1 remove failed Aug 15 07:28:14 vhost01 lldpad[1836]: evb_ifdown:port eth1 remove failed Aug 15 07:28:14 vhost01 lldpad[1836]: evb_ifdown:port eth1 remove failed Aug 15 07:28:16 vhost01 ntpd[2044]: Deleting interface #64 eth1, fe80::20a:cdff:fe1d:32e7#123, interface stats: received=0, sent=0, dropped=0, active_time=476 secs Aug 15 07:28:16 vhost01 ntpd[2044]: Deleting interface #65 eth1, 192.168.216.41#123, interface stats: received=0, sent=0, dropped=0, active_time=476 secs Aug 15 07:29:27 vhost01 kernel: r8169 0000:01:00.0: eth1: RTL8168d/8111d at 0xffffc90012588000, 00:0a:cd:1d:32:e7, XID 081000c0 IRQ 30 Aug 15 07:29:27 vhost01 kernel: r8169 0000:01:00.0: eth1: jumbo features [frames: 9200 bytes, tx checksumming: ko] Aug 15 07:29:27 vhost01 kernel: r8169 0000:01:00.0: eth1: invalid firwmare Aug 15 07:29:27 vhost01 kernel: r8169 0000:01:00.0: eth1: unable to load firmware patch rtl_nic/rtl8168d-1.fw (-22) Aug 15 07:29:27 vhost01 kernel: r8169 0000:01:00.0: eth1: link down Aug 15 07:29:27 vhost01 kernel: r8169 0000:01:00.0: eth1: link down Aug 15 07:29:27 vhost01 kernel: ADDRCONF(NETDEV_UP): eth1: link is not ready Aug 15 07:29:30 vhost01 kernel: r8169 0000:01:00.0: eth1: link up Aug 15 07:29:30 vhost01 kernel: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready Aug 15 07:29:33 vhost01 ntpd[2044]: Listening on interface #66 eth1, fe80::20a:cdff:fe1d:32e7#123 Enabled Aug 15 07:29:33 vhost01 ntpd[2044]: Listening on interface #67 eth1, 192.168.216.41#123 Enabled Aug 15 07:31:54 vhost01 lldpad[1836]: evb_ifdown:port eth1 remove failed Aug 15 07:31:54 vhost01 lldpad[1836]: evb_ifdown:port eth1 remove failed Aug 15 07:31:54 vhost01 lldpad[1836]: evb_ifdown:port eth1 remove failed Aug 15 07:31:55 vhost01 ntpd[2044]: Deleting interface #66 eth1, fe80::20a:cdff:fe1d:32e7#123, interface stats: received=0, sent=0, dropped=0, active_time=142 secs Aug 15 07:31:55 vhost01 ntpd[2044]: Deleting interface #67 eth1, 192.168.216.41#123, interface stats: received=0, sent=0, dropped=0, active_time=142 secs
So, what is going on? This host is the first one of two nearly identically configured machines. The second host does not report or evidence any problem with its eth1.
James B. Byrne wrote:
Having replaced the suspect card and rebooted the host I see these messages in /var/log/messages repeated over and over:
<snip>
Aug 15 07:20:13 vhost01 kernel: r8169 0000:01:00.0: eth1: RTL8168d/8111d at 0xffffc9001258c000, 00:0a:cd:1d:32:e7, XID 081000c0 IRQ 30 Aug 15 07:20:13 vhost01 kernel: r8169 0000:01:00.0: eth1: jumbo features [frames: 9200 bytes, tx checksumming: ko] Aug 15 07:20:14 vhost01 kernel: r8169 0000:01:00.0: eth1: invalid firwmare Aug 15 07:20:14 vhost01 kernel: r8169 0000:01:00.0: eth1: unable to load firmware patch rtl_nic/rtl8168d-1.fw (-22)
<snip>
So, what is going on? This host is the first one of two nearly identically configured machines. The second host does not report or evidence any problem with its eth1.
My eyes uncrossed, and I saw, buried in there, the firstlink, above, and the last. You might want to see if a) the 8168d firmware patch will work on that card; b) vhost - it's a virtual host? perhaps it's trying to load the firmware patch to the real NIC, and as a guest VM, it doesn't have rights?
mark