Hi,
I am curious if this sounds vaguely familiar to anyone else. I recall I had an issue with e1000 driver a few years ago but I can't recall seeing an issue like this for quite a while.
I've got a machine at a client SMB office, running proxmox with a couple of VMs. It is a 'entry level' server, ie, HP Pro6200 tower with i5 quadcore and 16gigs ram. Has onboard E1000e Intel gig nic. Just updated it from Prox4 to Prox5. It is an 'atypical' config host in that
-- I installed debian base first
-- setup SW raid config and suitable LVM for proxmox to arrive on the scene happily post-install
-- added proxmox after the fact
What I seem to observe with this machine,
- I first test my wall socket and cable onto my laptop - a lenovo x220 running win10pro / with integrated intel gig ether. This lights up immediately at gig speeds, no questions asked.
- when I plug it over to the proxmox host, and do a reboot of proxmox:
-- it comes up and negotiates a 100meg connection
-- if I try to use eth tool based commands to force something else, for example,
In this case, proxmox loses the link / fails to negotiate any speed / network is down and it tells me link is down. Using ethtool to try to force a renegotiate fails.
or alternately if I try to go onto the switch web-admin and force the suitable port to be not "auto" but instead "1000 full duplex, auto=off". Does not help.
I have found after network stops working, I have to reboot the host - I can't just restart networking service - for it to come back online, in which case it always goes to 100meg.
Clearly I trust the wall socket and cable, since my postive control test with my laptop win10 box gives a nice gig connection with no drama. Hence my believe this is something to do with the e1000e hardware and more likely? the driver on the proxmox host/ not happily auto-negotiating or even willing to play ball when being 'forced' to run at 1000-full.
I did try adding in to config control for the NIC but this did not help, ie, no change of behaviour..
Then what ends up happening in this case, is that if I have done a clean boot, it gets a 100meg connection, that is the end of the affair.
For reference I am putting in below output capture regarding the e1000e part / the driver present currently (as per debian 9 latest)
Anyhow. I realize I am asking about a custom config, so it is unsupported and long shot at best.
But I thought I would ask in case anyone has ever seen this kind of thing.
Thanks!
Tim
I am curious if this sounds vaguely familiar to anyone else. I recall I had an issue with e1000 driver a few years ago but I can't recall seeing an issue like this for quite a while.
I've got a machine at a client SMB office, running proxmox with a couple of VMs. It is a 'entry level' server, ie, HP Pro6200 tower with i5 quadcore and 16gigs ram. Has onboard E1000e Intel gig nic. Just updated it from Prox4 to Prox5. It is an 'atypical' config host in that
-- I installed debian base first
-- setup SW raid config and suitable LVM for proxmox to arrive on the scene happily post-install
-- added proxmox after the fact
What I seem to observe with this machine,
- I first test my wall socket and cable onto my laptop - a lenovo x220 running win10pro / with integrated intel gig ether. This lights up immediately at gig speeds, no questions asked.
- when I plug it over to the proxmox host, and do a reboot of proxmox:
-- it comes up and negotiates a 100meg connection
-- if I try to use eth tool based commands to force something else, for example,
Code:
ethtool -s eth0 speed 1000 duplex full autoneg offIn this case, proxmox loses the link / fails to negotiate any speed / network is down and it tells me link is down. Using ethtool to try to force a renegotiate fails.
or alternately if I try to go onto the switch web-admin and force the suitable port to be not "auto" but instead "1000 full duplex, auto=off". Does not help.
I have found after network stops working, I have to reboot the host - I can't just restart networking service - for it to come back online, in which case it always goes to 100meg.
Clearly I trust the wall socket and cable, since my postive control test with my laptop win10 box gives a nice gig connection with no drama. Hence my believe this is something to do with the e1000e hardware and more likely? the driver on the proxmox host/ not happily auto-negotiating or even willing to play ball when being 'forced' to run at 1000-full.
I did try adding in to config control for the NIC but this did not help, ie, no change of behaviour..
Code:
root@proxmox:~# cat /etc/network/interfaces
# network interface settings; autogenerated
# Please do NOT modify this file directly, unless you know what
# you're doing.
#
# If you want to manage part of the network configuration manually,
# please utilize the 'source' or 'source-directory' directives to do
# so.
# PVE will preserve these directives, but will NOT its network
# configuration from sourced files, so do not attempt to move any of
# the PVE managed interfaces into external files!
source /etc/network/interfaces.d/*
auto lo
iface lo inet loopback
allow-hotplug eth0
iface eth0 inet manual
#iface eth0 inet dhcp
auto vmbr0
#auto eth0
iface vmbr0 inet static
address 192.168.0.3
netmask 255.255.255.0
gateway 192.168.0.1
bridge_ports eth0
bridge_stp off
bridge_fd 0
# Force to 1000meg connection feb-28-2018 TDC
ETHTOOL_OPTS="speed 1000 duplex full autoneg off"
root@proxmox:~#Then what ends up happening in this case, is that if I have done a clean boot, it gets a 100meg connection, that is the end of the affair.
For reference I am putting in below output capture regarding the e1000e part / the driver present currently (as per debian 9 latest)
Anyhow. I realize I am asking about a custom config, so it is unsupported and long shot at best.
But I thought I would ask in case anyone has ever seen this kind of thing.
Thanks!
Tim
Code:
DMESG TELLS ME
============================
[ 1.184315] e1000e: loading out-of-tree module taints kernel.
[ 1.185117] e1000e: Intel(R) PRO/1000 Network Driver - 3.3.6-NAPI
[ 1.185118] e1000e: Copyright(c) 1999 - 2017 Intel Corporation.
[ 1.185296] e1000e 0000:00:19.0: Interrupt Throttling Rate (ints/sec) set to dynamic conservative mode
[ 1.294737] e1000e 0000:00:19.0 0000:00:19.0 (uninitialized): registered PHC clock
[ 1.364106] usb 1-1: new high-speed USB device number 2 using ehci-pci
[ 1.384266] usb 2-1: new high-speed USB device number 2 using ehci-pci
[ 1.400917] e1000e 0000:00:19.0 eth0: (PCI Express:2.5GT/s:Width x1) 3c:d9:2b:67:62:da
[ 1.400919] e1000e 0000:00:19.0 eth0: Intel(R) PRO/1000 Network Connection
[ 1.401014] e1000e 0000:00:19.0 eth0: MAC: 10, PHY: 11, PBA No: 0100FF-0FF
and a bit later,
[ 25.934168] e1000e: eth0 NIC Link is Up 100 Mbps Full Duplex, Flow Control: None
[ 25.934171] e1000e 0000:00:19.0 eth0: 10/100 speed: disabling TSO
[ 25.934212] vmbr0: port 1(eth0) entered blocking state
[ 25.934213] vmbr0: port 1(eth0) entered forwarding state
and
lspci tells me,
===========
00:19.0 Ethernet controller: Intel Corporation 82579LM Gigabit Network Connection (rev 04)
AND, MODINFO TELLS ME:
=======================
root@proxmox:~# modinfo e1000e
filename: /lib/modules/4.13.13-6-pve/kernel/drivers/net/ethernet/intel/e1000e/e1000e.ko
version: 3.3.6-NAPI
license: GPL
description: Intel(R) PRO/1000 Network Driver
author: Intel Corporation, <linux.nics@intel.com>
srcversion: 4EC66B021BDA67D9F6464A8
alias: pci:v00008086d000015D6sv*sd*bc*sc*i*
.... truncate many aliases here for brevity ...
alias: pci:v00008086d0000105Esv*sd*bc*sc*i*
depends: ptp
retpoline: Y
name: e1000e
vermagic: 4.13.13-6-pve SMP mod_unload modversions
parm: copybreak:Maximum size of packet that is copied to a new buffer on receive (uint)
parm: TxIntDelay:Transmit Interrupt Delay (array of int)
parm: TxAbsIntDelay:Transmit Absolute Interrupt Delay (array of int)
parm: RxIntDelay:Receive Interrupt Delay (array of int)
parm: RxAbsIntDelay:Receive Absolute Interrupt Delay (array of int)
parm: InterruptThrottleRate:Interrupt Throttling Rate (array of int)
parm: IntMode:Interrupt Mode (array of int)
parm: SmartPowerDownEnable:Enable PHY smart power down (array of int)
parm: KumeranLockLoss:Enable Kumeran lock loss workaround (array of int)
parm: CrcStripping:Enable CRC Stripping, disable if your BMC needs the CRC (array of int)
parm: EEE:Enable/disable on parts that support the feature (array of int)
parm: Node:[ROUTING] Node to allocate memory on, default -1 (array of int)
parm: debug:Debug level (0=none,...,16=all) (int)
root@proxmox:~#