|Summary:||[igb] igb drops ethernet ports 2 and 3|
|Product:||Base System||Reporter:||David Robertson <david>|
|Component:||kern||Assignee:||freebsd-net (Nobody) <net>|
|Status:||Closed Unable to Reproduce|
|Severity:||Affects Only Me||CC:||sbruno, shurd|
Description David Robertson 2013-03-20 15:40:01 UTC
We have two Dell servers which have an Intel I350 Gig 4 way network cards. Both servers drop igb2 and igb3 after a short time. igb0 and igb1 have so far been stable. We are running the latest firmware from Dell and driver version - 2.3.4. Any help or advice on fixing this would be much appreciated. Nothing is logged apart from the interface going down with status: no carrier How-To-Repeat: Configure igb2 and/or igb3 and wait.
Comment 1 Mark Linimon 2013-03-21 00:04:05 UTC
Responsible Changed From-To: freebsd-amd64->freebsd-net Over to maintainer(s).
Comment 2 jack.vogel 2013-03-21 00:17:03 UTC
Please provide more details, are the ports described as 'dropped' just losing link, or some other symptoms as well. Also, is there any different in the link-partner between the sets of ports? Is the activity different, etc... Jack
Comment 3 David Robertson 2013-03-21 11:02:49 UTC
Â Hi Jack, In dmesg and /var/log/messages we see igb2: link state changed to UP igb2: link state changed to DOWN Â ifconfig reports Â igb2: flags=8c02 metric 0 mtu 1500 Â Â Â Â Â Â Â options=401bb Â Â Â Â Â Â Â ether bc:30:5b:f6:12:de Â Â Â Â Â Â Â inet6 fe80::be30:5bff:fef6:12de%igb2 prefixlen 64 scopeid 0x3 Â Â Â Â Â Â Â inet 192.168.179.134 netmask 0xffffff00 broadcast 192.168.179.255 Â Â Â Â Â Â Â nd6 options=29 Â Â Â Â Â Â Â media: Ethernet 1000baseT (autoselect) Â Â Â Â Â Â Â status: no carrier This interface is being used exclusively for Postgresql database replication from one server to another. Both servers do the same.Â They can stay up for anything from a few minutes to a few hours but always die. One major difference is that the two interfaces are connected with a crossover (also tried straight through) cable. This is a configuration we have been using with great success for a number of years with broadcom adapters. Opted for the Intel card on these servers as we had trouble with the latest broadcom drivers. I have tried disabling msix as I read this could possibly help and also tried disabling autoselect and manually configuring the interfaces. None of these have helped.Â igb0 and igb1 are connect to switches and have been stable. So at the moment I have created a vlan on one of our switches and have plugged both servers into these vlan ports and they have remained up over night. Could it be that this network card does not like direct connections and is looking for a switch? David ----- Original Message ----- From: "Vogel Jack" To:"bug-followup@FreeBSD.org" , "firstname.lastname@example.org" Cc: Sent:Thu, 21 Mar 2013 00:17:03 +0000 Subject:Re: kern/177139: [igb] igb drops ethernet ports r2 and 3 Please provide more details, are the ports described as âdroppedâ just losing link, or some other symptoms as well.Â Also, is there any different in the link-partner between the sets of ports? Is the activity different, etcâ¦ Â Jack Â
Comment 4 jfvogel 2013-03-21 17:04:14 UTC
So, when the igb ports are in the failing configuration what are they connected to specifically, what device/nic? There is no special procedure "looking for a switch", its just the autoneg between two devices, so maybe there is some compatibility issue. Also occurs to me that an interesting test would be to swap the two pair of devices and see if the problem follows the function or not, do you understand? Regards, Jack
Comment 5 David Robertson 2013-03-21 17:31:57 UTC
It is an Intel I350-t4 nic to a I350-t4 nic. The problem occurs at both sides. Not sure I follow your swap suggestion as both devices should be identical. David
Comment 6 Eitan Adler 2018-05-28 19:45:51 UTC
batch change: For bugs that match the following - Status Is In progress AND - Untouched since 2018-01-01. AND - Affects Base System OR Documentation DO: Reset to open status. Note: I did a quick pass but if you are getting this email it might be worthwhile to double check to see if this bug ought to be closed.