Tantilov, Emil S writes: [...] > >Sep 5 10:56:16 host kernel: ixgbe 0000:04:00.0: eth0: NIC Link is Down > >Sep 5 10:56:20 host kernel: ixgbe 0000:04:00.0: eth0: NIC Link is Up 10 > >Gbps, Flow Control: RX/TX > > Are these the only messages from the driver in dmesg?
Yes, apart from those printed during system boot. E.g. Aug 19 16:41:30 host kernel: ixgbe: Intel(R) 10 Gigabit PCI Express Network Driver - version 3.9.15-k Aug 19 16:41:30 host kernel: ixgbe: Copyright (c) 1999-2012 Intel Corporation. Aug 19 16:41:30 host kernel: ixgbe 0000:04:00.0: PCI INT B -> GSI 28 (level, low) -> IRQ 28 Aug 19 16:41:30 host kernel: ixgbe 0000:04:00.0: Multiqueue Enabled: Rx Queue count = 16, Tx Queue count = 16 Aug 19 16:41:30 host kernel: ixgbe 0000:04:00.0: registered PHC device on 0000:04:00.0 Aug 19 16:41:30 host kernel: ixgbe 0000:04:00.0: (PCI Express:5.0GT/s:Width x8) 68:05:ca:06:c2:3a Aug 19 16:41:30 host kernel: ixgbe 0000:04:00.0: MAC: 2, PHY: 2, PBA No: E95990-004 Aug 19 16:41:30 host kernel: ixgbe 0000:04:00.0: Intel(R) 10 Gigabit Network Connection Aug 19 16:41:30 host kernel: ixgbe 0000:04:00.1: PCI INT A -> GSI 26 (level, low) -> IRQ 26 Aug 19 16:41:30 host kernel: ixgbe 0000:04:00.1: Multiqueue Enabled: Rx Queue count = 16, Tx Queue count = 16 Aug 19 16:41:30 host kernel: ixgbe 0000:04:00.1: registered PHC device on 0000:04:00.1 Aug 19 16:41:30 host kernel: ixgbe 0000:04:00.1: (PCI Express:5.0GT/s:Width x8) 68:05:ca:06:c2:3b Aug 19 16:41:30 host kernel: ixgbe 0000:04:00.1: MAC: 2, PHY: 2, PBA No: E95990-004 Aug 19 16:41:30 host kernel: ixgbe 0000:04:00.1: Intel(R) 10 Gigabit Network Connection > A link down event can be caused by removing the cable or a fluctuation in the > signal between the link partners. > The driver does not have much control over it other than setting the PHY. Ok. As I said in my other reply, I am quite confident it is not a cable issue. > > My current working theory is that flow control settings may be the culprit. > > All servers have RX/TX on. The Nexus 4900 has RX/TX on, the 3064 off. I > > found > > that ethtool doesn't allow me to switch RX/TX off unless I also switch > > autoneg > > off, so I'm reduced to playing with the resp. switch settings. I take it > > that > > flow control (layer 2?) is not something that is auto-negotiated between > > NIC/driver and switch? > > It is very unlikely that flow control has anything to do with it, but if you > suspect it you can disable it from the driver's side: > > #ethtool -A ethX autoneg off tx off rx off > > You can see the result in the link up message as the one from your email. I will try that again because I had a misunderstanding with ethtool. The autoneg setting under pause options applies only to pause options, not speed/duplex negotioation. Also, I am not quite sure how this autonegotiation should work overall - does the switch pin its settings and the NIC autonegotiates? Should switch and NIC have the same settings? I am getting a very confusing picture here, especially when I include switches and servers at some of our other DC locations. Three days ago, I disabled rx/tx on the switch side for one of the problematic machines, and no down events have been recorded so far. From previous experience, I need to leave this in place for about a week to be certain; when one 82599EB-equipped machine was moved to the 3064 switch, there were very few issues for a while, but about six days later, we observed a massive "link down" storm with several events every minute. At the time, the easiest and quickest solution was to unretire the 4900 switch and move machines with susceptible NICs back to it. Thanks. ------------------------------------------------------------------------------ Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk _______________________________________________ E1000-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
