dev.em.N.fc and dev.igb.N.fc read and wrote a function-static variable
shared by every em(4) and igb(4) device, so a read returned the last
value written to any of them (3 until the first write), not the state of
the device. The softc value started as 0, which is also the value of
"no flow control", while the hardware was set up for full flow control.
As a result:
- Writing 0 was taken for no change and did nothing, unless another value had been written to that device before.
- em_reset() took a softc value of 0 for "not set", so a device set to 0 went back to full flow control on the next init.
- On igb(4) with more than one receive queue the driver enabled per-queue drop (SRRCTL.DROP_EN), which is meant for a MAC that does not send pause frames, although the MAC was told to send them.
- Values out of range were accepted and ignored.
A write only forced the MAC's flow control bits. The pause bits
advertised to the link partner, the pause thresholds and DROP_EN stayed
as the last init had set them, and the next link event resolved flow
control from the stale advertisement again. On 82577 and 82578 (pchlan)
a write could also turn on transmit flow control, which em_reset() keeps
off there as a workaround.
Start the softc value as full, report it, use it as it is in em_reset(),
reject invalid values, and apply a change by reinitializing the
interface, as the dmac and eee_control sysctls do. This is the same fix
as 68386f6b551e ("igc: Fix the flow control sysctl"); igc(4) inherited
the handler from this driver. On pchlan, remove transmit pause from the
requested mode instead of replacing the mode with receive pause, so that
the workaround stays and 0 still turns flow control off.
MFC after: 2 weeks
Sponsored by: Rubicon Communications, LLC ("Netgate")