From patchwork Tue Jan 13 11:33:22 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Kirsher, Jeffrey T" X-Patchwork-Id: 428338 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 5070C14017F for ; Tue, 13 Jan 2015 22:35:00 +1100 (AEDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752069AbbAMLez (ORCPT ); Tue, 13 Jan 2015 06:34:55 -0500 Received: from mga01.intel.com ([192.55.52.88]:65096 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752266AbbAMLdg (ORCPT ); Tue, 13 Jan 2015 06:33:36 -0500 Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga101.fm.intel.com with ESMTP; 13 Jan 2015 03:33:35 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.07,749,1413270000"; d="scan'208";a="661053050" Received: from rdatta-mobl1.amr.corp.intel.com (HELO jtkirshe-mobl.amr.corp.intel.com) ([10.252.137.138]) by fmsmga002.fm.intel.com with ESMTP; 13 Jan 2015 03:33:35 -0800 From: Jeff Kirsher To: davem@davemloft.net Cc: Mitch A Williams , netdev@vger.kernel.org, nhorman@redhat.com, sassmann@redhat.com, jogreene@redhat.com, Jeff Kirsher Subject: [net-next 06/15] i40evf: don't fire traffic IRQs when the interface is down Date: Tue, 13 Jan 2015 03:33:22 -0800 Message-Id: <1421148811-9763-7-git-send-email-jeffrey.t.kirsher@intel.com> X-Mailer: git-send-email 1.9.3 In-Reply-To: <1421148811-9763-1-git-send-email-jeffrey.t.kirsher@intel.com> References: <1421148811-9763-1-git-send-email-jeffrey.t.kirsher@intel.com> Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org From: Mitch A Williams There is always a possibility that MSI-X interrupts can get lost. To keep this problem from stalling the driver, we fire all of our MSI-X vectors during the watchdog routine. However, we should not fire the traffic vectors when the interface is closed. In this case, just fire vector 0, which is used for admin queue events. As a result, we do not enable the interrupt cause for vector 0. This can cause the admin queue handler to be called reentrantly, which causes a scary "critical section violation" message to be logged, even though no real damage is done. Change-ID: Ic43a5184708ab2cb9a23fca7dedd808a46717795 Signed-off-by: Mitch Williams Acked-by: Shannon Nelson Signed-off-by: Jeff Kirsher --- drivers/net/ethernet/intel/i40evf/i40evf_main.c | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/drivers/net/ethernet/intel/i40evf/i40evf_main.c b/drivers/net/ethernet/intel/i40evf/i40evf_main.c index a21fb88..d55c4a9 100644 --- a/drivers/net/ethernet/intel/i40evf/i40evf_main.c +++ b/drivers/net/ethernet/intel/i40evf/i40evf_main.c @@ -1385,11 +1385,14 @@ static void i40evf_watchdog_task(struct work_struct *work) if (adapter->state == __I40EVF_RUNNING) i40evf_request_stats(adapter); - - i40evf_irq_enable(adapter, true); - i40evf_fire_sw_int(adapter, 0xFF); - watchdog_done: + if (adapter->state == __I40EVF_RUNNING) { + i40evf_irq_enable_queues(adapter, ~0); + i40evf_fire_sw_int(adapter, 0xFF); + } else { + i40evf_fire_sw_int(adapter, 0x1); + } + clear_bit(__I40EVF_IN_CRITICAL_TASK, &adapter->crit_section); restart_watchdog: if (adapter->state == __I40EVF_REMOVE)