On Wed, 21 Oct 2026 01:02:11 +0200 Andre Brait <[email protected]> wrote:
> On I219, a TSO packet whose first buffer is long and has a 4 KB > boundary just after the TCP checksum field makes the NIC send corrupted > data and then hang the Tx DMA. Forwarded VM traffic (tun/vhost-net) > produces such packets, so hosts bridging guests onto an I219 hit it > within minutes: > > e1000e 0000:00:1f.6 eno1: Detected Hardware Unit Hang > > Right before the hang the receiver gets TCP segments carrying data from > 128 bytes earlier in the stream, with a valid checksum. > > This is the erratum Intel documents for the 82571/82572 (#76), 82574 > (#17) and 82583V (#7): if the first buffer is larger than > 3 * (max_read_request - 4) bytes and a 4 KB boundary falls just after > the headers, a read is repeated, wrong data goes out with a correct > checksum, and the Tx DMA hangs. e1000e never implemented the documented > workaround. > > Apply it to all e1000e parts: limit the first data descriptor of a TSO > packet to 3 * (max_read_request - 4) bytes (372 on the I219, where > pcie_get_readrq() returns 128). The rest of the linear part goes into > the next descriptor, which e1000_xmit_frame() already reserves; Aren't you using an additional descriptor over and above those the code might already use? So either it was reserving one too many, or you need to reserve another one. I'm not actually sure all the logic there is actually needed. The code calculates the number of descriptors the packet is expected to need and gets the packet requeued if there aren't enough, but there is also the 'post transmit' check that stops the transmit if there isn't enough room for a full length packet. If the latter is valid you don't need the former. Although a sanity check that the ring isn't being wrapped might not do any harm. David > the NIC > still segments the packet. ...
