[BUG] e1000e: I219 with jumbo MTU: RX CRC errors for unicast DAs not in the RAR (promiscuous/bridged ports)

[BUG] e1000e: I219 with jumbo MTU: RX CRC errors for unicast DAs not in the RAR (promiscuous/bridged ports)

[Andrei-Alexandru Bleortu]

Hi,

On I219-LM (8086:15bb rev 10, pch_cnp) with MTU 9000, frames addressed
to a unicast MAC that is not in the RAR fail with rx_crc_errors at
roughly 0.1% of frames (rx_errors rises by exactly twice that; the
length and alignment counters stay at 0), while the same stream
addressed to the port's own MAC is clean. A port enslaved to a bridge or
OVS is always in this state, since e1000e_set_rx_mode() skips
e1000e_write_uc_addr_list() under IFF_PROMISC.

Hardware: Dell OptiPlex 7060 (BIOS 1.32.0) and HP ProDesk 600 G5 Mini
(BIOS R22 02.24.00), both I219-LM 8086:15bb rev 10, NVM 0.5-4. Kernel
7.0.14 (Proxmox); e1000e_set_rx_mode(), e1000e_write_uc_addr_list(),
e1000_rar_set_pch_lpt() and e1000_lv_jumbo_workaround_ich8lan() are
unchanged in net-next.

