Bug 177139 - [igb] igb drops ethernet ports r2 and 3
Summary: [igb] igb drops ethernet ports 2 and 3
Status: Closed Unable to Reproduce
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: Unspecified
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-net (Nobody)
Keywords: IntelNetworking
Depends on:
Reported: 2013-03-20 15:40 UTC by David Robertson
Modified: 2018-05-29 14:51 UTC (History)
2 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
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

How-To-Repeat: Configure igb2 and/or igb3 and wait.
Comment 1 Mark Linimon freebsd_committer freebsd_triage 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...

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
        ether bc:30:5b:f6:12:de
        inet6 fe80::be30:5bff:fef6:12de%igb2 prefixlen 64
scopeid 0x3
        inet netmask 0xffffff00 broadcast
        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
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?


----- Original Message -----
From: "Vogel Jack" 
To:"bug-followup@FreeBSD.org" , "david@dr.eclipse.co.uk" 
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â¦




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?


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

Comment 6 Eitan Adler freebsd_committer freebsd_triage 2018-05-28 19:45:51 UTC
batch change:

For bugs that match the following
-  Status Is In progress 
- Untouched since 2018-01-01.
- Affects Base System OR Documentation


Reset to open status.

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.