| Message ID | 1442532114.97487.11.camel@infradead.org |
|---|---|
| State | Accepted, archived |
| Delegated to: | David Miller |
| Headers | show |
-- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
From: David Woodhouse <dwmw2@infradead.org> Date: Fri, 18 Sep 2015 00:21:54 +0100 > Unless we reset the RX config, on real hardware I don't seem to receive > any packets after a TX timeout. > > Signed-off-by: David Woodhouse <David.Woodhouse@intel.com> Applied. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sun, 2015-09-20 at 22:24 -0700, David Miller wrote: > From: David Woodhouse <dwmw2@infradead.org> > Date: Fri, 18 Sep 2015 00:21:54 +0100 > > > Unless we reset the RX config, on real hardware I don't seem to > receive > > any packets after a TX timeout. > > > > Signed-off-by: David Woodhouse <David.Woodhouse@intel.com> > > Applied. Thanks. I'll send another batch, including the original patches 3/2 and 4/3 from this series, in reply to this message. After which, I think we might be able to turn on TX checksumming by default and I also have a way to implement early detection of the TX stall I've been seeing.
diff --git a/drivers/net/ethernet/realtek/8139cp.c b/drivers/net/ethernet/realtek/8139cp.c index 52a5334..ba3dab7 100644 --- a/drivers/net/ethernet/realtek/8139cp.c +++ b/drivers/net/ethernet/realtek/8139cp.c @@ -1261,6 +1261,7 @@ static void cp_tx_timeout(struct net_device *dev) cp_clean_rings(cp); rc = cp_init_rings(cp); cp_start_hw(cp); + __cp_set_rx_mode(dev); cp_enable_irq(cp); netif_wake_queue(dev);
Unless we reset the RX config, on real hardware I don't seem to receive any packets after a TX timeout. Signed-off-by: David Woodhouse <David.Woodhouse@intel.com> --- Now it does actually recover from the TX timeout, lots of the time. Sometimes it still hits that IRQ storm, which probably explains the apparent lockup right after the 'popf'... although I thought we handled it more gracefully than that these days. That's probably a race with the RX handling code, or something. I'll try harder to reproduce the TX timeout with the debugging enabled. Which might shed some light on this, and also on the reason why it happens in the first place. If we're lucky. drivers/net/ethernet/realtek/8139cp.c | 1 + 1 file changed, 1 insertion(+)