Linux kernel version is Linux - 3.10.0, download nic driver source code, ixgbe drive from ixgbe - 3. Updating the 7.0.x.x ixgbe - 5.3.7 version,
https://downloadcenter.intel.com/download/14687
Then server network will occasionally appear these days even without the period of time, when something goes wrong print log is as follows:
info MCA MCA: Rx link - tx_id: 1, tx_brd: XMPU, handle: 0 x55a4d4d8
The info the NETDEV WATCHDOG: eth1 (ixgbe) : the transmit queue 0 timed out
0000: the info ixgbe 01:00. 1 eth1: Fake, Tx hang detected with a timeout of 5 seconds
0000: the info ixgbe 01:00. 1 eth1: Fake, Tx hang detected with a timeout of 10 seconds
The info MCA MCA: Rx link - PROTOCOL_NORMAL, size: 0 x200000, rx_num: 1
The info MCA MCA: Rx link - rx_id: 0, rx_brd: XMPU, opt: 0 x9000000002001986
Relatively few online explanation about this error,
Relevant link: http://e1000-devel.narkive.com/NrwfbfVy/fake-tx-hangs
https://communities.vmware.com/message/2533755#2533755
Look like memory, the received data traffic over the network card driver processing range,
But now that is after updating the driver, the problem may be in the driver,
Guess:
1. In a certain period of time, the network traffic is very big, drive to deal with (receiving/sending queue setting in the driver is not big enough?)
2. The problem of network card driver of the other
3. The environment configuration is wrong?
4. After the nic driver update to the old kernel, you need to do to other configuration
CodePudding user response:
The building Lord problem solving? I also am high adapted version ixgbe, then run 500 m basic won't appear this problem, but to run to 600 m or more when it comes to time out problem, then the packet loss, doubt is equipment processing capacity to keep up with, gigabit nics are used this rate,