Received: by 10.223.176.46 with SMTP id f43csp1165477wra; Fri, 26 Jan 2018 13:02:25 -0800 (PST) X-Google-Smtp-Source: AH8x2244UBYknnx7AqA6xuVCIffbG3khc9QTsHn53WXdO8Ao5QyRC6KaySEkk5/HCwwyWL/hE5y0 X-Received: by 2002:a17:902:9044:: with SMTP id w4-v6mr15414121plz.354.1517000544902; Fri, 26 Jan 2018 13:02:24 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1517000544; cv=none; d=google.com; s=arc-20160816; b=EF7bn4LMp9izx188An1jOdEvoFVizE7cp53/73fD0JqOo/J6CI6JYTPP9JzKd6HNaK M90VMtDDoBGfEk59QxyuWE+p4AvYImcgadf+hEvdJVHqt7yib0Uhns/ckzJGVmApnwZL 9E8AeeR3n/Jz52Y+xyi+es5A4Buamls+1oKiR4UsHBnO6SjIUzTI6Q6O/g3ayHW+bj41 jLp/FRJsenesaaZESzIlI4mvl6WMC0jFAafStEZ+46FBZqLc5H6qXExj7QMAoDpL3Nhc Z5qGMV+yNvtHU9pnyCUJ632RpAm4cTmr22UfCLivVW/rjg6M1eDbY6izkPGKgLzhpM+l IpjQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=+s1pNsv41wNNVZnN6Ix6WiZo/6/tiOEYbmoN8XZqb8s=; b=NuE1Mb+qenTh3rDF+bwyH5W7R9W+NmfRVNvl7mCBPHTSIQY4E08a05q8G4Pzy+N/2Y PG1J1/RDyn9KUFB25NZetItLbJdn2XpQ0uIvUKIfYByWLJr5Y1/QZ6/RaHPiOIcDzqu+ CXduHx2XW3KiZwyOac+iVWDAkaFfLZj7RGJaKOnGTQJ9+tsRUbtBoxuEwbrWlEc7vHhx GoYG3CJ0inrOruNd7bbvdk/h/I4r6YG/E5s/3fKgQlnVhJDDG6qNqA3Nk+HsyvovXmOu kkKkcn04GXDnpBdYZ++3LQ83VO4o0lTPxiowuAvdfnmWc3pKo3euyhpAFkZhFHxFouHq 4GGg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=Hl0/Z0wO; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d8si6886423pfh.93.2018.01.26.13.02.11; Fri, 26 Jan 2018 13:02:24 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=Hl0/Z0wO; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752201AbeAZVBS (ORCPT + 99 others); Fri, 26 Jan 2018 16:01:18 -0500 Received: from mail-qt0-f193.google.com ([209.85.216.193]:43950 "EHLO mail-qt0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751561AbeAZVBO (ORCPT ); Fri, 26 Jan 2018 16:01:14 -0500 Received: by mail-qt0-f193.google.com with SMTP id s3so4588930qtb.10; Fri, 26 Jan 2018 13:01:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+s1pNsv41wNNVZnN6Ix6WiZo/6/tiOEYbmoN8XZqb8s=; b=Hl0/Z0wOi2doZ5tDCSP0u3JMWzX7viTcMS/5XdsMMntoWu6HQs+cOoriM7vYn9lS+h M9xkAe4DTeqLex+XP7JlH4wY0DoUhk9YXbZMX0eFfyUxc2K2wPij9vt3vidSpi4m40iF s7c4arYtO/I2prj7oRi/pujwsTFbR4B16mlvcMv9JsbMEtGFLUUVwwUq1XS9po3j+KuX 1sakIlQ7FxbZLjINBOFJjoqAibbKRsAwjiPmp3DS0BWYPZILF+bG3nK4xjg9ovnPXnDH qjSK9gaHewBjk1PozdLZDo9hX69RGqL/XuHPYGbCeqx9LacQfjQQmDqaAY2KvukbvTHY Vwcw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+s1pNsv41wNNVZnN6Ix6WiZo/6/tiOEYbmoN8XZqb8s=; b=adNMWMa3lX+NrHG4iDNIOmswJuJoPPaPp3HT3o+7aPyMZEMUsq2YL+pUXZ+5ypuToK HQZtsWkxPIRsit8zW+9n13/jR9LxDBjuxdCMDh1+VqSeuOBdVyamlGv7XiPwkx8czGl7 s9YcYz+Gm+wDFIktHBBHLM6Ck0JIpyOtZ1CFx38t8OOanLyskCr5YeB/5J/fcIQeahE8 SFMJcRY7Y/DNoRYhxla+QZQr110xBwUpFmfdxN1qj8fJy2yUutNDe4PXQBZUu9Xi0T9o TAobA2mYoQRfuqE4GSVHTrZOh89p+JNSIZDv7BTWZqKlNQyLRlrUC+Fy58MxHUlMDLvz sH/w== X-Gm-Message-State: AKwxytelMiurzAAiFjYY/OLVWqCRQq1gNLZHySF7GIHIxPgcppervrzX VUuh/GDqjHFUZl91GOlA3zlbIYa7VzEb+nwQUhs= X-Received: by 10.55.135.70 with SMTP id j67mr23155315qkd.34.1517000472561; Fri, 26 Jan 2018 13:01:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.89.199 with HTTP; Fri, 26 Jan 2018 13:01:11 -0800 (PST) In-Reply-To: <20180126091236.13044-4-bpoirier@suse.com> References: <20180126091236.13044-1-bpoirier@suse.com> <20180126091236.13044-4-bpoirier@suse.com> From: Alexander Duyck Date: Fri, 26 Jan 2018 13:01:11 -0800 Message-ID: Subject: Re: [PATCH 3/3] Revert "e1000e: Do not read ICR in Other interrupt" To: Benjamin Poirier Cc: Jeff Kirsher , intel-wired-lan , Netdev , linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jan 26, 2018 at 1:12 AM, Benjamin Poirier wrote: > This reverts commit 16ecba59bc333d6282ee057fb02339f77a880beb. > > It was reported that emulated e1000e devices in vmware esxi 6.5 Build > 7526125 do not link up after commit 4aea7a5c5e94 ("e1000e: Avoid receiver > overrun interrupt bursts"). Some tracing shows that after > e1000e_trigger_lsc() is called, ICR reads out as 0x0 in e1000_msix_other() > on emulated e1000e devices. In comparison, on real e1000e 82574 hardware, > icr=0x80000004 (_INT_ASSERTED | _LSC) in the same situation. > > Some experimentation showed that this flaw in vmware e1000e emulation can > be worked around by not setting Other in EIAC. This is how it was before > commit 16ecba59bc33 ("e1000e: Do not read ICR in Other interrupt"). > > Since the ICR read in the Other interrupt handler has already been > restored, this patch effectively reverts the remainder of commit > 16ecba59bc33 ("e1000e: Do not read ICR in Other interrupt"). > > Fixes: 4aea7a5c5e94 ("e1000e: Avoid receiver overrun interrupt bursts") > Signed-off-by: Benjamin Poirier > --- > drivers/net/ethernet/intel/e1000e/netdev.c | 10 ++++++++-- > 1 file changed, 8 insertions(+), 2 deletions(-) > > diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c b/drivers/net/ethernet/intel/e1000e/netdev.c > index ed103b9a8d3a..fffc1f0e3895 100644 > --- a/drivers/net/ethernet/intel/e1000e/netdev.c > +++ b/drivers/net/ethernet/intel/e1000e/netdev.c > @@ -1916,6 +1916,13 @@ static irqreturn_t e1000_msix_other(int __always_unused irq, void *data) > struct e1000_hw *hw = &adapter->hw; > u32 icr = er32(ICR); > > + /* Certain events (such as RXO) which trigger Other do not set > + * INT_ASSERTED. In that case, read to clear of icr does not take > + * place. > + */ > + if (!(icr & E1000_ICR_INT_ASSERTED)) > + ew32(ICR, E1000_ICR_OTHER); > + This piece doesn't make sense to me. Why are we clearing OTHER if ICR_INT_ASSERTED is not set? The original code that was removed was in commit 4d432f67ff00 "e1000e: Remove unreachable code" was setting IMS and returning, not clearing the ICR register. I would argue that the code is probably unreachable and if we just have the checks for OTHER and LSC then we should be taking care of all of this in the task anyway. All this code the code in the original was doing was re-enabling the interrupt via IMS so we probably don't need this bit as long as we are clearing OTHER and LSC when they are set so that we can get future interrupts. > if (icr & adapter->eiac_mask) > ew32(ICS, (icr & adapter->eiac_mask)); > > @@ -2033,7 +2040,6 @@ static void e1000_configure_msix(struct e1000_adapter *adapter) > hw->hw_addr + E1000_EITR_82574(vector)); > else > writel(1, hw->hw_addr + E1000_EITR_82574(vector)); > - adapter->eiac_mask |= E1000_IMS_OTHER; > > /* Cause Tx interrupts on every write back */ > ivar |= BIT(31); > @@ -2258,7 +2264,7 @@ static void e1000_irq_enable(struct e1000_adapter *adapter) > > if (adapter->msix_entries) { > ew32(EIAC_82574, adapter->eiac_mask & E1000_EIAC_MASK_82574); > - ew32(IMS, adapter->eiac_mask | E1000_IMS_LSC); > + ew32(IMS, adapter->eiac_mask | E1000_IMS_OTHER | E1000_IMS_LSC); > } else if (hw->mac.type >= e1000_pch_lpt) { > ew32(IMS, IMS_ENABLE_MASK | E1000_IMS_ECCER); > } else { > -- > 2.15.1 >