em(4) cannot maintain link in 12.0-STABLE
I have two NICs in a machine which acts as a gateway, and with the upgrade from 11-STABLE to the latest 12.0-STABLE tree (r346473), neither em(4) based NIC will maintain a connection. The behavior is similar to what is described in the last couple comments of this ticket: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219428 The behavior is identical with both devices. Link is established, dhclient starts securing a DHCP lease, and then once traffic starts to flow, the link switches to DOWN. Then back to UP, and back and forth. A syslog snippet: Apr 21 20:03:42 strawberry kernel: em0: Link is up 100 Mbps Full Duplex Apr 21 20:03:42 strawberry kernel: em0: link state changed to UP Apr 21 20:03:46 strawberry dhclient[15534]: New IP Address (em0): 173.228.83.96 Apr 21 20:03:46 strawberry dhclient[16069]: New Subnet Mask (em0): 255.255.255.0 Apr 21 20:03:46 strawberry dhclient[18914]: New Broadcast Address (em0): 173.228.83.255 Apr 21 20:03:46 strawberry dhclient[21483]: New Routers (em0): 173.228.83.1 Apr 21 20:03:48 strawberry kernel: em0: link state changed to DOWN Apr 21 20:03:50 strawberry kernel: em0: Link is up 100 Mbps Full Duplex Apr 21 20:03:50 strawberry kernel: em0: link state changed to UP Apr 21 20:03:57 strawberry kernel: em0: link state changed to DOWN Apr 21 20:03:57 strawberry ntpd[75785]: error resolving pool 0.freebsd.pool.ntp.org: Name does not resolve (8) Apr 21 20:03:58 strawberry dhclient[38043]: send_packet: Network is down Apr 21 20:03:59 strawberry kernel: em0: Link is up 100 Mbps Full Duplex Apr 21 20:03:59 strawberry kernel: em0: link state changed to UP Apr 21 20:04:05 strawberry kernel: em0: link state changed to DOWN Apr 21 20:04:06 strawberry dhclient[38043]: send_packet: Network is down Apr 21 20:04:07 strawberry kernel: em0: Link is up 100 Mbps Full Duplex Apr 21 20:04:07 strawberry kernel: em0: link state changed to UP Apr 21 20:04:15 strawberry kernel: em0: link state changed to DOWN Apr 21 20:04:15 strawberry dhclient[38043]: send_packet: Network is down Apr 21 20:04:16 strawberry kernel: em0: Link is up 100 Mbps Full Duplex THe version/hardware details: FreeBSD strawberry 12.0-STABLE FreeBSD 12.0-STABLE r346473 GENERIC amd64 em0@pci0:7:0:0: class=0x02 card=0xa01f8086 chip=0x10d38086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = '82574L Gigabit Network Connection' class = network subclass = ethernet em1@pci0:8:0:0: class=0x02 card=0xa01f8086 chip=0x10d38086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = '82574L Gigabit Network Connection' class = network subclass = ethernet My temporary workaround has been to use a USB-based NIC, but I am wondering if there are any tunables I could tweak to get this misbehaving driver to mind its manners? Cheers -- GitHub: https://github.com/rtyler GPG Key ID: 0F2298A980EE31ACCA0A7825E5C92681BEF6CEA2 ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Peculiar failure of re(4) to active a link after a RAM upgrade
I recently upgraded my 11.2-STABLE machine from 4 to 16GB of memory. Upon reboot the dual-NIC re(4) card which had been previously working failed to either negotiate or activate a link (i.e. lights up :)) with my DSL modem. ifcnofig lists the interface as 'no carrier' I verified that both ports (re0 and re1) were working by plugging network cables into my switch, and found that both were able to activate a link properly. When I plugin the DSL modem's cable into my em(4) based NIC, that activates a link properly. Regardless of which re(4) NIC I stick the cable into, it fails to create a link (ifconfig lists em0 as 'active'), while the same cable works properly in an em(4) NIC. I'm running r339079 right now, and if I remember correctly, had upgraded the world prior to the RAM upgrade, so it _seems_ like the RAM upgrade is the only variable which changed. I'm really clueless as to what would even be happening underneath the covers here, and would appreciate any pointers in the right direction for debugging here :) Cheers, -R Tyler Croy -- GitHub: https://github.com/rtyler Twitter: https://twitter.com/agentdero signature.asc Description: PGP signature
