From patchwork Thu Sep 17 23:21:54 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: David Woodhouse X-Patchwork-Id: 519074 X-Patchwork-Delegate: davem@davemloft.net Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 3D79E140273 for ; Fri, 18 Sep 2015 09:22:01 +1000 (AEST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752152AbbIQXV5 (ORCPT ); Thu, 17 Sep 2015 19:21:57 -0400 Received: from casper.infradead.org ([85.118.1.10]:38150 "EHLO casper.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751904AbbIQXV4 (ORCPT ); Thu, 17 Sep 2015 19:21:56 -0400 Received: from i7.infradead.org ([2001:8b0:10b:1:21e:67ff:fecb:7a92]) by casper.infradead.org with esmtpsa (Exim 4.80.1 #2 (Red Hat Linux)) id 1ZciV1-0006vG-D8; Thu, 17 Sep 2015 23:21:55 +0000 Message-ID: <1442532114.97487.11.camel@infradead.org> Subject: [PATCH 2/2] 8139cp: Call __cp_set_rx_mode() from cp_tx_timeout() From: David Woodhouse To: netdev@vger.kernel.org Cc: Francois Romieu Date: Fri, 18 Sep 2015 00:21:54 +0100 In-Reply-To: <1442531948.97487.8.camel@infradead.org> References: <1442531948.97487.8.camel@infradead.org> X-Mailer: Evolution 3.16.5 (3.16.5-1.fc22) Mime-Version: 1.0 X-SRS-Rewrite: SMTP reverse-path rewritten from by casper.infradead.org See http://www.infradead.org/rpr.html Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org 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 --- 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(+) 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);