Bug #5887
open
hardware_offloading_applyflags sets/unsets most values when already set correctly
Added by Chris Buechler almost 9 years ago.
Updated over 8 years ago.
Description
hardware_offloading_applyflags sets txcsum, rxcsum, LRO, TSO, etc. whether or not they're already set correctly. That'd be OK, but there are driver issues from time to time that trigger a NIC link cycle upon applying some of those. Then they get re-applied upon link up, making it go link down again. Rinse and repeat indefinitely.
- Status changed from New to Confirmed
thought this would fix the ix(4) link cycling issue on XG-1540 particularly when a DHCP client (rxcsum/txcsum causes link cycle), though that doesn't seem to do it. haven't had a chance to dig further into it yet.
I've seen the changes that you've done, dug a little and found non-initialized variables in another file which uses the same functions:
https://github.com/pfsense/pfsense/blob/master/src/etc/inc/interfaces.inc#L766
pfSense_interface_capabilities($laggif, -$flags_off);
pfSense_interface_capabilities($laggif, $flags_on);Possibly unrelated to this, still worth fixing if that proves to be a bug.
I had to revert the commit referenced here. In a LAGG+VLAN setup the parent NICs had unexpected flags (POLLING and LRO in my case) which broke connectivity. Reverting the commit brought back connectivity.
I have the status output from each state and a test setup if further testing is needed.
- Target version deleted (
2.3)
That caused a variety of fallout in a number of cases. encaps either doesn't report correctly, or things don't work without applying the caps again anyway, in various scenarios.
This doesn't help the link cycling issue that I was hoping to resolve by doing so. Leaving this as-is for 2.3.
- Assignee deleted (
Chris Buechler)
Also available in: Atom
PDF
Updated by 
Updated by 
Updated by