There are some tg3 devices that require the driver to post new rx
buffers in smaller increments. Commit
4361935afe3abc3e5a93006b99197fac1fabbd50, "tg3: Consider
rx_std_prod_idx a hw mailbox" changed how the driver tracks the rx
producer ring updates, but it does not make any special considerations
for the above-mentioned devices. For those devices, it is possible for
the driver to hit the special case path, which updates the hardware
mailbox register but skips updating the shadow software mailbox member.
If the special case path represents the final mailbox update for this
ISR iteration, the hardware and software mailbox values will be out of
sync. Ultimately, this will cause the driver to use a stale mailbox
value on the next iteration, which will appear to the hardware as a
large rx buffer update. Bad things ensue.
The fix is to update the software shadow mailbox member when the special
case path is taken.
Signed-off-by: Matt Carlson <mcarlson@broadcom.com>
Reviewed-by: Michael Chan <mchan@broadcom.com>
Reported-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
(*post_ptr)++;
if (unlikely(rx_std_posted >= tp->rx_std_max_post)) {
- u32 idx = *post_ptr % TG3_RX_RING_SIZE;
- tw32_rx_mbox(TG3_RX_STD_PROD_IDX_REG, idx);
+ tpr->rx_std_prod_idx = std_prod_idx % TG3_RX_RING_SIZE;
+ tw32_rx_mbox(TG3_RX_STD_PROD_IDX_REG,
+ tpr->rx_std_prod_idx);
work_mask &= ~RXD_OPAQUE_RING_STD;
rx_std_posted = 0;
}