Bug 235524 - igb ethernet interface loses active link state
Summary: igb ethernet interface loses active link state
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 12.0-STABLE
Hardware: amd64 Any
: --- Affects Only Me
Assignee: freebsd-net mailing list
URL:
Keywords: IntelNetworking
Depends on:
Blocks:
 
Reported: 2019-02-05 13:54 UTC by Denis Ahrens
Modified: 2019-06-03 16:30 UTC (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Denis Ahrens 2019-02-05 13:54:02 UTC
my machine uses an igb interface for pppoe to a dsl-modem. after some load on the interface (max 16mbit) the link state changes to DOWN.

sometimes using "ifconfig pppoe0 down" and then "ifconfig pppoe0 up" helps but mostly not and the only solution is to reboot the machine.

Every aspect of involved hardware changed over the years but the problems persists.

funny thing is that the link goes active if I run "ifconfig pppoe0 down". but as soon as I run "ifconfig pppoe0 up" the link state goes to inactive.

first messages in var/log/message when this happens:

Feb  4 16:20:14 monolith kernel: igb3: TX(0) desc avail = 42, pidx = 876
Feb  4 16:20:15 monolith kernel: pppoe0: link state changed to DOWN
Comment 1 eborisch+FreeBSD 2019-06-03 16:30:01 UTC
I'm running into this as well, no pppoe involved. Everything is up and running just fine until (on Friday evening of Memorial day weekend, of course) ...

May 24 21:28:03 <host> kernel: igb0: TX(0) desc avail = 42, pidx = 574
May 24 21:28:03 <host> kernel: igb0: link state changed to DOWN
May 24 21:28:05 <host> kernel: igb0: TX(3) desc avail = 1024, pidx = 0
May 24 21:28:35 <host> syslogd: last message repeated 18 times

Can't try net/intel-em-kmod as this is an I350 card:

igb0@pci0:4:0:0:	class=0x020000 card=0x152115d9 chip=0x15218086 rev=0x01 hdr=0x00
    vendor     = 'Intel Corporation'
    device     = 'I350 Gigabit Network Connection'
    class      = network
    subclass   = ethernet

After it decides there is no carrier (lights go out on physical card, too) rebooting is the only way I've found to wake back up.

Running amd64 12.0-p3 at the time. Custom kernel config, but comes up and is stable until this occurs. Doesn't *seem* to be during high traffic, but I suppose there could have been an undetected (looking at monitoring data) spike right before it happened. (This was the interface the monitoring data is sent out, so....)