Setup: lan0 (the I219) is an OVS port, so IFF_PROMISC and RCTL UPE|MPE
are set. A VLAN device on lan0 carries the host's IP with its own MAC
(different from lan0's). The sender is behind 10GbE switch ports; the
receiver's switch port is 1GbE.

Test: 1 GiB of TCP (ssh, MSS 8948) pushed into the I219 host, counting
rx_crc_errors before and after:

                                              host 1      host 2
  DA = lan0's own MAC (RAR[0])                  0, 0        0, 0     per GiB
  DA = the VLAN device's MAC (not in RAR)     438, 429    416, 417   per GiB

Workaround, confirmed on both hosts: giving the VLAN device the port's
own MAC, so the host's traffic is addressed to RAR[0], brings the same
test to 0, 0 per GiB. Frames to the MACs of bridged guests behind the
port cannot be helped that way and remain affected.

All of the following are needed. Removing any one gives 0 errors:
  - frame size: path MTU 3000/5000/7000/9000 -> 0 / 0 / 80 / ~370
  - back-to-back line rate: the same jumbo frames paced at ~1000/s -> 0;
    the same 1 GiB from a 1GbE sender through the same switch -> 0
    (only a faster ingress port drained into the 1GbE port produces
    minimum-IPG back-to-back frames)
  - a DA that is not in the RAR (table above)

Not affected (each tested, no change in the error rate): CPU C-states
(holding /dev/cpu_dma_latency at 0 -> 380/GiB), the disable-k1 private
flag, GRO, cable, switch EEE/jumbo settings. rx_missed_errors stays at
~0, so this is not an RX FIFO/descriptor overrun.

My reading of why (please correct me): the I219's PHY-MAC interconnect
runs at 1.25 Gb/s 8b/10b (datasheet section 2.2), i.e. no headroom over
1000BASE-T. e1000_lv_jumbo_workaround_ich8lan() copies the RAR into the
PHY (e1000_copy_rx_addrs_to_phy_ich8lan()), seeds PCH_RAICC(i) with
~ether_crc_le() of each RAR address and sets FFLT_DBG; the PHY register
fields described as "Crop ANM DA Jumbo" / "Filter on 1Gbps ... jumbo
fix" suggest the PHY drops the DA of known addresses to gain bandwidth
and the MAC restarts the CRC from the per-address seed. A frame whose
DA is not in that table gets no crop, and back-to-back long frames then
overrun the interconnect.

Two consequences in the driver, from reading the code:

1. Under IFF_PROMISC, secondary unicast addresses (a VLAN, macvlan or
   bridge MAC on top of the port) are never written to the RAR, so they
   never get the jumbo fix. This is the case measured above.

2. Even without promiscuous mode, e1000e_write_uc_addr_list() ->
   rar_set() writes only RAL/RAH (SHRAL/SHRAH), while PCH_RAICC and
   the PHY's copy are refreshed only in e1000_configure_rx(). An address
   added after the interface is up should have the same problem until
   the next reset or MTU change. (Not tested.)

Possible directions, if the analysis holds:
  - while the jumbo workaround is enabled, program secondary unicast
    addresses into RAR/SHRA even under IFF_PROMISC, and re-run the
    PCH_RAICC + PHY copy whenever the RAR changes;
  - for DAs that cannot be in the RAR at all (bridged guests' MACs, or
    an ME holding SHRA via FWSM.WLOCK_MAC), is there a hardware way to
    sustain line-rate jumbo for them? If not, a one-time warning when a
    jumbo MTU is combined with promiscuous mode on pch2lan+ would save
    the next person a long hunt.

I worked through this with the help of an AI assistant (Claude); the
numbers above were measured on my two machines.

I can test patches on both machines (Secure Boot is on, so that goes
through a MOK-signed module) and run further measurements if useful.

Thanks,
Andrei

Re: [BUG] e1000e: I219 with jumbo MTU: RX CRC errors for unicast DAs not in the RAR (promiscuous/bridged ports)

[Ruinskiy, Dima]

On 24/10/2026 1:22, Andrei-Alexandru Bleortu wrote:
> Hi,
> 
> On I219-LM (8086:15bb rev 10, pch_cnp) with MTU 9000, frames addressed
> to a unicast MAC that is not in the RAR fail with rx_crc_errors at
> roughly 0.1% of frames (rx_errors rises by exactly twice that; the
> length and alignment counters stay at 0), while the same stream
> addressed to the port's own MAC is clean. A port enslaved to a bridge or
> OVS is always in this state, since e1000e_set_rx_mode() skips
> e1000e_write_uc_addr_list() under IFF_PROMISC.
> 
> Hardware: Dell OptiPlex 7060 (BIOS 1.32.0) and HP ProDesk 600 G5 Mini
> (BIOS R22 02.24.00), both I219-LM 8086:15bb rev 10, NVM 0.5-4. Kernel
> 7.0.14 (Proxmox); e1000e_set_rx_mode(), e1000e_write_uc_addr_list(),
> e1000_rar_set_pch_lpt() and e1000_lv_jumbo_workaround_ich8lan() are
> unchanged in net-next.
> 
> Setup: lan0 (the I219) is an OVS port, so IFF_PROMISC and RCTL UPE|MPE
> are set. A VLAN device on lan0 carries the host's IP with its own MAC
> (different from lan0's). The sender is behind 10GbE switch ports; the
> receiver's switch port is 1GbE.
> 
> Test: 1 GiB of TCP (ssh, MSS 8948) pushed into the I219 host, counting
> rx_crc_errors before and after:
> 
>                                                host 1      host 2
>    DA = lan0's own MAC (RAR[0])                  0, 0        0, 0     per GiB
>    DA = the VLAN device's MAC (not in RAR)     438, 429    416, 417   per GiB
> 
> Workaround, confirmed on both hosts: giving the VLAN device the port's
> own MAC, so the host's traffic is addressed to RAR[0], brings the same
> test to 0, 0 per GiB. Frames to the MACs of bridged guests behind the
> port cannot be helped that way and remain affected.
> 
> All of the following are needed. Removing any one gives 0 errors:
>    - frame size: path MTU 3000/5000/7000/9000 -> 0 / 0 / 80 / ~370
>    - back-to-back line rate: the same jumbo frames paced at ~1000/s -> 0;
>      the same 1 GiB from a 1GbE sender through the same switch -> 0
>      (only a faster ingress port drained into the 1GbE port produces
>      minimum-IPG back-to-back frames)
>    - a DA that is not in the RAR (table above)
> 
> Not affected (each tested, no change in the error rate): CPU C-states
> (holding /dev/cpu_dma_latency at 0 -> 380/GiB), the disable-k1 private
> flag, GRO, cable, switch EEE/jumbo settings. rx_missed_errors stays at
> ~0, so this is not an RX FIFO/descriptor overrun.
> 
> My reading of why (please correct me): the I219's PHY-MAC interconnect
> runs at 1.25 Gb/s 8b/10b (datasheet section 2.2), i.e. no headroom over
> 1000BASE-T. e1000_lv_jumbo_workaround_ich8lan() copies the RAR into the
> PHY (e1000_copy_rx_addrs_to_phy_ich8lan()), seeds PCH_RAICC(i) with
> ~ether_crc_le() of each RAR address and sets FFLT_DBG; the PHY register
> fields described as "Crop ANM DA Jumbo" / "Filter on 1Gbps ... jumbo
> fix" suggest the PHY drops the DA of known addresses to gain bandwidth
> and the MAC restarts the CRC from the per-address seed. A frame whose
> DA is not in that table gets no crop, and back-to-back long frames then
> overrun the interconnect.
> 
> Two consequences in the driver, from reading the code:
> 
> 1. Under IFF_PROMISC, secondary unicast addresses (a VLAN, macvlan or
>     bridge MAC on top of the port) are never written to the RAR, so they
>     never get the jumbo fix. This is the case measured above.
> 
> 2. Even without promiscuous mode, e1000e_write_uc_addr_list() ->
>     rar_set() writes only RAL/RAH (SHRAL/SHRAH), while PCH_RAICC and
>     the PHY's copy are refreshed only in e1000_configure_rx(). An address
>     added after the interface is up should have the same problem until
>     the next reset or MTU change. (Not tested.)
> 
> Possible directions, if the analysis holds:
>    - while the jumbo workaround is enabled, program secondary unicast
>      addresses into RAR/SHRA even under IFF_PROMISC, and re-run the
>      PCH_RAICC + PHY copy whenever the RAR changes;
>    - for DAs that cannot be in the RAR at all (bridged guests' MACs, or
>      an ME holding SHRA via FWSM.WLOCK_MAC), is there a hardware way to
>      sustain line-rate jumbo for them? If not, a one-time warning when a
>      jumbo MTU is combined with promiscuous mode on pch2lan+ would save
>      the next person a long hunt.
> 
> I worked through this with the help of an AI assistant (Claude); the
> numbers above were measured on my two machines.
> 
> I can test patches on both machines (Secure Boot is on, so that goes
> through a MOK-signed module) and run further measurements if useful.
> 
> Thanks,
> Andrei

Hi Andrei,
Thank you for this analysis.

I am vaguely familiar with the limitation. As you correctly observed, 
there is no 100% proof solution because of the promiscuous case, but if 
we can achieve a small improvement with a risk-free driver change, I 
agree that would be a good idea.

Would it be possible to ask you to run a few additional tests, if you 
haven't yet? According to the current custom, the proposal is also 
AI-assisted.

Test 1. Add a secondary unicast address while jumbo mode is active

a. Bring the physical interface up with MTU 9000 and confirm jumbo 
reception is enabled.

b. Confirm the physical interface is not in promiscuous mode.

c. After the interface is already up, add a VLAN or other upper 
interface with a distinct unicast MAC address. Make sure that address is 
added to the physical interface’s unicast address list.

d. Send traffic to that secondary MAC at the test rate. Record CRC 
errors and whether packets are delivered.

e. Keep the same configuration, take the physical interface down and 
back up, then repeat the traffic test.

The useful comparison is live-added address versus the same address 
after interface reconfiguration. More CRC errors before the restart, but 
not after, would support the stale-workaround-state hypothesis. Please 
note if adding the upper interface unexpectedly puts the physical 
interface into promiscuous mode; that would make this a different case.

Test 2. Change the physical interface’s MAC while it is up

a. With jumbo MTU active and promiscuous mode off, change the physical 
interface to a different valid unicast MAC while it remains up.

b. Send the same traffic to the new MAC and record the counters.

c. Take the interface down and back up without changing the new MAC, 
then repeat.

d. If convenient, restore the original MAC and repeat the live-change 
comparison.

Again, compare the live change with the post-restart result. This checks 
whether updating RAR[0] also needs to refresh its CRC seed and PHY 
address copy.

Thanks!
--Dima