Bug 205759 - igb cannot receive packets on first port only
Summary: igb cannot receive packets on first port only
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: CURRENT
Hardware: amd64 Any
: --- Affects Some People
Assignee: Sean Bruno
Keywords: IntelNetworking
Depends on:
Reported: 2015-12-31 17:14 UTC by Alan Somers
Modified: 2016-02-05 18:34 UTC (History)
6 users (show)

See Also:

Alexander L's example fix. Not a permanent solution. (445 bytes, patch)
2015-12-31 17:14 UTC, Alan Somers
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Alan Somers freebsd_committer 2015-12-31 17:14:39 UTC
Created attachment 164902 [details]
Alexander L's example fix.  Not a permanent solution.

On two separate systems with Intel S5520HC motherboards, FreeBSD CURRENT cannot receive any packets on igb0.  igb1 works fine, and igb0 works when booted into FreeBSD 9/stable.

* Disabling tso, lro, rxcsum, and txcsum has no effect.
* tcpdump reveals that igb0 transmits successfully, but fails to receive
* Curiously, "netstat -I igb0" shows nonzero values for Ipkts, even
though "tcpdump  -i igb0" shows no inbound packets at all.
* I can't really tell if IPv4 or IPv6 are working, because even ARP
doesn't work.
* SVN revisions 291495 and 292570 are both bad.  I don't know any
recent good revision.
* Alexander Leidinger reported a similar problem, but didn't specify whether all igb ports were broken or only one (or even whether he had multiple ports).  He reported that 11-CURRENT worked at svn r287323, but failed at r290633.
* Alexander also provided the attached patch, which fixes the issue.
Comment 1 Alexander Leidinger freebsd_committer 2016-01-01 09:30:07 UTC
The system where I see the issue is a Intel S5520SCR mainboard with
igb0@pci0:1:0:0:        class=0x020000 card=0x34e28086 chip=0x10a78086 rev=0x02 hdr=0x00

It has two igb ports, but I have only the first connected. IPv6 is configured, but when I had the issue I didn't check if it works, I only tested IPv4.
Comment 2 Eric Joyner freebsd_committer 2016-01-03 17:49:43 UTC
Even if it isn't a permanent fix, it's pretty clear that call is the problem. I'm guessing both of you are using 82575-based adapters then?

It might be that the fifo flush for those is put in the wrong place.
Comment 3 Jeff Pieper 2016-01-05 21:13:40 UTC
I can reproduce this, and as Eric stated, the problem is in e1000_rx_fifo_flush_82575(). We really can't just NOT call it, as it includes an IPv6 HW workaround.
Comment 4 Eric Joyner freebsd_committer 2016-02-05 18:34:29 UTC
Should be fixed in r295323.