| 68386f6b | 05-Oct-2026 |
R. Christian McDonald <rcm@FreeBSD.org> |
igc: Fix the flow control sysctl
dev.igc.N.fc read and wrote a function-static variable shared by every
igc device, so a read returned the last value written to any of them (3
until the first write)
igc: Fix the flow control sysctl
dev.igc.N.fc read and wrote a function-static variable shared by every
igc 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.
- igc_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.
- 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: a port set to 0 came back
honoring pause frames, for example.
Start the softc value as full, report it, use it as it is in
igc_reset(), reject invalid values, and apply a change by
reinitializing the interface, as the dmac and eee_control sysctls do.
Two things behave differently now. Changing the mode of a running
interface takes the link down to renegotiate. And with the default
mode and more than one receive queue DROP_EN is no longer set: a full
receive ring makes the MAC send pause frames, and holds up the other
queues, where it used to drop that queue's packets. Setting fc to 0 or
1 selects per-queue drop.
Tested on I226-V ports with four receive queues: for each mode, the
flow control bits in CTRL, the pause thresholds and DROP_EN were read
back, and the mode the link partner resolved, also after a down/up.
Reviewed by: gallatin
Fixes: 517904de5cca ("igc(4): Introduce new driver for the Intel I225 Ethernet controller.")
MFC after: 2 weeks
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D60363
show more ...
|
| 9f7633b9 | 12-Aug-2026 |
Kevin Bowling <kbowling@FreeBSD.org> |
igc: Report corrected internal ECC errors
I225 and I226 do not interrupt for corrected internal ECC errors.
Instead, the DMA packet buffer and PCIe memories expose sticky status
bits in PBECCSTS and
igc: Report corrected internal ECC errors
I225 and I226 do not interrupt for corrected internal ECC errors.
Instead, the DMA packet buffer and PCIe memories expose sticky status
bits in PBECCSTS and PCIEECCSTS.
Sample these bits with the regular hardware statistics update, preserve
the PBECCSTS ECC enable state while clearing its RW1C indication, and
expose separate counters for the DMA packet buffer, PCIe transmit-data
memory, and PCIe retry buffer.
These counters represent observed indications rather than an exact error
count because multiple corrections between samples collapse into one
sticky status bit.
Hardware validation used an I225-IT (rev 3) and a debug kernel that
wrote only the documented self-clearing injection bits. Each test
armed the injector, exercised the owning RAM with traffic, and compared
the corresponding counter before and after.
Coverage:
Memory Observed result
DMA packet buffer corrected_dma advanced once
PCIe transmit data corrected_pcie_tx_data advanced once
PCIe retry buffer No PCIe replay source; not exercised
The retry-buffer injector requires a real PCIe replay to read the
corrupted entry. The test root port exposed AER and DPC reporting but
no protocol error injector, so ordinary traffic could not cover that
case.
MFC after: 2 weeks
Sponsored by: BBOX.io
show more ...
|
| bbf93227 | 12-Aug-2026 |
Kevin Bowling <kbowling@FreeBSD.org> |
igc: Recover from fatal internal memory errors
I225 and I226 report uncorrectable internal memory errors through
ICR.FER and identify the affected region in PEIND. Depending on the
region, hardware
igc: Recover from fatal internal memory errors
I225 and I226 report uncorrectable internal memory errors through
ICR.FER and identify the affected region in PEIND. Depending on the
region, hardware stops transmit or all PCIe and DMA traffic until the
port is reset and reinitialized.
Enable the fatal error interrupt and capture its read clear status in
the interrupt filter. Mask the cause while an iflib reset is pending,
report the affected memory regions, and expose per region indication
counters.
PCIe region parity failures require a different recovery order from a
normal reset: assert DEV_RST, wait at least 3 ms, disable PCIe master
requests, clear PCIEERRSTS, and then reinitialize the port. Follow that
sequence before entering the normal reset path and clear the remaining
LAN status afterward.
The I225/I226 PBECCSTS layout is unrelated to the PCH layout previously
copied into the igc headers. Replace those unused definitions with the
I225/I226 memory error register definitions.
Hardware validation used an I225-IT revision 3 and a debug kernel that
wrote only the documented self-clearing injection bits. It did not
synthesize interrupt or status state.
Coverage, notably DMA and Mgmt are not fully testable in my setup:
Region Observed hardware status Result
LAN PEIND 0x1, LANPERRSTS 0x200 Reset and recovered
PCIe PEIND 0x4, PCIEERRSTS 0x8 Reset and recovered
DMA DRPARC injection read back zero DFT-gated on test NIC
Mgmt Host debug strap unavailable Not injectable
The repeated LAN and PCIe tests recovered without a panic or watchdog.
A PCIe-to-LAN sequence also verified that reset-time PEIND indications
are drained before FER is unmasked.
MFC after: 2 weeks
Sponsored by: BBOX.io
show more ...
|
| 423927d6 | 12-Aug-2026 |
Kevin Bowling <kbowling@FreeBSD.org> |
igc: Remove invalid debug ring pointer iteration
The debug routine reads queue registers by queue index. It also
advanced unused pointers to rings embedded in queue structures. Those
pointers had
igc: Remove invalid debug ring pointer iteration
The debug routine reads queue registers by queue index. It also
advanced unused pointers to rings embedded in queue structures. Those
pointers had the wrong stride and could proceed beyond the ring object.
Remove the unused pointer arithmetic.
MFC after: 2 weeks
show more ...
|
| 19f75b38 | 12-Aug-2026 |
Kevin Bowling <kbowling@FreeBSD.org> |
igc: Add led(4) identification support
I225 and I226 expose three programmable LED outputs. Use LED1 for
adapter identification, following the convention in DPDK. Preserve the
OEM configuration ac
igc: Add led(4) identification support
I225 and I226 expose three programmable LED outputs. Use LED1 for
adapter identification, following the convention in DPDK. Preserve the
OEM configuration across identification requests.
Restore the OEM configuration before a device reset so an active led(4)
pattern cannot leave the output overridden across stop or detach.
The LED mode values follow the Intel I225 Software User Manual.
MFC after: 2 weeks
show more ...
|
| 1121aaa0 | 11-Aug-2026 |
Kevin Bowling <kbowling@FreeBSD.org> |
igc: Check PHY control register reads
Do not modify a zero-initialized PHY control value when its preceding
read failed. Leave the PHY unchanged when the void power helpers cannot
read its current
igc: Check PHY control register reads
Do not modify a zero-initialized PHY control value when its preceding
read failed. Leave the PHY unchanged when the void power helpers cannot
read its current state.
This follows the defensive checks added to the corresponding e1000
helpers.
MFC after: 2 weeks
show more ...
|
| 3fc1786a | 11-Aug-2026 |
Barbara Skobiej <barbara.skobiej@intel.com> |
igc: fix data type in MAC hash
DPDK commit message
net/e1000/base: fix data type in MAC hash
One of the bit shifts in MAC hash calculation triggers a static analysis
warning about a potential over
igc: fix data type in MAC hash
DPDK commit message
net/e1000/base: fix data type in MAC hash
One of the bit shifts in MAC hash calculation triggers a static analysis
warning about a potential overflow. Fix the data type to avoid this.
Fixes: af75078fece3 ("first public release")
Cc: stable@dpdk.org
Signed-off-by: Barbara Skobiej <barbara.skobiej@intel.com>
Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
Obtained from: DPDK (458734aaac)
MFC after: 2 weeks
show more ...
|
| cba56bc3 | 11-Aug-2026 |
Aleksandr Loktionov <aleksandr.loktionov@intel.com> |
igc: fix MAC address hash bit shift
DPDK commit message
net/e1000/base: fix MAC address hash bit shift
In e1000_hash_mc_addr_generic() the expression:
"mc_addr[4] >> 8 - bit_shift", right shiftin
igc: fix MAC address hash bit shift
DPDK commit message
net/e1000/base: fix MAC address hash bit shift
In e1000_hash_mc_addr_generic() the expression:
"mc_addr[4] >> 8 - bit_shift", right shifting "mc_addr[4]"
shift by more than 7 bits always yields zero, so hash becomes not so
different. Add initialization with bit_shift = 1, and add a loop
condition to ensure bit_shift will be always in [1..8] range.
Fixes: af75078fece3 ("first public release")
Cc: stable@dpdk.org
Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
Obtained from: DPDK (1749e662f6)
MFC after: 2 weeks
show more ...
|
| 5587cb18 | 11-Aug-2026 |
Amir Avivi <amir.avivi@intel.com> |
igc: fix iterator type
DPDK commit message
net/e1000/base: fix iterator type
Fix static analysis warning about comparison between types of
incompatible width, which might lead to an infinite loop
igc: fix iterator type
DPDK commit message
net/e1000/base: fix iterator type
Fix static analysis warning about comparison between types of
incompatible width, which might lead to an infinite loop due to
overflow.
Fixes: af75078fece3 ("first public release")
Cc: stable@dpdk.org
Signed-off-by: Amir Avivi <amir.avivi@intel.com>
Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
Obtained from: DPDK (3d36053991)
MFC after: 2 weeks
show more ...
|
| e2aff507 | 08-Aug-2026 |
Kevin Bowling <kbowling@FreeBSD.org> |
igc: Correct descriptor control programming
The transmit-ring setup was copied from the e1000 path. On I225
and I226, bits 22 through 24 are reserved and bit 25 enables the
queue; it is not a legac
igc: Correct descriptor control programming
The transmit-ring setup was copied from the e1000 path. On I225
and I226, bits 22 through 24 are reserved and bit 25 enables the
queue; it is not a legacy low-water threshold. Correct the field
masks, remove the nonapplicable legacy definitions, and program only
defined fields.
Use PTHRESH=8 and HTHRESH=1. Keep WTHRESH at zero so the hardware
honors sparse RS descriptors issued by iflib. Linux and DPDK use a
writeback threshold of 16, but request status on every packet. A
nonzero threshold makes hardware ignore individual RS bits and is
unsuitable for the iflib completion model.
The receive-ring setup likewise used a magic mask that left bit 20
of the five-bit WTHRESH field untouched. Define the receive threshold
fields and replace them exactly before installing the established
PTHRESH=8, HTHRESH=8, WTHRESH=4 policy.
MFC after: 2 weeks
show more ...
|
| a108ee91 | 03-Aug-2026 |
Kevin Bowling <kbowling@FreeBSD.org> |
igc: Correct hardware error statistics
Track RERC separately instead of adding receive errors to the collision
count, and read the previously omitted RXERRC register. Include RFC in
input errors be
igc: Correct hardware error statistics
Track RERC separately instead of adding receive errors to the collision
count, and read the previously omitted RXERRC register. Include RFC in
input errors because CRCERRS does not count bad-CRC runts, implementing
the I225 length-error accounting workaround alongside RUC and ROC.
Stop treating host transmit MAC discards as receive errors. Expose both
RERC and HTDPMC as dedicated MAC statistics so their overlapping counts
remain available without corrupting aggregate interface counters.
MFC after: 2 weeks
show more ...
|
| 70942655 | 03-Aug-2026 |
Kevin Bowling <kbowling@FreeBSD.org> |
igc: Work around I225 v1 minimum IPG erratum
I225 v1 cannot receive the minimum inter-packet gap required at
2.5 Gb/s. For affected back-to-back links, Intel recommends using a
15-byte transmit IPG
igc: Work around I225 v1 minimum IPG erratum
I225 v1 cannot receive the minimum inter-packet gap required at
2.5 Gb/s. For affected back-to-back links, Intel recommends using a
15-byte transmit IPG instead of 12 bytes.
Program TIPG.IPGT to 0xb for pre-v2 I225 devices at 2.5 Gb/s and
restore the default at lower speeds. Avoid penalizing fixed I225 and
I226 parts.
MFC after: 2 weeks
show more ...
|